Android Rapid Prototyping

For me, the key to developing great software is the ability to quickly iterate.  There are two competing forces here, discipline and time.  You must be disciplined enough keep iterating until the software is 100% right (and not "good enough" or 90%).  Then their is time, which is telling you that 90% IS good enough since you've got a laundry list of other (and potentially more interesting) problems to solve.

One of the first things I identified while using android was "speed".  At first I thought, "Wow, I can get an application up and running on Android quickly"... but then after iterating and making simple (minor) changes to text, variables and parameters (and having to redeploy every time) I was reminded of  the old EJB days, where you'd make a change (to an EJB or deployment descriptor) then cross your fingers and hope it'd deploy.

For example, I find myself "adjusting" some algorithms for the sensitivity of the accelerometer (i.e. where is the dead zone, what are would I consider the maximum tilt which allows the player to view the screen) through trial and error... and for each minor adjustment it requires a recompilation (fast) and a deployment to the phone (slow) so I might make a minor adjustment to a single number and it takes about 1 minute to get that change up and running... that's not very efficient.


I realized, for me to be more efficient,  I've got to be able to iterate more quickly... So my first attempt to develop a way of rapid prototyping for Android was to avoid deploying to Android entirely. To do this I wrote an abstraction layer around Android's API specifics (mostly handling of Graphics/Bitmaps) so I could deploy my code on my desktop to a JFrame (which is instantaneous). When I got everything working and running 100% on my desktop, I "ported" the code over to Android (I fleshed out the Android abstractions).  This worked, but there some problems with this approach:
1) The amount of code in the middleware became kinda a mess, (even though it was limited to simple operations)
2) Using interfaces slows things down when on Android (and speed is key)
3) I developed a sub-optimal "more generic port" solution to work on both platforms (Java Desktop, Android) rather than an optimal solution (based on the speed and efficiencies provided by Dalvik)
4) Really this approach wont work for something like the camera or accelerometer, so it's fine for the more "plain vanilla" applications, but not an approach for Android
5) I had to write of ugly "factory" code and other boilerplate to allow me to swap in/ out the implementations (I could have avoided this by using Dependency Injection... more on that later)

Segue:
If someone asks me "whats the difference between a 'developer' and an 'architect'?" My answer is "The differentiating factor between an architect and a developer is that an architect can improve efficiencies in the development process, (strategic) while developers focus on the tactical aspects of coding. 

Even though I was successful in creating the contour generator, the whole process wasn't ideal and I need a new way to approach the (rapid prototyping on Android) problem.  Ideally I would be able to update simple things (like text, variables, settings) in real-time without having to rebuild and repackage and redeploy the app every time.

My next approach is using a real-time client-server approach (in development) where the android application/device is a client and it gets all of it's settings/assets from a Server, and the server can be updated real-time and the Android/Application will poll the server for changes which can take effect immediately) At first I want to provide simple property settings (i.e. general assets like strings, etc.) but in the future maybe the entire wiring of the application could be provided remotely... (We'll see how far down the rabbit-hole I get)