ubuntu-phone team mailing list archive

[Michi Henning <michi.henning@xxxxxxxxxxxxx>]

> I'm not sure if what you described is like that ^, but the idea is that the
> aggregator seems to know the order it wants to put things, and it knows what is
> up to date and out of date. Keep the order and replace out of date with up to
> date in place when ready.

This doesn't deal with the "jumping icons" problem though. The general issue with in-place updates is that the cardinality of a query result set can change as well as individual items returned by that query.

The accidental activation issues this causes are real. I've been annoyed in the past by other applications that fill a list with actions/items and me activating the wrong thing by mistake because the list updates just before I click.

Caching results from queries can be problematic too because, in general, queries and results do not have any reliable identity. Just because the query is the same does not necessarily mean that, when the query is run a second time, it will produce the same results as it did the first time. And, for results, the issue generally is that two different URLs can identify the same resource, and that the same URL can identify different resources over time, or lose its resource altogether.

Usually, the scope implementation knows a little more about the semantics of the results it is dealing with, so that is typically the right place to do caching. But, even a scope may not understand much about the results it produces, if the scope is a simple front end that scrapes information from some back-end source. And, for aggregators, the situation is worse, unless the aggregator always aggregates from the same fixed set of well-understood child scopes.

Michi.