[Prev] Thread [Next] |
[Prev] Date [Next]
[route-me] Re: serious performance issue with cache directory, also rejection hiccup
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
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.
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
> > 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
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