Initial thoughts on Android platform


Initial thoughts on Android platform and review of the programming experience from the perspective of an iPhone developer

  

When I was growing up reading any technical paper I could download before I realized most of the world ran on windows I thought based on the documents being shared online that we lived in a world of C, C++ and Unix machines.
Years later when I started looking into iPhone development the platform felt very familiar. Smart phones might feel a million miles from 80’s servers but the operating system and the languages share the same lineage.
A few years later Android came out. It’s designers courting web developers proclaimed how the platform web like. I must admit to being a little biased because of this. I didn’t like the web like UI design or the idea of Java running on a virtual machine and that made me put off fully embracing Java.
Even though I try to be open minded about these things, I like all the major OS’s for different reasons and I knew I was biased but still the idea along with the idea that I wasn’t a web developer (although I’d dabbled) meant I that the information just wouldn’t stick.
Since then I have changed 180 degrees. I still like the close-to-the-metal aspect of Objective C, I actually kind of like memory management and having to alloc and dealloc memory but there is a lot to be said for the order and abstraction of android way of doing things too.
The first thing that I had to deal with with programming for android was the structure. Android like Ruby on Rails (but not to the same extent) is highly dependant on it’s folder structure. I think developers in the past would have thought of it as limiting but developers are more and more coming around to the idea that sometimes it’s good to be forced to do things a certain way because it makes it easier to localize and for the next developer to work on the code (and it’s that what most of software engineering is).
Years ago people thought of program as getting programs to do things, and a good programmer as someone who could get the program to go things quickly. I think over the past decade or two it has become more clear that a good programmer is one that makes things easy for the programmer (or designer or translator) that comes afterwords and who works in a structured way.




Android reflects this. Text, Design and code are separated out. So in theory you could give the Strings file to a translator, give the .xml GUI files to a designer with HTML experience and give the .java filed to a programmer with .java experience and they could all do their jobs. It makes sense from a version control point of view too. They can all work on their respective pieces of the project while that is more difficult in iOS/Objective C and Windows Mobile/C#.
The XML files for designing the screen are actually quite nice to deal with. I’m still not crazy about how fragmented the android platform it deals with different layouts nicely.
I was surprised with the Java files. I knew the platform was Java based and I have Java experience but I expected it to be more difficult to learn. After learning how the app lifecycle worked, how to connect the GUI elements in code and how to work with fragments and the back-stack not much was different from the Java I know well.
While it might miss that nostalgic close to the metal feel I have to say they really have thought of the development process and designed accordingly from the simple to set up IDE/SDK to the file structure.