Hi there, fellow developers!
We’re happy to announce our complete framework for implementing a highly customizable ListView/GridView/TableView, or optimizing your already-existing, ScrollRect-based one.
Useful for chat systems, leaderboards, inventories, view pagers, spinners, and actually for any kind list you can think of.
Then please provide a full width/height list demo, because all the list assets out there work when they are not covering whole screen area just like your example.
Make your list cover whole screen area, and provide a demo , an apk and you got a new customer
Didn’t fully understand the “full width/height list” part(if you’re saying the scrollviews should be fullscreen, that would imply we must have a toggle that shows either the horizontal or the vertical view, which would complicate further the demo), but we’ll make the vertical scrollview in the first page cover the whole screen height, so it’ll be the same as the one in the second page (the default mehod). And it’s a great idea to give an actual APK as a demo. Here you go > https://www.dropbox.com/s/xm533zn8h4apgb2/ScrollRectItemsAdapter8 v2.0 - demo.apk?dl=0.
And we’ll put a link in the asset store for this apk as well when the next update comes (shortly). This link will be also updated regularly.
PS: we’re also working on a new video that’ll show the implementation steps one by one. So it’ll be both a demo and a tutorial.
Thats what i mean full height width http://applenapps.com/wp-content/uploads/2013/12/twitter_6_1.jpg
As you can see Twitter List is covering whole screen height width except header and footer. secondly each item height is based on content, and thirdly its quite complex item.
We are currently developing exact same List with NGUI, and NGUI is ultra fast, but we prefer a NewUI based plugin so we have the flexibility to use NewUI related stuff like TextMeshPro, Image/Raw Image related stuff etc.
So please provide an APK like twitter list (with hardcoded data ofcourse) but this demo show both handling of images and variable height, and if it works well on my device, ill buy it immediatly even without source code.
I just checked the demo and i started to have hope that it can be used but then i changed to variable item height and then it started to lag, it doesnt smoothly scroll with variable height and now im 100% sure that it wont scroll well with when you create above example.
Of course it’s slower with variable sizes, but it shouldn’t be way slower, as you describe it. You’re doing something wrong, or seeing it wrong. I don’t notice a FPS difference between having 10, 100, 1000, 10000 items, variable sizes or not. And also take note that in the demo app there are 2 scrollviews (horizontal and vertical) at the same time, so the performance is a bit slower than usual. If you say that the scroll view looses it’s inertia(doesn’t continue scrolling and decelerate after you released the click/finger), that’s natural - it’s the content’s size that’s too big that causes this. Too small of an issue to work on it now. But you really need to have like >1000 items for this to happen, and at that point, you should re-design your app’s logic (i.e. do pagination). Also note that the prefab used there is a quite complex one (it has 14 children - just to cover the worst-case scenario), while you’ll usually have 1-2 texts, and 2-3-4 images => 4-7 children.
I can guarantee you can’t go faster than this. We used this asset for ourselves and continue using it. If we would’ve found what we needed in the asset store, we would’ve bought it and didn’t bother making our own optimizer from scratch. We squeezed every bit of performance from it. Trust me.
PS: sources will be out for v2.1 - the package submission is in review
Edit: v2.1 is out (+ fixes/improvements)
Alright, i really love you to prove me wrong because i personally dont want to plugin NGUI based List inside New UI, so if you can make a twitter example list with hard coded data with variable size (still 1 list in whole screen) and provide APK, then it will prove whether it can be used in production app or not.
The APK linked above exposes all the features you can ask for in this asset. Did you tried it?
Sorry, but another APK is really redundant… it doesn’t matter if it’s half of the screen or not… it should work anyways. The optimizer only helps you recycle unseen items behind the scenes. You’re setting the size/position at edit time as per your design document.
PS: You have my word that this is and will be a serious asset with constant improvements and that it’s implemented with both large and small projects in mind - especially the former
You can simulate a lot of scenarios using a “row” item prefab, a basic grid layout included. your items can be arbitrarily complex, arbitrarily wide/tall.
Can’t understand your second question, though. the items are parented to the Content game object of the ScrollRect. they are enabled/disabled/repositioned/updated during the scrolling (thus, recycling) process.
You can read on the section Simple Scroll View element pooling that this approach have hiccup when setparent object to empty one that scrolled and be visible.
A second solution more complex is to use Position-based Scroll View pools . In this implementation you will move transform instead of parenting it.
From the beginning, we’ve targeted the most optimal way of pooling the items (that we were aware of at that moment) in order to increase the maximum number of items it could handle. We’re talking about 100k-300k items of avg complexity (demonstrated in the demo video on the asset’s page) - we thought more than this amount would be overkill and usually if someone needs to display so much items without paging, it smells as a bad design in the first place. In a very, very small nutshell, it’s similar to “Position-based Scroll View pools”. Item parenting is only done when that item is instantiated. If it’s not visible, it will be disabled. If it goes too far outside (usually happens with variable-sized items or in the case of dynamically resizing the scrollview’s viewport (or the scrollview itself) to a smaller height/width), it’s destroyed, to obey our rule: the total number of instantiated items is number of visible ones + 1.
But in the upcoming version this will improved further in the case of variable sized items, so that the number of destruction events will be reduced even more.
We’re actively improving/extending the optimizer and we’re trying to implement as many feature requests from you as we can. For example, the next version will have a ScrollTo, SmoothScrollTo and RequestChangeItemSize methods. The last one allows you to request a new height(or width, in case of a horizontal ScrollView) for a specific item if it’s visible - this can optionally be done for consecutive frames in order to obtain an expand/collapse animation, which is very common.
I think it will be great to use Interface and Abstract class to represent Data and Item.
I have a base Class that inherit from another one and I cannot annd your ViewHolder base class.
Edit: Ok that’s because I have not well understand how to use it. I will add an holder class with an instance of my Item. Alongside a BaseParams class for holding what to see.
Right. A “row prefab” is the way to go in this case (assuming you have a (edit: sorry, I meant vertical) vertical ScrollView). So now the prefab used for an item in the ScrollView won’t represent an individual data model, but a ROW containing 0 or more data models. You’ll need to manage it yourself, depending on your particular requirements
