3 Ways To Fix Your iOS Testing Woes

Lots of companies have constant problems testing their iOS apps. Here are some ways to fix or ease them.

1. Don’t Make Developers Run or Write UI Tests

UI tests are black box tests and test the app from the perspective of the user. Your developers are the worst choice to test the app from this viewpoint and you need a fresh set of eyes for those tests. The QA engineer’s job is to test the app from the user’s viewpoint. Your QA Engineers should write these tests.

Plus, UI tests run entirely too slow for your developers to run them all the time and are much too failure prone. Don’t waste their time by making them write and run these tests.

Continue reading →

What are the Downsides to Putting the Core Data MOC in the App Delegate?

I saw this question on the iOSProgramming topic in reddit:

I’ve seen a number of different ways to access the NSManagedObjectContext when working with Core Data, but I was wondering if there are any downsides to the way I’ve been doing it. Basically, I stick a computed variable in the AppDelegate, and grab it when I need it…

Please let me know if you see any flaws… If not, feel free to use it!

The writer then shows the following code which is the computed variable:

There are a number of downsides to this:

  1. The app delegate is managing the Core Data stack. Classes should only have one responsibility. The app delegate is already responsible for managing application lifecycle. It shouldn’t be managing the Core Data stack as well.
  2. You are completely dependent on Core Data and using it as your persistence method for your app. What if you decide to switch to Realm or something?
  3. Any code you write that uses myManagedObjectContext will be dependent on the App Delegate.
  4. Any tests you write will be dependent on the App Delegate and Core Data and will be hard to test and slow as a result.

This is basically the lazy developer’s way of doing things. Granted the Xcode templates generate the Core Data code in the app delegate and doing this makes it easy to get the MOC, but Apple’s example code and the Xcode templates are not always the best way to do things. They are frequently the opposite.

In this post, let’s just focus on the 2nd issue, that of being dependent on Core Data and using it as your persistence method. Perhaps I will cover the other issues in future posts.

Continue reading →

Elixir Robots


Elixir Robots

My robot hobby is picking up steam. After going through the Python examples that came with the GoPiGo, I got inspired by some embedded Erlang videos on YouTube and decided to see if I could control the GoPiGo with Elixir. After watching Elixir Sips, I learned of a project called Elixir/Ale, an Elixir library for embedded programming. With Elixir/Ale, you can talk to the GPIO ports on the Raspberry Pi and some common hardware bus protocols: I2C and SPI. I2C is used by the GoPiGo board, so Elixir/Ale looked like what I needed. So I looked up some Elixir docs, typed mix new exgopigo, and started coding. The result is ExGoPiGo. All it lets you do right now is turn on and off the robot’s two front LEDs, but it does that by writing to the I2c bus. Controlling the motor and such shouldn’t be too hard.

I also ordered an USB kit for my robot arm. This lets you plug the arm into your computer. The software that comes with it only runs on Windows, but the Internet is a wonderful thing. Somebody reverse engineered the protocol and wrote a C program to talk to the arm via the USB port. Somebody else wrote a Mac OS X app using IOKit to talk to the arm via USB. There’s also a Python project that uses libusb to talk to the arm. At first, it didn’t seem like I could you Elixir to control it, but I found an article on Elixir’s Ports and NIFs, which lets Elixir talk to external code. Using that example as a base, I modified the C program to talk to the USB like the C program in the reverse engineered protocol article and created an Elixir module to talk to my new C program via a port. The result is ExRobotArm, which ables you to fully control the arm with Elixir. I tried it on both Mac OS X and my Raspberry Pi. Now it is totally plausible to attach the arm to whatever robot has a Raspberry Pi controlling it.

My compass and GPS module for the GoPiGo have arrived, so that’s next. Then more work on ExGoPiGo.





Robots! Robots! Robots!

I’ve been getting into robots lately. For a long time I was searching for the perfect robot kit to use with my Arduino. Then I decided I’d rather use my Raspberry Pi to control my robots so I could use better programming languages like Clojure, Elixir, Scala, Ruby, etc. So I was looking around for the perfect Raspberry Pi robot kit.


For Christmas, my parents gave me the OWI Robotic Arm Edge. For the longest time, I didn’t like it. I wanted a moving robot and something I could program.


Finally in April, I decided to pull the plug on the GoPiGo, a Raspberry Pi robot kit. It was a little challenging to put together the motors at first and one of the encoders broke. I asked for a new one and they sent it right out. I ran the examples that simply let me remote control the GoPiGo by ssh’ing into the Raspberry Pi on the robot. I had no sensors or anything else. My goal is to create an autonomous robot. No remote control.


So I ordered an ultrasonic sensor, and a Raspberry Pi camera and waited. It took probaby a month before those all came in.


In the meantime, I decided to put the robot arm together. 48 steps! Took me 2 days, but it wasn’t that hard. I ended up with this.


Completed robot arm


Then I went to our local Microcontroller meetup hosted by Make Salt Lake. There were lots of cool projects everybody was working on, and I talked a little about my GoPiGo. I expressed my desire to make it autonomous and also to have a battery that I could recharge. Somebody mentioned the iRobot Create and that got me thinking. A couple of weeks later, I ordered one, and a week later it showed up.


iRobot Create 2


Finally, my GoPiGo parts came and I added those to my robot. That was a little bit of a challenge as well. So here’s the GoPiGo:


Completed GoPiGo


I ran the examples for that demonstrating how to use the sensor and camera. They worked. I decided to order a compass and a GPS module to add to the GoPiGo because there are examples that use that. I want to make this thing as smart as possible.


So lots of things to do. I want to:



    • Control the robot arm wirelessly


    • Make the GoPiGo roam around on its own.


    • Use Clojure to program the Roombda (iRobot Create) and see what I can do with that. Someday maybe add a Kinect to it, or attach the robot arm to it.


I don’t know where all of this is going, but I’m just having fun exploring and seeing what I can do. I’ll keep you informed.





Sticky Footers with UITableView

The Problem

Last week, I had to implement sticky footers in a table view. Sticky footers are where the footer comes at the end of all the table contents, but if the contents are such that the scrollable content height of the table view is less than the height of the view, the footer will still appear at the bottom of the view.

Non Sticky Footer

A non-sticky footer

A sticky footer

A sticky footer

I searched for a solution to this, but all I found were solutions where the footer was always at the bottom of the view. That’s pretty easy to solve. You just use a UIViewController and put a UITableView and your footer view into the view controller’s view, lay it out properly and you’re good to go. In this scenario, the footer never scrolls and is always visible. That’s not the kind of sticky footer I needed.

The Solution

The solution I came up with was to stick my footer view into another view that I used as the UITableView’s footer. Let’s call it the main footer view. You then resize this main footer view depending on the scrollable content of the table. If the scrollable content height is greater than the tables view’s visible height then no need to do anything. The main footer view and my footer view are the same size. However, if the content height is less than the visible height then you just resize the main footer view to occupy the remaining space.

The Code

First, I added a propery to my UITableViewController subclass:

@property (nonatomic) BOOL footerNeedsLayout;

Then I overrode viewDidLayoutSubviews:

What this does is recreate the footer and position it after everything has been laid out. What this means is that whenever your data changes and before you call reloadData on the table you should set footerNeedsLayout to YES.

This could have been done with programmatic constraints and let AutoLayout take care of it, but I chose to do it this way as it seemed to be a simpler solution and easier to get done in the time constraints I was under. Plus I wanted the compliance footer to be a reusable component and didn’t want to duplicate the UI all over the storyboard for the app.

Adding the footer works like this:

Notice that we do set the autoresizing masks of the compliance footer and the main footer so that AutoLayout will generate the correct constraints.

Finally, here’s the code to compute the frame for our main footer view:

We just compute the visible space of the table view (its height – its content insets). If the height of the table view’s content is less than the visible space – the footer height then we adjust the footer to fill up the empty space. Otherwise we leave the footer alone.

It wasn’t as hard as a thought it would be. A better solution would be to use layout constraints in such a way that the footer wouldn’t have to be constantly recreated and repositioned whenever the data changes.

Back to WordPress

You’ve probably noticed that my blog has changed again. I’ve moved back to WordPress from Octopress. I could never find a plugin for Octopress that did image captions right. I spent way too much time on it and just decided to use something that just worked. I looked at a lot of static blogging engines and they all had their issues.

With WordPress, I have to use the web based editor, but it works and their is a lot of plugins and support behind it. I have better things to spend my time on. To make things better, I think I’ll try Desk. I’ve also installed the Markdown plugin, so I can continue to use it.

This has also got me thinking. Wouldn’t be nice if there was a Mac app that provided a nice writing environment (with Markdown of course), and then would generate your static website, without having to use the command-line or be a programmer? There used to be an app from Fog Creek called City Desk that did this. Maybe I’ll create this app.


App: The Human Story – My Story

There is a Kickstarter project that was started recently for a film titled App: The Human Story. It “is the story of the cultural phenomenon that touches all our lives.” It is about the people who make apps. Many of them are people I follow on blogs, and listen to on podcasts, and look up to. I simply had to back the project, and I did.

The producers of the film, on their blog, have asked that others involved in apps write about their own stories. This is my story.

Even though the popular term “apps” has only been in widespread use since 2007, in some way, apps have been a part of my life for over 35 years. For me, it started in 1977, when my Dad bought an Apple ][+ and brought it home. Almost immediately, I found the BASIC manual that came with it and started going through it page by page. I finished it in two days. Back then apps were simply called “programs”.

Your first programs are always very simple. In BASIC, it was probably something like this:

Which would print HELLO forever until you typed Ctrl-C, causing the program to be aborted. Back then there was no lowercase available. That came later with the Apple //e and an 80-column card that extended the width of the screen from 40 to 80 characters.

I don’t know what it is about that simple program, but when you type it in and then type RUN, something magical happens when you do it for the first time. You realize that you are in control. You can make the computer do whatever you want. It opens up a whole new world.

That was the start of my story. From there, I probably spent most of my time learning Applesoft BASIC. I would read Nibble magazine and type in the listings of programs I was interested in. Listings were the source code of a program in BASIC. They were pages and pages long. It would take hours or days to type them in. Many times, you have a typo, or other error and you would have to track them down. That was my first experience with debugging. Sometimes the listings would have 6502 assembly programs. So I learned a little of that too.

I advanced and wrote my own programs or apps. One of my first was a program to keep track of all my little league baseball stats. For each game I played, I would enter my at bats, hits, as well as fielding chances and errors. I could then see what my batting average and fielding percentage was for the year so far. It was a menu driven app, which was the fashion back then. All your commands were executed by navigating through a set of menus.

In 1984, the Macintosh came out and shook up the world. Now programs were called “applications” and they had graphical user interfaces, or GUIs. A little later you could buy a mouse for the Apple //e. You could write programs that could use the mouse. I started to implement a menu bar on the Apple // in 6502 assembly. I got it partially working but never completed it.

In college, I bought myself a Macintosh SE with a 20MB hard drive. I used it to remotely dial into the University of Utah’s computer systems to do assignments and, of course, write my own applications. I had learned Pascal back in high school and used it to write a tennis ranking system for college tennis. I took the Artificial Intelligence series of classes and used Lisp for a whole year. I came in 4th in the rover competition. We wrote AI programs to control simulated rovers. I think this was the beginning of NASA researching how they might control a rover on Mars. This was about 1990.

Always, my dream was to start my own software company and make a living selling applications. I wrote a Numerology program for the Mac using THINK C and the THINK Class Library (TCL). I never tried to sell it though. Back then you had to go through a publisher and get it in the store. I really had no idea how to do that.

This was the 90s and Apple wasn’t doing so well. I couldn’t get a job writing Mac applications so I moved to the Windows world. I still followed Apple, and, of course, I followed NeXT, the company that Steve Jobs started when he left Apple.

The first time I saw a demo of Interface Builder, I was amazed. I had to get it and use it to write applications. Interface Builder was NeXT’s tool for creating GUIs. You simply dragged buttons and other components onto the screen and set their properties. You could even create instances of non-GUI objects and then connect GUI objects to non-GUI objects to actually do something. One of the demos even showed how to do something useful without writing any code. You could connect a text field to a slider and then as you moved the slider, the text field would get updated with the value of the slider. If you entered a value in the text field, the slider’s position would update.

I believe the term “app”, originated with NeXT. NeXT applications were actually folders, called bundles, that had an extension of .app. This told the operating system to treat this folder as an application. Long before “app” became a household word, the Apple and NeXT communities used the term “apps” or “app” as a shortcut for “application”.

I dove into learning all I could about NeXTSTEP, NeXT’s application framework or software for writing apps, and learning Objective-C, which was an object-oriented language that was used to write NeXT applications. In 1993, I went to NeXT World, and I get a free copy of NeXTSTEP for 386. It would run on PCs, but you had to have just the right configuration. Mine didn’t meet it. Before then NeXTSTEP only ran on very expensive NeXT machines that I couldn’t afford. So all I could do with NeXT development was read about it. I did however implement a simple version of the Objective-C runtime at my job. I recreated as much as I of the THINK Class Library and used it to write object-oriented programs at work in C. I even had others using it. It worked pretty well.

Finally, Apple bought NeXT, and Steve Jobs came back to Apple. When OS X came out for the Mac in 2000, I knew my time had come to finally get to develop using NeXTSTEP, or Cocoa as it was now called. I bought a Mac Powerbook and started to learn Cocoa development.

In 2003, I started infiniteNIL Software. I began writing Cocoa software full-time, writing my own apps and doing contract work.

The first Mac Cocoa app I wrote and sold was PhoneWord. With PhoneWord, you entered a telephone number and it would tell you all the phrases that you could make with that number. For example, the number 555-3865 could be turned into 555-DUNK. Each digit in a number has letters associated with it and you substitute a letter for a number and see if you can make a word.

Another app I wrote was Packrat, a desktop client for 37signals’ (now called Basecamp) Backpack web app. Backpack was a personal information system.

These apps I tried to sell on my website. I would upload them to MacUpdate and other download sites.

Apple became more and more popular again with the release of the iPod and people switching to Macs either because they liked the iPod and they wanted more products from Apple or because they were tired of all the problems with Microsoft Windows. More and more software developers, like myself, “went indie” to write their own software and sell it on the internet.

Then in 2007, everything changed again. Apple announced the iPhone. I bought it right away because I wanted to write apps for it and it was a very cool device. I remember be crazily excited during the announcement. It was pretty much everything once could imagine in a device. In 2008, when Apple announced Cocoa Touch, the SDK for the iPhone, we all were very excited. We could finally use the great Cocoa frameworks to write iPhone apps.

My first app, Numerology, was released when the App store opened for the first time. Earlier, I had written it for the Mac, and this time I brought it up to date for the iPhone. Over the years, Numerology has done way better than I ever expected. It started slow and at one point it got to the point where I completed lived off my Numerology earnings. That lasted until 2012. Since then it has decreased, but it still pays my mortgage.

Other apps I have released are:

  • PhoneWord, the iPhone version of the Mac app I wrote earlier
  • Numerology: Baby Namer, an app that used numerology to help you name your new baby.
  • Favors, an app that lets you give IOUs to people that they can add to their Passbook. Apple rejected this app, saying my IOUs didn’t meet the definition of coupons that could be added to the Passbook.
  • Pitching Radar, an app that tells you how fast a baseball pitch is and lets you record pitches, keep track of the average speed and pitch count, and generate a report. Pitching Radar is written with RubyMotion.

PhoneWord, Favors, and Baby Namer have all been discontinued. Favors was rejected by Apple, and the others just haven’t sold well. Pitching Radar shows promise, and Numerology is my best seller.

Even though I haven’t been a great success at selling apps, the dream lives on. I do more contracting work now and there is a thriving job market for iOS developers. I still have ideas for apps and hope to find that one app that will let me go completely “indie”, and forge my own destiny. It has always been my dream and probably always will be.

A New Start

If you haven’t noticed, my weblog has a new design and new content. I have switched from WordPress to Octopress and have used a new theme. So far, I like it. It’s nice to be able to use Markdown instead of some slow web tool to write my posts.

My old blog was mostly political commentary and I’ve decided to remove that. Some of my most popular posts were the posts about my sabbatical that I took in the summer of 2002. Those, I have preserved and ported over to the new system. I enjoyed reading them myself. You can find them in the Sabbatical category.

Going forward, I would like to focus more on technical articles. Occasionally, I might talk about some personal interests. I will avoid political commentary. There’s enough of that on the web and it really doesn’t accomplish anything or help anyone.