> > Also, the design pattern we<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> > use aims to minimize network activity (thus saving battery) by<br>
> > loading the<br>
> > data locally to a database and most interactions with the data are<br>
> > through<br>
> > the local database. It would be far too slow from a UI/UX standpoint<br>
> > to<br>
> > always be loading data from the backend on demand, and it would<br>
> > drastically<br>
> > affect battery.<br>
><br>
> I'm finding this a bit difficult to believe.<br>
><br>
> Does any other frontend on any platform work this way?<br>
<br>
</div>I will jump in here, somewhat to Dan's defense, since I gave him crap earlier<br>
in the week about this.<br>
<br>
If, as he suggests, and I'm not inclined to disbelieve him, the problem<br>
is that the server side of this client/server system is not presently<br>
optimized to support the query which his use case requires, then yes,<br>
I could see why he might decide to take this approach, as pessimal as it is.<br>
<br>
Whether other MythTV frontends work this way is only relevant if they are<br>
as network constrained as a client on an Android phone might be -- it's not<br>
reasonable to evaluate this merely, say, in the context of an Android<br>
tablet on the same WLAN as the backend.<br>
<div class="im HOEnZb"><br></div></blockquote><div><br></div><div>Would it be unreasonable for the application to perform a limited query on a smaller local dataset, and reach out to the backend for a more powerful quer?. For example provide a "search titles" option and have an advanced search screen for more indepth searches against the backend DB?</div>
</div>