Cory Wiles Blog

Almost 3 Years Ago

Just when I thought I had a somewhat decent grasp on developing and deploying iOS apps Apple came out with the iPad and threw a whole new element in the mix when it comes to developing.

It was almost three years ago that I published the first blog about my Universal App Template. I was inspired by, at the time, a little tutorial by a guy you might have heard of…Ray Wenderlich). His tutorial really helped me with a project I was working on and get through stumbling blocks. I wanted to provide a set of examples that any iOS developer could refer to that was straightforward and get up and running with creating a universal app in as short of time as possible.

Over the following months I added additional features such as iAd support, tabbar controller and iAd with tabbar support. Since then it is still the most visited article and starred/forked repo that I have.

Bueller, Bueller…

Over the years that followed I got busy and wasn’t able to keep up with the iOS updates, new features requested or bugs. The project was quickly becoming outdated.

I’m happy to say that I’ve carved out sometime to update this project. The plan is to start with the master branch, which is the most basic example, and update it from the ground up. I’ll then move on to the “feature” branches. I’m dropping support for iOS 3.2, 4.x and 5.x. Due to the fact that the iOS upgrades happen so rapidly, thanks to OTA, and iOS 7 is being released in less than a month, this is the perfect time to hit the reset button. The project, as well as, feature branches, will support ARC. I’ve also spent some time cleaning up the code base and removed a lot of duplicated code.

If you still need access to the “old version” I’ve tagged it.

No developer is perfect and I’m sure there are tons of things to improve so please drop me a line or file a bug and I’ll fix it ASAP.

One Thing Multiple Times

When it comes making iOS apps multi-threaded by now we should have at least heard of Grand Central Dispatch. The most common use case that is implemented and used is asynchronously fetching an image or web page, returning the resource…manipulating it in some fashion and the updating the main thread (UI) with updated resource.

Image Async Example

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_NORMAL, 0), ^{
    // fetch image from remote server
   dispatch_async(dispatch_get_main_queue(), ^{
     // set image for imageview
     // reload view if necessary...i.e. table view
   });
});

Copy and Paste Should Work Right?

For a project I’m working on I thought I would be able to utilize the same paradigm for the following scenario;

Grab a list of all our customers accounts. For any given customer they can have n+1 accounts and I don’t want them to run serially, but concurrently (our vendor has a POORLY design datastore so the queries take forever) to keep wait time to a minimum. Once all the calls for getAccountDetailsForAccountNumber have finished the tableview on the main view controller is refreshed with the info.

// AccountInfoViewController

- (void)viewWillAppear:(BOOL)animated {
      [super viewWillAppear:animated];

      [self.imf getAccountListMetaInformation:^(id obj, BOOL success, NSError *error, IMFClientErrorType clientError) {

          if (error) {
           // handle error
          } else {
            // NSArray *aggregatedInformation = (NSArray *)obj;
            //refresh tableView with aggregatedInformation
          }
    }];
 }

// IMFClient pseudo

@property (nonatomic, strong) NSMutableArray *willHoldAccountDetails

-call getAccountListMetaInformation
       // do general setup and check for cache
       // START CODE THAT SHOULD RUN CONCURRENTLY
      // BUT getAccountListMetaInformation COMPLETION BLOCK SHOULD WAIT
      -call getAccountDetailsForAccountNumber
         -run completion block
             - ADD return object from getAccountDetailsForAccountNumber to willHoldAccountDetails property
      -call getAccountDetailsForAccountNumber
        -run completion block
             - ADD return object from getAccountDetailsForAccountNumber to willHoldAccountDetails property
     -call getAccountDetailsForAccountNumber
        -run completion block
             - ADD return object from getAccountDetailsForAccountNumber to willHoldAccountDetails property
      // END CONCURRENT CODE - SAFE TO CALL COMPLETION BLOCK FOR getAccountListMetaInformation
-finish getAccountListMetaInformation
-willHoldAccountDetails is now populated and passed to completion block

First Attempt

I failed.

Why It Failed

The first reason my code failed was because of my failure to take the time and truly appreciate and understand what happens with custom queues, dispatch_* methods and how objects are managed by queues and threads. I tried to apply the same logic to a totally different scenario.

The second reason my code failed was getAccountListMetaInformation is running on the main thread, so none of getAccountDetailsForAccountNumber’s dispatch_async calls are going to be able to run until getAccountListMetaInformation returns. Anytime the code runs on the main (or any) thread, that’s going to block other code from running on that thread.

I regrouped….literally

I went back and rewatched the WWDC videos from 2010 and 2011 on Grand Central Dispatch, as well as, read over Mike Ash’s posts regarding GCD. Paying particularly close attention to Friday Q&A 2009-09-04: Intro to Grand Central Dispatch, Part II: Multi-Core Performance.

Winning with Simplicity

dispatch_group_async to the rescue. When going back and evaluating what I was trying to do, which is to iterate over list of accounts and fetch each one concurrently, and then updating the comletionBlock with aggregated array, the simpliest approach was to push each request on to a dispatch_group and then WAIT for all of them to complete.

Shocker…it worked.

Lesson Learned

The most important lesson I took away from this is regardless how much abstraction and convience that GCD provides it can’t/won’t abstract the business logic and having a firm understanding of the GCD paradigms are paramount.

Project

ThreadingHell. If you have a better/different implemenation then please let me know.

It is said that necessity is the mother of invention. Granted, I haven’t invented anything, however necessity did drive my latest solution.

Vendors – PIA

While working on a project for work I have the unfortunate requirement of using one of our vendor’s iOS frameworks that is horribly written and documented. From day one I discovered bugs and inconsistencies with how it is implemented. For one case I ended up reverse engineering what they were doing and sent them the snippet they should add in to fix the problem.

Not Wasting Time

Getting vendor to make changes that I needed, and consequently, the company, is about as quick as standing in line at your local DMV. I had to move the project along as fast as possible. During the early stages of the project I picked up a copy Graham Lee’s Test Driven iOS Development and took his advice on how to make my unit testing much more efficient with better coverage…so I started writing as many mock objects as I could for unit testing. In order to handle future test cases I created a MockObjectDataManager, but I found myself writing a lot of if/else statements throughout the app itself to handle switching between dev/test/stage/production web services vs. mockobjects. This was not good.

What I needed to do was setup the app so that any other developer, including myself, only had to write calls to the vendor’s framework, but could switch easily to using mockobjects when appropriate.

Method Swizzling to the rescue!

Fo’ Swizzle

The What

Unlike creating a category method with the same name as the original method (effectively replacing the original method), MethodSwizzling lets your replacement method make use of the original method, almost like subclassing.

Source: CocoaDev

Danger Will Robinson, Danger

I have read and seen developers using this technique, but it usually followed up with disclaimers such as:

• unstable
• experimental only
• use at your own risk

Because of this general attitude I had seen I shy’d away from every really using this runtime feature. While I was foolish early on in my iOS development career to not learn more about it, using it without serious thought and consideration would probably proved distasterous. Granted, swizzling does allow a developer to swap methods for their own implemenations, sed developer has to make a lot of assumptions about the implemenation of the original method. If that implemenation changes the likelihood for your replacement method to break increases.

Necessity

As stated earlier myself and my team needed the ability to rely on the vendor framework for communication to and from the web services, but also needed the ability to writing unit tests and CRUD mockobjects WITHOUT cluttering the app code base.

First, I recreated the json response from each endpoint and saved those into static files. Second, I rewrote the mock object manager to access and cache the models asynchronously, with better error handling. Third, I added in a preprocessor macro to flag whether or not the swizzled method should be used. Finally, added in a convience method to handle swizzle.

I hit Cmd+r and was off to the races. The app crashed. Had I been over confident in my ability to leverage the almighty runtime. Well, no…I just needed to pay attention to how classes are loaded. As I stated earlier, my mockobject data manager loads the .json files asynchronously. When the swizzled method was called the dispatch_queue was NULL and resulting in a BAD_ACCESS error.

iFixit

The first attempt was to check for existence of the queue in the loadLoginResponse method:

if (!_fileQueue) { _fileQueue = dispatch_queue_create(fileQueueName, 0); } But wait…I had already instantiated _fileQueue in the sharedManager class method. Didn’t seem very reusble. As to not be out done this far into it I remembered the lifecycle of how/when classes are loaded and most importantly which the order of the meta methods. I moved the property and check from both the sharedManager and loadLoginResponse methods to + (void)initialize. Setting the USEMOCKOBJECTS to 1 and rerunning the app I successfully loaded my mock objects.

Lessons Learned

The most important lesson learned is to not be afraid to experiment with the more advanced features of Objective-C. When used correctly they provide a lot of flexibility and benefits to development and testing. My app is now setup to give any developer the ability to test against any live enviornment, as well as, test out new/existing features without changing a 3rd party framework or cluttering the codebase with a bunch of unnecessary “if/else” statements.

A great example of using these types of techniques is PonyDebugger from a little company called Square.

Get the Gist

gist.github.com/3762103

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