Goodbye Android

There are 2 reasons, that, since I've started developing in .Net I haven't looked back. Good tools and reusable skills. I was looking at the applications on my start menu today and remembered that I had also installed the Android SDK on my personal machine and was thinking about doing an Android application for Veronica to get a head start on Android development at work.

I found out yesterday that since we decided to back burner the Android development that we're sending my "new toy" to another office where they have someone doing some testing with another one of our already completed Android applications. This is basically the nail in the coffin for my Android project I think. I think as a company we are moving away from it and the one application we have may live on as the only application we ever have in Android.

As, I looked at the application on my machine, I felt a bit of sadness. I may have played some role in us migrating away Android. I was clearly no supporter of it. But I would have loved the chance to have the company basically fund my learning the platform. And I'm sure I would have grown to appreciate things about it. It isn't that I can't learn it on my own, but my free time seems so small these days that at least for the foreseeable future this is probably the end of my Android development.

So I started thinking about the things I liked and disliked about the experience and it came back to those 2 things I like about .Net which are noticeably absent here. Don't get me wrong. Not all of the tools are bad. The emulator for example, while picky, is ultimately highly configurable and the settings are easy to access. The package manager makes pulling down new versions of the SDK fairly painless and I'm sure that there are other bits in there I never got a chance to touch. My problem on this front was the lack of a proper out of the box solution. I seriously think Google is slowly abandoning Android, but it would have made all the difference in the world to have had them provide their own IDE. Eclipse is open source, I imagine that they could have stripped it down and created a dedicated Android port of that which was maintained by Google. This one move alone would have made a world of difference. 

The next issue I had was the reusable skills. Yes, Android more or less lets you code in Java. But 2 things are of note here, Google did not write Java, so Android did not provide this skill and secondly the Android related parts of the API don't feel like native Java libraries. Also, many of the concepts on the UI front are mandatory (concepts like Actions and Intents) and not core Java concepts either. Basically, everything I learned about Android is only valid for Android programming. And much of what I know from Java isn't applicable. Frankly, I would have actually been happier if Google had skipped the illusion that they are somehow a Java based platform and simply forced their own language. Unlearning the things you already know is difficult to begin with, but trying to do it while you're simultaneously looking at code that looks like what you're trying to unlearn makes it even harder.

Of course at this point Google is too in bed with their Dalvik engine to throw it out. Thankfully that is the more minor qualm I had. In reality there are very few languages that bear any degree of transferability. I think that there would be a chance of me going back to Android development much sooner if they fixed the IDE problem. It doesn't need to be as good as Visual Studio. But some things that are needed: 1 Installer. Should include an IDE and entire SDK for at least the latest platform version with the ability to download others. IDE should be pre-integrated with SDK, so I should be able to open it and start a new Android project. There should be a default emulator configuration for each version and debugging should launch this without the user needing to create it (it can remain configurable, just should run out of the box). And should support debugging from the emulator as well as a device.

Many of these things were missing. The SDK has no IDE, so you need at least 2 installers. The SDK itself is really just a hollow shell, it launches an API manager upon completion where you need to choose the pieces you want. Then depending on your IDE you need to figure out how to get it integrated. Some times the process involved in starting a new Android project is difficult as well. The first time you may need to point the IDE to the install path, if the IDE and SDK were in the same package this wouldn't be necessary. There is no default emulator, you need to open the AVD manager and create one for each API level you want.

These tasks take no small amount of time or effort. Especially not the first time you try getting it setup. 

If they had the things above, then they would given their developers what they need to get started coding quickly and simply. That will attract new talent to your platform. And while Android attracts a lot of developers, it is because of Android's market share and in my short time with an Android device that I can say that very few people who develop for that platform have talent.