Appearance:
When loading more big images than fits into one screen, sliding across list is not fluid.
Problem:
Resizing big images (like 3000x6000 px) takes place on the main thread and blocks UI from being responsive.
Generalization:
There will always be images of that size that will harm UI fluidness.
Solution:
Put resizing into separate thread (async, non-main thread). To do that I did experimentally split RemoteImageLoadingStatesuccess state into two: successLoaded and successScaled. This way when image is retrieved (from Web or locally) it is only scheduled for resizing i.e. its processing is not completed yes. Only after image had been recalled (on non-main thread), it is marked as 'successScaled' (previously success and is ready to be displayed onscreen.
Additionally, framework could resize image and save on disk resized version, not original. That would save even more space/time.
Appearance: When loading more big images than fits into one screen, sliding across list is not fluid.
Problem: Resizing big images (like 3000x6000 px) takes place on the main thread and blocks UI from being responsive.
Generalization: There will always be images of that size that will harm UI fluidness.
Solution: Put resizing into separate thread (async, non-main thread). To do that I did experimentally split
RemoteImageLoadingStatesuccessstate into two:successLoadedandsuccessScaled. This way when image is retrieved (from Web or locally) it is only scheduled for resizing i.e. its processing is not completed yes. Only after image had been recalled (on non-main thread), it is marked as 'successScaled' (previouslysuccessand is ready to be displayed onscreen.Additionally, framework could resize image and save on disk resized version, not original. That would save even more space/time.