Make sure you have more objects in the scroll than it is tall.
Use placeholder fills (like a 16x16 transparent image) for off-screen objects.
Detect the drag portion of the interaction and detect whether more objects will be needed before the finger is released and momentum takes over. If so, add objects then.
Following these steps will ensure you don’t run out of elements to show, you don’t waste memory on fills for offscreen objects, and you don’t stop the momentum part of the scroll.
Also, don’t forget you can download and modify the widget library to suit your needs.
I forgot to mention that what populates the list are images from the loadRemoteImage callback, in batches of 50 small images.
When they are created, I insert them into the list as they arrive.
Of course I can wait until all are downloaded and insert all in a loop but whichever way i do this, the resizing of the scrollView halts the slowdown momentum.
Point 1 is given but to my knowledge, I cant use a placeholder and then replace it with a different object since i’d have to insert the new one anway after destroying the old, and scrollView will always recalculate heigh (in my case) when an object is inserted. Or am i wrong?
Point 3 is gonna be hard as I do not know when the images will be finished loading.
What i’ve done as an alternative solution to keep scrolling smooth is that once the scroll reaches the end, it freezes, pops a loading tag, and once all is downloaded and checked, removes the tag and unlocks for forther scrolling.
It works quite well, albeit not exactly how I wanted in the first place.
Note: If you want to till the scroller on the fly from remote images whose size you do not know and you also want those images to be shown full sized, then this will be a bit harder, but probably not impossible.
However, that sounds like bad design to me. I’d change the design so that all images must be displayed at a uniform size, even if that means you scale and or clip parts of the image when it arrives.
In this case, a little uniformity in the design rules will help a lot.
cut my code down to bare minimum to figure this out and found that the culprit to this hick-up is that i do my progressive preload check in the scrollView event which only fires when finger is on the board. The release slow down scrolling does not fire any events.
I’ll fix this with a enterFrame runtime check instead tomorrow. it should work.
In my case the rect fill doesn’t work as I have lots of text objects and filters. Plus doing dynamic insert/remove saved over 70MB RAM so it was win/win.
Read the post you linked to and wonder if you’d mind sharing the improved dynamic load/unload version of this script that you fixed? It’s exactly what i’m looking for.
If not, thats fine too, just want to know before I “get to it”.
downloaded the script from github, removed the line in question, and tried to require it and use it, but it seems i’m too inexperienced to get it to work in my code.
all i need is to get rid of that pesky line that stops the scrolling.
any pointers is appreciated as to how i setup/use the modified script
There are some internal referencing issues that need addressing if I remember correctly - check all the requires have valid paths. This will depend on how you have the project physically laid out.
It seems I have not choice but to try and solve this somehow.
This link describes the problem and the fix, but I need someone more skilled to either help me or guide me on how to do it, as my feeble attempts remain unsuccessful. I am able to edit the error but not to execute/use it.
Comment out or remove line 438, which looks like this: “self:scrollToPosition( { x = origX, y = origY, time = 0 } )”
Save the lua file and copy it to the root of your project.
Scrolling should now work perfectly without changing anything in your own lua code.
I am not entirely sure why this works, but I am guessing that when the widget code looks foor lua files, it defaults to the root directory, and as such overrides the old file with the new edited one.
This problem/bug needs to be fixed by Corona with a simple deactivate option to accommodate all users and uses.
I’ve spent almost a week in frustration trying to work around and/or fix this, and frankly, official support could have been better.
Anaqim
UPDATE!!!
It seems this is not fixed after all and I am at loss what to do.
The above solution works with a win32 build but not in the simulator, nor on android.
I’m pretty sure the local copy of the lib is NOT getting used.
Simply dropping it in the root folder isn’t enough. The widget library preloads the first time it is required, and you have to do some specific things to get your local changes to be used.
PS - Please don’t vent on the staff. I realize you may be frustrated, but lets be clear. Their time is worth gold. While your week spent has probably been educational. Additionally, this feature may not be so universally useful to warrant adding it to the standard builds.
Finally, features are not changed based on posts in the forums except on rare occasions. There are two ways to get changes into Corona:
File a bug using the bug link.
File a feature request.
PPS - Don’t forget. Time is money for us all. I and others try to help a little for free, but this goes against time we could spend making money. I personally offer a paid service for situations exactly like this, where more help is required than I can afford to give for free.
This may seem simple “to fix” but we were going through it last night and there are lots of potential ramifications to removing that line. No-one likes “fixes” breaking their existing code.
You really are better of customising the widgets library to your implementation as this will certainly be quicker. I’d recommend you let Ed (aka roaminggamer) help you with this as unfortunately I am far too busy.
A horizontal tableView would be the answer and I am pushing for this, but again this is not going to be anytime soon.