Taming Core Location

In today’s mobile development environment using the device’s GPS in some shape, form or fashion is a given. Apple provides a great toolset for developers to access and utilize this functionality, but this is often done carelessly. I am not talking about privacy concerns or the misuse of the data, but many developers, myself included early on, had a poor code design implementation. The characteristics of such are usually:

  • CoreLocation implementation that was always tied directly to a particular UIViewController
  • Set the accuracy to kCLLocationAccuracyBest
  • Set filtering to kCLDistanceFilterNone.
  • Requests way to many location updates

Let’s examine each reason why these are not the best practice

Tight Coupling is Wrong

This is a more of a development practice that developers should always attempt to achieve in their code. There are always examples and uses cases as to why you would have to break this paradigm, but is still goal none the less. What we generally see, and most tutorials on the topic do this, is that the UIViewController sublcass will conform to the CLLocationManagerDelegate protocol, setup the manager and properties and listen for callbacks. I guess that is OK if you have only one use case and user interaction that requires CoreLocation, but in most cases you need to access CoreLocation more than once, thus you have to duplicate the same code. The “C” in MVC has now broken it’s intended contract and you have tightly coupled code.

Less Accuracy is More

This lesson is pretty simple. The more accurate the location you request, the longer it takes to get and the more battery power is drained. The faster the battery is drained the faster the iOS user gets pissed. The simplest example is a weather application. There is NO need to request such a detailed location. By setting your accuracy to kCLLocationAccuracyThreeKilometers you save yourself, and most importantly the user, time and end up with same information. Weather is usually shown based on a region area. i.e. zip code or city.

“For example, setting the desired accuracy for location events to one kilometer gives the location manager the flexibility to turn off GPS hardware and rely solely on the WiFi or cell radios. Turning off GPS hardware can lead to significant power savings.” – CoreLocationManager Reference

Filters are For Your Protection

Unless you are creating a turn-by-turn navigation app set a filter. Getting a location updates every half step or every second doesn’t add any value to the task of the application, but does have the same downsides as mentioned above. Poor battery life and horrible user experience.

You Don’t Need Updates Every Two Feet

This error is really an error in judgement. Apple provides developers with the fine grained control via distanceFilter and desiredAccuracy, but should be used sparingly and with apps that require multiple checks throughout the app session for location updates.

This service is most appropriate for applications that need more fine-grained control over the delivery of location events. Specifically, it takes into account the values in the desiredAccuracy and distanceFilter property to determine when to deliver new events. The precision of the standard location services are needed by navigation applications or any application where high-precision location data or a regular stream of updates is required. However, these services typically require the location-tracking hardware to be enabled for longer periods of time, which can result in higher power usage.

For apps that don’t require a constant stream of updates it is best to use start/stopMonitoringSignificantLocationChanges.

This method is more appropriate for the majority of applications that just need an initial user location fix and need updates only when the user moves a significant distance. This interface delivers new events only when it detects changes to the device’s associated cell towers, resulting in less frequent updates and significantly lower power usage.

Better CoreLocation Pattern Options

The first issue to tackle when implementing CoreLocation features is how to create your own manager that can be used and called throughout the app. The second issue that has to be addressed is how to allow other classe, regardless of type, UIView, UIViewController, NSObject, get notified of updated location information.

Issue One

The basic approach is to create subclass of NSObject that conforms to CLLocationManagerDelegate and implements the appropriate delegate methods. In my particular case I do have to listen for a stream of updates so I will be setting the desiredAccuracy and distanceFilter properties.

Issue Two

In order to tackle issue 2 I go one of three ways: NSNotification, Target/Action or KVO.

NSNotification would solve this problem, however it is seemed too decoupled and I personally feel that NSNotifications should be reserved for OS level notifications not service layer/domain model context changes. Finally, there are performance considerations when it comes to using notifications. No matter if the post to the notification center is done asynchronously or synchronously it is dispatched to the object synchronously. If there are a number of observers or if there is an instance where an observer must do a lot of work then your app could experience a significant delay.

Next on the list is the target/action pattern. While NSNotification was too decoupled from listeners, using target/action has now added a level of coupling that I felt a little unnecessary. In our custom manager class I would have to set a property, either NSMutableArray, NSSet or id that would hold the target instance, in addition, a property for the SEL, and when the location manager’s delegate method received a valid location update I would have to call something like:

`//NSMutableArray or NSSet

[clmListeners makeObjectsPerformSelector:@selector(methodToPerform)];`

`//id target

[target performSelector:@selector(methodToPerform)]`

There are two issues with doing the above proposal:

  1. You have the manager class now responsible for another class’s implementation without a contract.

  2. You are getting really close to having a delegate pattern which brings us closer to a one-to-one coupling between our classes.

The final option that we come to is Key Value Observing…which is the solution that I have gone with. Not only does it keep our manager class independent, but we also are also able to write our location code once while allowing our other classes to handle any UI or model manipulation as they see fit…independent of any other implementation or logic.

Custom Core Location Manager Class

gist.github.com/2421914

View Controller Observing Change to Current Location

gist.github.com/2421928

UILocalNotification Example Project Using iOS4

One of the greatest new features that is included in iOS4 is the power that developers have to deliver local notifications.  At the time that the first beta was released in April I was writing specs/requirements and project timeline for a potential app which would have ended up taking me about 5 months to develop.  A large part of the project schedule dealt with having to setup/maintain user reminder preferences...the number of reminders, frequency of each one, time zones, etc.  I tried to think of ever solution that I could that didn't involve the server component, but there really wasn't any other way.

UILocationNotification to the rescue.  After looking over the API docs, Apple had provided exactly what I needed and I was able to cut out 2.5 months from the project schedule because of it.

I was able to create an POC app using UILocationNotifications in literally 5 minutes.  It involved two easy steps:

 

  1. In the app delegate class I added the following method to verify that the event was fired off if the app was running. -(void)application:(UIApplication *)application didReceiveLocationNotification:(UILocationNotification *)notification;
  2. In the -(void) viewDidLoad method of my controller you alloc/init a new UILocationNotification object, set the fireDate which is an NSDate object, what time zone you want, what the notification message(body) should be and then add the UILocationNotification object to the UIApplication scheduleLocalNotification method

 

There are two possible end results.  The first being that the event is fired off while the app is running in which case you will not see anything. Hence, why I added the NSLog to the didReceiveLocationNotification method.  The second is if you close the app before the notification has fired and in that case you will receive the alert box with your message.

Download XCode Project

Note: This was compiled with iOS4 GM and tested on iPhone 3G/3GS

Facebook Graph API with a Native iPhone Application

One of the biggest gripes that I have with working with the FBConnect iPhone SDK, and really the Facebook API, in general was having to deal with a very inefficient REST implementation.  Callback after callback, protocol after protocol, major bugs (that have yet to be fixed as far as I know), and my biggest issue is the nasty user experience having to login a user.  I was very excited to hear when last month Facebook announced they had came out with a new API that would allow great security, ease and flexibility.  The pains of having to go through currently working functionality and refactor the code to accommodate the new features wasn't too much of a problem for me because it would mean a reduced code set on my part and I would be able to get rid of the Facebook Connect SDK.  I set out to test my theories and functionality via a quick web app.  No problems.  Then I proceeded over to my native iPhone app.  EraseUrX v2.0.  The new authentication mechanism utilized in Open Graph is OAuth2.0.  While many of the headaches and complexities of using OAuth are addressed and the documentation for using it in a mobile web app are well documented with Facebook they TOTALLY dropped the ball on providing any direction on using it with a native iPhone app and they don't provide an updated SDK.

I could one of three things: 1. Use the old Facebook Connect which should still work for the forseeable future, but as stated above has too many issues that I don't want to deal with and they could drop support at any moment. 2. Wait for Facebook to publish a new SDK, but how long would it take them 3. Just figure it out myself and have a flexible solution that didn't relay any third party framework.  I went with option 3.
The first thing you need to do is setup your app with Facebook.  Second, you will need to create a "callback" page that Facebook will send the request back to once the appropriate code and token has been given to your original request.  Third, once you have gotten the access_token from Facebook then you need to put it in a DOM object. This is important so that you can retrieve it via the UIWebview's javascript string evaluation and then finally save the access_token in NSUserDefaults for any subsequent requests.  In my case I wanted to get a list of the currently logged in friends.  Instead of having to go through the callbacks and delegate methods associated with the FBConnect SDK I now have user's login via OAuth and I make a call to, https://graph.facebook.com/me/friends, and get a JSON response of what I need.  Simple. Beautiful.
Callback Example (PHP):

Custom ViewController (I am not including setting up the uiwebview. I assume you already know how to do that):


Create Custom Sized UITableView with Header and Footer Views

I am currently working on a photo gallery/slideshow app and one of the requirements is for the main gallery listing page to have static header and footer that shows the app name, contact information and adverts.  The logical first method of attack is to just setup a UITableViewController subclass, slap some views and subviews to the table view header and footer and get on with the day.  However, the table itself should scroll, but the "header" and "footer" views should remain stationary.  My first approach, I found out quickly, did not work.  Surprisingly, there are a lot of people having issues with custom sized uitableviews in general and the discussions that I saw online didn't provide a very straight forward solution so I decided to create one.

The first big problem that most people run into is that they can't seem to resize the uitableview no matter what frame size they set.  It doesn't matter if you do it programmatically or through Interface Builder it still takes up the ENTIRE screen.  That is because they have subclassed UITableViewController.  To be honest I am not sure that happens "under the covers", but the custom frame sizes/locations are ignored.  You must make your controller a subclass of UIViewController and then add your UITableView as a subview to the your controllers view.

For example:

At this point your frame size and height will be respected.

In my example I setup a simple UINavigationController project with two controllers.  The first has a header view, footer view and uitableview.  The second "detail" controller just has a UILabel with placeholder text.  Everything is built programmatically so that you can adjust frames and positions easily as well as any other customizations you would like.  Comments/suggestions are always appreciated.

Download Project

Creating Custom Glossy Gradient Buttons Programmatically

As my experience, and hopefully skill, in iPhone development has matured over the past year and half I am in the constant search for the best techniques for my apps to run better, faster, and consequently more efficient.  Of the top developers that I follow they all make references to the importance of utilizing subclasses of UIViews and the underlying subsets of views in general.

I love the UI elements that are used on the phone. I didn't realize the awesome power of CoreAnimation and the flexibility that it gives you to manipulate and create graphics as such a granular level.  I set out to see if I could recreate a common iPhone UI element completely programmatically: a glossy gradient button that still responds to touch events.

The end result was a success and a great learning experience.  I still need to add in more testing to make sure that interacting with all these views is more efficient than interacting with standard pngs.

This biggest issue that I ran into was "re-enable" the button actions.

Simply subclassing UIButton did create a problem when dealing with the UIControlEventTouchUpInside/UIControlEventTouchUpOutside methods that you associate with buttons.

I was able to overcome this issue by implementing the touchesBegan and touchesEnded methods.  Remember...UIButton inherits from UIControl, which in-turn inherits from UIView.

Problem solved.

Download Project