Tal Bereznitskey

Here’s a peek at my newest iPhone app:

The iPhone app I use the most is Waze, a turn-by-turn navigation app. Without it, I would probably never get anywhere.

Google Maps is great when I travel abroad, it really is becoming a great navigation app with tons of cool features.

There’s one problem both these navigation apps have, they lack the ability to enter a new destination during driving.

I always have to lie and say “I’m not the driver” while trying to tap the correct letters of my desired destination. It never works.

Drive Mode

Meet Drive Mode, the app that lets you speak and tell your iPhone where you want to go.

It listens and understands where you asked it to go and automatically starts navigating using your favorite navigation app with the destination you spoke.

It currently supports Waze, Google Maps and Apple Maps. It does not rely on Siri so you can use it on iPhone 4 and older devices.

Other than the coolness of talking to your iPhone, you can also keep your eyes on the road and drive more safely.

Download

The app is now available on the App Store.

We all want to write better code. One that is easy to read, understand and extend. Finding the path to good code might not be trivial and is sometime achieved by searching out side of the box.

This is the case with NSBackbone. It’s a sample project that takes inspiration from the successful javascript library Backbone.js. Building web apps with javascript and backbone.js can teach us a lot about keeping our code short, clean and simple.

One of the best things about Backbone is how predictable its code is. Each Backbone.View has the same structure. This makes the code dead simple to understand, no matter which view you’re looking at.

UIViewControllers however, are a different story. UIViewControllers are unpredictable. Some will refresh the UI on viewWillAppear where others will do so on viewDidAppear. Some will only update the UI once on viewDidLoad. We must hunt down all of the viewDid/viewWill methods and figure out what’s going on.

Although Backbone is not a 100% MVC (Model-View-Controller) framework, it still makes handling data and UI easy. Backbone makes it easy to observe changes to a model (an object holding data) and act upon them. We use this feature to ensure the UI is always showing the most updated data.

Backbone.Views are predictable. Take a look at the following typical view:

It’s very short, but accomplishes a very common and important task in apps. The task of keeping the UI updated to reflect the changes in the model’s data.

The rules I follow with Backbone:

1. A view renders the UI when it loads.

2. A view observes changes to the model’s data and re-render the UI.

3. User actions change the model’s data and not the UI. The UI will be updated by observing the model’s changes.

With these rules in mind, let’s rewrite the code with Objective-C:

(This amazing library is used to simplify the model observation code)

Take a good look at this code. The view is always updated no matter what changed the model. The model could changed due to action taken by the user or by an async network request, but no matter what - the view will reflect the changes. The user will see the changes as they happen.

It just works.

The NSBackbone project on github shows this concept in action. You’ll love it.

Please share your ideas about bringing concepts from different programming languages to iOS development.

I really liked the latest update of Backbone to version 0.9.9 which will probably be the last one before 1.0.

There are a lot of changes and tweaks, but what I really like are the changes/additions made to the Backbone.Events.

1. Global Notifications

Backbone now supports a global Pub/Sub notification system. The implementation is very similar to what I’ve suggest at a previous blog post (Backbone global notifications).

The Backbone object now extends Backbone.Events instead of adding another object onto it. Smart and simple.

2. Defeat memory leaks

If you’re new to Backbone then you probably don’t even know about the problem of memory leaks when binding to objects.

If you’ve been using Backbone for a project or two, you already know that for each .on you call on an object, you must also call .off in order to let the Garbage collector do its job. We always seem to forget this especially when Views are binding to Models.

Backbone now allows you to bind the other way around. A view can bind to a few model notifications and then unbind from all of them with a single call.

This is done with the view.listenTo(model, ‘event-name’, func) and view.stopListening(). The default remove() function of views will call stopListening() for you so you won’t forget.

3. Bind only once

Another cool new feature is binding to a notification only once. A call to once() ensures that the callback only fire once when a notification arrives.

4. Alternative syntax

Binding now supports a map syntax:

model.on({

    ‘change:name’ : this.nameChanged,

    ‘change:age’ : this.timeMachine,

    ‘change:height’ : this.newShoes

});

This is much cleaner than having three separate calls to .on and aligns well with the events hash used for Views.

Happy coding!

I remember when my team leader asked me if I think it’s possible to compile our C libraries for a new platform called “iPhone OS”. I said yes and my programming career took a 180 degree turn that day.

A new platform was born for learning, hacking and building cool stuff that could run on my super sleek new phone. When the iPhone SDK came out, I sat to write the first iPhone app of my company. I love working on new platforms and learning all I can about it. 

I read about every single article about iPhone development and found out that “Interface Builder” (IB) is not to be used by real men. I used to hand-code HTML and I knew how crappy those WYSIWYG editors were so I didn’t think this IB will be any different. Also, a builder tool is for newbies, right?

Read More

When I was looking for a javascript templating engine, I initially wanted to pick mustache.js for all templating needs. The syntax is ridiculously simple and it takes less than 5 minutes to integrate it.

Then I heard about handlebars.js and the precompilation feature won me over. This should speed loading times for the end users.

After playing with handlebars for a while, I wondered what’s the best way to integrate it into our web app development cycle. I googled, stackoverflowed, etc… but surprisingly, I couldn’t find decent information about the subject.

I opened my sketch-book and wrote a few goals for integrating handlebars:

• No build/compile step for development.
• Production code will use precompiled templates.
• No code changes required when switching from development to production.

Now that I knew what I was looking for, It was time to analyze handlebars behavior and write some code.

Read More