Category Archives: ios

Lessons from AngularJS

AngularJS

AngularJS

The past two weeks I’ve been working on a web project using AngularJS.  Angular is a Javascript MVC framework with the backing of Google.  I always enjoy taking some time to learn a new language or tool from time to time.  As iOS developers I think there’s a couple of concepts we could learn from Angular.

Bindings – Bindings everywhere.

One of the first thing you learn in Angular development is its two way binding system.  Placing a binding in your HTML template is dead simple; simply enclose the variable in the handlebars: {{myvar}} or link it via the ng-model attribute on an input tag.  The binding is two way such that changing the value of a text field will update that in your model.

Unfortunately iOS is often much more difficult and manual when it comes to keeping your model and UI in sync.  MacOS provides bindings to developers but there’s no once and done solution for iOS.  However binding is not difficult to implement using KVO.  KVO has its downside when it comes to performance, but it may be worth it for the simplicity.  I haven’t tried to implement it myself to be able to tell.

Thin models; thin controllers

Angular makes very few assumptions about what your model in the MVC way of thinking is.  In fact, the model for any controller is expected to be a special variable called the $scope.  The $scope object is provided by the controller, whose entire job is to do nothing but populate the scope.  Compared to iOS view controllers, Angular controllers are extremely light.

iOS view controllers have a bad habit of being very involved in both in view-ish things and model-ish things, as well as its dictated function of handing controller-ish things.  How many times have you managed a view directly in your view controller as well as managed changes back to the model?  Probably a lot.  One of the downsides of UIViewController is that they often wind up being behemoth and barely manageable monster objects. Angular’s documentation strongly advises that you don’t make changes to the DOM (the literal view of a web application) from within the controller, delegating those tasks elsewhere.  The result is a very simple controller that does its job of exposing the model to the view well and without needless other operations.

Greater separation of the view and the controller

Web applications have an inherently strong presentation layer: the HTML and CSS that handles display in the browser.  In Angular style, the HTML provides structure of a view, CSS provides the presentation of the view, and Angular does the job of providing data to the view.  As mentioned above it’s all too common in an iOS application to jam all this functionality into a single view controller.

It’s not a stretch to say that UIViewControllers are often required to do far too much for any non-trivial application.  A view controller might be responsible for loading data from somewhere, maybe through an NSURLConnection, doing any formatting or transformation of the data, creating a view in loadView: and laying all the pieces out.  It may also be the datasource and delegate for a table view providing cells and handling cell selection.  After all of that it might also be accepting event callbacks from UI controls and altering the model appropriately.  That’s a huge set of tasks and I’m as guilty as anyone of writing multi-thousand line view controllers.

Applying the lessons

So how should we break up a UIViewController subclass into more manageable chunks?  I think Angular presents a couple of ideas.

  1. The most simple task is to separate the model related concerns of a UIViewController from its view related concerns.  In iOS development you need to have view controllers, but there’s no rule that you can have other controllers to handle other tasks.  NSFetchedResultsController provides a great example of a way to separate the needs of dealing with CoreData from the other responsibilities of the view controller.
  2. Relegate the UIViewController subclass to what its name implies:  management of the view.  Offload data related concerns to a custom defined model controller.
  3. Make views a little smarter.  HTML and CSS provide a natural separation between controllers and views.  Interface builder is one of the best tools and iOS developer has but there’s no reason we can’t make smarter views that know more about it’s layout and the properties of it’s subviews.  If reuse is concern there’s nothing wrong with the root view of a view controller being a custom subclass that arranges other pre-made components.
  4. Attempt bindings using KVO.  You could easily inject a transformer into the mix for formatting.

Fully realizing these are all a little abstract right now I’m planning to take a concrete stab at these in some future posts.  For now the takeaway is that learning a different way of doing things can always open your eyes to some better ideas in your current workflow.

6 Things in iOS 5 That Will Make Your Next Project Easier

There’s no shortage of hype around the arrival of iOS5 this week.  Much of it has been about iCloud, ARC, notifications, and Siri of course.  These are big deals to be sure, but for a coder there’s some great improvements that simply make your development process easier.  Here’s my list of favorites, some of which I’ve already started using:

CoreImage and CIFilters – The addition of the CoreImage framework will give you more ways to create compelling UIs.  CIFiltlers aren’t limited just to images.  You can apply them to any CALayer.

UIAppearance – It used to be that if you wanted a custom looking UISwitch or or UIProgressView you’d have to implement it from scratch or try and rip the control apart view by view and modify it yourself.  Writing a custom control is of course time consuming and modifying the view hierarchy leaves your UI at the mercy of the next iOS update.  UIAppearance and the appearance proxies let you configure the look of the default controls in ways you couldn’t before either on a per instance or hierarchy level, or application wide.

Container View Controllers – Absolutely huge, probably my the most useful improvement for me.  It used to be that if you wanted a custom container, like a tab bar or split view, you had to implement it yourself from scratch.  It was always problematic and you often had to hack properties like myParentViewController because the property was locked down.  Now you can make container view controllers and the existing controllers (and containers like UINavigationController) will play nice with them.

Real locations in the simulator – You’re probably not really at Apple headquarters anyway.  Glad the simulator has finally caught on 😉

Ordered relationships in CoreData – If you’ve ever tried to do this on your own, you know how valuable this can be.  Not only does your “group” have “users”, they now have an ordered collection of “users”.

EventKit upgrades – What strikes me a severe limitation of EventKit is that up until now you can’t create calendars in your iOS app.  EventKit upgrades now allow it.