303

This is my last blog post here on blogger.com! You'll find my new thoughts, projects and development ramblings at http://dlinsin.github.com. I migrated to blogger.com in late 2005 and was always quite happy with it. More than 5 years and exactly 502 posts later it's time to move on to something new. Subscribe to my new blog feed, check my stuff on github or follow me on Twitter.

I think I Spider

I'm writing for the Synyx GmbH & Co. KG mobile solutions blog. From time to time, I'll cross post articles here, if I think they are of interest for you. If you'd like to read all of my other posts, subscribe to the Synyx Mobile Solutions Blog.

I'm proud to present, that our first own App has made it to the App Store last week. It's a beautiful mobile interface to the web site http://ithinkispider.com. You can find out more over at the Synyx Mobile Solutions Blog, or just hit the App icon and download it for free from the App Store!

My lovely mister singing club!

One week in the App Store

Last year I was working on a Nine Men's Morris mobile game called Doublemill. My job was to implement a REST-based server back-end on the Google App Engine. You might remember a couple of posts on that. My colleagues were responsible for coding the Android client. Since I'm an iPhone user and I'm not going to switch to Android anytime soon, I decided to port the game to the iPhone/iPod touch platform.

One week ago Doublemill Lite hit the App Store and it has been received very well, according to the download numbers. I'm pretty stunned by the magnitude of more downloads we have compared to the Google Marketplace. It could be that we only have full fledged paid version for Android out there. However, you can refund your money with Google within 24 hours, if you don't like the game, so basically every App is also a Lite version.

I believe in the App Store as a channel of distribution, although only after one week we already see the negative sides of it: user ratings. Doubemill Lite started off pretty good with 3-4 stars the first couple of days, but then rapidly dropped down to 1-2 stars. First, I was pretty bumped about it, but then realized that you are only asked to rate the App when deleting it from your phone. Considering, that less than 3% of people who downloaded the App also rated it, I guess most of the others might still happily play with Doublemill Lite.

We received some feedback, mostly about the controls, which we've already addressed and improved. There should be an update in the next couple of weeks, but at the moment I'm kinda handicapped, because my MacBook Pro died on me and I have to wait for my new one to arrive next week. With the soon to be released update, we've also added iPad compatibility, so you can have a virtual Nine Men's Morris Board sitting on your table.

There's also been progress on the premium version of Doublemill, which will go Beta any-time soon. So if you are interested in testing it, drop me a line and I'll hook you up!

Doublemill Lite submitted to the App Store

Last year I was working on a Nine Men's Morris mobile game called Doublemill. My job was to implement a REST-based server back-end on the Google App Engine. You might remember a couple of posts on that. My colleagues were responsible for coding the Android client. Since I'm an iPhone user and I'm not going to switch to Android anytime soon, I decided to port the game to the iPhone/iPod touch platform.

It's done! Doublemill Lite is on Apple's table for review!

I started working on the iPhone port of Doublemill almost 6 weeks ago. I decided early on to release a free version of the game. Actually, I wanted to release it after only 2 weeks of intensive hacking. By that time I had implemented a full Player vs. Player feature.

However, my colleagues convinced me to first implement a Player vs. iPhone feature before releasing the free version and I'm glad they did. Although it meant a lot of additional hours of work, it cleared the way to the full version, because I completely finished implementing the foundation of the game. After just two weeks I got the Player vs. iPhone feature fully working.

The last two weeks I spent in beta testing. The funny things is, I almost caught all the major bugs myself. The feedback I got was positive without exception and I was confident enough to release Doublemill Lite today.

It's going to be the third free Nine Men's Morris game on the App Store, but with all due respect, I think our game can easily beat the competition in terms of UI design and iPhone compliance. If you don't believe me, I'll post a full featured marketing post on Doublemill as soon as it's available on the App Store. Stay tuned and follow us on Twitter @doublemill!

Is the Future of Mobile Apps the Web?

The Mobile Times 2010 conference in Dusseldorf, which took place last Thursday, featured a lot of talks on how to do approach cross platform development. A lot of them suggested web development technics as a way to escape native vendor lock-in, such as Apple's iPhone OS.

There are mainly two approaches:

1. You develop a web site using HTML, JavaScript and CSS zip it and deploy it together with a Player

2. Or you develop a custom website which is served from your servers

The first approach is usually tackled using a framework such as PhoneGap. It event provides an API to include platform specific functionality such as GPS in your application.

The second approach either uses traditional web development technics or targets a specific browser, such as WebKit. One example is jQTouch, a jQuery plugin with cross platform support - unfortunately only WebKit.

The presentations, advocating those two approaches, mentioned mainly two advantages:

1. No need to comply with platform policies (think of Apple's App Store)

2. And you can leverage cheap web coding skills

Those are the facts, I collected during Mobile Times 2010. Unfortunately, the benefits using the web development approaches were not really balanced by any downsides.

I really doubt that the web development approach is the way to go in terms of cross platform mobile app development. I think frameworks like PhoneGap are doing an awesome job, putting an abstraction around the native platform.

Unfortunately you get the least denominator of your platform is capable of and that's a real downside to me. If I put on "average Joe head", I want an app that is using the full potential of my phone. I don't care that it was cheaper to develop a web-based solution and I definitely don't care that the framework I'm using is only offering partial support for my phone features.

Another problem is platform defragmentation! I won't go into it - don't worry - I simply want to point out one downside: In my humble opinion, it is not possible with web development technics to "write once, run anywhere"! You will have to tweak the CSS and work around the abstractions of the framework your are using! It might be cheaper, because we all know that the average web development frickler (amateur craftsman), only charges what he deserves. However, I don't think it gets you anywhere in the long run.

I think we shouldn't approach mobile application development with only the engineering side in mind. Instead we should rather focus on the customer and what he asks from a mobile app. I think the success of the App Store has proven that native apps are the way to go, even if they mean more effort on the development side.

Mobile Times 2010

On Thursday, I'll be attending the mobile times 2010 conference in Düsseldorf, Germany. It's a rather small one day event and as the name suggests, all about mobile development.

There's only a two or three sessions, I'm really interested in, since my focus is iPhone and Android. However, there's one session which I'm really looking forward to: "Cross-compiling Android Apps for iPhone with XMLVM". The reason why I'm interested in this is that I just went through a rather unpleasant experience of porting our Android game Doublemill to the iPhone OS. If there was a faster and more efficient solution, I'd be happy - frankly, I don't think it works!

I'll blog more about my roller-coaster ride from Android to iPhone in a future post, but for now I'm looking forward to Mobile Times 2010.

Http Basic Authentication with Android

The Google App Engine infrastructure, I'm developing in my spare time, is meant to be used by an Android client. To give our users at least a vague feeling of security, we decided to use a Basic Authentication together with HTTPS. Apparently, Android 1.5 is shipping with Apache's HttpClient 4.0 Beta2, which has a pitfall, when it comes to Basic Authentication.

When you search for HttpClient and Basic Authentication, Google will most definitely send you to the official documentation of HttpClient 3.x, which shows you, how to do Basic Authentication in a preemptive way. That means, sending the client's credentials with every request, instead of waiting for a 401 Unauthorized response and only then sending the credentials. That's probably what you want to in the first place, because it saves your client a request.

HttpClient client = new HttpClient();
client.getParams().setAuthenticationPreemptive(true);
Credentials defaultcreds = new UsernamePasswordCredentials("username", "password");
client.getState().setCredentials(new AuthScope("myhost", 80, AuthScope.ANY_REALM), defaultcreds);

This sample code won't compile with HttpClient version 4. The method called setAuthenticationPreemptive is missing. The problem is, if you omit this very method call, the code still works, but the authentication is not preemptive. We missed this little detail and only noticed after a while, that every request was preceded by a 401 Unauthorized request/response cycle. That doubled the amount of requests we served.

The HttpClient 4 documentation shows how to do preemptive authentication with the new API. You need to implement a so called HttpRequestInterceptor:

HttpRequestInterceptor preemptiveAuth = new HttpRequestInterceptor() {
    public void process(final HttpRequest request, final HttpContext context) throws HttpException, IOException {
        AuthState authState = (AuthState) context.getAttribute(ClientContext.TARGET_AUTH_STATE);
        CredentialsProvider credsProvider = (CredentialsProvider) context.getAttribute(
                ClientContext.CREDS_PROVIDER);
        HttpHost targetHost = (HttpHost) context.getAttribute(ExecutionContext.HTTP_TARGET_HOST);
        
        if (authState.getAuthScheme() == null) {
            AuthScope authScope = new AuthScope(targetHost.getHostName(), targetHost.getPort());
            Credentials creds = credsProvider.getCredentials(authScope);
            if (creds != null) {
                authState.setAuthScheme(new BasicScheme());
                authState.setCredentials(creds);
            }
        }
    }    
};

It basically sets the Basic Authentication headers, before each requests and thus avoids the 401 response. In order for the interceptor to work, you need to add it to the request chain:

DefaultHttpClient httpclient = new DefaultHttpClient();
httpclient.addRequestInterceptor(preemptiveAuth, 0);

You might also run into the problem of using the old HttpClient 3.x way of doing Basic Authentication. It does work, but it's not preemptive, which you might not notice right away. Save yourself some time and checkout the sample code provided by Apache.

Furthermore, I wasn't abel to find any official site, which states the version of HttpClient, used in Android 1.5. There are various sources, you might encounter, when searching Google, but I would like to see an official site, that states the version. A reason for Google not to reveal this information might be, that they adopted HttpClient and thus are not compatible anymore. However, to avoid mistakes and confusion, it would be nice to know, on which version the Android HttpClient is based on.