Category Archives: Tools

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.

Markdown on MacOS

Readown is a markdown viewer for MacOS. I couldn’t get it to open .markdown files on my machine after downloading the binary, so I grabbed the source from github and rebuilt for Lion which seemed to solve the issue. I’m posting it up here thinking it may help someone else. Cheers!

Great New Developer Tool in Lion

via Matt Gemmell 

Lion adds a new utility for simulating network types, called the Network Link Conditioner.  Seems like a great tool for simulating rough network conditions in your apps.

Network Link Conditioner Screengrab

To install this (it’s a preference pane) you’ll have to find it in a folder inside the utilities under applications.  Simply double click to install!

Matt’s original post

Parsing Sucks

The developers of Hipmunk posted a recent blog article detailing their post-mortem thoughts on the creation of their iPhone client.  It’s a good read top-to-bottom, but I thought the most interesting bit was regarding the performance and data transfer between the Hipmunk servers and the client.  This quote I think sums it up aptly:

Parsing large amounts of JSON sucks.

I think that can hold true whether you’re talking about JSON or XML. In fact, I find that parsing a given XML feed into business objects eats up a sizable chunk of time on any project. Their solution was to send compiled plists rather than big chunks of JSON, which cut the import time down by more than an order of magnitude. Not too shabby.

Compiling a plist server side doesn’t seem to be as big of a chore as you’d think. In fact, there’s a github project that will do the server side compilation for you. We have a couple of end-to-end products developed here at Mindgrub that we’re going to look at implementing using compiled plists over the XML we’re using now.

10 iOS Libraries + 2

AppDevMag posted a list of 10 libraries to make iOS development easier. We’ve used Three20 and a few of the others here at Mindgrub, and wound up writing our own library similar to ASIHTTPRequest back in the iOS 2 days, though it was built around NSHTTPURLRequest rather than CFNetwork.

Two great libraries they left out however:

  • ShareKit – Post to many social network sites out of the box. This library is light and fast, and easily extendable to add other services.
  • XMLRPC in WordPress for iOS – Writing XML-RPC from scratch is a pain, but this library will get a lot of the boiler plate code out of the way. The app is open source.

Search the developer docs from the Chrome Omnibar

ClickOnTyler posted a couple of helpful Chrome extensions for searching apple’s documention directly from the Omnibar. Simply type “ios UIImage” or “mac NSApplication” to search the apple docs. Very Handy!