David Linsin

Test-Driven iOS Development

2012-05-01T00:00:00-07:00

A couple of weeks ago, I started reading Test-Driven iOS Development by Graham Lee. I had a blast reminiscing about my days as a Java developer, where every piece of code had a unit test counterpart.

Graham is doing a great job introducing the notion behind unit testing and answering the basic question of why you should write unit tests for your code. The book mentions unit tests can be documentation, help you think about API design and a way to get to know other people’s code.

I especially like the way Graham talks about Refactoring. I’ve read a couple of books on this kind of topic, the difference with Test-Driven iOS Development is that I really enjoyed how Refactoring is a steady topic through-out the whole book.

For me one of the most important reasons for writing unit tests is not so much to show that something works now, but to have that safety net some time in the future, which helps you to make sure things still work after refactoring your code.

Graham uses a sample App, which is available on Github, to show how to approach unit testing on basically every layer of an iOS App. It covers setting up OCUnit in Xcode, a couple of interesting testing frameworks and tools, all the way to testing the view layer with a UITableView.

The most interesting aspects of the chapters about the sample App, was how to design your classes with testing in mind. I’ve never been a big proponent of a test-first, however, Graham shows with no doubt, that it has advantages. The most important one, in my opinion, is that it makes you think about the API of your class, before starting to code.

Overall, Test-Driven iOS Development is really worth reading, especially if you are new to test-driven development or need some revision on the topic. The book contains lots of code and even though I usually don’t mind, I sometimes had a hard time staying on top of it.

If you are not practicing test-driven development today, I highly recommend reading Test-Driven iOS Development and let Graham show you its benefits.

Mantis to Issues Safari Extension

2012-04-01T00:00:00-07:00

Back in January I wrote a Safari Extension called Mantis-Issues-Ext:

It extracts information from an issue of a Mantis bugtracking system and adds it to a GitHub issue

It’s available on GitHub, where you can download it or directly install it into Safari.

At my day job our whole development workflow is based on GitHub. We document our requirements, push our code and keep our issues in GitHub. Unfortunately, our customers are using different systems. Among others, the horrible Mantis Bug Tracker.

Instead of going the route of forcing our customers to use our system, we are usually going the extra mile of maintaining two systems - e.g. Mantis and GitHub (at least for issues). In order to make life easier for our developers, I came up with Mantis-Issues-Ext.

Here is how it works: you can navigate to an issue in Mantis, hit a shortcut, create a new issue in GitHub and with another shortcut fill in all the relevant information.

Although it doesn’t help with the maintenance part, it makes life easier when creating issues.

Now let me say that I’m not a JavaScript guru and Safari Extensions are mainly based on JavaScript. I don’t really enjoy developing with web technologies - I’m a downright native guy. That said, I think my code probably sucks and could definitely be improved. However, it works and that’s the main goal of this extension.

Apple makes a great job - as always - in documenting Safari Extentions. However, the development experience in Safari is not as great as I would have imagined. You need to add a lot of logging in order to really see what’s going on, but I guess if JavaScript is your thing, it should be quite easy for your to get something going.

Unfortunately, I wasn’t able to setup an automatic update mechanism for Mantis-Issues-Ext yet. You need to fiddle with the MIME types of your web server and I just don’t have anything in place for that.

I hope Mantis-Issues-Ext makes life easier for some folks out there and helps you focus on working in GitHub instead of Mantis.

Focus

2012-02-12T00:00:00-08:00

The latest update of “Cologne Train” (aka “Bahn Köln”), which hit the App Store a couple of days ago, reflects furryfishApps continuos effort of narrowing the focus while at the same time increasing the value for the user.

We believe that the focus of our App, even though it was already very narrow, was still too wide and needed some redefinition. This is by the way quite opposed to what people tell us in their App Store ratings. They always want more bells & whistles and they all want it for free. So our decision to narrow the focus of “Cologne Train” might seem contradicting. However, we believe it’s the right step:

The more narrow focused an App is, the better it can be at what it does - hence more valuable for the user.

As outlined in a previous blog post: the original purpose of the App, which was notifications about train disruptions, has already been demoted to a second class feature. With the latest update, it disappears into the background and is merely an add-on. Don’t get me wrong, it’s still there and works as advertised, however the main focus of the App has shifted to displaying the most up to date train arrival times in Cologne.

This change has come a long way. We have been thinking about this move since September and running a prototype with various versions for a couple of months. We wanted to get it right and integrate the former main feature as seamlessly as possible with our vision of a more narrow focus.

So far the feedback has mostly been positiv and we are quite happy to have once more narrowed the focus and at the same time increased the value of “Cologne Train” (aka “Bahn Köln”).

Crash Reporting - Don't let your user do quality assurance

2012-01-07T00:00:00-08:00

I’m not a big fan of crash reporting in App Store Apps. In a lot of discussions with developers I had the feeling they see it as some kind of quality assurance. As if it would replace thorough testing, because you can fix everything with an update. I think it’s not a user’s job to find bugs and report them to you. It’s your job as a developer to go the extra mile and test your App to ensure a sufficient level of quality.

That said, I do realize it’s almost impossible to find every bug and to test every possible scenario. That’s why I decided to add crash reporting to furryfishApps’ latest App “Bahn Köln”, when being asked by Crashlytics to join their private beta program.

When reading about Crashlytics I expected it to be one of those frameworks, which is almost impossible to integrate with an existing App. To my surprise it was quite the contrary. Everything was setup within a couple minutes, it couldn’t have been more hassle-free. It’s worth checking out if you consider adding crash reporting to your App.

It’s been two weeks since the first version with crash reporting shipped. Almost 1600 users (about 60%) installed the update and with the Christmas holidays and new years eve, we’ve got some pretty good usage numbers to draw a conclusion.

Overall we had about 4 crash related issues, with merely 15 users affected. That’s 1% of the users who installed the update. Keep in mind: we decided to not send reports automatically. The user must agree to send them, hence there’s a good chance we missed a couple of reports. However, due to the thought we put into each and every decision of our App, we can be quite happy with the numbers.

From a developer’s perspective the numbers are secondary. What’s important is the source of the crashes. As it turned out, only 1 crash was actually a programming error. I forgot to check the length of an array - a stupid mistake, which surfaced in an edge-case. All other crashes were weird side-effects from our very unstable datasource - the KVB-Widget generator. We try our best to protect the user from those side-effects, unfortunately it doesn’t always work.

My reservations when it comes to crash reporting remain: It doesn’t replace thorough testing - on various devices and in different scenarios. Don’t let your user do quality assurance.

In My Humble Opinion

2011-12-30T00:00:00-08:00

In my humble opinion aka IMHO is a phrase you hear quite often in technical discussions found on blogs or twitter. It’s nothing new and doesn’t need further explanation, since you’ve used it probably a thousand times, just like me. However, I’d like to talk about the small, but quite important difference between opinion and fact.

I think (notice, how I didn’t use IMHO here) that in most cases, especially when using IMHO in a face to face discussion, the word opinion actually could be replaced with fact, truth or verity.

I have noticed this for a while and came to the conclusion that the iOS developer community is worse in this regard than the Java community. I’m not too sure why. I assume it’s due to the fact that most of the iOS developers are working on their own, whereas the typical Java developer usually works in a team. I guess you tend to confuse opinion with fact much easier, if you are the only one involved in a project. Every decision you make caters to your own needs and is mostly a perfect fit.

A couple of years ago I read a blog post from Jeff Atwood on Coding Horror, which has been my mantra in terms of voicing my opinion ever since:

I suppose it’s also an issue of personal style. To me, writing without a strong voice, writing filled with second guessing and disclaimers, is tedious and difficult to slog through. I go out of my way to write in a strong voice because it’s more effective. But whenever I post in a strong voice, it is also an implied invitation to a discussion, a discussion where I often change my opinion and invariably learn a great deal about the topic at hand. I believe in the principle of strong opinions, weakly held

I have been applying the principle of strong opinions, weakly held in almost every discussion I had or blog post I published.

My opinions are usually deduced from personal experience and observation, so I will try to defend them to a certain degree. However, I’m more than happy to reconsider my position, if there’s a valid argument against it.

App Store Ratings

2011-11-20T00:00:00-08:00

Inspired by a couple of tweets from fellow iOS developer Max and my own experiences with bad App Store ratings over the past two and a half years, I’ll give you my 2 cents in this blog post.

I don’t want to point out any solutions or suggest what Apple could change. I’d rather like to
highlight what I think motivates the average Joe user to give you a 1-star rating. Maybe it’ll help you understand why your App gets bad ratings and hurtful reviews.

First motivation for a bad rating that comes into mind: your App sucks! It is very easy for average Joe to say that your App sucks. Especially, if he had to pay for it. If your App says it plays music in the background, it must play music in the background! It doesn’t matter to average Joe, that it is not supported on iOS 3 - your App just sucks to him! Average Joe does not read the big disclaimer in your App description and the UIAlertView telling him, that background process are not supported on his version of iOS was dismissed without any notice.

Second reason that I can think of: you are screwing him! The average Joe likes his Apps to be free! That’s one reason why average Joe’s platform of choice is Android - everything is free! Now, you and I know the world doesn’t come in “free”. Chances are high, that you have to operate some sort of backend or pay a designer - maybe both. Well, guess what? Average Joe doesn’t know and doesn’t care. He wants his App for free - although, he is willing to make you a huge courtesy by paying 0.99 cents at most. For average Joe this means: lifetime support and a service with 99.99999% uptime - no big deal!

Third motivation which definitely gets you a 1-star rating: your App doesn’t get him laid! Even you and I know, that we are sometimes guilty of “RTFM”, but as I mentioned before, it applies to average Joe ALL THE TIME! Average Joe doesn’t care if your App is not meant to get him laid, if he thinks it’s supposed to, he’ll tell you! The bad news for you and me is, that he doesn’t know how E-Mail works, but hey - he knows his way around the App Store ratings system! It’s easy enough to hit that 1 star and write “Doesn’t do X, Y and Z!”.

Now, I assume, since you are still reading this, you care about your App and I’m pretty sure it doesn’t suck or at least you are trying. Well, I developed a lot of Apps and frankly some of them might not be masterpieces. However, if I get an App for free, I’ll never go out and give a 1-star rating, because I know how much work went into such an App. That’s exactly the difference between me and average Joe - they don’t know and they don’t care.

For furryfishApps’ latest App “Cologne Train”, we put a lot of thoughts into optimizing the App’s workflow and usability, just to get bad reviews falling into the three mentioned categories. I really don’t mind getting bad reviews for a crashing App or one that doesn’t work as advertised, but I think we always will - thanks to average Joe!

I guess the recipe for 5-star App Store reviews might be: don’t screw average Joe, so he has enough money to get laid and show off, with an App that doesn’t suck!

AppDev Meet November

2011-11-15T00:00:00-08:00

Last months edition of AppDev Meet was awesome, so we are looking forward to a new installment this months:

We will meet on Thursday, Nov 17th - 18:00 at Starbucks near Neumarkt in Cologne (Calendar Export)

In order to stay updated and informed you should follow AppDev Meet on Twitter @appdevmeet!

Git.io OS X Service

2011-11-13T00:00:00-08:00

I’m a big fan of GitHub as some of you might know, so it was a pleasant surprise when they released their very own URL shortener - Git.io.

Services like that always inspire me to build stuff on top of them. It’s just great to see companies you love come up with cool stuff to play with. Sutini and I even had a brainstorming session over a nice cup of Starbucks coffee, whether this could be a project for furryfishApps. I wanted a simple way to generate Git.io URLs for pasting into E-Mails or Tweets. I could think of more features, but that’s the basic requirement.

Eventually, I decided to come up with a simple Mac OS X Service. When installed, you can highlight any GitHub URL, navigate to OS X’s Services Menu and generate a Git.io URL. You’ll get a nice Growl notification displaying the original URL and the shortened version. In addition to that you can instantly paste the Git.io URL into your E-Mail or Tweet.

There’s a lot to improve and it doesn’t work under certain conditions, however you can grab an unpolished version of the Service from my GitHub repository.

AppDev Meet October

2011-10-09T00:00:00-07:00

As mentioned last week, the dates for AppDev Meet October were up for voting on Doodle. Although, there was a choice between 2 suitable dates, there can only be one winner:

App Dev Meet October will be on Wednesday, October 19th 18:00 at Starbucks near Neumarkt in Cologne (Calendar Export)

Last time there was plenty of space, however please remember: Starbucks is a public venue, seats are available on first come first serve basis.

Please follow AppDev Meet on Twitter @appdevmeet for updates and further information!

AppDev Meet October

2011-09-28T00:00:00-07:00

Our first AppDev Meet took place a couple of weeks ago with @sutinisaid, @coderWarning, @daniel_a_a and @anGrauel. We talked about @coderWarning’s plans for his iOS App “Risikoanalyse” as well as development for the Mac with @daniel_a_a and his App “Timing”.

Our October installment will take place here in Cologne again, following the same formular. In order to find a date, we’d like to ask you to head over to doodle and fill in your dates of choice.

We’ll announce the winning date on twitter, so if you haven’t already, you should follow AppDev Meet on Twitter @appdevmeet to stay up to date!

AppCode Screencast

2011-09-19T00:00:00-07:00

A couple of weeks ago I blogged about AppCode and my reasons to stick with it, even though it wasn’t production ready yet. Since then Jetbrains announce that AppCode 1.0 is imminent and released a beta version.

They also give you the chance to get a free version, by show off what you like about AppCode in a screencast. Since I’m already in love with AppCode, I took my chances and produced a video of my favorite features. Unfortunately, I only noticed the horrible quality only after I already edited and tweaked the whole thing. I do apologize and hope you like it anyways.

None flash version here.

First AppDev Meet

2011-09-04T00:00:00-07:00

A couple of weeks ago, I blogged about our plans for the first AppDev Meet here in Cologne. The feedback was amazing and we had a good number of people participating in our poll to find a date. Luckily we had a clear winner:

The first App Dev Meet will be on Tuesday, September 13th 18:00 at Starbucks near Neumarkt in Cologne

We think there should be enough space for everyone who participated in the doodle. However please remember: Starbucks is a public venue, seats are available on first come first serve basis.

If you haven’t already, you should follow App Dev Meet on Twitter @appdevmeet to stay up to date!

AppCode

2011-08-27T00:00:00-07:00

I recently announced on twitter, that I’d be using AppCode, the Objective-C IDE from Jetbrains, in production for at least one week. It’s almost two weeks now, here’s what I experienced.

I’ll get to the point quickly here: It’s a pleasure to develop with AppCode! If you are looking for a strong editor with solid refactoring support, go get AppCode’s 1.0 and never use Xcode’s editor again. If you’ve used any other Jetbrains product, you’ll feel at home instantly. Version Control works out of the box and the debugging UI is a lot more stable than in Xcode.

If I haven’t convinced you yet, keep on reading.

AppCode has great refactoring support. Out of the box, the most important refactorings are assigned to keyboard shortcuts, you are accustomed to if you’ve used e.g. IntelliJ. However, the biggest advantage over Xcode is the variety of refactorings: “Introduce Variable” or “Extract Block” is something that Xcode doesn’t offer you and I would already miss it.

The stability of the EAP build is great, it’s still buggy, but let’s face it: you’ve probably seen Xcode’s “Crash or Continue” dialog at least once the past couple days - with a “stable” version. No matter what went wrong the past week AppCode never crashed! You get a notification, indicating something went wrong and a textfield to report a bug, which can be submitted directly from the App. However, everything kept working - no restart required.

Although AppCode is great, there are some problems, which I mostly blame on the fact it’s still EAP.

I wasn’t able to debug my iOS Apps on any device, which basically is a no-go for production usage. However, the iOS Simulator works fine, so I used Xcode for device debugging and AppCode for development. In a stable version this must be fixed, though.

I only needed Xcode for Interface Builder, to edit Core Data Models or archiving/submitting to the App Store. Those things are not possible in AppCode and frankly, I don’t think they’ll ever be. I could imagine, that editing Core Data Models might be included, however for the other two tasks you’ll need to fall back to Xcode. Personally, I don’t mind switching between applications, however, I can see that this might not appeal to everyone.

I’ll continue using AppCode, even in production, since for me a strong editor is much more worth than an integrated experience. However, I’m looking forward for AppCode’s first stable version.

AppDev Meet

2011-08-25T00:00:00-07:00

Sutini had this great idea for a meet up similar to NSCoderNight, but with a design angle. Welcome AppDev Meet! Here’s our pitch:

What? “AppDev Meet”? Shouldn’t it be called “NSCoderNight” or something?

Yes and no! We wanted to start something fresh and new, so we decided to update the name.

Okay!?! So is it still about code and stuff?

Sure! AppDev Meet is about iOS and Mac development as well as UI/UX-Design. We want to hang out, code and meet fellow developers and designers from the Cologne area.

Will there be a presentation?

Nope! No slides, no talk and no presentation. Just bring yourself, your code or design and some stuff to talk about. That doesn’t mean there won’t be presentations or talks in the future. However, it’s not in scope for version 1.0.

Sounds cool, where can I sign up?

Actually, you don’t have to sign up! No, seriously! AppDev Meet is based on the idea to meet up once or twice a month on a weekday after work - you just show up or you don’t. No strings attached - no hard feelings in case you cannot make it.

We’ll meet up at Starbucks at Neumarkt in Cologne 1. It’s easy to find and easy to reach.

So when’s the next AppDev Meet?

You decide! We set up a doodle to schedule possible dates for a kick-off. The dates with the most votes wins - easy.

Please help us spread the word to fellow iOS/Mac developers as well as UI/UX-Designers. You can follow on Twitter @appdevmeet for the latest updates!

1 in case there’s no space at Starbucks for the estimated crowd, we can relocate to another location in Cologne, so keep an eye on @appdevmeet.

Appdate

2011-07-31T00:00:00-07:00

Our very own app dev shop furryfishApps has been busy lately. We’ve been working hard on an App called “Cologne Train”. As the name indicates, it makes life easier commuting via local trains here in Cologne.

In this blog post I’ll tell you a little bit about the app and highlight a couple of things, which I think are quite interesting. It’s probably not going to get too technical and more informative.

Cologne Train really serves our own needs. We commute almost daily and always ran into the problem of arriving at the train station just to notice that the train is either delayed due to some disruption or just left a couple of minutes ago. We wanted to know about disruptions and train departures before we leave the house - that’s when the Cologne Train App idea was born. It took about 19 days from inception to 1.0, although I have only worked on the App a couple of hours everyday.

For our first feature - informing users about disruptions - we built a custom server backend. It takes care of detecting disruptions and sending out Push Notifications. In our App, users can select which train lines they are interested in and “subscribe” to Push Notifications. It was one of our design goals to make our App as non-invasive as possible. If you are only commuting on train line 16, for example, you probably don’t want to receive Push Notifications for any other lines and thanks to our custom server backend, you won’t receive any.

For Push Notifications we use Urban Airship, which is awesome! In case you’ve never heard of them: Urban Airship provides an infrastructure for Apple Push Notifications (APN) as well as In-App Purchases. In plain English: they solve all those nitty-gritty details with Device Tokens and APN. They also provide an easy to use client library, which handles device registration and badge updates with Urban Airship. It also helps to configure “quiet times”, another feature, which helps our App with non-invasiveness.

Although it’s great to know about train disruptions, something was missing. We also wanted our App to know when the next train would leave at our station. However, our App is not meant as a timetable App, it’s merely meant to save you a couple of minutes, when leaving the house. It’ll show you an estimate of how many minutes you’ve got until the train arrives at the station of your choice. It updates live, meaning if the train takes longer that estimated, it’ll adjust appropriately.

In order to implement this, we tap into the local train companies website, which fortunately, offers a little html snippet, which you can add to your own website. It’s easy and fast enough to parse on the device and scales nicely up to a couple of dozen stations.

Due to the fact that Cologne doesn’t have too many stations, we decided to offer a preloaded indexed list, as opposed to an “only searching” feature. It was a design decision, which we believe, makes the App feel rather concise and easy to use. There’s still a search bar, however the fact that users can instantly scroll through the list, makes the App feel even more native.

Unfortunately, there are situations when our App cannot display any information, e.g. due to a downtime of the local train companies systems or a disruption of network service. However, if the user just refreshed the content a couple of minutes ago, we think the information displayed is still valid. So we decided to not discard the displayed disruptions or train times, but rather add a subtle notification to indicate something went wrong. There are a lot of Apps replacing the content with an error message, which we believe is simply a bad design decision.

Although our App looks quite simple, we pondered over little design decisions like the latter a lot! We want our App to be as helpful and non-invasiv as possible, mostly because we also use it every day.

A couple of days ago version 2.1 was approved, which mainly fixes some bugs. However, we have a lot more ideas to come, so stay tuned. Oh and we love feedback!

Dismiss Keyboard on Tap "Outside"

2011-06-04T00:00:00-07:00

In almost every App I’ve developed so far, the client requested to be able to dismiss the keyboard by tapping “outside” of an input area like an UITextField or UITextArea. I guess it’s kind of a natural thing, especially on the iPad, where you can see a lot more content and have this urge to “move on” after entering some data. Apple’s built-in Apps support it to some extend. For example, if you search for a contact on your iPhone and tap the dark area, covering the UITableView”, the keyboard is being dismissed.

I always managed to get the job done somehow, but was never really satisfied with the solution. Last week, I had to implement this very requirement again and took a step back to think about a more general approach.

The first step to dimiss the keyboard by tapping outside an input area, is to actually be able to detect the tap. Take a look at Apple’s approach in Safari.app, when you enter an URL: it adds a dark translucent layer to the content view in order to detect the tap outside the UITextField. It also prevents accidental taps on any element in the content area.

You can do the same in your App: In your UIViewController, you can listen to UIKeyboardDidShowNotification and UIKeyboardWillHideNotification, in order to add/remove a UIView receiving the taps. It doesn’t necessarily need to be a dark translucent layer like in Safari.app, it could be transparent. I’ve blogged about those to notifications before and posted some sample code on github, in case you have no idea what I’m talking about. I’ve never really though about this before, but it is a general approach, you can take in order to detect taps outside a UITextField or any other element that takes an input.

The second step is to actually dismiss the keyboard. So far we only know, if a user taps outside an input area. I always thought there must be a way to tell the keyboard to dismiss, however the docs clearly state you are on your own. That means you need to call resignFirstResponder on the input element currently active. Fortunately, it’s not too hard to go from detecting a tap to finding and resigning the first responder. I found a neat category on stackoverflow, which does exactley that:

@implementation UIView (FindAndResignFirstResponder)
- (BOOL)findAndResignFirstResponder
{
    if (self.isFirstResponder) {
        [self resignFirstResponder];
        return YES;     
    }
    for (UIView *subView in self.subviews) {
        if ([subView findAndResignFirstResponder])
            return YES;
    }
    return NO;
}
@end

David Linsin

Test-Driven iOS Development

Mantis to Issues Safari Extension

Focus

Crash Reporting - Don't let your user do quality assurance

In My Humble Opinion

App Store Ratings

AppDev Meet November

Git.io OS X Service

AppDev Meet October

AppDev Meet October

AppCode Screencast

First AppDev Meet

AppCode

AppDev Meet

Appdate

Dismiss Keyboard on Tap "Outside"

iOS 3.x is Dead

iOS App Lifecycle and UILocalNotifications

UITextFields hidden by keyboard

Reset App Icon Badge with UILocalNotification

DLWebView - a drop-in browser component

ATMHud

Don't use MainWindow.xib with Autorotation

JSON frameworks API comparison

Different country - Different App Store

Hello World

ShareKit Pimping

UI Test Automation with Instruments

5 Star Rating