Phone development myth

I recently stumbled upon a quote. For the life of me, I can not remember where I got it from or who wrote it. It sums up the past year of my life in mobile development.

Let's dispel the myth that mobile development is 'EASY', beginner-friendly, and suited for 'web developers'. This is marketing crap and media hype. Mobile development is VERY difficult - it's much more difficult and more complicated than web or server app development. If you have experience in web or server app development, this experience will NOT help you with mobile. Sample code you find on the Internet, books, tutorials (even good ones) will not come close to getting you ready for the minefield that is mobile development, deployment, and testing. The code you copied and pasted might simply stop working on a real device (even though it compiles and runs in the simulator) due to a carrier limitation, device limitation, or user configuration choice.

You cannot just read the API docs for a mobile platform and start coding, they do not give you any idea what really happens on a real device, on a real network. No API docs, books, or tutorials can give you experience on multiple handsets, carriers, and OSes. If your mobile app works perfectly in the simulator, this means nothing at all, and you have just gotten started (not finished).

Mobile is a whole different ballgame full of hardware capability divergence, screen size & form factor divergence, carrier limitations, DPI independence issues, and it all gets increasingly more difficult when you get into  cloud-connected multiplatform-mobile

I'm going to quickly dissect this as maybe it will spread some appreciation to users when they use applications on their Android powered phones. If you have ever developed support for Internet Explorer in the web design world, then designing layouts for mobile phones is 10 times as worst. Layouts can look great on emulators and test phones, but then look like utter crap on similar phones due to small differences of pixel ratio and display size. Remember .dip is your friend.

Lets start with Android APIs. Phones can run anywhere from 1.6 to 2.3 (most updated). If developers want their application to reach as many users as possible they will code support for all versions. However, some features in 2.2/2.3 just aren't available in 1.6, so developers are either forced to reduce functionality or leave a group of users in the dark. Some wealthy corporations will basically make 10 different versions of their application just to account for each possible API version. However, for small time developers developing out of their home, that just isn't a realistic possibility.

I don't know how long I spent debugging problems that were visible on one version of Android, but non-existent on another. My friend became Build.VERSION_CODES as I could determine what version they were running and run X block of code depending on it. If your are messing with XML/SAX and any databases, I guarantee you will run into this. Make use of the version codes, as trying to build code that works in all versions just isn't possible nor efficient.