Archive for the Programming Category

Phone Hacking Update

Posted in Programming with tags , , on February 7, 2009 by zolthanite

If what CNET reports is true, then Apple might finally put their apps on the level with the rest of the mobile world and give them background threading support after all.

This only addresses a small part of my beef with the thing.  But, better late than never I suppose.

Hacking on Phones

Posted in Programming with tags , , , , , on January 27, 2009 by zolthanite

I recently spent a good 3 months going development for the Google Android mobile phone platform.  I also had the rare opportunity to work closely with two other people doing development on the iPhone and BlackBerry.  Communicating with each other is like putting an American, a Jamaican, and a Canadian together.  The American and Canadian think the other has a funny accent and have some cultural differences, but at least the words make sense.  Neither, however, probably understands the Jamaican, not without trying really hard to get past the slang.

Android and BlackBerry apps are both written in derivatives of Java, a language most people learn in high school or early in college.  iPhone is written in Objective C, a language which no one comes close to working with on a regular basis.

Over the coming years, the iPhones, BlackBerries, and gPhones of the future will all be sporting touch screens, app stores, and scores of developers trying to make a killer app sold to a wide market that will make them a comfortable amount of money.  Each phone has its weak spots, so if you choose to develop for one of them, you have to be fully aware of what you’re getting into.



Platform:  From what I understand, you basically have to be running XCode.  Which means, Mac only buddy.  No PC for you.

Language: All iPhone development is in Objective C.  Objective C, from a syntax perspective, takes C-like syntax and adds a pure Object Oriented design philosophy to it so it’s more akin to SmallTalk.  The problem is, no one really knows Objective C on their own, and Apple’s own online resources on the subject are fairly difficult to get through.  It’s a hideously ugly language, and requires much more time than the other two devices to learn.

Imperialism: Apple runs a very tight ship with the iPhone.  Even getting access to the developers kit requires $100, so unless you’re a true trooper, you could do development on Android for free, where the only fee is for creating an account to publish to the Android Market.  

Developing on the iPhone also requires you code everything yourself.  You are unable to use 3rd-party libraries of any kind, or your app is immediately rejected.  This, coupled with the other language issue, makes iPhone development a path not for the faint of heart.

You also can’t develop anything that would behave well as a thread, like blocking I/O.  But if you’re going to do it, you have to be displaying something while that code is going on.  Apple doesn’t want you naughty programmers developing apps with rogue threads.

Publishing your app to the market also requires an approval process that can only be described as “arbitrary”.  Apple can, and will, deny your app access to the market for any reason it feels do not correctly aid the “user experience”.  Some of it is common sense.  However, we developed quite a few apps that only had a change of UI.  One of the later apps was rejected for not displaying something that none of the other, approved apps had to do.

Communication: Apple censors a lot of communication, both with the developer and among the developer community.  It wasn’t until maybe… two months ago that Apple allowed developers to exchange some code on their forums.  They partially-reversed the prior decision of non-communication to protect intellectual property among developers.  Think about that for a second.

You’re in a foreign language, you can’t help other developers with libraries, and you can’t even say “Hey, this is your problem”.  It’s a miserable situation to be in unless you’re naturally gifted.  Of course, most of this probably doesn’t matter if you end up Jailbreaking the phone.  I would probably recommend that if you are so inclined.


Platform:  You’re in Windows, so it’s much more ubiquitous than OS X.  The problem, however, is you have to pick which phone you want to develop for.  The JDK they use for the Pearl, for example, is not the same as the Curve or the Bold.  Instead of being feature-based and developing for phones that support a given feature, you have to target specific phones from the beginning.  Which would be okay, except the new phones getting the newer JDKs also get the enhancements on the things that were present in legacy elements which are not backwards compatible.  Like a new look for the UI which would be completely cross-compatible.

Libraries: Java ME uses a highly trimmed version of Java SE in order to give the companies that use it control over what their VM will support on the phone by meeting small subsets of specifications, or at least I hope that’s why it’s as fractured as it is.  Standard Java libraries and JARs are not useable as a result.  RIM, therefore, has to be able to fill in the gaps with their own libraries.  The problem is, they kinda don’t.

One of the issues we ran into is that, if you use REST services your client needs to be able to construct multipart HTTP POSTs.  It’s a very tedious thing to do, and took us about a week or so of straight up hammering away at the design to get it right.  It’s annoying, because a developer wanting to make an HTTP GET or POST isn’t outlandish, and would make the lives of incoming programmers who would simply use Apache libraries for the same thing in Java SE.

Hosting:  RIM is developing their version of the app store.  I don’t know when it’s launching, although it’s supposed to be soon.  In either case, you’ll need your own hosting solution.


Hardware:  The T-Mobile G1 is a sketchy phone running a great OS.  No, really.  Acquiring a GPS signal for location-based apps takes much longer than either the BlackBerry or the iPhone.  The battery in my current test phone doesn’t even fully discharge before the phone cuts itself off.  Even if the phone were to run without problem, the battery would still die within the day unless WiFi and 3G is disabled.

Camera: One of the things that really stands out on Android is the camera.  BlackBerry allows you to switch to the native camera app to take pictures, and iPhone seems to be relatively straightforward in that regard, but Android makes you manage the surfaces, previews, etc. all on your own.  You pretty much have to do it on your own, it’s completely trial and error, and it completely kills any kind of background processes you have running in order to run it (It does restart them afterwards though, if you’ve programmed it well).

Orientation:  One of the things the iPhone has spoiled people on is rotating the phone causing a change in view.  Android seems to support it in the SDK, but the actual hardware does not.  It’s problematic when you’re taking pictures, because they are all taken in landscape unless you make provisions otherwise.

Android Market:  Being able to upload without an approval process, much like publishing software, is great.  You cannot access the Android Market from anywhere except your G1.  You can’t see the comments people are leaving at all, just star ratings.  If you want to browse them, you need to use a 3rd-party site like Cyrket to do so.  Download statistics from the Google Account Console also do not update but so often.  

More significantly, and more problematic, the comments that will get left on your app are occasionally marketing bots or extremely negative comments by a group of people that are fairly profane.  Over New Year, many of the comments in the app had nothing to do with the app itself and were shout-outs and “first!!!”‘s.  Seriously, where’s the quality in that?

Google Maps:  One of the strangest things about Android is that the iPhone supports Terrain and Hybrid view with the Maps API, but Android does not.  Not much else to say.


My personal opinion is that, if you’re going to pick a platform, pick Android.  Especially if you’re starting out on programming, or want to teach a class on mobile app development or something similar.  It’s free, the dev support is there, and you don’t compromise as much as you would on the other platforms by leveraging what most people already know.  For exposure, BlackBerry will probably be the best bet if you can make the initial two-weeks of the app store launch with a solid, quality product.