Where to put common code for iPhone, CLLocationManager

Question

If I have a tab bar app, and plan on using Core Location in different tabs, is there a good common place to put the code used to alloc/init the CLLocationManager, and get the updates once startUpdatingLocation is called? Or if it's going to be used in two different tabs, do I then just put it in the code for each tab? Just wondering what best practices are since I am new to programming. Thanks.

Answer 1

The App Delegate is a good, central place for such data. You can always get to the app delegate with [[UIApplication sharedApplication] delegate]

Answer 2

I don't agree with John, the AppDelegate is the "easy" way to do it, but not always the better.

I would do this with a singleton. You can look at Matt Gallagher's article on Singletons, AppDelegates and top-level data for reference.

Answer 3

if you notice you're duplicating what you've written, or faced with writing code which exists, consider creating an interface (object, set functions, etc.) to handle these tasks.

see DRY (do not repeat yourself). there will be a lot of duplicate functionality by the time you've written a few apps. it's best to write it once, and to write that correctly.

here are some high level guidelines:

• don't put app-specific features in a common interface (instead, use a subclass shared by the 2 projects)

• always keep your bases free of hacks (unless you're dealing with an issue in the system libraries). if clients (e.g., subclasses, callers) need a particular workaround or require a specific check, then it is better to make them handle it.

• use assertions to ensure they use the interface as intended, check every argument, precondition/postcondition, the state of your object, etc..

• keep your objects/interfaces very small and maintainable, with a clear purpose of their intended use. naturally, this will result in a higher number of objects.

• avoid the urge to use singletons and static data; there's almost always a better way even if it's as simple as forcing clients to create an instance of your class.

• create libraries with these interfaces, and divide them logically.

now that that's covered…

i'd begin by using (potentially multiple) instances of the objects you'll need. there is nothing in the documentation that states "you should not create multiple instances of the object".

if this is somehow inadequate in profiling, then consider using a shared object which relays messages to the objects (in your app) which need updates.

rationale: chances are, apple's already optimized the implementation, so you don't have to.

finally, i broke these guidelines in an app which required a ton of location requests, and displayed a ton of location information. the app used some static data behind an interface which stored the location manager and the location (among other things). so i ended up using static data with private (hidden) static data to reduce the memory and cpu demands in this case.