It looks like this was mentioned years ago in the forum, but not recently, so I thought I would ask again:
I am looking to wait until all of my images are loaded before moving forward in the app, but it looks as though display.newImageRect is non-blocking, so I am hoping there might be a way to determine if everything is loaded first… Any suggestions would be helpful.
Thanks, Allen
can you explain more in detail as what order do you want your app to load?
I think display.newImageRect _is_ blocking … it won’t return control to your program until the image is loaded from memory and displayed.
Are you using a URL as the filename? I’ve never tried that but I’ve assumed it won’t work (i.e. the filename has to be local)
Take a look at display.loadRemoteImage … it has a listener/callback function.
I usually load the files locally, haven’t played much for loading remote images. Basically, do you want all of the images to load first, then the app can start for listening touch? or do you want the app to be able to react even if the images are still loading?
Usually, I create a method to hold all touch listeners using native.setActivityIndicator to check whether all functions are loaded properly. use false to negate all touch activity, and at the end of your chunk code, set again to true to ‘unlock’ the screen.
is that what you wanted to do?
Sorry, I should have been more specific… it looks as though the actual code is non-blocking, but the images are not done loading by the time I start using them, since I don’t know of a way of determining when they are done. Although I don’t get any errors when I use the new images, for example moving them, they are popping in while the objects are already in motion.
The other older context in the forums I saw was for loading bar, where the person wanted to put up a loading bar while the images are actually loading, showing progressive movement as they loaded.
If this is not the behavior other people are seeing, as in their apps are freezing completely until an image is loaded then proceeds to the next line, let me know, since its entirely possible I have issues with my other parts of the code causing this behavior.
Thanks in advance, Allen
can you give screenshots? have you tried your app yourself in real devices? sometimes animations, transitions doesn’t work like it should be on simulator. If you don’t organize your code well between loading images assets and doing movements, touch listeners, it can go scrambled, and give unexpected results.
to prevent app to receive listeners, as I said before, is by far the best method i know is to use the native.setActivityIndicator to false, to prevent any animation before any other code is done in one file. you have to count the approx. time to prepare for all your assets finished loading, and then create a callback function to return native.setActivityIndicator back to true, and your app should ready for given any listeners, or any transitions.
@jonathan.simananda I was trying to avoid using a “guestimated” time on the block, as recommended in the older thread. Since starting this thread, I’ve reworked some of the code, like using smaller proxy version of the images instead of the full resolution images, which seems to have help dramatically, so I think the issue has been resolved for now. Thanks for your help and suggestions.
can you explain more in detail as what order do you want your app to load?
I think display.newImageRect _is_ blocking … it won’t return control to your program until the image is loaded from memory and displayed.
Are you using a URL as the filename? I’ve never tried that but I’ve assumed it won’t work (i.e. the filename has to be local)
Take a look at display.loadRemoteImage … it has a listener/callback function.
I usually load the files locally, haven’t played much for loading remote images. Basically, do you want all of the images to load first, then the app can start for listening touch? or do you want the app to be able to react even if the images are still loading?
Usually, I create a method to hold all touch listeners using native.setActivityIndicator to check whether all functions are loaded properly. use false to negate all touch activity, and at the end of your chunk code, set again to true to ‘unlock’ the screen.
is that what you wanted to do?
Sorry, I should have been more specific… it looks as though the actual code is non-blocking, but the images are not done loading by the time I start using them, since I don’t know of a way of determining when they are done. Although I don’t get any errors when I use the new images, for example moving them, they are popping in while the objects are already in motion.
The other older context in the forums I saw was for loading bar, where the person wanted to put up a loading bar while the images are actually loading, showing progressive movement as they loaded.
If this is not the behavior other people are seeing, as in their apps are freezing completely until an image is loaded then proceeds to the next line, let me know, since its entirely possible I have issues with my other parts of the code causing this behavior.
Thanks in advance, Allen
can you give screenshots? have you tried your app yourself in real devices? sometimes animations, transitions doesn’t work like it should be on simulator. If you don’t organize your code well between loading images assets and doing movements, touch listeners, it can go scrambled, and give unexpected results.
to prevent app to receive listeners, as I said before, is by far the best method i know is to use the native.setActivityIndicator to false, to prevent any animation before any other code is done in one file. you have to count the approx. time to prepare for all your assets finished loading, and then create a callback function to return native.setActivityIndicator back to true, and your app should ready for given any listeners, or any transitions.
@jonathan.simananda I was trying to avoid using a “guestimated” time on the block, as recommended in the older thread. Since starting this thread, I’ve reworked some of the code, like using smaller proxy version of the images instead of the full resolution images, which seems to have help dramatically, so I think the issue has been resolved for now. Thanks for your help and suggestions.