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
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
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.
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
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
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 &
- 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
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
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
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.