Qt Quick vs. Android XML Layouts

Qt Quick vs. Android XML Layouts

In the last month and next couple of weeks we were/are developing a similiar application for Android, iPhone and the Desktop (using Qt and Quick) with native technologies. I will focus on Android and Qt as both are Open Source and we were developing them in a similiar fashion with one designer and one developer interacting with each other.

In both cases the application has a couple of views mainly consisting of a ListView of some sort and I will explain how this has been realized for Android and then with Qt Quick and provide some summary of what has worked well, what Qt Quick could learn from that. I have not worked with Qt Quick or Android prior to this project so I might have used the technology in the wrong way, and at your option you can either hold this against me or the technology.
We have started the project by doing the Android application. The model for my data is based on the abstract class called android.widget.BaseAdapter and I needed to implement a couple of functions. The first is the answer how many items I have, return an Object at the given position, an identifier for a position and finally a function that creates a View.
This function is called getView(int position, View convertView, ViewGroup parent) and the common usage is to check if convertView can be used to display the item at position and then modify (e.g. set the iccon, text, hide things on that view) otherwise we were using the LayoutInflater to create a View from one of the pre-defined layouts and set the items.
In Android one can describe Layouts in a XML Document, or use a still very basic Layout Designer (that will mess with the indenting of the XML), one unique feature is one can have different layouts for different properties, e.g. one can create a layout that will be only displayed if the application is in Landscape, uses Docomo as Operator and more. This is a very powerful system and we have only used it to have different layouts in portrait/landscape so far. The next important thing is one can ask the LayoutInflater to create the View for a given identifier, the next part is to find the items inside that view. Each View has a method called findViewById that is searching the children for that id.
One common pattern is to not call findViewById everytime one needs to access a widget but create a ViewHolder class with references to the Views and use View.setTag(Object tag) on the top View to set that ViewHolder on the View.
So how did the Designer and Developer interaction work here? First of all the Designer was responsible to create the View for the various parts of the UI and I was responsible for creating that BaseAdapter derived class, implement the getView method and set the right text/icon/visibility on the items of the layout based on the item that is to be displayed.
How did that work? In general it worked great, I could create a UI that worked, the Designer could make it look nice, the biggest problem (besides the basic UI editor, fighting with the RelativeLayout class) is that during redesigning a layout id’s were dropped from the Widgets and I had to assist the Designer to identify the missing IDs and add them back to the Design to keep things working and display the right thing again.
The Quick project is still work in progress and a lot like the Android project, the Developer creates the code (or states and interaction) and the Designer makes it look good. Our ListView’s are backed with classes based on QAbstractListModel (using setItemRoles to export the roles as QString) and the designer is forced to edit the files by hand right now.
The thing that really works better with Qt Quick is that the delegate (equivalent to the getView in Android) is in the hand of the Designer. This means that the Developer only needs to export the right strings for the roles from the model and the designer can use that to create the UI.
From my point of view the Qt Quick approach is really superior to Android’s XML Layout system, with Qt Quick we could get started faster by having a full click dummy (create the ListModel and fill it with dummy data), allowing the designer to fill the UI with content from the first day of the project, and by having the delegate in the Designers hand we have no “losing” id’s in the diff of an unformatted XML Stream. The only thing that has no proper equivalen in QML/Quick is basing the state on external properties, or with other words, I have not seen any documentation for some basic system/device properties.
Comments are closed.