ubuntu-phone team mailing list archive

[Robert Schroll <rschroll@xxxxxxxxx>]

On Thu, Nov 20, 2014 at 4:08 PM, Sam Segers <sam.sgrs@xxxxxxxxx> wrote:
> I have set up something in my app PLACES scope. This is roughly based 
> on the click scope.
> Most interesting are:
> https://github.com/labsin/places-scope/blob/master/data/CMakeLists.txt
> https://github.com/labsin/places-scope/blob/master/po/CMakeLists.txt

Thanks, Sam.  I'll steal the relevant bits from you.

On Thu, Nov 20, 2014 at 5:43 PM, Rodney Dawes 
<rodney.dawes@xxxxxxxxxxxxx> wrote:
> Google throttles on number of requests over time, not amount of 
> results
> they return. If you need to paginate, that's of course an issue. Maybe
> instead there is a better way to limit the number of results you get?

The usage limits for Gmail are based on the methods you call.  Getting 
the information needed for one thread, for example, requires one method 
call.  n threads require n calls.  I can (and do) batch them to cut 
down on HTTP overhead, but "A set of n requests batched together counts 
toward your usage limit as n requests, not as one request."

> Why do you want to reload the results whenever the user closes the
> preview, anyway? Does something in the preview change what results 
> will
> be returned, for a given query?
>
> Generally, a preview should not alter the result set from the query.
> There are some exceptions of course, but in those cases, the action
> should also be immediately visible.

For example, I have an action that marks a given message as read.  It 
triggers a reload of the preview to update that UI.  But if the user 
returns to the list of query results, this message will still be marked 
as unread.  The ideal way to handle this would be to alter the read 
attribute of that result.  But I hear that's not possible, nor likely 
to be possible, so the next best solution would be triggering a reload 
of all the results.

Most scopes won't have this problem, but any scope that's based around 
notifications that the user needs to deal with could run into this.

Thanks for the help,
Robert