Coming to Android development with a background as a web developer, I found the learning curve to be steeper than I’d expected. I didn’t start completely cold, as I had taken a brief look back when 2.2 was the newest set of APIs, but the combination of eclipse + XML scared me off that time. This time around, at least basic platform concepts such as Activities and Intents, the application lifecycle, and the standard file hierarchy weren’t totally new, but I hadn’t actually done anything beyond “Hello World”.
Project idea (non-Android tangent #1)
I’ve always found it helpful to have a project in mind when picking up a new toolset. This time around I got the idea of writing an N-back training program. The promise of N-back training protocols is more or less that they make you smarter. Figuring out how plausible that might be could quickly become its own PhD project, so after skimming the above FAQ and a few Wikipedia pages, I figured that the area was at least interesting enough to use for the purposes of learning to write an app.
As with every product idea I have ever imagined, there are already a number of N-back apps in the Play market. I identified the following non-existent combination of features to aim for:
- single N-back, which may be as effective as dual N-back, and is less of a PITA.
- ad-free. Ads can be quite distracting for this sort of task.
- an opinionated experience. The other apps tend to have a bunch of options which only make sense to someone already versed in the N-back concepts.
Some initial takeaways
- Obvious point number one: you write your apps in Java. The language mostly came back to me, after about 10 years off, but I don’t find myself any more fond of the verbosity or the minimal nature of the standard library. I know that other JVM-languages-on-Android efforts exist, but a quick survey suggested that none of them are being used widely, which scared me off.
- Getting layouts to work seems pretty fiddly compared to, say, building an HTML UI using Bootstrap, as does testing on various devices and form factors. The same could be said for web apps as well, but somehow the expectations for mobile apps feel different. For example, even if an Android app itself doesn’t need any particular artistry, a decent icon seems important. Also, with so many free apps, the bar to releasing a paid app feels pretty high.
- I didn’t initially have much luck finding open source Android apps that seemed worth investing the time to learn from. I did find a site listing open source Android apps, which I probably have not spent enough time combing through – when I gave it a look I was focusing on puzzle-type games since that seemed closest to my app idea. It has since come to my attention that at least one app I regularly use is open source, and I’ve been looking into submitting some tweaks to it.
Metalearning (non-Android tangent #2)
I happened to pick up Tim Ferriss’ Four Hour Chef early on in my Android learning process, and was intrigued by the book’s first section, which is on metalearning. Despite working in a profession that demands constant learning, reading about Tim’s learning practices made me realize that I’ve never stopped to examine, much less optimize, my own learning process in any detail.
Surprise surprise, I can see that I have room for improvement. Enthusiastically diving into topics is easy for me, but focusing my attention on the right aspect of a subject at any given time is often a challenge. This project was no exception; if anything, the breadth and complexity of the Android ecosystem encourages wheel spinning. Some questions I found myself getting stuck on:
- Which IDE to use? Eclipse is the default, but it has issues. Some people use other Java IDEs, and some barbarians use text editors.
- Which version(s) of the Android SDK to focus on? If more than one, how much effort to spend on the various APIs & their conventions?
- What display densities and screen formats to think about? Most devices in the wild are phones, but there’s huge variety in phone displays. Tablets are becoming more popular, of course.
- These things are changing pretty steadily. Are there authoritative sources for figuring out what the current wisdom is?
- What do the Play Store pages for successful apps look like?
So, did Tim’s learning tactics from FHC offer anything to help with these sorts of problems and questions? For some, yes. Example: Tim is a huge proponent of the 80/20 rule. Most of the above questions can be helpfully addressed by asking “what’s the essential 20% of this to start with?”. I’m a huge fan of YAGNI when coding, so this isn’t a big stretch; it’s mostly a matter of remembering to apply the principle in different domains.
I can see how Tim’s techniques would be helpful for natural language study, one of his main hobbies. Unfortunately, I didn’t find enough correspondences to learning a development ecosystem. For example, Tim’s strategy of reducing a subject down to key patterns would be great if I could identify those patterns, but in the Android context that task feels synonymous with “learn the Android platform”.
Another tactic from FHC that did prove helpful was “begin with the end in mind”. While it can be educational to fire up the IDE and noodle around, I found it motivating to spend some time on the Play store looking at successful projects, then sketching out how my project might appear. As with so many of these sorts of tips and tricks, it sounds obvious, but being reminded of the right obvious thing at the right time remains valuable.
20% answers to the above questions
- IDE-wise, I went with Eclipse as it is the most commonly used, and thus hopefully best supported. Thank god yet again for stack overflow, because its answers to my searches for eclipse [obscure error] have been real sanity preservers.
- As for the API, the 2.x & 4.x branches look to be the only ones worth considering. The obvious options today seem to be 1) 2.x only 2) 4.x only 3) both. While most devices are currently running 2.x, that will obviously change, so option #3 seems pretty reasonable, if you aren’t doing anything fancy. I’d guess that apps that want to really take advantage of new 4.x stuff must have hard decisions re: investment in backwards compatability.
- Screen sizes and densities, much like the API question, become clearer when you look at the data on what people are using. I got my hands on a Nexus 7 during this process, which helped motivate me to support the tablet form factor.
- The official Android docs are OK. They made more sense as I spent more time with the platform, so it’s a little hard to judge. Later on in the learning process, I picked up a copy of O’Reilly’s Programming Android, which has been so-so.
Project icon (semi-Android tangent)
The Android design guidelines have some strong opinions about what your app’s launcher icon should look like. Apparently, many developers have been successful using Inkscape to come up with decent vector icons, which can then be exported to the various required formats. Not having used Inkscape before, I invested enough time following tutorials to determine that I would probably be better served paying someone else to do this for me.
So, where’s the app?
Sitting in my copy of Eclipse. I’ve demoed the current prototype to a few people and watched them give it a try, and I do still think there’s potential. Another week or two of effort might get it polished enough to be worth putting in the store.