Mapkit. Getting nearby places from a server and possibly caching them (e.g. for offline use)

Question

I am developing iOS 5 app which I want to communicate with server providing information about the nearby places for a given location: places locations and annotations. I want to use MapKit to populate my map with this information.

I didn't find any straightforward information regarding the following questions:

1. Does MapKit has tiles functionality (Google Maps way) out-of-the-box and do I need to work on it additionally, if not?
2. What is the best practice of retrieving places information (markers positions and annotations) from server?
3. Is it possible to cache this information so an user can see the nearby places of "his city" in offline mode?

Actually questions 2 and 3 are interrelated: they both address the problem of not retrieving an information (locations + annotations) that is already on map multiple times.

Hopefully I am not overlooking something obvious here.

Thanks!

Update 1: (Regarding places, not maps) More specifically I am interested in, how should I create a "hand-crafted" logical tiles for regions containing the places I fetch from the server, so they would not require refetching themselves when user scrolls the map? I know I can dive into implementing this functionality myself. For example, should I write the places just fetched to a local storage using Core Data immediately after fetching them or organize some queue? Or how could I know when I need to perform a request about the specific region on server and when I just fetch local data that is already on the device? I just want to know, are there any recommended approaches, best practices? Hopefully, I wrote it clear here.

Update 2: I am wondering about best practices here (links, example) not to start creating all this (points 2+3) from scratch. Are there any frameworks incapsulating this or good tutorials?

Answer 1

@Stanislaw - We have implemented the functionality you describe in an app called PreventConnect for one of our clients. The client already had some data stored out in a Google Fusion table. We extended their existing solution by adding another Google Fusion table which stores the geocoordinates for a number of locations. All this being said, to answer your questions...

1) The map portion itself is pretty out of the box, the tiles and what not, but you'll need to do some coding to get zoom extents, pin drops, annotations, and things like that working the way you expect them to work.

2) We found the Google Fusion solution to be quite effective. If you don't want to use Google Fusion there are other cloud database providers like StackMob, database.com, and many others. Google is free and they have an iOS SDK that makes communicating with Google Fusion pretty simple.

3) Absolutely! We cache much of the data in a Core Data store locally on the device. This greatly improves performance and responsiveness.

Answer 2

Time to write a solid answer to this my question (I could have it written a year ago but somehow I lost it from my mind).

---

Does MapKit has tiles functionality (Google Maps way) out-of-the-box and do I need to work on it additionally, if not?

The answer is yes: MapKit does have it. The keywords here are overlays (MKOverlay, MKOverlayView and others). See my another answer.

See also:

WWDC 2010 Session: Customizing Maps with Overlays,

Apple-WWDC10-TileMap.

---

What is the best practice of retrieving places information (markers positions and annotations) from server?

Actually since then I didn't learn a lot about "best practices" - unfortunately, nobody told me about them :( - that is why I will describe "my practices".

First of all, there are two strategies of populating a MapKit map with places:

The first strategy is about populating your map with the places by demand: imagine you want to display and see all places nearby (for example, no more than 1km from current user location) - this approach assumes that you ask your server only the places for the box you are being interested in. It means something like: "if I am in Berlin (and I expect 200 places for Berlin), why should I ever fetch the places from Russia, Japan, ... (10000+ places)".

This approach leads to relying on "tiles" functionality that question N1 address: Google maps and Apple maps are usually drawn using 'tiles' so for your "Berlin" portion of map you rely on corresponding "Berlin" tiles that are drawn by MKMapView - you use their dimensions, to ask your server only the places within the "Berlin" box (see my linked answer and the demo app there).

Initially this was the approach I've used and my implementation worked perfectly but later I was pushed to use second approach (see below) because the problem of clustering appeared.

The second strategy is to fetch all the places at once (yeah, all this 10000+ or more) and use Core Data to fetch the places needed for the visible portions of map your are interested in.

Second approach means, that during the first run you send your server a request to fetch all places (I have about 2000 in my app). Important here is that you restrict the fields you fetch to only geo-ones that you really need for your map: id, latitude, longitude.

This 'fetch-all' fetch has a significant impact on my app's first start time (On "the oldest" iPhone 4, I have near 700ms for the whole Fetch + Parse-JSON-into-Core-Data process, and extensive benchmarks show me that it is Core Data and its inserts is a bottleneck) but then you have all the essential geo-info about your places on your device.

Note, that whatever strategy you use, you should do a process of fetching these geo-points efficiently:

Imagine Core Data entity Place which has the following fields structure (preudo-Objective-C code):

// Unique identificator
NSNumber *id,

// Geo info
NSNumber *latitude,
NSNumber *longitude,

// The rest "heavy" info  
NSString *name,
NSString *shortDescription,
NSString *detailedDescription, etc

Fetching places efficiently means that you ask only your place records geo-data from your server to make the process of this mirroring as fast as possible.

See also this hot topic: Improve process of mirroring server database to a client database via JSON?.

The clustering problem is out of scope of this question but is still very relevant and affects the whole algorithm you use for the whole proces - the only note I will leave here is that all the current existing clustering solutions will require you to use second strategy - you must have all the places prepared before you run into the clustering algorithms that will organize your places on a map - it means that if you decide to use clustering you must use strategy #2.

Relevant links on clustering:

WWDC 2011 Session: Visualizing Information Geographically with MapKit,

How To Efficiently Display Large Amounts of Data on iOS Maps,

kingpin - Open-source clustering solution: performant and easy-to-use.

---

Is it possible to cache this information so an user can see the nearby places of "his city" in offline mode?

Yes, both strategies do this: the first one caches the places you see on your map - if you observed Berlin's portion of map you will have Berlin part cached...

When using the second strategy: you will have all essential geo-information about your places cached and ready to be drawn on a map in offline mode (assuming that MapKit cached the map images of regions you browse in offline mode).