I think your maybe making too many requests to the server, particularly over a network that may be spotty while driving. Add to that the speed of the car and you have a problem.
Actually because the car is moving in a straight line, you can do a single query for the next N kilometeres. you only need to redo it if the car makes a turn or you run out of points. Better yet, the data can't be that large. Why not simply download all the data for a 5 or 10 kilometer radius and and only update it when the car reaches the boundary? I'd say you could even dov it for a whole region and the data wouldn't be that large. If you had the user select what region they were living in, it would be fairly simply to download the data file before they even start. Doing that, you'll save the user batter as well. Not sure if your trying to load images as well, but the number of road signs is limited so you can just package those up with your app. - Brill Pappin On Jan 17, 9:32 am, cellurl <gpscru...@gmail.com> wrote: > The data is speed limit signs. I think its time I switch to a local > copy like Jonathan said. I noticed there are tons of sort routines, so > I probably don't need sqlite... > Thanks guys! > cellurl > > On Jan 15, 2:47 am, Jonathan Foley <jonefo...@gmail.com> wrote: > > > > > > > > > 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
