Tag: Programming

The other day I was looking at a website of a contracting company that specializes in mobile development. The site said that they were pioneers in the field. The site then had as its next line that the company was started in 2009. I normally think of pioneers as people who initially settle an area or who are first in a particular field. Unless my history of mobile is a little off, 2009 is a bit late to the party. If we just consider the “modern” era of mobile development that began with the iPhone and Android, they are still late as the iPhone was released in 2007 and the SDK in 2008.

However, saying that mobile development began in 2007/2008 is doing a disservice to all the predecessors to iOS. PalmOS came out in 1996, the Newton came out in 1993, Windows CE came out in 1996 and the Psion was about the same time.

I have no idea what meaning of pioneer this company had in mind, but they are certainly not pioneers in mobile applications. I’ve been writing mobile applications since 1994 when I first got a Newton (the Apple Personal Interactive Electronics group which made the Newton licensed my NotifyMail program and sent me a Newton MessagePad 110 in exchange for the license) and I don’t consider myself a pioneer. I know a number of people that wrote mobile applications prior to this.

If the company considers themselves pioneers, what do they call their developers that have 1-2 years of experience? Experts?

One of the ways programmers use to help ensure that inputs to methods are correct is to use asserts. Basically these will test conditions and stop execution if a test fails. By default, Xcode suppresses these asserts in release builds so that the code will simply continue.

This past weekend, I was helping out on a project and found that the app stopped because of an assert indicating that a condition was not satisfied. As I looked into it closer, the programmer had put in asserts to test the results of what came back from the server. The author then didn’t do runtime checks to validate the data, he simply assumed that if the assert passed, that the data was valid and continued. The problem is that, in this case, the server returned data that the code wasn’t expecting, so in a release build, the code would have continued and then crashed because the data wasn’t in the correct format.

While I’m not a huge fan of asserts, they do have their place, just not here. The code should have done runtime checks and gracefully handle bad server data.

I suspect that the author hadn’t done enough client-server communication to know that servers return bad data more often than you’d expect. I’ve worked on so many projects where a simple server change causes clients to have hiccups, that I’ve gotten pretty good at defensively programming against this.

If you choose to use asserts, make sure that you also use runtime checks and gracefully handle conditions that you test for in the asserts as the asserts go away in release builds.

In my last article, I wrote about an issue I had with my Bluetooth heart rate monitor and my Bluetooth headset. After analyzing the issue and trying to reproduce the issue, I was unable to do so in my office and then on my next run, everything working perfectly. However, on my run this morning, the problems came back. When I got home, I turned off RunKeeper and ran my test app. My test app either disconnected or I heard an audio dropout every 6 seconds. The big difference between my initial tests and this test was that my heart rate was up and the contacts on the heart rate monitor were conducting quite well. This would indicate that the issue is not a RunKeeper issue, but either an iOS issue or an iPhone 5 issue.

I’ve gone ahead and reported it to Apple as radar://13004711. Based on my past history with Apple bug reports, I don’t expect a resolution any time soon. This would be quite unfortunate as more and more Bluetooth devices come on the market.

In November, I saw that TI announced a product called SensorTag which is basically a development board for working with Bluetooth 4.0. I was immediately intrigued as iOS 5.0 supports Bluetooth 4.0 (LE) and lets me write apps that aren’t certified by Apple via the Made for iPhone program. I ordered the device (it was $25 which I consider a bargain) and then in early December, it arrived.

While I had no real use for it, I decided to learn how to write code to use Bluetooth LE and wrote a app that monitors all the sensors in the SensorTag and reports them. The TI app did this, but wasn’t very elegant and I also wanted to add alarms for high/low temperature. A few weeks later (I worked on it an hour at a time in the evenings), I finished my code and had a working app. Since I don’t have any plans to monetize my work, I’ve made all the code available under an MIT license. One of the comments I’ve received about my work is that my code is better than the code provided by TI! It might be that I’ve been writing Objective-C and iOS code for awhile or my goal was to produce an app that anyone could use. In any case, I may release it to the app store, but the audience is quite limited as it requires the SensorTag which is basically a developer/hacker tool.

Now, where was I going? With all this Bluetooth 4.0 knowledge, what should I do next? I wanted to learn something new and I did that; I likely won’t make any money from my new found knowledge, but it is fun playing around with it. However, today while I was running, I determined what I could do with the knowledge.

Let’s rewind a few months. When I run, I take my iPhone, use a pair of Motorola S10-HD Bluetooth headphones and a Wahoo Fitness Blue HR heart rate monitor. I use RunKeeper to log all the data. I have been using this combination successfully for many months and have been quite happy with it. When iOS 6 came out and I got an iPhone 5, things started going downhill. RunKeeper was no longer able to talk to my heart rate monitor and they blamed Wahoo Fitness as they use a Wahoo Fitness library to talk to the heart rate monitor (the library also supports ANT+ heart rate monitors via a Wahoo Fitness dongle). After a few app updates, RunKeeper appeared to support the heart rate monitor again.

After hurting my foot and then being sick, I started running again on Sunday. During that run, I noticed that the heart rate monitor reported accurate results via RunKeeper, but my music kept cutting out periodically. I initially blamed the Motorola headset as I’ve already had to return one pair due to the buttons failing. Today I ran again and noticed the same problem. However, I decided to count how often the drop outs occurred. The drop outs occurred every 6 seconds. For anyone doing sampling of data, this should ring a bell. Every 6 seconds is 10 minutes per minute which is a reasonable period to be sampling data. I took off my heart rate monitor, put it in my pocket and after a few minutes when the Bluetooth connection disconnected, my music continued without drop outs!

So now I knew the problem wasn’t necessarily with the Motorola headset, but there were too many variables:

• Switched from iPhone 4S to iPhone 5
• Went from iOS 5 to iOS 6
• Updated RunKeeper

The only pieces of the equation that hadn’t changed since everything was working smoothly were the Bluetooth Heart Rate Monitor (it is a Bluetooth 4.0 device) and the Motorola headset. Having worked with earlier versions of Bluetooth, I thought that maybe there was a conflict between the Bluetooth devices. However, the devices remained the same and only the phone had changed. How was I going to track down the problem? Since I now knew had to write a Bluetooth LE app, I decided to write an app to talk to the heart rate monitor and get readings. This turned out to be a simple task and took about an hour to write the app. I ran the app and played music through the headsets; I was expecting to hear dropouts, but no such dropouts occurred. So, this little test told me that the iPhone 5 with the Wahoo Bluetooth 4.0 Heart Rate Monitor and Motorola Bluetooth headset could all be operating at the same time without problems.

So what next? I ran RunKeeper again and tried to duplicate my results from my run, but was unable to do so. Granted I wasn’t running, but I expected to have dropouts. I’ll go for a run tomorrow and see what happens. I’m a bit suspicious about the Wahoo Fitness library as Bluetooth 4.0 is quite simple to talk to the heart rate monitor. I turned on the option for the device to notify (and not poll) the heart rate monitor and received an update every 2 seconds. So if the Wahoo Library was using the notify option, I wouldn’t have heard dropouts every 6 seconds.

I think that this issue is worth a look as the Wahoo Fitness library is doing something funky and that RunKeeper can directly talk to the heart rate monitor without using the library. If the library is polling, it should be changed to use the notify feature of Bluetooth 4.0.

When I started ReceiptWallet over 6 years ago, I wanted to use the latest and greatest Mac OS X technologies, so I used Cocoa bindings to make it easier to bring the UI to life. Bindings allowed me to write less code and have UI elements updated automatically based on what was selected and other variables. Bindings work great for simple cases, but once things start getting complex, bindings almost become a problem. Bindings are quite hard to debug as there is no one place where you can see all the bindings and one slight change to the code can cause a crash; tracking down the crash can take hours. I had to write custom debugging routines to examine the bindings and eventually shipped a stable product.

Fast forward 6 years. This past week I wanted to write a simple app and choose to use bindings again to link up the user interface. This app didn’t do much, but it took me hours to figure out bindings again discovering that I had forgotten almost all I learned about bindings and the documentation wasn’t much help. My biggest problem was that I accidentally setup a binding for an NSTableView in addition to setting up a binding for the NSTableColumn. Of course, nothing warns you of this and debugging is a nightmare. I’m sure if I started using bindings again I’d get better at them, but with as infrequently as I write Mac applications, I’ll probably struggle the next time I attempt to use them.

Is there a simple guide I’m missing? Should I abandon bindings completely? I have no idea.

Lately I’ve been more aware of developers using NSDictionary where a class should be used. While it may seem easier to use an NSDictionary to store data and pass it around, the lack of type checking and easily mistype keys is prone to failure. Creating classes with a bunch of properties has gotten even easier with the latest version of Xcode; you don’t even have to synthesize properties. Just define the properties and presto, you have a class where you would have used an NSDictionary. NSDictionaries have their place, but in many cases classes serve developers better.

As I’ve written in the past, I have mixed feelings about open source, so I take a close look at a lot of it, especially for some side projects that I have. There is a lot of decent code out there, or at least ideas that I can build on, so I’ve flagged code to look at and cloned a bunch of repositories from Github. The problem I’ve been faced with is that I have a folder filled with open source that becomes out of update quickly and updating each repository is cumbersome. I want to have the latest and greatest so I don’t have to think twice about the code when I go to evaluate it or use it.

Today I had a little time, so I threw together a shell script that walks through my open source directory and updates each repository in it. I could probably set this up us a cronjob, but for now, I’ll run it manually. For all those out there that want to do something similar, here is the script in all its glory!

#!/bin/sh
OIFS="$IFS"
IFS=$'\n' 
for i in $(find "/Users/scott/Documents/Development/OpenSource" -type d -maxdepth 1); do
    cd "$i"
    echo "Pulling from: $i"
    git pull
done
IFS="$OIFS"

About a year and a half ago, my manager suggested that I learn Android development, so I played around with the SDK for a few days and then got distracted by real work. Now that my role at work has changed, my manager again encouraged me to learn it and said that I could goto a class if it would help. So, this past week, I went to a class given by Big Nerd Ranch outside of Atlanta, GA. The class was quite informative, I learned a little Java and a lot more about Android than I probably needed to know.

I currently have no plans to write Android apps, but knowing a bit about it should help me better understand the other half and make it easier for me to communicate with my Android counterparts.

The biggest thing that I think is a stumbling block for learning Android is the development tools. Many developers use the Eclipse IDE. Any iOS developer that complains about Xcode, needs to use Eclipse for a day. Eclipse and the Android tools are extremely unpolished, buggy, and hacky. I’ve realized that this is probably the reason I didn’t get very far in the past; I like high quality developer tools and they just don’t seem to exist for Android.

Is it a telling sign that the instructor carries an iPhone?