Toran Billups

Unit testing basics in objective-c

05/04/2012

Tomorrow I’m giving my first in depth objective-c talk on unit testing and I decided to produce a screencast of the content for those who can’t make the event.

I decided to keep this presentation religion free and to the point. I wanted to show unit testing in action from the very basic substring examples to parsing JSON. This along with a light introduction to the ocmock library proved to be more than enough content for a 60 minute unit testing introduction.

As always, if you want the code from this presentation you can find it on github.

Direct Download (mp4)

If you make it to the event please leave a comment with some feedback!

Automatically activate your virtualenv

04/22/2012

Since I started writing python last year I’ve spent the majority of my time developing with virtualenv. This is a great way to silo your python environment from system python so you run different versions of a dependency without having to worry about upgrading every app that’s running on your development machine / production web server / etc.

One of the annoying things about working with virtualenv on your development machine is that you need to explicitly "workon" or activate the python environment each time you open a new terminal window or change directories. This got me thinking -why not write a simple bash script that would automatically activate a virtualenv when it found one that matched the directory name.

The above can be put into your .bashrc file if you want this same auto workon behavior I was looking for. The script does assume 3 things

You only consider a directory that has a git repository
You must name the virtualenv the same as the directory that contains your project
You want the script to deactivate one virtualenv and workon another when you switch between different project directories

I decided to be a little more strict about when to auto workon a virtualenv because this script runs each time you execute the "cd" command. So by first making sure you had a .git file and second by making sure the name even existed as a virtualenv on your system it might save some would be wasted effort trying to activate something that wasn’t needed or didn’t exist altogether.

How to export your first signed android package

03/01/2012

The first time I went to publish an Android app it was unclear how to export an apk. I also thought if the app was free I wouldn’t need to do anything special to the final apk, but as it turns out you still need to sign the apk before the google market will let you upload it.

The video below is a simple walk through showing how to version/build/sign/export your apk for the google market. It’s under 5 minutes and straight to the point.

Direct Download (mp4)

If I left anything out be sure to leave a comment.

Making the case for native mobile app development

02/20/2012

Developers seem to be in two camps these days. There are those who feel native mobile development is the way forward, and those who feel it isn’t. This topic has been close to me recently because I was asked to play an advisory role for a mobile project internally. And strangely enough I found myself on both sides of the issue.

So what’s the problem with native mobile app development anyway? Over the last year I’ve built several mobile apps across iPhone/Android/WindowsPhone and I can tell you from experience that maintaining a code base for each platform sucks. It goes against everything great programmers know and love: DRY (do not repeat yourself).

So naturally software developers and vendors started to build tooling that would allow for a single code base. And the idea is spot on. Why write a feature X times when I can write it once and have a compiler build the native code for me? (Or just use html/js/css to build a webapp and tunnel it through the various browsers)

The problem with this wonderful idea is that in practice it never lives up to the hype/promise. And because I couldn’t find many objective posts about why to build native I thought I’d take the time to compile a list that I used internally to settle the "native vs web/hybrid" debate.

Performance

I was reading a great post recently on the 37 signals blog about how they got Basecamp vNext to be so blazing fast. One of the great points made in the post speaks to performance as a feature and I firmly stand behind it.

Speed is one of those core competitive advantages that have long-term staying power. As Jeff Bezos would say, nobody is going to wake up 10 years from now and wish their application was slower. Investments in speed are going to pay dividends forever.

If you have ever used an app built with one of the web/hybrid tools you know what I’m talking about. You click a button and it seems to be less responsive than the native counterpart. You scroll a list view and notice the lag as new items are presented on the page. You transition to another part of the app and you see what looks like frames dropping.

Anyone who thinks performance isn’t a feature in the mobile app eco-system isn’t part of one. For our sake devices are getting faster with each hardware rev, but clearly native code will always be a step ahead of anything else. (Isn’t that why most game development is still done in c/c++)

Consistent User Experience

I downloaded my banks iPhone app recently and the moment I opened it I could tell it wasn’t a native app from the look of the buttons and other navigation elements. Turns out they just tunneled their mobile website through a UIWebView so it didn’t have any of the usual iOS buttons/date picker/tab navigation/etc. But naturally I thought to myself "I’m not the average iOS user, so this astetic is surely something only hardcore iOS geeks like myself look for in mobile apps".

But that illusion vanished recently when I started working with a group of business people to design our companies first mobile app. They not only recognized native iOS and Android components, but asked for them by name/description. One specific example is the UIDatePickerModeDate for iOS. It spoke volumes that normal iOS users loved the native look and feel of controls like this.

It’s no secret native controls provide a better user experience but how can you justify writing a code base for each platform? You can justify this because the goal of your mobile app should be to provide a great user experience. Initially this may sound like fluff or something your "UX guy" might say around the office, but in reality if you aren’t the app consumers "want" to use, they won’t use the app at all. Or worse -they will go to a competitor (me and my banking app for example).

Close To The Metal

I was talking with a friend recently who is big into the web/hybrid app ecosystem and he was showing me an issue he ran across with one of these popular frameworks. It was a simple cosmetic bug that didn’t effect the functionality of his app in any way, but it bothered him regardless.

Now that issue specifically could be found in the open source code base and fixed because it’s javascript or css related. But this did get me thinking about what level of control the web/hybrid solutions offer today. On the iPhone for example you are doing everything inside of a UIWebView. Because you are working on a layer above the native stack you only have so much control over the micro optimizations you are allowed to use when your app needs it for example.

I always find this interesting because one part of me says this is no big deal and you could do any optimization in javascript if needed. But the reality is you are already working in a sandbox and in the case of the iPhone you can only go as fast as the UIWebView will let you. If the complexity of your app starts to grow and you find that you need to optimize something you’ve already given up a great deal of options because you only have the UIWebView available to work with.

Another great example is when you need access to the platform specific features like location, camera, photos, native maps, gyro, address book, etc. Unfortunately I can’t speak about how easy/or hard it is to access these from web/hybrid solutions because I don’t have any experience first hand. I can say conceptually these things should be easier to work with from native code because you don’t have to work with a generic / lowest common denominator api that may limit platform specific functionality.

At first glance, this may appear to be a minor issue on my list but as I started to think about how applications grow over time I realized the more options you have on a technical level the better. And with mobile apps, native development offers the most control today.

Better online support

When I started building mobile apps the first thing I did was bookmark stackoverflow (as if it wasn’t already the defacto). As someone who has spent the last 18 months learning 5 platforms I can tell you from experience that the dedicated people on stackoverflow can really provide a way forward when you get stuck learning a new language or platform.

A simple search for questions about objective-c turns up 72,825 results. The same search for phonegap questions results in 4,184 results. This metric alone makes me want to stick with native app development for the simple fact that it has the most online resources available.

That’s not to say other open source tools/vendors won’t have great support but from the numbers it’s clear the majority of mobile development is done in native code today.

It’s an eco-system not just a language

If you want to hear a developer throw something/cry/punch you in the throat just ask them to learn objective-c. The programming language has a bad name in the community that doesn’t know much about it. I’m guilty of this myself. Before I even started learning objective-c I was prepared for the worst programming experience known to man.

And I spent a great deal of time learning how to build my first iPhone app, but looking back it wasn’t because of objective-c. It was the entire eco-system ...

Cocoa Touch
Objective-C
Xcode
Interface Builder
Learning the iOS 3/4/5/vNext apis
Provisioning DRM to get my app into the store
How to avoid rejection in the App Store

I would argue that most people who just want to avoid objective-c might find that a great deal of time is spent on the iOS platform/ecosystem and that isn’t necessarily something web/hybrid frameworks get you out of completely. Especially if you are using a cross compile (non web) based solution like Mono Touch, you may get to write everything in c# but you still need to learn all the apis / front-end components to build an app.

Learn from my mistakes

When I started my recent project I thought that maintaining 2 or 3 codebases for a single app was nuts. A large part of the reason I feel this way is that on a personal project I was rewriting core domain logic in each app. This wasn’t a good idea because any time the business logic changed I found myself in 3 code bases.

Looking back now it’s clear I should have abstracted that core logic to some type of REST api so I could avoid rewriting the same code 3x. This way the bulk of the native code I write in each code base is platform specific user experience / like front-end code. The stuff that provides the true value add for mobile in the first place. If you don’t need this type of application experience and your business can compete with "just another app" then maybe native app development isn’t the right fit. But for those of us who want to make a run away hit, native app development is the best option today.

The year I thought I wanted to be a mobile developer

12/31/2011

Just one year ago I ended my journey on the Microsoft stack and decided it was time to play on the JVM. I thought about writing the ever popular blog post about why I left the .NET community but in all reality I just wanted to see how the other half lived. Most of the people I looked up to in the community were writing software on some other platform and it was time to see what I was missing.

Unfortunately after only a few weeks at the new job, it was clear I wouldn’t be writing much code for a variety reasons so I decided to spend my time outside of work learning something different. This was unusual for me because in the past I’d spent most of my time outside of work on the ’technology treadmill’ learning the latest frameworks, tools, etc so I could keep up with Microsoft as they pushed out every enterprise piece of software you could think of. The big problem with this approach is that it increased my burnout rate dramatically for obvious reasons. But after talking with a friend of mine about how to deal with burnout he suggested writing software for fun (again). To be fair it was the reason I got into this industry in the first place so I took his advise and decided it was time to code for fun in my spare time.

At the time iOS development was the hot new thing so I started spending most of my "free time" learning about objective-c and cocoa touch. What started out as a simple hobby soon became the reason I got up in the morning. And when I say "got up" -I’m talking early. I was working 7 - 4 at my day job so I started getting up at 2 or 3 am to write objective-c until I had to leave for work. It was about 2 months into my first project that I started waking up on my own at this time without an alarm clock. My life started to revolve around this simple mobile app that I was building and soon I found myself wanting to write objective-c full time.

I started to look back at the seemingly big shift developers made in the early 2000’s when web development hit the scene. I was just out of college and web programming was all I knew about the world of software development. So to me at the time it was the only way software was built (in my little world). What I didn’t realize was how the entire industry was making a shift away from legacy (non-web that is) tech and the developers who didn’t jump in got stuck maintaining systems that no one else wanted anything to do with.

For some reason I applied this idea to mobile development and took it to an unrealistic / unhealthy extreme that got me thinking the personal computer was dead. That some how people would quit using computers altogether and only use software that was available on a phone or tablet. I still remember an interview this past year where I said "consumers have quit using desktop computers, if your software isn’t built on a mobile platform your business is dead".

Not to say you shouldn’t be doing mobile development but in reality people are still using desktop computers. The majority of that time is during work hours but at 5pm ish most consumers unplug from work and fire up the tablet / smart phone. Yet for some reason I was obsessed with this idea and decided that if I was still writing web apps in 2012 my career was over. At this point I should have realized my dogmatic view of mobile development was flawed but for some reason I kept moving in that general direction.

It was about this time my first iPhone app was approved by apple and made it into the app store. This only fueled my sick passion for mobile development further so I started learning Android. I spent the next 7 weeks building my first Android app. When this app was finished I went on to the Windows Phone platform. I couldn’t get enough of the mobile development story. With each app I felt closer to landing my dream mobile gig.

Then it happened. The dream job I was waiting to interview for finally landed in my lap. But for some odd reason I had the opposite reaction about the job in question. I decided writing apps for iOS might actually limit the amount of other work I would get to do. Instead of writing back-end services to communicate over http I might be told that was someone else’s job. Instead of writing web apps that would have me doing html/css/javascript/sql I might be stuck dragging and dropping table views and wiring them up with objective-c.

I realized that instead of having to specialize I wanted to get back into a more general web development role working with a small team where I could see a direct impact from my work. I was writing a batch application at the time on a very dysfunctional team and decided it was time to move on.

Just a week after I finally decided to move on, I heard about a small team that was looking for a python web developer. Not having any experience with Python and limited experience with Linux it was a long shot but somehow I was able to express my passion for learning and got a job offer.

Without a doubt 2011 will be known as "The year I thought I wanted to be a mobile developer" because of my insane drive and passion for mobile development. But through that experience I found that the mobile web isn’t going away anytime soon. And since then web development has become my passion all over again.

How to install pip, virtualenv and django on ubuntu

12/22/2011

I recently started developing on linux again, but this time I’m doing Python professionally. And with any new platform, you learn how to setup your development machine on day one. Initially I just installed Python 2.x and started writing code without a care in the world. But it turns out most of the real-world Python developers are working with this thing called virtualenv.

The short version -virtualenv allows you to silo a development python environment from system Python. So without further ado -the steps below will get you up and running from a fresh install of Ubuntu 11.10

This install assumes you are a normal (non root) user who has sudo access to install packages (but please don’t do something like sudo -i before starting this install)

sudo apt-get update

sudo apt-get install python-setuptools python-dev build-essential git-core -y

sudo easy_install pip

sudo pip install virtualenv

sudo pip install virtualenvwrapper

At this step type pwd **to make sure this is your home dir -ie /home/toranb. If you are not cd ~/ and you should be.

mkdir ~/virtualenvs

echo "export WORKON_HOME=~/virtualenvs" >> ~/.bashrc

echo "source /usr/local/bin/virtualenvwrapper.sh" >> ~/.bashrc

echo "export PIP_VIRTUALENV_BASE=~/virtualenvs" >> ~/.bashrc

source ~/.bashrc

The above is a great start, but if you want to use the best Python editor known to man keep going. If you don’t want a bulky IDE or you just don’t have the hardware to run it, install vim the right way as the vanilla install of ubuntu won’t have anything installed.

sudo apt-get install vim vim-scripts vim-doc vim-latexsuite vim-gui-common vim-gnome -y

If you decided to install the Pycharm editor -it requires the JDK so let’s get started!

sudo apt-get install openjdk-7-jdk -y

Next go download Pycharm from jetbrains. Once this is finished cd into your downloads directory

cd ~/Downloads/

tar xvzf [name of the tar.gz]

Now cd into that new directory after the extraction is finished.

cd bin

./pycharm.sh

Now you have a full python stack so lets create our first virtualenv and install django! (back to the terminal)

mkvirtualenv blog

This will create a new virtualenv (very minimal install). To install django use pip.

pip install django

Now you can develop, install other packages using pip,etc (go to town people!)

If you want to get out/off your virtualenv use this command

deactivate

If you want to jump back on the virtualenv we just created and installed django use this command

workon blog

And finally if you want to remove the virtualenv altogether

rmvirtualenv blog

Now you should have a fully functional Python/Pip/Virtualenv/Django development environment!

Talking mobile development on Hanselminutes

12/17/2011

When I started doing web development years ago I found podcasts were a great way to learn about different facets of software development. If I wasn’t exposed to different ideas I might never have thought to innovate on my own projects and keep learning. And if you are at all familiar with the .NET community one of the most respected podcasts in existence today is hanselminutes. This weekly podcast features Scott Hanselman doing what he does best - speaking with interesting people in the software community to get a different perspective on popular (and sometimes unpopular) topics in the software industry.

Recently I was fortunate enough to talk with Scott about my experience developing mobile applications across iPhone/Android/Windows Phone and thought to mention it on the blog. The actual interview covered my previous blog post about the mobile development report card but Scott did take it a bit further at times. The most entertaining part without a doubt was when Scott asked about memory management and I said to ignore it initially (I was then given the ’opportunity’ to dig myself out of that hole rather quickly).

But even with this misstep I think the show ended up a huge success! If you are interesting in the podcast give it a listen, and if you just want to read about it you can find a full transcript here.

How to publish your first iPhone app

11/07/2011

When I finished my first iPhone app earlier this year, I just assumed the hard part was over. But it turns out learning objective-c wasn’t the worst part of my transition to the iOS development eco-system. The most difficult part was figuring out the crazy certificate/provisioning profile madness that had me ready to throw in the towel.

I actually phoned a good friend for help the first time around just so I could get my product into the app store. But recently I had to pave my workstation and re-install OSX from scratch. After doing so I realized I would have to go through this painful setup again, so instead of the guess work I did last time around I decided to record it so I could share the actual steps required with others who might be struggling to publish an iPhone app for the first time.

Direct Download (mp4)

If I skipped anything that should be covered in more depth please shoot me an email or leave a comment. I hope this helps guide someone else through the nightmare that plagues all new iOS developers (at least this one anyway).

The Mobile Development Report Card

10/06/2011

I’ve spent the last 9 months building mobile apps in my spare time. I honestly needed a hobby project that would re-introduce me to the fun side of programming. I found joy in the early iPhone development I was doing and by the time my first app was finished I decided it was time to learn another mobile platform.

I kept learning and soon found that I was having fun at the keyboard again. I had finished my first Android app and decided to give that Windows Phone 7 thing a shot (despite what others had said about the market). It was about this time that I started to see the "my iPhone/Android experience" like blog posts showing up on Hacker News.

I found these interesting and decided I would write a little about my experience on all 3 platforms. But instead of a simple post about my likes/dislikes, I thought a "report card" like comparison with a letter grade would give other developers interested in learning mobile a high level view into the platforms from the view of an aging web developer who started on the .NET stack and recently turned to the JVM.

To be clear I’m far from an expert on any of the platforms listed below. At the time I was far more intersted in building a product and having fun again to get caught up in deep SDK hacking so what you see below is simply my thoughts about how the platform felt as a newbie. I could very well be wrong so please feel free to let me know in the comments :)

	iPhone	Android	WP7
Hello World	A	D*	A
Learning Curve	F	B	A
TDD Friendly	B+	A	F
Navigation	F	A	A
Global State	A	B+	A
Multi Tasking	A	B	C
Persistence	C	B	A
Debugging	C	B	A
Layout	A	F	A
Images	A	F	A
Tooling	C	B+	A*
Emulation	A	F	A
Local Install	B	A	-
Device Testing	B+	F	A-
Publishing	F	A	B+
Sales	A	B-	B

Hello World

Definition: The amount of effort required to get a working app out of the box for someone with zero experience using the platform.

iPhone: Even with no experience developing on OSX I found it brain dead simple to get my first iPhone app up and running in the simulator. After downloading and installing Xcode you simply open the IDE and select new view based app, compile and away you go.

Android: I hesitate to open with ’don’t get me started’ but honestly this was the worst experience of all the mobile platforms. I should clarify that I didn’t get started with eclipse and didn’t want to. I wanted to work with Intellij and build using Maven so my experience might be the exception for Android development. Either way I had one heck of a time trying to get my first project up and running. After I got a working app built I did a screencast to help others get up and running with Maven and Intellij (hopefully with less pain). I did put an asterisks here because if you are down with using Eclipse this might not be a total failure as it was for me.

WP7: Much like the iPhone experience you simply download the tools and away you go

Learning Curve

Definition: The amount of effort required to honestly grok the platform and be productive.

iPhone: To say the learning curve was steep would be the understatement of the year. To be fair I wasn’t an OSX user, had never used Xcode, and I’ve never written a line of C in my life (unless you count a semester of c++ 7 years ago). It took a good 2 months of writing code daily for 2-4 hours to become productive. I should mention this was by far one of the best learning opportunities I’ve had in the programming space since college so it wasn’t a bad thing (just wanted to be honest about how long it took me to feel productive on the platform)

Android: I’ve been writing java/groovy since January this year so I had some experience with not just the language, but the platform. I didn’t incur much of a cost, if any at all when I started coding. I felt super productive out of the box until I hit layout (described in more detail below).

WP7: My first real programming gig out of college was writing aspnet web applications. In addition I’ve spent the better part of my career since then working in c# and .net so I can safely say the learning curve was non existent. I’ve also done a little with Silverlight 3 so the front-end XAML wasn’t a big deal. Productivity started high and remained that way throughout the development process.

TDD Friendly

Definition: The amount of effort required to get your software under test on the platform. (excluding front-end testing)

iPhone: When I started writing objective-c last year Xcode 3 didn’t ask you if you wanted to create a unit test project along side your production app like it does today in Xcode 4. So I spent a great deal of time trying to figure out how to unit test my code, but with the support coming out of the box now I couldn’t help but say this is a decent experience today. I still run into the occasional issue and thrash around a little but it’s a decent experience for someone new to the platform.

Android: Because I was using Maven this was by far the best experience of all 3 platforms. I just added the junit dependency and away I went.

WP7: To say the community and Microsoft itself don’t value unit testing would be an unfair statement, but this is how it felt when I started my first WP7 project. For starters if you are using the free tools you aren’t allowed to use a plugin like resharper. And because I only write my tests in .net with nunit I’m not sure how you can run tests with just the free tooling. If you decide to pay for a full blown commercial license you can use a plugin like resharper of course, but even with the tooling I had to first find an nunit assembly that was Silverlight friendly, and then work through a few other issues (shown in yet another screencast I published to help developers who might follow)

Navigation

Definition: The amount of effort required to build a project with multiple views that can be navigated to.

iPhone: I found hooking up an app delegate (main controller) for any given project difficult at first. And along these lines I found adding multiple views and having them wired up to this app delegate difficult to get right for the longest time. Looking back most of the pain came from having to write a few lines of code, and then having to drag n drop references around inside the interface builder (UI) tooling. Now that I’ve been working with the platform for some time this is practically muscle memory but I still find it to be the worst experience across all the mobile platforms currently.

Android: To navigate between activities you simply create a new object (intent as it’s called) that knows about the current activity and the type you plan to invoke next. Then you start it - done

WP7: Although I liked how simple Android made this task look it had nothing on WP7. To jump between pages (views) on the platform you simply ask the Navigation Service to navigate to a given url -done

Global State

Definition: The amount of effort required to store something globally for use across the application.

iPhone: Once you figure out the wonky app delegate wire up process on the platform it’s very simple to share global state. Typically I would create a new controller to start up inside the app delegate object during a navigation event and during the init process I would pass any state required for the next view.

Android: In android you simply inherit from a base class (Application to be exact) and in doing so you can push/pull state from this object at almost any point. The only thing I didn’t like about this passing data between activities directly is that it felt painful so I often used this global class instead (for better or worse)

WP7: Very similar to the Android story here, except you don’t need to create your own class. A global class named App already exists and you can push/pull data from this almost anywhere. For small bits of data you could pass along a url like param to share data between controllers, but everything else I just pushed into the app object and pulled it back out inside the next view when I needed it.

Multitasking

Definition: The amount of effort required to save state and restore the application when a user switches between your app and the next. *(not necessarily the effort to program the app to work well with this paradigm)*

iPhone: The reason I gave iPhone the best in class is that you have the option to support or not support multitasking. And if you do support it you don’t have to do anything special to keep the global state of your app ’as is’ - so the restore process is painless

Android: Multitasking on Android is required so if you are cool with this you have no worries. When a user restores the app you shouldn’t find any surprises when you attempt to display the view that was just up.

WP7: At the time I was working with WP7 you had to explicitly save / restore that state you cared about manually. This wasn’t a huge deal but it was painful because the other platforms already do this for you.

Persistence

Definition: The amount of effort required to store something long term and retrieve it (using SQLite for example)

iPhone: At the risk of sounding incompetent I have to say my experience with SQLite on the iPhone was more difficult than I had hoped. To this day I’m still afraid (code fear) to touch the binary file that holds the database itself because I never really understood how the darn thing worked. I had no trouble writing SQL statements or getting general data in/out of the database once it was setup correctly, but this is still the #1 area I avoid on the platform today.

Android: Aside from a few fragmentation issues (I’ll talk about this later) and a ton of incorrect blog posts I found the general SQLite setup easy enough on the platform. The only part of the persistence work that was painful is that the code itself was in java.

WP7: When I started building my first WP7 app I was under the impression that I would be releasing after Mango was released so I built my persistence with LINQ to SQL. This experience was by far the best on all platforms. But when I decided to ship a little sooner I had to revert everything to LINQ to XML instead as Mango was still not out and I wanted to get my product in the hands of paying customers. Even this wasn’t a painful process as LINQ provides a low friction way of working with XML/SQL/etc.

Debugging

Definition: The experience using a debugger to find problems on the platform.

iPhone: In the latest version of Xcode the debugger has improved a great deal. I still don’t enjoy the experience because it feels light years away from debugging in modern IDE’s like Visual Studio/Intellij. In the future look for a jetbrains product similar to Intellij (but for objective-c) called AppCode. I’ve been using the beta and if it gets released at an indi dev friendly price point I’ll be sure to pick it up and never look back.

Android: I’ve used Intellij exclusively throughout my Android development and love the IDE. The debugging experience is about the only thing that could be improved greatly. Not to say you can’t find the state of an object during execution, but once you have used Visual Studio the bar for debugging is a little higher. One big example of this is that I can’t drag a break point around in Intellij. Beyond this I’m being a little more critical by saying it just doesn’t feel polished.

WP7: Hands down the best experience in mobile today. Very polished product built for debugging (after all Microsoft is a product company). The only thing I would ask for (if it’s not already available) is the ability to execute a LINQ statement in the debugger.

Layout

Definition: The amount of effort required to build a view on the platform.

iPhone: When I built my first hello world app for iPhone I remember building the layout by hand in objective-c. This was in part because I was afraid to learn the drag n drop interface builder style of front-end development. I had this misconception from my early webforms days on the Microsoft stack that drag n drop would eventually cause me a great deal of regret. This wasn’t the case with interface builder on the iPhone stack. I found the ability to drag a given control on the form and wire it up a time saver long term. The only learning curve was how to wire up the stuff I was dragging around, but even that wasn’t much of an issue for view specific work.

Android: If I said Android layout was the IE6 of mobile development it still wouldn’t fully describe the pain I felt building xml based layouts for the platform. For starters the tool I was using, Intellij, offered no preview of what the xml I was working on would actually looked like on a phone. This made the feedback cycle painful because I would change some xml, push it to the slow emulator (more on the emulator below) and pray it worked. Other tools do exist to help build layouts but to this day I still use an older unsupported tool called DroidDraw to get the general structure in place. Lots of work could be done to improve this process as it’s typically the slowest part of the Android development process for me personally.

WP7: If you are not familiar with XAML it’s yet another XML based markup language of sorts. I found it fairly simple to build even the most complex layouts. In addition the preview tooling inside Visual Studio was rock solid. I never once had something look one way in the preview and another on the phone itself.

Images

Definition: The level of comfort I had using images in my commercial apps.

iPhone: At the time I’m writing this the iPhone has 2 resolutions to support. When you build your images you need 2 versions, one in 326 dpi *(iphone 4 / 4S) and one in 72 dpi for the other iphone models. To get this for free in your app you mark the 72 dpi as foo.png and the 326 dpi as foo@2x.png (the phone takes care of the rest)

Android: As someone new to the platform I froze like a deer in the headlights when I noticed a separate layout folder for small/med/large displays. I instead decided not to use custom images for my buttons,etc and just use native buttons with colors (sadly). The app still looked decent when I had finished, but I honestly didn’t have enough Android devices to test all the different resolutions. Fragmentation to the max ...

WP7: The best part of WP7 is that one resolution exists, so you only need one image and if it looks good on a single phone you are good to go. This was a nice change from the Android development I was doing at the time.

Tooling

Definition: The quality of tooling used to build my first app on each platform.

iPhone: I could bash Xcode until the end of time but instead I will say that they are making solid improvements and the product will eventually be something I can use on a daily basis. But to be clear for anyone new to the platform - it still has a long ways to go before I can recommend using it for objective-c development (again much prefer AppCode from jetbrains). From the Xcode 3 days I still fear any automated refactoring in the IDE.

Android: As I stated in the above debugging section - Intellij is a rock solid IDE and It’s very TDD friendly. I use this at my day job and love it for Android development - nuff said

WP7: I put an asterisks next to this grade because if you are using the free tooling it’s sorta limited. You can’t use any plugins for example - and in my experience this is a HUGE limitation because I personally can’t use Visual Studio without Resharper. So if you have the $$ for a professional/ultimate version of Visual Studio 2010 and another $200 for ReSharper this is by far the best tooling for mobile development hands down. If you are stuck with the ’free’ tooling I can’t say the same ...

Emulation

Definition: The quality of the platforms emulator/simulator (does it match a real device/actual speed of the emulator/etc)

iPhone: One of the best parts of developing for the iPhone was how quickly the simulator launches apps. Even though this isn’t a direct emulation of the app on native hardware I’m yet to find something that didn’t work on the phone but did on the simulator and vice versa (excluding gps like features of course).

Android: Worst part of android development next to building layouts. The emulator started with a great idea ’lets match exactly what Android will be like on a phone’ - but in practice they sacrificed speed. This effected my development because it caused my feedback cycle to be very long, meaning even the smallest change was painful to verify. In addition I had the emulator cover up a SQLite problem when I was working between 2 physical devices (more on this below). In the end a good work-around for this was to plugin a real phone and use this directly instead of launching the emulator to verify my work.

WP7: The simulator is blazing fast so feedback was quick and painless. I was able to test multi-tasking and even gps location code with the new GPS tooling in the Mango SDK. I Never found a single problem between what a phone would render/do vs the simulator I tested with, except on GPS issue. On a real phone you can toggle off the network services and use this to see how your lack-of GPS error handling works. But on the simulator you don’t have the option to toggle this setting (caused me some grief as I don’t own a real device currently).

Local Install

Definition: The ability to install your app on hardware locally (without paying $$ to do so) and the effort required to do this as a n00b

iPhone: I started developing for the iPhone when I only had the first generation device. I’ve been a fan of jailbroken phones for some time and found this process to be easy enough. I didn’t want to pay the $99 until I had a great app that would in turn make money so I simply pushed the compiled app over to my phone via scp (more on this technique at stackoverflow if you are interested). I did drop the grade here because to pass along your app to a beta tester over the air would require you do 1. spend the $99 or 2. jailbreak their device and scp it over on a local network (and most of my friends don’t want to be jailbroken)

Android: The best option by far on all the platforms. No need to spend any money (not that $25 is a large amount) - just plugin a phone and push the apk over to see if it works. For beta testers just email them the apk directly (if they have an SD card it can be installed directly -how could this get any better right?) **note does increase the ease in which your app can be pirated sadly so be careful if you do this with people you don’t trust

WP7: I decided not to rate this category for WP7 because I never owned an actual device. I borrowed a device for 6 days to verify everything was rock solid before I shipped the first 2 apps I built on the platform but because it wasn’t my phone I just paid the $99 and opted not to jailbreak it (as I’ve heard you can). But because I didn’t take the time to side-load an app myself I’m not sure about the level of effort required to do so.

Device Testing

Definition: The issues I ran into when I tested my apps on a phone directly and how many are required to make sure they were RTM ready.

iPhone: Just before I finished my first app Verizon had released the iPhone 4 and I had bought it. Prior to this I had the first generation hardware so for me testing the app on both phones was a non issue (as I had both a 3.x and 4.x phone at the time). Also as I had a device for each supported resolution this helped me prove each app was ready for 3.x and 4.x customers. The only thing I really couldn’t test in the simulator (aside from how do they look on each resolution) was gps specific features. In the future I might only support the 4.x devices so testing on a device with iOS 3.x (and older) might be a non-issue.

Android: When you talk about physical device testing for Android you have to start with the f-word. Fragmentation to the max sadly. I knew lots of resolutions/versions existed in the wild so I found 2 phones on craigslist for less than $100 to test with. The first was a popular phone I figured tons of people had (the Droid 2) and the other I was unsure of but for $25 I figured it was worth it (the Droid Eris). Both had different versions of Android and both seemed to display things the same (visually anyway). But I did find a few issues programming -one with GPS lookup and the other with my SQLite code. So I fixed these issues and assumed all was well with my app. So after finishing what appeared to be a rock solid v1.0 of my app, I shipped the app in both the (Google) Android Market and the Amazon Android Market. I soon found that my app had 2 other issues when the Amazon Android app store review process started. So I had to call on friends/family to verify and fix the new bugs in question because I couldn’t reproduce them on any of the devices I owned. Long story short - it was very very painful to make sure the app looked/functioned exactly the same across all devices.

WP7: As I don’t own a device I went to craigslist and found someone willing to let me borrow a device for 6 days. I spent $50 and verified a few GPS things as the rest of my development was an exact match with the simulator. The only real issue I had with the simulator as my sole development phone is that persistence is reset once you push a new xap over or re-launch the simulator directly.

Publishing

Definition: The amount of effort required to publish your app in the AppStore/Market/Marketplace

iPhone: I still remember almost giving up when it came time to publish my app in the AppStore for the first time. First you had to create a valid cert for this, and another cert for that. Then locally you had to get your project configured correctly to use the distribution cert and build it /etc. Assuming you got all that figured out and pushed the app to the next phase (review) ...good luck. The first time you submit expect a rejection for something. Work through it and keep your spirits high (remember you learned objective-c for this moment). They do a good job of finding everything in 1 go and its usually done within 2 weeks the first time you submit a new app. Updates to an existing app take between 2 and 4 days usually. By far the most complex/painful part of the iOS development experience *(and you thought learning objective-c would be the hardest part)*

Android: Very simple process (with the current DRM process I used -not the new licensing model). Put a min Android version in your xml file, add a version or bump it up and build the project. Ask your IDE to take a keystore and build the final apk for the Market. Upload it - done (no review from what I’ve experienced). One small note about the Amazon Android Market -- don’t waste your time. I’m yet to have a single sale here and find that most customers only download this to get the ’free app of the day’.

WP7: Change your compile options from debug to release and do a build. Pay the $99 and push your xap into the Marketplace. The review process took about 5 days for a new app. I’m yet to do an update so I’m not sure if it gets better/worse. Overall not a bad process to get your apps in the store.

Sales

Definition: The amount of people willing to pay $$ for your app (in my experience)

iPhone: By far the most lucrative app market you can be a part of without a doubt. If you have a product be sure to launch on this platform first. Without talking numbers directly I usually have 500% more iPhone sales than Android in the same period. People don’t mind paying money for apps and that is a good thing if you like to get paid building apps on the side as I do.

Android: A few months ago I would have said stay out of this market altogether. But recently I’ve seen an upswing in sales that makes me think it just takes time to get off the ground. I actually got into mobile dev in the first place because a good friend of mine make some serious $$ with an Android app that was much needed at the time. I would recommend you build your commercial apps for this market last because the ROI just isn’t their yet. That said, the Android market it is still a place you can make money if you have the right app. Also people seem to find apps in this market without much effort (glad Google got that much right).

WP7: I’ve only had my apps in the WP7 Marketplace a few weeks now but I’m happy with sales so far because I know the install base is much smaller. I also have 2 apps that I feel are much needed in the Marketplace today and as with anything you must have a great idea to sell your product (along with some rock solid software to get the word of mouth sales). In general the sense I get is that people on the platform are willing to pay for apps (similar to your average iOS customer).

My Love-Hate Relationship With Mock Objects

08/30/2011

I first learned about mock objects when I started wrapping unit tests around a legacy system back in 2007. In the context these mock objects helped me isolate tricky behavior that I wouldn’t have otherwise been able to test.

I still remember spending a great deal of time learning about the various mock frameworks available for .net. Strangely enough this was also the time I became obsessed with code coverage metrics. And like a perfect storm these two concepts pulled my attention toward writing a test "just to write a test".

After the project ended I remember thinking to myself

wow this testing stuff is awesome, heck I was able to test everything in that darn system!

It wasn’t long after this triumphant moment that a co-worker had to make a slight modification to that legacy code base. And just minutes after reviewing the change it was clear the tests I had written didn’t help the development process in any way. In fact it looked as if all new feature development would take twice as long because each test would need to be rewritten as the mocks I riddled all over the code had made the tests extremely brittle.

So from what I considered a "learning opportunity" I took away this notion of mocks causing more harm than good. I came to this conclusion because of my own (mentor-less) experience writing unit tests after the implementation was already in the wild.

And in the test-after sense I was feeling a lot of pain around mocks not because mock objects are intrinsically bad, but because the code itself was rotten. You start to see this pattern emerge when you adopt true test-first practices and it’s a sign that you need to refactor. But in my early test-after experience I didn’t understand this pain point so I never refactored enough to improve the design of the legacy system I happened to be working on.

At this point the problem I had with mock objects was that when I tried to refactor the code under test each test itself had to be rewritten because the test knew very explicit details about the implementation. So when the implementation changed it caused the tests to fail for no good reason. And the more I learned about test-first development the more importance I placed on "tests should know what, not how"

This caused me to reflect on how I was writing my test code and I had decided that the #1 goal (at the time) was regression testing. So with this I decided to avoid using mocks altogether in hopes that my implementation could be refactored without having to worry about brittle tests.

During the year that followed I spread a great deal of negativity about mock objects. I rarely wrote a mock object and when I did need some form of mock/stub to help me isolate behavior I hand rolled it to prevent what I called "mock abuse" or "overmocking".

But earlier this year I started to see a strange pattern emerge in my production code. No longer did I see dependencies mixed in with logical statements, instead classes either delegated to a dependency or they performed a calculation of sorts directly.

With this new pattern in my implementation I soon found my test code easier to read because classes were smaller and did just one thing. It was at this point that I noticed a shift in what I valued about tdd. It was moving from regression testing to the design process. (not to say that regression testing is worthless)

So with this revelation (ah-ha moment if you wish) I began looking at the delegation classes I was writing. These classes had gone without any tests up to this point because I refused to write a mock object for "interaction" based testing. Beyond the dogma that was a sickness all its own I realized that if I was writing these "delegation heavy" controller like classes the mocks would tell me when I’m adding to many dependencies. So I put aside this blind hatred of mocks and embraced the test friction as a symptom of "it’s time to refactor".

When I look back at my own "love/hate" relationship with mock objects it’s hard not to ask the question "what’s your relationship with mock objects like today?"