Write your Android apps the Python way
Android build times are slow
Build times for large (think multidex large) Android apps suck, it comes with the territory. Google are working hard to improve this fact, don’t misinterpret this as a complaint piece- it’s far from it, but the reality is that anyone adding a feature to a large Android application, better have amazing focus to stay in flow while the build processes are doing their build processing.
Advice for my 5 year old
I have been teaching my 5 year old that every difficult problem is actually just a number of smaller, easy to solve problems. Such is the same with software development.
As a good wee developer I’ve been dabbling outside the Android playground to keep up with how the rest of the development world has been getting on.
During my time with Android there has been a number of tools that have been released by the Google camp that end with the .py suffix. It’s encouraging as well to see that of the few lucky languages to be supported by Google app engine, Python counts itself one.
How the Python people do it
Many times over when working through Python exercises I have come across the good advice to get the 1st small part of your large problem working, then the next small part, check, then the next, check, and so on.
When you’re working with a single language for so long it’s easy to become distanced from this fact. You gain too much knowledge, and can write gigantic solutions without even so much as a command-tab to consult the great StackOverflow. You optimize prematurely and overly complicate solutions. You forget the fact that development is more like telling a story to another developer on how your feature works, than writing the most efficient, difficult thing to read out there.
Creating the feedback loop
I’ll share my ways of achieving this fast feedback loop whilst working with a large, unforgiving code base.
The first thing I do is create a ‘Lite’ version of the app in question. Reimplement cleanly just the basics. It’s time spent not implementing your feature, but you will get your time back in spades once you’re up and running. If nothing else I find it therapeutic to over simplify your legacy codebases in nice, new crisp code. Reimplementing something is also a great way of gaining understanding as to why the original developers did something in a certain way, as you’ll experience and solve the same problems they have discovered.
When a new feature comes along you first implement it in the ‘Lite’ version you’ve previously created, then port it back into the real deal. Any extra time spent on your port will be given back in the maintenance costs of refactoring or living with bad code.
The second way to create a fast feedback loop is via unit tests. TDD is a whole other blog post, but unit tests in Android are very, very fast as they are purely a Java affair (as long as you separate your concerns nicely and test only pure Java classes). You forget in Android land, but Java is a very fast language, it benefits from decades of work from brilliant minds all geared to make it they best language they can. Write as much of your feature in pure Java as possible without ‘imports com.android’ at the top of your files (I see you there TextUtils), and test your small easy to solve problems with unit tests and you’ll have that large problem solved in a jiffy.
The last paragraph
Don’t lose touch with the basics when deep diving into a language or platform. It’s so easy to get caught up in the interview question make everything super efficient world of development, and to lose sight of the fact that we’re not writing applications to tell a computer what to do. We’re writing them for our fellow adventuring developers, who for all we know may be murderous psychopaths who know where we live.