Why don't you pull down data ahead of time? You haven't told us exactly what you are querying. Maps, logging the route?? In any case, you can either pre-cache some of the data you'll need or cache the data you'll be sending and send it less frequently in either direction. The only reason I can understand polling so frequently is if you are pulling data that is completely unpredictable. That is you have some huge table or tables and really have no idea what the next query is. Maybe you need to think a little more about how to predict what you'll need from either end. As folks have mentioned, latency and bandwidth are highly unpredictable and fluctuate in time and space. Your design will have to heave enough headroom to account for that while still delivering whatever minimum user experience your app needs..
Jonathan On Jan 15, 12:14 am, Frank Weiss <fewe...@gmail.com> wrote: > I would suggest being more flexible about *when* the queries are made. You > seem to have fixated on every 50 meters. Why not every two minutes? Or every > n minutes, depending upon the current network latency? Or even a heuristic > scheduler based on multiple factors? I would also suggest considering > decoupling the activity from the provider. Perhaps by using a separate > service that pushes new queries to the activity. Avoid creating your own > threading framework. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
