Tal Bereznitskey

iOS Apps: Keeping data over re-installs

Sat, 18 May 2013 12:27:52 -0400

I took my own advice and decided to create a Freemium version of Drive Mode and call it Speak and Drive.

The app will allow users to dictate 20 destinations to their favorie navigation app. After these 20 free uses, the user has the option to unlock the app for unlimited use with an In-App Purchase.

Where should I store this “uses” counter?

The easiest place to store this data is the NSUserDefaults dictionary. This is a big mistake since the user can trick the counter. All he has to do is uninstall the app and then re-install this. This will delete the NSUserDefaults entry and return the counter to 0.

Hello Keychain

The only place to store data that never gets deleted is the Keychain. The purpose of the keychain is to store sensitive data like usernames, passwords, etc. I’ll use it here since it doesn’t get deleted when the app is deleted.

Reading and writing to the Keychain isn’t as straight forward as writing to the NSUserDefaults dictionary. There is a lot of boilerplate and you got to deal with a lot of C code (the iOS SDK doesn’t provide a neat Objective-C interface for it).

Fortunately, the open source community is always there to save me. I found this amazing Keychain wrapper and it makes the Keychain work similar to NSUserDefaults.

Except for one small detail. It will only allow you to store NSStrings in the Keychain. I quickly created my own counter wrapper class:

https://gist.github.com/5604924

Now I can track the number of uses easily without letting people trick the counting system.

I suck at marketing

Fri, 03 May 2013 08:35:00 -0400

I have a lot of ideas for products. Some are really bad, others are quite good.

Once in a while a really good idea comes along. This is the product I build.

The last good idea turned into Drive Mode. A good product that solves a real pain for users. I also know that people are actively looking to solve this pain.

I created two versions of the app:

A localized version for my own country (Israel)
A multi-language version

Marketing is so easy

The localized version was so easy to market. I just sent a few emails to relevant blogs, they picked it up and so did the users. A national newspaper wrote about it and I was even interviewed for a popular TV show about it.

(I do have eyes in real life, just not in this photo)

The app is still a regular Top 10 ranked app in the Israeli App Store and it has a great rating score from a lot of users. Not my-friends-users, but real users who use the app every day (And I have the analytics to prove it).

Marketing is so hard

After conquering the Israeli market, I was sure I could repeat the same success in other markets.

So I took the “Marketing Recipe” from the localized version and applied it again: I sent the information about the app to as many blogs and review sites as I could. Not only to English blogs, but to French, Dutch, Italian and you-name-it language blogs as well.

It got a few reviews on those blogs, but it didn’t drive many users to download and use the app.

Those who did use it liked it. I know, they said so on the App Store: “Ottima”, “WELL DONE !!!”, “Perfect”, “Fantasticaaaaaaaa!!!!!!!!!!”, “Realmente práctica”, “Life saver”, “Handige app!”. (To be fair, there were some users who weren’t impressed by it, but they are the minority).

So here’s a useful product that people like. Why doesn’t it take off by itself?

I knew I had to do something about it. I started reading every blog post ever about marketing apps and marketing in general and took some actions. Still, I couldn’t reach the result I aimed for and that is suitable for the app.

What should I do next?

“What have you tried?”

Matt wrote a long time ago that after asking a question you might face with the “What have you tried?” question. I’m all up for that.

Here’s what I’ve tried:

I used Applaunch.us services to help me reach bigger review sites. It didn’t work.
I wrote on car/driving forums about the app. I don’t regularly visit these communities, so my posts were not welcomed there (I asked for permission before posting about the app. Most told me “Thanks for being honest and asking for permission, but please don’t advertise on our forums”).
I dropped the app price to attract more downloads. It didn’t work. People were either willing to pay or not. It wasn’t about the price.
I posted a few posts on hacker news about it.
I updated the app to support more navigation apps. That didn’t change much (Most users did upgrade to it).
I’ve tried using Google Adwords to attract traffic to the app landing page. Unfortunately, Google did not approve the keywords I was targeting (They didn’t like “Siri” nor “Google Maps”).
I’m currently looking at Twitter ads as well. I love Twitter and I hope this might actually work.

What’s next?

I have a few ideas for my next steps.

People like the app once they download it, but not many are willing to give it a spin. I could create a new lite version of the app and give it away for free. It will support X operations and users can unlock it with an In-App Purchase.

Friends told me that the app name should be better and that it should say clearly what the app does. The current name is “Drive Mode”. The idea was that when you get on an Airplane you use “Airplane Mode” and when you start Driving you use “Drive Mode”. I might change the app name to something like “Speak and Navigate”, “Speak and Drive” or similar.

Other than that I’m quite lost. I suck at marketing.

Do you have an idea?

I would really love to hear your ideas about what can/should be done. Please leave a comment below, I read and answer every single one, always.

You can download it for free with one of these app promo codes:

(1 2 3 4 5 6 7 8 9 10)

Remote control your iOS app

Sat, 27 Apr 2013 16:14:28 -0400

If you’re in the business of developing iPhone apps, you probably already know that app version upgrades are a pain. Each app upgrade must go through Apple’s app review process which takes 5-14 days.

That’s the reason why I always add remote configuration to my Apps. I call it a “Remote control” for apps.

Remote Control for apps

What I do is include a JSON file as my configuration. It controls everything that can be configured: supported languages, number of items to show per page, colors to use, etc.

Once a day, the app connects to my servers and pulls a new version of that configuration JSON file. This way, I control the configuration from my server. I can change my app behavior whenever I want.

This is how it saved me with Drive Mode, my latest iPhone app:

Drive Mode is an app that let’s you speak and control navigation apps with your voice. It supports various navigation apps. The integration with one of the apps, Navigon, was buggy and didn’t work. My super nice users sent me feedback about it and asked me to fix it.

Since it is all remotely-configured, I just had to change a string in my JSON file and upload it to my server and BOOM! Every user gets this update instantly.

I managed to fix the issue in one hour instead of 5-14 days.

I can also add support for new apps without having to submit a new app to the App Store. Now that’s a competitive advantage.

Do you want something like this for your app?

This is so simple to implement, so I wonder why it isn’t part of the iOS SDK (something like NSRemoteUserDefaults). I’m thinking about open sourcing this or maybe making a small (free) hosted service to handle this for everyone.

Let me know if you’re interested.

My [disappointing] experience with AppLaunch.us

Fri, 12 Apr 2013 11:31:00 -0400

I used the services of AppLaunch.us exactly twice: for the first time and the last time.

I first heard about AppLaunch from the popular weekly newsletter curated by Dave Verwer (@daveverwer), the iOS Dev Weekly.

It was a sponsored item and as I truly respect Dave’s work, I concluded that AppLaunch.us could help me market Drive Mode, my latest iPhone app.

AppLaunch.us is a tool for easily getting your app to the press. I decided to try their most basic package costing $55 and see how it works.

I filled all the information about my app, payed and got a confirmation email telling me that my submission arrived successfully. They also said I can contact them with what ever questions I had.

After 4 days of hearing nothing, I contacted them to ask what is the roadmap for the campaign. I was never answered. Three days later I got a generic email stating that my campaign started. On that day I got 7 more identical emails saying that my press-kit was downloaded by a review site.

I waited a few days to see if a review site will contact me, or post anything about the app, but nothing happened. It’s okay, maybe the app wasn’t interesting enough.

I tried contacting AppLaunch.us asking about the state of the campaign and exploring what else could I do. It was never answered.

I logged in to their website, but there was no info for my account, just stating that the campaign is in “Preparing campaign” state.

After a few more days, I tried contacting them again. Guess what? They never answered it as well.

It was now 3 contact attempts and 0 answers.

After about two weeks, AppLaunch.us website had been redesigned and now the account page shows statistics about the campaign. Here it is:

140 Reviewers have read the launch email
6 Reviewers have viewed the press release
13 Reviewers have downloaded your Press Kit
0 Reviewers have requested a promo code

Pretty much a campaign failure, but this is not their fault.

I did however try to find one developer saying AppLaunch.us did work for him, but I couldn’t find anyone. Finding people saying it didn’t work for them was much easier.

As Apple would say it: It just doesn’t work.

On my own

Okay. Anyone can send an email pitching an app to the press, right? That’s exactly what I did.

The results:

21 email sent
4 reviews posted

So without “press connections” and reputation I got more reviews than a service that “specializes” in this operation.

My suggestion: Do not use AppLaunch.us! Do it on your own.

The part-time indie developer

Sat, 16 Mar 2013 08:55:40 -0400

I’m a “Full-time software developer” for a startup company. I wake up everyday and drive to work where they pay me to work on my hobby. I develop iOS and web applications that lots of people use everyday. It’s a great job and I consider myself to be very fortunate.

When my work day ends, I go home and become a “Part-time indie developer”.

So what is a “Part-time indie developer”? I’m not totally sure myself as I just came up with this title a few minutes ago. Basically, if you’re working alone on $0 budget side-projects in your free time then you are one. I am one.

Why do I keep working on my free time? That’s a great question. The truth is I get the urge to create new and useful stuff that are out of the scope of my workplace. I can work on whatever I want without thinking if it’s a waste of time or not.

Creating apps is not a one-man’s mission. The process includes coming up with an idea, validating the idea, designing the app, developing the app, QA testing the app, marketing the app and providing support for the users. As an indie developer, I love doing all of these myself.

Why? Because I love acquiring new skills. Validating an idea is an important skill to have at any level. Designing an app from scratch is a great UX/UI school. Marketing an app is a great way to learn marketing.

Being a one-man-army is not the only challenge. The real challenge is transforming your idea into a working product you can tweet about. And for this to happen, you have to play your cards right. The most important card you have is time.

Time is scarce and this leads to choosing certain kind of projects to work on. This is the single most important thing I learned: Small ideas win. Small ideas can be translated into small projects. Small projects can be completed in a short time. Completed projects are a success for a part-time indie developer.

Yes, the part-time indie developer must be a passionate, versatile and effective creature.

Challenge accepted!

New iPhone app - Drive Mode

Mon, 25 Feb 2013 16:18:55 -0500

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.

NSBackbone - Porting Backbone.js concepts to native iOS Apps

Sat, 22 Dec 2012 18:20:00 -0500

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:

https://gist.github.com/4361743

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)

https://gist.github.com/4361749

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.

4 Changes in Backbone.Events you should know about

Sat, 15 Dec 2012 03:48:29 -0500

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!

8 Reasons why real men DO use Interface Builder

Sun, 30 Sep 2012 11:37:00 -0400

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?

So the entire iPhone app was hand coded with beautiful segments of code to alloc views, init them, set their frame, color, alignment, alpha value, text when they are normal and text when they are highlighted, connected buttons to actions and let scrollview know if they should be paging or not. Very fun.

Seriously, I think 70 percent of the code was doing UI work. 90 percent of my time was shuffling pixels from one line of code to the other. I had so many #defines and static variables so the code would be… neat… and of course it wasn’t. Should I use the Interface Builder? Hell no, I’m a real man.

One day I decided to use the IB for our next upcoming feature. Just to try it out… it wouldn’t make me less of a man. That was a good decision. I found out that the IB is a time saver, a clutter saver and a pixel-nazi’s best friend.

From then on I I set a goal: “Always use the Interface Builder, unless impossible”. And so I did. I had my chance at working on some crazy, customisable, non-standard UI so believe me when I say that almost everything can be done using the IB.

Interface Builder is not a crappy WYSIWYG HTML editor. It will not make your code worse. It will not break when you upgrade to the next version of Xcode. It’s the suggested way to build the app UI, and real men DO use it.

Not convinced yet? Here’s the full list of reasons (IB > code) when it comes to UI:

1. Easy prototyping

When you just want to play around with an idea, you can use IB to drag and drop views and get an overall feel of your next feature.

2. Easy changing stuff

Oh, that view is a few pixels off? Let’s move it a bit to the left. IB is much faster at this then the usual loop of changing-values-in-your-code, running it on the simulator, rinse and repeat…

3. Less code

How many lines does it take to configure a label? At least 6: One for alloc’ing it, another for sizing it, another for an alignment mask, add one to choose a color, another for choosing the correct font, oh and don’t forget a line for setting the actual text on the label. Yes. you can throw this entire code away.

4. Easier to maintain

Once everything is configured, you can let your grandma play with the IB to change stuff. I don’t let my grandma touch my UI, but if my product manager asks for it, he can open the UI in the interface builder and have a kick at it.

5. All options are revealed

Do you know everything a view has to offer? When coding, you’ll have to lookup the header file or documentation of each and every parent-class of the view you’re creating. With IB all options are in front of you, so you can’t miss a feature like auto-sizing, text-shadow, content-offsets and others.

6. One for iPhone and one for iPad.

Creating a universal app? You can use a dedicated XIB for each device that uses the same class. Some people even use this feature to design one UI for portrait mode and a different for landscape.

7. Educate your designer

I showed my designer the IB and let him play with it a little. Once he figured out how I’m going to “build his PSDs”, he understood how to cut them into beautiful PNGs, all ready to use.

8. What can’t be done with it, can be done without it.

Yes, some things are impossible to achieve with the IB. For example, reusing a UI control from a different Xib is not yet possible. So what do I do? I create everything in the IB and connect them in code.

Today I added code so my button will use a stretched UIImage as its background. So the UIButton was all configured in the IB expect for this tiny unsupported feature. The point is it all plays along well.

Some people would suggest dropping the IB completely over this. They are plain wrong! It’s okay to turn to code when things are not possible. Maybe the next version of Xcode will allow it.

IB > Code

To sum it up: use IB whenever possible, but do know how to build the same UI using code. You’ll need both skills to create a killer, easy-to-maintain app.

Handling handlebars.js like a pro

Sat, 09 Jun 2012 09:24:00 -0400

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.

Compiling templates at runtime

The usage of handlebars consists of three steps: (1) reading a raw-template, (2) compiling it into a javascript function and (3) running the compiled-template with the desired arguments:

https://gist.github.com/2900899

This is suited for development, where raw templates are edited all the time.

Precompiling templates

The idea of precompiling templates is to eliminate step 2 from runtime. We do this by performing step 2 in an earlier build step called precompilation.

When you precompile a template, the raw template must reside in its own file with the .handlebars extension.

For this example, I created a file named hello.handlebars with the following conent:

<p>Hello {{name}}</p>

Running the handlebars compiler from the terminal is easy:

handlebars hello.handlebars -f templates.js

Include the output script (templates.js) in the html file to get access to the templates. The templates are attached to the handlebars.templates object. Since my file was named hello.handlebars, it will set the compiled template as the value of the ‘hello’ key.

Here’s how to use it:

https://gist.github.com/2900902

This is great for production code where templates aren’t changing at all.

The handlebars compiler can be used to compile multiple raw-template files into one templates.js file. Place all your .handlebars files in one folder (let’s name it templatesfolder) and issue the following command:

handlebars templatesfolder/ > templatesfolder/templates.js

So if you have hello.handlebars, goodbye.handlebars and you.handlebars in that folder, the output will be Handlebars.templates[‘goodbye’], Handlebars.templates[‘hello’] and Handlebars.templates[‘you’].

Mixing it together

How do we mix the development code with the production code?

We’ll create a wrapping method that returns the compiled version if it’s available. otherwise, it will fetch it (read the input of the raw template file), compile it and return it to the caller.

I call this function getTemplate and It’s going to be attached to the Handlebars object. Let’s see how the final code will use this function:

https://gist.github.com/2900942

Let’s implement the getTemplate method in an empty templates.js file:

https://gist.github.com/2900905

There are a few things to note here:

1. I used JQuery’s GET method in a synchronized way since the caller is expecting the template as the return value. This will somewhat degrade performance, but only in development mode. Since most developers use their own localhost for development, you should not feel any difference.

2. The use of jQuery’s GET requires that you host your site on a local server and not from disc (meaning: http:// is good, but file:// isn’t).

3. Once a template has been compiled at runtime, it will be added to the Handlebars.templates object (same way as the precompiled templates). The next time the template will be asked, the function will return it immediately.

Wrapping it up

So now that we have our getTemplate method residing in the templatesfolder/templates.js file, we need to precompile our templates and add them to the end of the templates.js file:

handlebars templatesfolder/ » templatesfolder/templates.js

The templates.js file now contains both the getTemplate method and all the compiled templates. When getTemplate is called, it will already have all templates compiled under Handlebars.templates and will not have to fetch/compile anything at runtime.

Summary

There are four steps in order to get handlebars working:

1. Include templates.js in your html after the handlebars.js script

2. Use getTemplate to get a compiled template.

3. Run the handlebars precompiler before delivering build to production.

A few more tips

1. You can optimize the templates with the compiler options:

handlebars <input> -f <output> -k each -k if -k unless

2. Since your templates are already precompiled, you can use the slimmer version of Handlebars (handlebars.runtime.js) on your production. It has a smaller footprint and will load faster.

Have fun!

The Android developer who made me a better iOS developer

Sun, 27 May 2012 18:47:50 -0400

The iOS app I’ve been working on lately was given a hugh feature redesign, making it beautiful but a bit more complex. I was happy with the result and how I overcame all the hurdles along the way.

A few days later, right when the entire team was about to leave the office and head home for a long weekend break, the Android developer showed off the same redesign on his Android device.

It all looked great and was blazingly fast and smooth. Much smoother than the experience on the iPhone. How did he do it?

I felt really bad. How didn’t I notice the iPhone was lagging and non-smooth? How did I let this happen?

[One geeky paragraph ahead, skip it if you hate nerds]

So I sat down and started debugging the hell out of it. Am I using too many subviews? Are the table cells not cached? Are the text labels not opaque? Is the scroll-spying code slowing everything? After a bit of digging, I found out it was Core Data. Database reads were taking place while scrolling, and that’s… bad (and slow).

I found the problem and fixed it. I now know there’s plenty of other areas were I must ask myself if there’s a better way to do it. Now’s the time to fix myself.

So thank you Mr. Android developer for making me sweat and work a little bit harder.

Booleans are free. Use them.

Fri, 04 May 2012 07:42:05 -0400

Last week a co-worker asked me how I implemented a certain feature in our product. I couldn’t really remember all the fine details of the implementation so I loaded the file into the editor and we sat to read it together.

The code was actually good and I didn’t feel I had to “protect” it by saying it was done under pressure and other excuses I use often. He read the code and said “Oh, I see what you’re doing here. Thanks!”.

The one thing that made the code super readable can be summarized by this programming tip:

Booleans are free. Use them.

Here’s an example:

Look at the following code:

https://gist.github.com/2594221

Your brain has to concentrate on unimportant things like expressions, math and pixels in order to figure out (=guess) what the if statement is trying to do.

This is much easier on the brain:

https://gist.github.com/2594243

This code is easier to read as the intention is “injected” into the code explicitly by naming the if statement with a boolean.

An added bonus is making the surrounding comments obsolete (=delete them). The code is practically documenting itself.

Backbone.js global notifications

Thu, 15 Mar 2012 14:23:00 -0400

I was looking for a way to allow two Backbone.Views to exchange information between them.

Here are some solutions to this problem:

1. The bad idea

We could just let them reference each other. Then view1 could say this.view2.doSomething() and it’s the easiest way to solve this.

However simple it may be, this will lead to a very tight coupling and a very bad design for our web app. If we have a circular dependency, we should probably rethink our design.

2. The good idea (that doesn’t always work)

We could have a model and share it to both views. One view will bind to an event on the model, and when the other view does something important, the model can trigger the event.

This is great except that a Backbone.View can only hold one Backbone.Model at a time. In many cases the two views will need to reference different models.

(Yes. I know that a View can hold extra models by ‘view.model2 = new Model()’ but this seems to stray from the convention)

Another weak point of this solution is that someone (probably the router, or a custom controller object) will have to create the model and hand it off to the two views. And if one of these views has subviews, we will have to pass it on to them and the chaos takes over.

3. The better idea

We could create a global notifications system where any object can bind to global events and any object can trigger a global event.

So instead of the first view registering for events triggered by the second view, it can register for global notifications.

This can be easily done by adding a Backbone.Notifications object:

https://gist.github.com/2045615

Now we can let the first view bind to a global event (in this example: SomeViewRendered) and the second view can trigger it.

https://gist.github.com/2025061

Seems to work, it’s easy and it creates a very decoupled interface between the different Backbone objects.

More uses

We can also use this to ask the Backbone.Router object to navigate somewhere else without direct calling it. Something like this:

Backbone.Notifications.trigger(‘navigateRequest’, ‘/task/50’);

A router can bind to this notification and act upon it. This allows any object to request anything from the system and if another object can provide it, it will magically happen.

Is this Neat or what? What do you think?

Adding custom Getters and Setters to Backbone models

Thu, 23 Feb 2012 15:37:00 -0500

I started using Backbone.js for web development. It’s a really great framework for structuring your javascript code.

After digging in further, I figured out Backbone models are missing one important feature: custom Setters and Getters.

Sure, you can add functions like “getFullName”, but Backbone internal functions (like .sync and the defaults hash) will never know about it.

Fortunately, Backbone can be easily extended by writing plug-ins.

So here’s a plug-in that adds Getters and Setters to your Backbone.Model(s), hosted by github:

https://github.com/berzniz/backbone.getters.setters

This will allow you to define a function for each attribute’s getter and setter.

Export your AppAnnie data

Mon, 16 Jan 2012 18:35:00 -0500

I love AppAnnie. If you don’t know them, you should.

Here’s what AppAnnie say:

More than 75,000 Apple App Store apps trust App Annie Analytics to track their downloads, sales and reviews completely for free.

I am one of those 75,000 App owners who trust them with my data.

And if it is in fact my data, then I should have the ability to export it to my computer, right?

Well, not really. App Annie doesn’t have this option. It doesn’t even have an API.

So let’s hack together an “Export API” for them, shall we?

(Updated: Thanks Nick for providing the new method in the comments.)

1. Login to your AppAnnie account:

https://www.appannie.com/account/login/

2. After login, navigate to

https://www.appannie.com/care

3. Choose an account and go to “All Apps” page.

4. Take a look at the address, it should be:

https://www.appannie.com/sales/YOUR_ACCOUNT_ID

5. You can get your revenue data by navigating to (replace YOUR_ACCOUNT_ID with your actual account ID from the previous step):

https://www.appannie.com/sales/revenue_data/YOUR_ACCOUNT_ID/?type=revenue&s=2010-01-01&e=2013-01-01

You can get your units data by browsing to:

https://www.appannie.com/sales/units_data/YOUR_ACCOUNT_ID/?type=units&s=2010-01-01&e=2013-01-01

As you can see, the time frame is set in the URL. I set it from 2010 to 2013 so I get some extra unimportant data, but you can change the dates to fit your needs.

The result will be a JSON string. To be more precise, it is a JSON string followed by more data. Just look for a “ —end-data—” text and copy everything before it (excluding it) and you will have a valid JSON data.

You can now paste it into a JSON viewer to nicely view the reports.

A few notes:

You will need some coding skills to turn this JSON to an excel sheet. Not rocket science.
If there is a demand, I can hook up a script to do all this for you (get the reports and turn them to an excel file with a single click).
All the information in this post is current to the day of the posting, AppAnnie might change their URL or data structure at any time and this blog post will be obsolete.

Get your data while it’s hot!

Don't be a liar! and 4 other tips for iOS graphic designers

Fri, 23 Dec 2011 08:58:00 -0500

As an iOS developer I had the pleasure of teaming up with awesome graphic designers to create iPhone and iPad apps.

I try not waste their time, and make sure they don’t waste mine. So I came up with a list of tips that will keep us productive and happy.

If you’re a designing for iOS, the following tips I shared with them will probably save you hours of work as well.

1. Don’t be a liar!

Nicholas Felton, the infographics guru who was behind the Facebook timeline design, suggests to be honest with your mockups:

“As a designer, you have your baby that you want to try and sell. To make it saleable, you might pick someone who has really nice photos in their profile and use that to make your mockups, but you’re ultimately just lying to yourself and the rest of the group if you think everyone’s page is going to look like that.”

This is the most important tip you must remember. When creating a screen mockup, imagine how it would look like when not all the information you wish to display is available.

Why? Because real life data is mostly incomplete, too short or too long and will mess up your pretty designs. Research how the real life data looks like before(!) you launch photoshop and make designs that flatter the real life data.

Once you stop being a liar we can progress to some specific iOS related tips

2. Sit with an iPhone developer at least once

After designing the first screen of the app, ask me to sit down with you and show you how I turn your static graphics into a living app. Ask me to open up XCode interface builder (the tool for creating iOS user interfaces) and see how your graphics are applied in real time.

Your graphics will have to be turned into buttons, labels, text-area and other controls. It will be a good idea to get familiar with the work needed to be done in order to turn your graphics into a living app.

If you’ll sit with me, I’ll show you that buttons have 3 states (normal, highlighted and selected) each needing a different graphic, that every text on screen must be defined with font/color/decoration/size and many other helpful information.

3. Generalize your art

If your design includes a few buttons with the same style, but different labels (“Done”, “Go”, “Cancel”, etc.) you can just drop the label and deliver one blank button.

As a developer, I prefer using a blank button and attaching the label to it myself. This allows me to create a “Search” button without emailing you and asking for a new “Search” button. Less work for you.

Don’t forget to tell me which font should be used for the label of the button, or I’ll have to use Comic Sans just to piss you off…

Go with this concept further, if you have the same graphics repeating with a small change in each one, you should generalize it. I will add the finishing touch myself.

4. Fonts and placement

I’m an idiot, I need to be told exactly what to do. If I get a graphic design from you with a title on the top, I must know a few things: what font is used? is it bold? what RGB color is this? and some more.

To answer my questions, please add an accompanying text file that looks like this:

The title on the top is Helvetica Bold, 17.0px in size, the RGB color is #FFBBGG and it’s placed 15px from the top and should be centered horizontally.

The name of the song is Helvetica, 12.0px in size, the RGB color is #FFFAAA and it’s placed 5px from the top and 25px from the left.

And so on…

5. Delivering your files

I’m lazy. All I really want to do is take your files and add them to the project. In order to do that, here are my demands:

Organize.
Each screen should have it’s own folder with the screen’s name. Each folder should have a screenshot of the whole screen so I will understand how the final result should look like. The rest of the files in this folder are the elements cut into pieces: buttons, cells, borders, whatever, each separately in its own file.
Be consistent.
All graphic files must be PNGs.
Understand iOS graphics.
Each graphic file must have two versions: an high-res version and a low-res version. The first version will be used for iPhones with retina display (iPhone 4 and later) and the second version for non-retina display devices (older iPhones and iPads).
Name Clearly.
The low-res version should have a good descriptive name such as BigBlueButtonNormalState.PNG and the high-res version should have the same name with a @2x suffix: BigBlueButtonNormalState@2x.PNG - The @2x suffix is read by the iPhone and used if retina display is available.
Size correctly.
The high-res version must be double the size of the low-res version. If the low-res version is 100x150 pixels then the high-res must be 200x300 pixels. Now I know you create the high-res version first and then downscale it, so just make sure your high-res version is even (width has even number of pixels and so does the height).

These demands are tough, but will earn you the “Best designer ever” badge.

Thank You for being awesome!

Designers are always awesome when applying these tips. Be awesome!

Don't call yourself an iOS developer if you don't know these tools

Sun, 11 Dec 2011 16:19:00 -0500

Here are 4 tools out of my iOS development toolbox. They’re all free and great!

Unretiner

Are you developing retina aware software? If so, you probably know that you should use two versions of each image resource in your app. An high-resolution version with a name of image@2x.png and a low-resolution with a name of image.png.

Unretiner will take an high-resolution image and create the low-resolution image for you automatically. Just drag the images (click the + button if you’re developing on Lion, dragging has a bug) and get the resources already renamed for you.

MOGenerator

Core Data can sometimes be hard to manage, especially creating and updating Obj-C objects for your custom entities. MOGenerator will change all that by creating the objects for you.

The best part is the separation of machine-objects and human-objects. Let MOGenerator manage the machine object and focus on the logic of your app in the human readable objects.

OCMock

If you’re into testing your code (good for you!) then you’ll probably like OCMock very much. With a few lines of added code you can take your regular class and replace methods with test-methods, verify that specific methods are getting called and much more.

MadRuby

This app has nothing to do with iOS development directly, but it is very helpful. MadRuby is a keyboard macro recorder. You can use it to record your keyboard clicks and then play them back multiple times.

Know other tools? Let me know.

Learning is not (just) reading blogs

Tue, 06 Dec 2011 16:37:28 -0500

I spend a lot of time on the web reading great blogs. I like to read anything about technology, from founder’s stories for inspiration to low-level technical articles.

That’s a good way to learn about new trends and get new ideas, but the only way to learn a new skill is by doing.

I also believe that the best way to learn anything is to actually create something useful and not just an “Hello world” half functioning program. Creating a small product will push you to dive deeper and the end result is you’ll learn more.

That’s why I love spending some of my free time to hack small side-projects. About six months ago I set my goal at creating an iPad app that will be super-fun to use. I decided to create a web browser that would suck less than Mobile Safari.

The idea was to load webpages blazingly fast by throwing away unneeded content like, let’s say, images and advertisements. The end result was BrowseBear and it was released for free.

It wasn’t very successful since it doesn’t, well, render webpages, but it still got some kick-ass reviews on the App Store.

“Great! - Only app I have found which truly does speed up browsing times, it has replaced safari’s place in my iPad :) (sorry safari!)”

“UnBEARable not to have - DOWNLOAD THIS APP. IT’S COMPLETELY WORTH THE $0.00 I PAID”

The most important thing was that I had fun making it and it helped me learn new iPhone development skills. I use these skills on a daily basis at the start-up I work for.

One thing I need to do more is push myself to languages and platforms I’m not familiar with. The next time I take a shower and have an idea, I’ll sit down and implement it with a technology I don’t know.

Take the time to read the web, but leave some time for real learning by doing.

Go Do!

Breaking the rules is allowed

Sat, 03 Dec 2011 18:39:00 -0500

If you’re not into programming, stop reading this post now.

A few weeks ago I showed my code to a colleague and as always, I knew exactly where my code was great and when it was a complete mess. My friend shared some programming tips and I enjoyed the code-review and learned from it.

However, we got into one disagreement: every method in my code tries to “Fail fast” and exit as quickly as possible. Just as I was failing non programmers on the first line of this blog post above.

Failing fast means you’ll see many return statements in any function I write. He claimed that it’s a convention and a known coding standard to use one and only return statement in each method. “Just ask anybody.” he said.

I couldn’t disagree more, but I thought it would be a good idea to ask the community over at stackoverflow. As always somebody already asked that, more than once. There isn’t a definite answer there, but the general idea is that this rule was correct for older programming languages.

The goal of coding rules is to make programming easier. And by that I mean reading and maintaining the code should be as simple as possible. If a rule tells me to do the opposite, I break it.

Rules get old as programming languages evolve. Evolve with them and break the old rules.

Not having fun? You probably need a new job

Sat, 26 Nov 2011 10:08:20 -0500

I remember creating my first computer game at the age of 11.

The game was an *amazing* simulated football game, programmed in Basic on my beloved Atari. Essentially, it was a black screen with a timer running up to 90 (simulated) minutes. Footy events like goals, free kicks and red cards were randomly plotted to the screen.

I was the only one to ever play it, but even so, I was very excited. I actually had an idea for something, I convinced myself I could pull it off and so I did. Above all, I had fun programming it. About 11 in a scale of 1 to 10.

Soon later I found out about Championship Manager, a game with the same basic idea, which quickly became my favorite computer game.

I’m now a grown-up myself (and act as one most of the time), finished university and spent a few years working for a big software company. I developed solutions for un-trivial problems while working there and was always proud of the result, but something was missing. I missed the fun-factor of programming.

I recently joined a small startup writing it’s first lines of code for a new awesome product. When I sat down to write the first line of code I realized something. Developing new software for a company is much like hacking a small video game when you’re eleven.

There’s an idea, you visualize how it can be done and you do it. Starting with an empty project and growing it into a product people love. It felt just like those Atari hacking hours after school when I was a kid. The fun-factor was back.

It was fun clicking that “New Project…” button in my editor. It was fun seeing the product come to life. It was fun seeing the first user signs up for our system. It was fun spotting people use the product in real life and it’s fun getting great feedback about it from our users.

How much fun are you having at work? if it’s somewhere below 11, you might need to find a new job.