5 ms·

Building quality software for Android - A post-mortem for Tweagle

32 points by njern 14y ago

loeschg 14y ago
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 14y ago
  The article said they use Jackson for parsing json. A great library by the way.
  - loeschg 14y ago
    Missed that. Thanks. I'll tuck that little tidbit away for later use.
    - triathlete 14y ago
      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 14y ago
        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.
      - maatanin 14y ago
        Another neat library is JSON Simple if you looked for SAX style json parsing. http://code.google.com/p/json-simple/ http://code.google.com/p/json-simple/
  - biafra 14y ago
    I use Google GSON on Android. Also a great library for serializing and deserializing JSON. I did not yet try the streaming api.
adambyrtek 14y ago
I was surprised by the word "post-mortem" in the title. Looks like the project is alive and well.
huggyface 14y ago
"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 14y ago
  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).
mtgx 14y ago
Post-mortem? I don't get it.
tzetter 14y ago
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."
- deleted 14y ago
  [deleted]
ajross 14y ago
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 14y ago
  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!
Dove 14y ago
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.
- king_jester 14y ago
  I think your post highlights one of the problems with the Android framework when it comes to UI: it's difficult to know what the right approach is for a particular task, esp. when thinking about many OS versions and device types. There are simple solutions to the problems you mention, but it is very difficult to know they even exist without several hours of research and trial and error. For framework environments like Android this slows app development and leads to apps that don't behave well. The tools and docs available right now need to be better if Android wants to be the dominate mobile platform for devs.
  - Dove 14y ago
    Yes, it's learning *nix all over again. There is an easy way to do things, which you cannot on any account find, until you complain and look like an idiot when someone tells you how to do it in twenty-eight characters. I'm moving to the "It's not me, it's you" phase of the relationship faster this time, though.
triathlete 14y ago
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.
baconner 14y ago
"..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 14y ago
  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 14y ago
    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.
ibisum 14y ago
My solution: MOAI. http://getmoai.com/ http://getmoai.com/ + moaigui: https://github.com/derickd/moaigui https://github.com/derickd/moaigui Perfectly readable layout management: https://github.com/derickd/moaigui/blob/master/resources/layouts/variouslayout.lua https://github.com/derickd/moaigui/blob/master/resources/lay... .. and delivers the same results on iOS and Android, from the same codebase. Its not 'polished' yet, however. But it is an interesting approach to the entire Android/SDK/iOS kerfluffle: roll yer own and stick a VM in it.

32 points by njern 14y ago

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 14y ago
The article said they use Jackson for parsing json. A great library by the way.
- loeschg 14y ago
  Missed that. Thanks. I'll tuck that little tidbit away for later use.
  - triathlete 14y ago
    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 14y ago
      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.
    - maatanin 14y ago
      Another neat library is JSON Simple if you looked for SAX style json parsing. http://code.google.com/p/json-simple/ http://code.google.com/p/json-simple/
- biafra 14y ago
  I use Google GSON on Android. Also a great library for serializing and deserializing JSON. I did not yet try the streaming api.

adambyrtek 14y ago

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

huggyface 14y ago

"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 14y ago
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).

mtgx 14y ago

Post-mortem? I don't get it.

tzetter 14y ago

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

deleted 14y ago
[deleted]

ajross 14y ago

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 14y ago
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!

Dove 14y ago

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.

king_jester 14y ago
I think your post highlights one of the problems with the Android framework when it comes to UI: it's difficult to know what the right approach is for a particular task, esp. when thinking about many OS versions and device types. There are simple solutions to the problems you mention, but it is very difficult to know they even exist without several hours of research and trial and error. For framework environments like Android this slows app development and leads to apps that don't behave well. The tools and docs available right now need to be better if Android wants to be the dominate mobile platform for devs.
- Dove 14y ago
  Yes, it's learning *nix all over again. There is an easy way to do things, which you cannot on any account find, until you complain and look like an idiot when someone tells you how to do it in twenty-eight characters. I'm moving to the "It's not me, it's you" phase of the relationship faster this time, though.

triathlete 14y ago

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.

baconner 14y ago

"..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 14y ago
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 14y ago
  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.

ibisum 14y ago

My solution: MOAI. http://getmoai.com/ http://getmoai.com/ + moaigui: https://github.com/derickd/moaigui https://github.com/derickd/moaigui Perfectly readable layout management: https://github.com/derickd/moaigui/blob/master/resources/layouts/variouslayout.lua https://github.com/derickd/moaigui/blob/master/resources/lay... .. and delivers the same results on iOS and Android, from the same codebase. Its not 'polished' yet, however. But it is an interesting approach to the entire Android/SDK/iOS kerfluffle: roll yer own and stick a VM in it.