route-me-map

[Prev] Thread [Next]  |  [Prev] Date [Next]

[route-me] Re: serious performance issue with cache directory, also rejection hiccup Tracy Wed Jun 17 11:00:46 2009

The problem is that the iTunes sync is painfully slow.   If you're
caching a lot of data, it can take hours...

I do not use the route-me cache for my locally cached data, as I found
that sqlite wasn't up to the task
of storing 10s of thousands of tiles.  I store my tile meta-data in
sqlite in ~Documents, but the tiles themselves
in ~Library/Caches.  If the cache is reset, the app will re-download
the tiles.  My cache is manually selected, though.

Since the route-me cache truly is a MRU tile cache, moving it to
~Library/Caches makes sense as there are no side-effects to losing
it.

Definitely get the reachability popup in there.  Everyone I know has
been hit by that rejection.  The fun part comes in that
there is a bug in the reachability library that can cause your app to
crash once-in-a-blue-moon given certain wireless conditions.  Damned
if you do; damned if you don't.

/tracy

On Jun 17, 10:20 am, Matt Farnell <[EMAIL PROTECTED]> wrote:
> Thanks Hal,
> Isn't having it in Documents because it syncs a good thing?
> Then on upgrades the cache is still available. So from the selfish
> perspective or apps wouldn't that be a good thing?
>
> On Wed, Jun 17, 2009 at 10:16 AM, Hal Mueller <[EMAIL PROTECTED]> wrote:
> > If you have a shipping app (or even more importantly, a close-to-shipping
> > app), pay special attention to
> >http://code.google.com/p/route-me/issues/detail?id=109:
>
> > The existing FMDB/SQLite tile cache stores its data in a subdirectory of 
> > ~/Documents.
>
> > ~/Documents is backed up when the iPhone syncs. Apple recommends using 
> > ~/Library/Caches for
> > any cache data that can be regenerated; that folder is not backed up.
>
> > Each cache, for each tilesource, is backed up on each sync. This makes the
> > syncs quite slow. Apple best practices says to put any data that can be
> > regenerated into ~/Library/Caches, which is not backed up.
>
> > If you haven't shipped yet, just switch the folder that FMDB uses. This
> > probably needs to be done on both the trunk and a branch for 0.5 (we're
> > picking up other 0.5 patches, might end up pushing a 0.51); any volunteers
> > to do this?
>
> > If you have shipped, it's more complicated. You already have a cache in
> > ~/Documents. Simply changing the FMDB code won't be enough. You'll have to
> > push a new version that cleans out the old cache(s) in ~/Documents. If you
> > have changed the unique tilesource identifier, you'll have even more dead
> > data in there.
>
> > Another point: at least a couple of us have received rejections from Apple
> > for not handling the case of no network connectivity on app launch. In my
> > case, I was presenting a mostly blank  screen if no tiles could be
> > downloaded and the cache was blank. It's simple to add an alert for this
> > case (following the Reachability sample code) instructing the user to
> > connect to a network.
>
> > I'll be sending out a longer WWDC summary today or tomorrow, but wanted to
> > get this in front of everyone right away.
> > Hal
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"route-me" group.
To post to this group, send email to [EMAIL PROTECTED]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/route-me-map?hl=en
-~----------~----~----~----~------~----~------~--~---