I have been developing for roku for several months now and one thing still boggles my mind.
Why name a method AsyncGetToFile if it is truly not Asynchronous? If i have to create a message port and put a wait timer on it for a message to appear then this is not Asynchronous at all. Why didn’t the developers at roku think that it would be a good idea to allow image loading straight to an object and then it would appear whenever it was loaded? Am I completely lost or does the Roku Development team not know the meaning of the word Asynchronous. I develop for applications with iOS, Android, C#, and Java and never have run into a programming language that is as horrible as brightscript.
If anyone has a truly Asynchronous way to download images, please enlighten me.
The async methods are asynchronous in that they don’t block execution while they are downloading. If you share your message port across components, then you’ll get notification of the download completing without having to block processing of other messages. For images, roTextureManager handles asynchronous downloading.
I have to create a roURLTransfer object to get this image to a file and store in the “tmp:/” directory. My company is a streaming content provider much like netflix. So we have different channels and libraries with different arrangements of content. If I am trying to return a Bitmap using the roTextureManager then to assign that bitmap to a unique image location I have to create a msg port listener which will block the UI thread of moving objects on the screen.
One would think that you could create a listener object that would just listen and do work in the background and load to appropriate location when completed.
Instead I have to do something like
mgr.RequestTexture(request)
msg=wait(0, msgport)
if type(msg)="roTextureRequestEvent" then
state = msg.GetState()
if state = 3
bitmap = msg.GetBitmap()
if type(bitmap)<>"roBitmap" then
'print "Unable to create robitmap"
else
'print "There was great success"
end if
end if
end if
If you don’t use the wait function then you will never get the image.
And if the messagePort is a global port and it gets a message for the imageRequest completing then subsequent code will block even if user is pressing buttons because it is on the same msgPort
Why would you not design this language to keep the UI Controls and Data Management explicitly on separate threads?
“Travonisoft” wrote:
If you don’t use the wait function then you will never get the image.t
Not true. Use different ports for the texmanager and the UI, listen for the texmanager events in the UI loop, and use port.getmessage() not wait.
“Travonisoft” wrote:
I have been developing for roku for several months now and one thing still boggles my mind.
Why name a method AsyncGetToFile if it is truly not Asynchronous? If i have to create a message port and put a wait timer on it for a message to appear then this is not Asynchronous at all. Why didn’t the developers at roku think that it would be a good idea to allow image loading straight to an object and then it would appear whenever it was loaded? Am I completely lost or does the Roku Development team not know the meaning of the word Asynchronous. I develop for applications with iOS, Android, C#, and Java…
Hmm, i in turn am puzzled how come you’d be developing for “iOS, Android, C#, and Java” yet never grasped the concept of synchronous vs asynchronous API. A synchronous call is a blocking call - you make the request - your thread execution stops right there awaiting result - and when the call returns, you got the data or success/fail code. An asynchronous call on the other hand will not block the caller (returns right away) - and if you expect some result from it, you either get a handle you can poll at will - or provided a callback function - or will receive a message when it is done. Which is the case with AsyncGetToFile, it is asynchronous.
… and never have run into a programming language that is as horrible as brightscript.
You are right but on a technicality only - one won’t run into a language that is exactly “as horrible” as B/S. You’d find some languages that are less horrible yet many that are more horrible. Looking for exact match in “horribleness” is like comparing float/doubles for == equality. Somewhat more seriously, B/S i pretty decent language, i would’s cluster it somewhere with Perl and Tcl. And as subjective opinions go, i’d say Java the Hutt is much more horrible
Why is there a function AsyncGetToFile(), when said function will not place that file in the temp directory without handling a message from a messagePort?
Shouldn’t it place that file straight into the tmp:/ directory without me having to handle a message.
“Travonisoft” wrote:
If you don’t use the wait function then you will never get the image.
And if the messagePort is a global port and it gets a message for the imageRequest completing then subsequent code will block even if user is pressing buttons because it is on the same msgPort
It sounds like you don’t understand how message ports and event loops are meant to work. a) You’re telling the texture request to block, because you’ve passed 0 into your wait(). If you set that to something higher than 0, then it will only block for the length of time (in milliseconds) you pass in. If you don’t want to block at all, then you can pull a message directly by calling msgport.GetMessage() which will return immediately with “invalid” if there is no message ready. b) Why do you think your code will block after you get the roTextureRequestEvent?
Why is there a function AsyncGetToFile(), when said function will not place that file in the temp directory without handling a message from a messagePort?
Shouldn’t it place that file straight into the tmp:/ directory without me having to handle a message.
It does exactly that. The message on the message port is just to let you know when the operation is complete (or if it failed). If you don’t listen for it, the image will still get saved to tmp:/. If it’s not, then I’d bet you’re letting the roUrlTransfer go out of scope before the operation completes. Doing so will cancel the request.
So if this is the case, and I have 30+ images to load would you recommend having a pool of roURLRequestTransfer objects that I create and then alloc use for one for each image needed whenever I need?
“EnTerr” wrote:
You are right but on a technicality only - one won’t run into a language that is exactly “as horrible” as B/S.
Oh gawd, I’m working an info booth right now but I couldn’t help a little nerdy lol at that one :mrgreen:
On a more serious note, I’m reading this thread with interest because I need to learn more about this process and how it really works myself. So thanks for the answer and explanations
“Travonisoft” wrote:
So if this is the case, and I have 30+ images to load would you recommend having a pool of roURLRequestTransfer objects that I create and then alloc use for one for each image needed whenever I need?
If they all need to be downloaded asynchronously, then you’d either need to create a separate request for each, or create a block of 5-10 that you re-use after the previous transfer completes.
“EnTerr” wrote:
You are right but on a technicality only - one won’t run into a language that is exactly “as horrible” as B/S. You’d find some languages that are less horrible yet many that are more horrible. Looking for exact match in “horribleness” is like comparing float/doubles for == equality. Somewhat more seriously, B/S i pretty decent language, i would’s cluster it somewhere with Perl and Tcl. And as subjective opinions go, i’d say Java the Hutt is much more horrible
I just looked and there doesn’t seem to be Wikipedia page for the VS.H.Q*. There’s some homework for you EnTerr.
“as horrible” as B/S. You’d find some languages that are less horrible yet many that are more horrible. Looking for exact match in “horribleness” is like comparing float/doubles for == equality. Somewhat more seriously, B/S i pretty decent language, i would’s cluster it somewhere with Perl and Tcl. And as subjective opinions go, i’d say Java the Hutt is much more horrible
