The data model:

• must be aware of the data being viewed and need only monitor that data for changes.
• must allow optimal retrieval of data from storage and optimal exposure to QML.
• allows threaded retrieval of data
• "rows" in the model must have an associated type. The type could be used to select a delegate when multiple alternatives are provided.
• the view could provide hints to the model, such as the direction of movement
• for performance reasons, only some data may be available immediately. Other data could be provided later as it becomes available.

• the view must be able to cancel an incomplete request if the data is no longer needed. This is common in a quickly flicked list with threaded retrieval from a slow source.

• allow typed roles. QML can optimize when the type is known.
• consider hierarchical models
• consider sorting models - current models have persistent indexes to help tracking items when they're sorted.

We must also allow others to write views and use our models. This is impossible at the moment since our internal models (XmlListModel and ListModel) use an internal model interface.

QDeclarativeVisualDataModel is also internal, so it is not possible for 3rd party views to use our data access abstraction.

Preliminary Results

We experimented with a model that doesn't use roles, simply provides a QObject for each row. A convenience model caches these until no longer required by the views. We reimplemented ListModel and XmlListModel using this approach, as well as SQL model classes.

Future work/open issues:

• The model should notify the view of changes as a "changeset" when possible rather than individual, unconnected signals (i.e. the model should say "I've added two items, and removed 3", rather than "I've added two items" and "I've removed 3 items")
• With a simple QObject approach, it's difficult to correctly manage the lifetime of the object. For example, if listModel.get(3) is called, when can the model delete the object returned? We've discussed some sort of simple wrapper for this, and well as a QObjectRef that would take care of references both across JS and C++.
• Caching worked well, but it can be relatively expensive to invalidate that cache when things in the model are added/removed/moved. Need to investigate alternatives to QHash for the caching.
• For our own models, making it easier to work with dynamic objects would be nice
• For compatibility, we need to make sure model/modelData/index and all combinations continue to work as before. An autotest was added for this (if we are returning the actual QObject as "model", then we need to annotate it with e.g. model.index)