Blog Archives

Lessons from 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.

More On The Whole “Learning to Code” Thing

Scott Hanselman wrote an excellent piece on the “learning to code” discussion that occurring (still) on sites like HackerNews.  I feel he gets closer to the point of Atwood’s original idea.  Maybe a different angle.  The point is that you should learn to code if you have a burning desire to and more importantly if you have a need to.

Bloomberg would do well to learn how the internet works, but coding is not necessarily a requirement.  Same goes for Congress — because they have to deal with and legislate technological issues.  If you own a sink you should learn a bit about plumbing to know how it works.  Water doesn’t simply materialize out of thin air and enter the faucet and it doesn’t just evaporate in the drain.  Just as plumbing is a means to have a running water system in your house.  Coding is likewise a skill to be used to create larger systems but it’s no more a solution to anything any more than plumbing (as a skill) is a solution to supplying water in your home..

The point — Coding in itself is not a solution.

To Code or Not To Code – That is the (stupid) question

There’s a lot talk this week around Jeff Atwood’s post on CodingHorror where he asks the populace at large to not learn to code.  I’m not sure of what to think of the numerous responses and comments on the web.  Perhaps it’s a matter of people being too caught up in their craft.  Perhaps it’s simply vogue to disagree with Jeff Atwood.  Regardless, 90% of the responses are missing Jeff Atwood’s point.

When all you have is a hammer . . .

You don’t have to look around and see that multiple systems are horribly broken: education, healthcare, government just to name a few.  Entrepreneurs everywhere are and should be chomping at the bit to fix these problems.  There’s a hell of business to be made on solving these problems successfully and safely.  Code is not the way.

These industries have no shortage code.  Government has more code than they know what to do with.  So does healthcare.  Much of it is probably bad.  Simply throwing more code at it shouldn’t be the answer, especially if it’s bad code.  Jeff Atwood makes the point that the world doesn’t need more bad code by bad coders.  He’s right.

What these industries need and what Jeff is really advocating is solutions.  Code should be the last thing we’re all thinking about when we’re trying to solve the enormous problems plaguing them.  Code will most certainly be a part of the solution, but only a means to that solution once the important decisions have been handled elsewhere.  Code itself is not the solution anymore than a hammer and nails are the solution to housing problems.

Code if you want to . . .

Code if you want to learn to code.  Code if you really want a deep understanding of how computer programs work.  But if you’re going to delve in learn it well and learn it right.  Don’t learn “just enough to be dangerous” as the adage goes.  If you’re an entrepreneur, learn to find and craft solutions.  Solutions are always more than just code.  Once you have a good solution to horrible problem there will be no shortage of great coders to work with you and take care of the hammers and nails.