This is the first part of an ongoing series about my adventures in building my first (non-trivial) Android application. For more information about the application, you should peruse my series introduction.

I still don't plan to show any code yet, so I guess you can still consider this an introduction to the application. I feel it's important to talk about the tools and frameworks I'm using, and then talk about how I'm structuring my application.

First, the tools and libraries I'm using:

• Eclipse and the Android SDK: Just about every tutorial lists Eclipse as the editor, and for good reason. There's some nice features there, including a lot of nice refactorings. It's not quite as good as Resharper and Visual Studio, and I still fumble my way around a bit, but it gets the job done.
• Instinct: This is a BDD framework based on jMock that John Sonmez showed me. It doesn't use the AAA syntax that I'm used to, but it works and allows me to test code in roughly the same way that I'm used to. This uses jUnit to run the tests, which works well, since Eclipse has nice integration to run jUnit tests directly in the UI.
• Roboguice: Back when I spent more time in IRC, I remember Nate Kohari talking about how he based Ninject on Guice, a IoC container in the Java world. Well, Roboguice is essentially Guice, but with a few additions that make it easier to work with Android-specific objects. Since I work with Ninject on a daily basis, going with this just made sense.
• kSoap2: I'm communicating with existing SOAP web services from the Pay It Square site, so I'm using a fork of kSoap2 specifically compiled for Android.

We're considering moving to a more REST-based interface for our web services, and if that happens, we'll swap out kSoap2 for something else. I've also thought about moving to using json for data transportation instead of XML, but that's down the road as well. V1 is top priority right now, and XML and SOAP work fine for now, as long as I properly insulate their usage.

I've been asked if I'm going to be using MonoDroid to build this application. The short answer is no. The slightly longer answer is that when I started building the application, I wasn't yet in the MonoDroid beta program (I am now), and I wanted to get a feel for what it's like to build for the Android platform using the toolset Google recommends. It's the same reason I would probably go with Objective C if/when we build an app for iPhone. I will definitely be exercising MonoDroid, but not for this, at least not right now.

On to project structure. Right now, I have three projects. First, I have my UI project, which contains all of my Activities, layout files, resources, and my application manifest. It's the only project that actually has a reference to the Android library.

Next, I have my core library. I'm using the MVP pattern, and this project contains all of my presenters. It contains any of my services, repositories and domain objects as well. It also has a series of interfaces I've created that wrap functionality in the Android libraries. I've done the work to create interfaces for all of the Android-specific functionality so that I can easily test the core library with my third project - my tests. Wrapping the interfaces gives me two things: 1.) It's testable, because I can't run Instinct's tests against any Android objects, and 2.) More importantly, it allows me define how my presenters will interact with the Android OS, rather than the other way around. That's not entirely true, but it sounds good, right?

Now that we've laid out the tools I'm using and the structure of my project, it's finally time to get into some code. In part 2, I'll get into the details of how I'm actually wiring up my presenters and activities.