Why use CoreLocation in this chapter


#1

Can anyone suggest a reason, other than didactic, to use CoreLocation in the map annotation exercise?

As far as I can tell the findLocation and foundLocation methods, to use locationManager to find the user location, aren’t necessary. In the textFieldShouldReturn method, instead of sending the findLocation message,
add the annotation directly since the user location is in the userLocation property of worldView. The user is, after all, entering an annotation label on a map already zoomed to the current location so the locationManager finds the user location essentially instantly – hence the activity animation and text field hiding aren’t even perceptible and since the zoom level doesn’t change that result of foundLocation isn’t visible.

I see the educational point of coding extra methods for some asynchronous event like finding the user location. The activity animation and field hiding are interesting and good to learn. But since it seems unnecessary to me in this case I initially found it quite confusing.
Why was I doing this?

Perhaps I didn’t’ figure out that it wasn’t necessary – perhaps I just don’t understand why it is necessary – or at any rate a good idea.
Thoughts?


#2


#3

It was mostly for teaching purposes. It’s nice to see a method trigger a delegate method that triggered another delegate method.


#4

OK, thanks.
I see the educational purpose.
I think that for me it would have been good if the text had pointed out that it wasn’t strictly necessary to fire up the existing locationManager in this particular case, but that it was an example of a pattern and required delving into the documentation which was a good thing.

I think Mr. G. S. Alien’s reply illustrates the mental-model difficulty that I had – multiple methods that were activated when the user location was found without a sufficient handle to distinguish their purpose. If findLocation and foundLocation had instead been named more specifically (findAnnotationLocation and foundAnnotationLocation or maybe findLabelLocation and …), it would have helped me.

I have some appreciation for how excruciatingly difficult it is to make even halfway good example programs, let alone exemplary. My observation here is a mere quibble – intended to be useful feedback. So far, the text is doing a good job for me. Thanks.


#5

@cprice53, I hope you keep posting your ideas and thoughts to this forum as your insight on the last question was useful to me.


#6

Yes, me too. I was going to post and ask why the Whereami example used an instance of CLLocationManager to provide the location when making an annotation. It looks like the MKMapView instance already provides the current location whenever it changes in its mapView:didUpdateUserLocation: from the userLocation - coordinate call. So I was stumped as to why a CLocationManager instance was fired up to get it. Couldn’t we just keep the latest MKMapView location and use it whenever an annotation is made? Would this actually work, with some modified code? I had added an NSLog call to mapView:didUpdateUserLocation: and it seems to emit a message whenever the location changes, at least in the simulator. For use on a real iPhone, you probably wouldn’t want to display any message, since it would be constantly changing. I agree that some book text explaining why CLLocationaManager was used would have cleared things up. So, would the mapView-only scheme work?