This Blog Has Moved!

Right, so yes, five years ago I moved to github pages, and never bothered to redirect any of these pages there. Now I've moved on from there, and... Finally I am using my real domain, trishagee.com . My blog is now at trishagee.com/blog .  See you there!
Post a Comment

My Experiences with Android Development

Because I was missing coding, and because my friend and I had an awesome phone app idea at the weekend, I thought I'd try my hand at developing an Android application this week.

I want to give a quick overview of my preliminary thoughts on getting started on this endeavour.

Background: I've got more than 10 years Java experience, but any UI for the applications I've worked on was always a web UI.  I am completely new to mobile app development.

Getting Started
I spent maybe a day and a half reading the excellent Android developer documentation and attempting to hack out a quick 'droid app.

I was surprised to find the Application Fundamentals section actually made sense to me.  There appears to be a clear architecture with design guidelines laid out for developers to follow.  This shouldn't really be a surprise I suppose, but years of hacking around with web UIs with poorly implemented MVC architectures must have left me thinking that all frameworks are less "frame" and more "work".

Setup
I remember the disaster of trying to get my first JDK working on my 486 - what a nightmare!  And getting Tomcat 3 installed and running?  Forget it.  I also remember the last time I made a serious stab at a learning a new technology.  I tried develop a Grails/Groovy application in Eclipse.  The IS guys had to rescue my laptop from me during that enterprise before I could do it any serious damage.

Installing the SDK on my mac was surprisingly simple, especially bearing in mind I'm new both to OSX and to mobile development.  I don't know if it's because Android development has been well thought out and well supported, or if it's a function of both the industry's maturity and my own experience.

The integration with IntelliJ was much slicker than I expected, especially since I'm using the freebie Community edition.  I don't remember the exact steps to tell it I wanted to create an Android project, but it must have been ridiculously easy otherwise I would remember the trauma.  I do remember a little confusion around installing the Android platform - I hadn't understood the difference between installing the SDK and then installing a specific API for it.  But the documentation and the android application got me on the right track in the end.  And then when I clicked the "run" button in IntelliJ, hey presto!  The emulator appeared and there was my app!

I loved the emulator.  I had some confused idea that I would have to plug my own phone into the laptop to see my application.  Instead, the emulator looks enough like my actual phone to give me decent feedback on how the app is going to behave.  The downside is I was trying to play with the camera, and I couldn't see how that would really work in the emulator, but I got a fair idea.

Did it work?
I managed to get a rudimentary application running, with a button and some descriptive text (it's not about to win any awards).  The button was supposed to launch the camera viewer, but my first few attempts just resulted in the crash notification.  It didn't take long to figure out how to use logcat to see the stack trace and see I hadn't set the permissions correctly to use the camera, so I rooted through the CameraPreview example in APIDemos to figure out how to set up the AndroidManifest.xml correctly, and rather amazingly it all worked!

Any downsides?
I was surprised (and slightly disappointed) at the amount of XML configuration.  I've seen plenty of evil Spring and Ant XML in the enterprise and I thought frameworks were moving away from that.  The manifest I can understand I suppose, but it felt a bit weird to be defining the UI in XML.  It seemed like a bit of an afterthought tagged on after all the well-defined architecture behind the scenes.

But maybe this will make more sense to me as I develop my application further.

In Summary
  • I was pleasantly surprised to be able to get an Android application (albeit a very basic one) working in only a few hours.
  • Development in IntelliJ was much easier than I expected.
  • The documentation is actually very good.
We'll see how I feel about it when I start trying to do more than a very simple example application.

Comments

  1. Mark27 January 2011 at 10:31

    I too was surprised by how easy it is to get up and running developing an Android app. I still haven't progressed beyond that stage (really must get back to it!). Having an emulator is great, as having to transfer it to my phone each time would be a pain.

    As for using XML to define the interface, I wonder if this idea came from the XAML used by Microsoft for WPF development. I haven't decided yet whether I like this or not...

    Mark

    ReplyDelete
  2. Mark27 January 2011 at 14:13

    You might want to give this a go...

    http://www.droiddraw.org/

    ReplyDelete

Post a Comment

Comments have been disabled since this blog is no longer active.

Popular posts from this blog

Dissecting the Disruptor: What's so special about a ring buffer?

Image
Recently we open sourced the LMAX Disruptor , the key to what makes our exchange so fast.  Why did we open source it?  Well, we've realised that conventional wisdom around high performance programming is... a bit wrong. We've come up with a better, faster way to share data between threads, and it would be selfish not to share it with the world.  Plus it makes us look dead clever. On the site you can download a technical article explaining what the Disruptor is and why it's so clever and fast.  I even get a writing credit on it, which is gratifying when all I really did is insert commas and re-phrase sentences I didn't understand. However I find the whole thing a bit much to digest all at once, so I'm going to explain it in smaller pieces, as suits my  NADD audience. First up - the ring buffer.  Initially I was under the impression the Disruptor was just the ring buffer.  But I've come to realise that while this data structure is at the heart of the patte
Read more

Dissecting the Disruptor: Writing to the ring buffer

Image
This is the missing piece in the end-to-end view of the Disruptor.  Brace yourselves, it's quite long.  But I decided to keep it in a single blog so you could have the context in one place. The important areas are: not wrapping the ring; informing the consumers; batching for producers; and how multiple producers work. ProducerBarriers The Disruptor code has interfaces and helper classes for the Consumer s, but there's no interface for your producer, the thing that writes to the ring buffer.  That's because nothing else needs to access your producer, only you need to know about it.  However, like the consuming side, a ProducerBarrier is created by the ring buffer and your producer will use this to write to it. Writing to the ring buffer involves a two-phase commit.  First, your producer has to claim the next slot on the buffer.  Then, when the producer has finished writing to the slot, it will call commit on the ProducerBarrier . So let's look at the first bi
Read more

Dissecting the Disruptor: How do I read from the ring buffer?

Image
The next in the series of understanding the Disruptor pattern developed at LMAX . After the last post we all understand ring buffers and how awesome they are.  Unfortunately for you, I have not said anything about how to actually populate them or read from them when you're using the Disruptor. ConsumerBarriers and Consumers I'm going to approach this slightly backwards, because it's probably easier to understand in the long run.  Assuming that some magic has populated it: how do you read something from the ring buffer? (OK, I'm starting to regret using Paint/ Gimp .  Although it's an excellent excuse to purchase a graphics tablet if I do continue down this road.  Also UML gurus are probably cursing my name right now.) Your Consumer is the thread that wants to get something off the buffer.  It has access to a ConsumerBarrier , which is created by the RingBuffer and interacts with it on behalf of the Consumer .  While the ring buffer obviously needs a se
Read more