

Building quality software for Android - A post-mortem for Tweagle - njern
http://walkbase.com/798

======
Dove
_One of our two full-time developers on the project spent most of his time
fighting a never-ending war against our XML views to make the app look just as
good on a ZTE Blade as it does on a brand new Galaxy Nexus._

I'm definitely feeling that way these days.

When I first started learning Android, I was very excited about the resource
system. _The ecosystem is highly fragmented, but they give you the tools to
deal with it!_ , I thought. _How cool, I want to learn from their wisdom!_

Six months later, I'm actively shopping for a _different_ UI framework. This
one makes easy things hard and hard things impossible. I was recently trying
to make a button 40% of the screen width and aligned kinda leftish and kept
from getting too big on wide screens. In CSS, that's couple lines, maybe
thirty seconds. But in Android . . . well, I spent six hours thrashing through
documentation and recommendations and opinions on StackOverflow before I gave
up and _wrote my own Button class._

It's really that bad.

Ever try to change the color of a button on Android? It requires something
like fifteen 9-patch PNGs, two or three arcane XML files, and navigating a
style hierarchy for your activities. No siree, no .myButton { border: 3 px
solid #C88; } here.

Ever try to wrap text on a canvas? Or scale a font based on the display size?
Or add an element to a view when a screen is a little bit larger? The hoops
you have to jump through are simply amazing.

I'm convinced it's not fragmentation, per se, that's the problem. The web has
even more fragmentation, and it handles it well enough. No, it's that the
tools you're given for _dealing_ with the fragmentation are so very poor.

~~~
huggyface
Not really looking forward to apologizing for the weak graphical tools,
however-

"Ever try to change the color of a button on Android?"

android:background="#ffee11" on the button?

Or use something like CSS variables (you know -- where CSS _wants_ to go) and
pull from a resource. Are you talking about something much more complex?

You can define a shape resource and then reference that in your button. Your
button can be almost any shape and look you desire, via a shared resource file
so it's easy to replicate elsewhere in your app. Making a shape occupy
n-percent of the screen, or having padding left, right, above, below is
_trivial_ , and I'm predominately an NDK developer and don't even deal with
this normally (but just quickly validated it. Rounded corner buttons with
gradient backgrounds and specific padding occupying n-percentage of the
screen).

I am left completely baffled by your complaints. There is nothing arcane about
a shape XML file (it is profoundly clear, and is obviously intended to be
reused so you aren't scattering disparate presentation code -- such as a
button style -- throughout your code), and if you don't like that you can
declare the color directly. Of course that is only one of your complaints, but
if you don't understand something so elegant and trivial, I have to question
the rest of your concerns.

~~~
Dove
_android:background="#ffee11" on the button?_

That . . . actually works! Well, now I'm embarrassed. I had previously had to
go this route [http://www.androidworks.com/changing-the-android-edittext-
ui...](http://www.androidworks.com/changing-the-android-edittext-ui-widget)
with text fields, and assumed it was the only way.

How do you get buttons to occupy a percentage of the screen (I hesitate to
ask, as it's probably something similarly trivial . . . but it's been such a
painful subject for me that I really want to know!)?

~~~
huggyface
_How do you get buttons to occupy a percentage of the screen_

In a LinearLayout take a look at layout_weight -- it is the key (or rather,
one of the keys) to goodness. It really is an onion, and if you can get
through the crying the flexibility comes in the layers.

~~~
Dove
Oh dear! That's really not the answer I was hoping for. That's about where I
gave up last time -- somewhere around a dozen nested vertical and horizontal
linear layouts with various weights, gravities and alignments that _still_
wasn't giving me quite what I wanted.

Still, for correcting me on the button background thing alone, I suspect
you've added years to my life. Dunno what the online equivalent of buying you
a drink is, but . . . thank you.

------
ajross
Where's the actual post mortem analysis? I wanted to see a discussion about
actual problems encountered developing Tweagle specifically. Instead, this is
just another exposition of the generic flames we've all seen done to death.
Android apps have lots of screen resolutions (so what did you have to do to
manage that?). "Some devices lack WiFi, A-GPS or both." (what is your fallback
if the user doesn't have local internet or location services?).

I especially like this one: "Some people “hack” their Google Play app to be
able to download incompatible apps and then write 1-star reviews when the app
doesn’t work" ... with no discussion about why their app was marked
incompatible in the first place.

~~~
njern
You have a valid argument. My only excuse is that this is the first (publicly
available) post-mortem I've written.

The answers to the questions you bring up have enough material for a blog post
of their own, so I'll most likely end up doing a follow-up to this blog post
where I address them.

Thanks for the feedback!

------
adambyrtek
I was surprised by the word "post-mortem" in the title. Looks like the project
is alive and well.

------
tzetter
From Wikipedia: "A project post-mortem is a process, usually performed at the
conclusion of a project, to determine and analyze elements of the project that
were successful or unsuccessful. Project post-mortems are intended to inform
process improvements which mitigate future risks and to promote iterative best
practices."

------
triathlete
I was trying to learn android recently and had to take a break due to
increasing headaches. Theres so many issues. Some of which they mentioned in
this article. One of which is that supposedly alot or some of the performance
issues are fixed in 4.0. Of of curse nobody uses 4.0. So you have to just
pretend those fixes dont exist.

And the xml views are a nightmare. I actually decided to learn ios instead
maybe sometime next year.

------
loeschg
An application I'm currently building (shameless plug - www.quaffic.com) will
definitely benefit from this post. If nothing else, I feel affirmed that we're
on the right track. From what you're saying, the value of ACRA is huge. That's
my big takeaway at this point. I wondered what the normal process was for
getting crash reports from users.

Also, what did you end up doing to alleviate your JSONObject problem?
JSONSmart?

~~~
buerkle
The article said they use Jackson for parsing json. A great library by the
way.

~~~
loeschg
Missed that. Thanks. I'll tuck that little tidbit away for later use.

~~~
triathlete
Parsing json is a pain in android. You have to do so may things to do what
should be a simple straightforward thing. One article mentioned that library
but i never looked at it.

~~~
njern
I can definitely recommend Jackson. Performance is stellar and it's easy to
use.

It does make your APK a bit bigger (in our case, about 20% of the APK size
comes from Jackson) so if you're only going to be parsing very little JSON,
you can still make do with JSONObject.

------
baconner
"..we’re using MS Paint while we would like to use Photoshop."

Ok i feel some of the authors pain on getting complex layouts right, managing
lots of different density image resources, etc. But what in android dictates
what graphic editing software you have to use? I'm happily using Photoshop for
my resources.

~~~
njern
What I meant was that the current system feels like Paint while I would like
something with the power of Photoshop.

Sorry for the confusion, English isn't my native language :)

~~~
baconner
Ha! I don't think its your English that failed, its mine...

Now that I agree with. The ui tools are not first class though they're
improving slowly. There's a ton of power in there but one hits a lot of
speedbumps on the way to building good layouts that work on many devices.

------
mtgx
Post-mortem? I don't get it.

------
huggyface
"I’m a firm believer that premature optimization is the root of all evil."

Gah. Premature optimization is not a willful blindness to all matters
performance related. It is a _perversion of computer science_ that it keeps
being twisted to such grossly different meanings that Knuth's original
statement.

Don't celebrate and herald your invalid philosophical righteousness with the
Knuth quote (as we've seen over, and over, and over, and over again here on
HN. Yes, we all know the quote, and yes it _always_ appears when someone
discovers how crap their implementation is). You failed and wasted your time
because you didn't consider performance a basic tenet of development,
especially on limited mobile devices.

~~~
njern
Don't take me wrong, I'm not a proponent of being "dumb" with performance
either. However, I'm perfectly okay with using the standard libraries like
JSONObject & AsyncTask until they prove to be too slow.

Thanks to a decent architecture the usage of JSONObject was confined to just a
few methods that had to be refactored. There were a few more AsyncTasks we had
to switch out, but in the end the refactoring took about two days which I
would find to be perfectly acceptable "losses" compared to researching the
performance of every single class before using it.

I definitely see where you're coming from though and I'll be sure to not throw
that quote around without a better explanation in the future (at least on HN).

