I recently had the opportunity to switch a client app over to making use of the (relatively) new Titanium ListView. The ListView is a high-performance UI element designed to display templated sets of data in an ordered fashion, making use of some arcane optimizations that I can only assume involves black magic to beat out the performance of a table view by an order of magnitude. Coming from TableViews, the switch over to ListViews was somewhat jarring, differences in view structure, event structure, and the unique quirks of these view elements made the transition a somewhat challenging process. Here are a few interesting things I learned in the process.
Everything is structured.
Everyone has a few guilty little lapses in structure when making an app. Why bother redesigning a view for one specific case when I can just add the new view elements at run time? ListViews will have no part of that. Each template has a static set of views, and after creation, the elements in a given row are unchanging. The only way to change the information contained in a row is to push a new data object to the row, and the only way to add another view element is to modify the template. This requires a rather significant shift in how you develop for list views, as ad-hoc development and spaghetti code just doesn’t work with list views.
There are no row events. Only list events.
This was one of the most distinct differences in developing for ListViews as opposed to TableViews. Where Table views expose all of the events available to their child elements to you, ListViews expose a solitary ‘itemclick’ event. As the name suggests, this event is triggered when the user clicks on an individual list item. From there, you need to sort out what to do with the individual item, figure out which subview triggered the event, and proceed from there as you would with any click event.
Quirks, limitations, and tradeoffs
One major consideration with using a ListView is that they are in active development, and as such have a number of quirks and limitations, not all of which are documented. At one point, I had been debugging an app crash that produced no error messages and realized that simply changing the bindId of one of the subviews of a template fixed it completely. Additionally, there are a number of little styling quirks (for instance, you can’t presently style the separator color or the section header/footer), and an I mentioned earlier you cannot change the contents of a row without rebuilding and replacing it. As with all new view elements, you need to weigh these drawbacks against the benefits before you’ve spent the better part of a week developing with a view element that just won’t work.
The benefits
The core benefits of list views are, as I see it, performance and maintainability. The forced structure of list views require you to declare all of your view elements upfront, to run all of your events through the same functions, and structure all of your data in the same way, making a well designed ListView much easier to understand and maintain than an equally well designed TableView. Additionally, the performance isn’t even comparable. Before switching over to ListViews, we were lucky to get twenty items into our lists. Now, we can easily load more than 500 at a time. That kind of performance difference speaks for itself.
Sign up for the Shockoe newsletter and we’ll keep you updated with the latest blogs, podcasts, and events focused on emerging mobile trends.