First Impressions of Android Development
I started doing iOS development around 4 years ago. It‘s certainly not perfect, but developing for it is totally different than the way you work with the largely open source based stacks that have come to dominate the Java World. There‘s documentation, sample apps, and stuff works. Having written an app for the iPhone that I needed to port, I have finally started into the Android World, seriously, with an open mind. So far, there are some good things, but to my mind, a dispassionate comparison to iOS would make Obama‘s electoral college victory look like a squeaker. Since I‘ve shown myself incapable of dispassionate analysis, I‘ll give my usual screed format, hoping (genuinely) that others can perhaps tell me where I‘m reading the gauges wrong.
TDD: Bring Out Your Excuses
When cars get reviewed or examined, there‘s a list of expectations that we have that together constitute our notion of what a modern car should be. For me, TDD provisions would literally be the first item on the list. In his seminal book, way back in 1994, Bertrand Meyer said garbage collection was a requirement of a modern language (ARC and 10 years of suffering with the VM‘s GC disabused me of that notion), but seriously, if you don‘t think that TDD is an absolutely essential ingredient in a modern framework offering, you are a neanderthal. Apparently, even though Cedric, author of TestNG and a book on testing, was on the Android team, really, seriously, what score does this platform get? I would give it a 2 (out of 10). Their page on ‘Testing Fundamentals‘ (here), reads like ‘I drew the short straw and had a choice between writing this retrospective, dog‘s dinner documentation or train new recruits for the next month..‘ Funny thing is, at first I read this and thought ‘oh, ok, this sounds promising,‘ then the holes in it fed a vortex that gobbled up so much time I started to see spots.
The sale here is that there is an easy way to do end-to-end tests, which is great. Sadly, the reality is that the emulator is a torture device that‘s so slow that you cannot say its suited for work unless the operator is lobotomized. Have these guys ever seen the Simulator in Xcode? Lightning fast and 100% coverage; in short, exactly aha you want in a simulator. When I tried to run my first tests, I seriously lost almost an hour because I was convinced my tests were hanging. Then I was reading threads (how you learn) and came across one where a responder was telling an OP that you have to wait because the test could still be loading. Sure enough, finally got it to work.
Running the app on the device is extremely fast.
The next thing I wanted on the TDD front was to just write a simple unit test. Next task was to call a web service, get some HTML back and parse it. There is an HttpClient inside the android jar. Great. So I want to start with a bunch of unit tests that just parse the HTML. Ok, how do you just write a unit test that is not an integration test? Turns out, like almost everything else, that requires a bunch of reading and the answers are still not forthcoming. Furthermore, android has junit inside it, so you aren‘t just pulling in your own version. I took some time trying to add Hamcrest. That‘s rather simple, but then it gets tangled too because Android‘s version of JUnit is an older one so you don‘t have assertThat in your static import options.
You‘d think there would be a lot of sample code that would include both unit tests and ‘unit‘ integration tests. I couldn‘t find them. There are examples from elsewhere. There are also other testing tools, one that uses mocks Roboelectric, that looks pretty good, but seriously, before you can write a simple app, you have to do all this research and figure out which tree limbs to inch to the end of?
Overall: 2 might be generous. Early on going in this direction, it was pretty clear that even after all this work, there‘s zero chance the result would be as good as iOS where you can just turn things on/off in schema and run them at light speed.
Granted, I have not wandered far into the woods yet, but the framework itself looks really tired. Everything is an action, or an intent, and components are looked up by id, etc. Anemic I don‘t think covers this. Reminds me of and exchange on The McLaughlin Group yesterday where Pat Buchanan said most drug offenders started with pot and Clarence Page‘s response was ‘another study said even more started by drinking milk.‘ If I went into a design meeting to lay out my thoughts about, I dunno, say a model for implementing a nutritional problem and said ‘if you think about it, everything‘s pretty much an action,‘ my guess is that there would be a lot of chuckling.
It‘s also just tiring to see the usual stuff of having to stick casts in all over the place. Seriously?
But even more surprising is this: if the Java World really believes the BS they trumpet from the mountain tops all the time, that its base of open source is what makes it so wonderful, how come Android is an island? The team chose not to use maven (in 2007), not to update JUnit, not to make DI the backbone of its architecture (good choice there, but DI sucked up most of Java‘s energy in said decade). Probably the strongest defense would be ‘well we are doing a platform so we can‘t drag in these other things.‘ Ok, then the great advantages of open source are only available on one layer to users who are at the end of the fabrication chain. Pretty sure that sounds like a bad idea.
Cocoa is not perfect, but either there‘s another clatch of undiscovered docs about Android or this is looking like another huge mismatch.
Already mentioned that the emulator is completely insane. Slow. The wizard to create a new one (and the supporting documentation) is abysmal. The result is unusable.
Working inside eclipse has been ok so far. There are a few wizards for making new things that speed stuff a little bit (of course Xcode‘s are much more extensive, which is inexcusable because I think eclipse is easier to extend, having written some plugins). The code completion works pretty well. I have not used the debugger for much yet. Logging looks a tad more capable in Android as you can create different logs by associating different strings with the logger and each will have its own console.
The design tool is a complete joke next to Interface Builder. I would love to see someone make some screencasts that show someone using this thing to create a simple app or a stub for an app. For sure if you made a split screen where you had one iOS dev and one android dev and gave them a simple app to do that involved stubbing out a few screens and getting some simple navigation working, that‘s going to be not John Henry versus the Steam Engine, more like a featured subject from Hoarders vs. someone who‘s pushed work across an organized desk for some time.
Another mismatch here.
The results on this was completely unexpected to me. I thought surely there would be some form of ORM in Android. Nope. Folks, most projects end up bearing the scars of having been too ambitious, Android just shows at every turn that this was slapped together by madmen who were running to match an existing offering. Again, ORM was one of the things the Java world spent most of its energy on in the same decade, and I have argued, to greatest success. There is none. They expect you to use some stupid helper class and then just push your junk into the database on your own. Really? Again, maybe I am missing some other area of smoldering slag somewhere. Laughably incapable of being compared to iOS which has CoreData. Not perfect, but CD allows me to make a simple diagram, wire up some attributes and relationships, and then have my stuff going in and out of the db, and it has migration tools, etc.
I checked these items with a friend who has been doing a bunch of Android development. He urged me to adopt Roboelectric, the Maven plugin and IntelliJ.
Read a review today of the Nexus. Their conclusion was the iPad beat it primarily because of the better software that was available. Again, the Developer, surprise, sees his role as central. There were probably a ton of reasons to jack Forstall, but if the new Apple is the CFO running the company and the knighted industrial designer ‘designing‘ the software, they are doomed. I am convinced, still, though, that it‘s theirs to lose. Android is not going to get magically fixed; the MFC experience was a good example of how a simplistic, inept core cannot just sprout a capable spawn. Even for the people who are willing to endure some more pain in the name of open, are going to find that the law of diminishing returns quickly starts to be exponential rather than fractional or multiple. In other words, you‘ll start thinking ‘ok, I can add a few ‘if platform()==KINDLE‘ statements where needed,‘ and then wake up one day to a subpar experience that requires a stupid amount of bloodflow to keep alive.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)