Building quality software for Android - A post-mortem for Tweagle • Hacker News Board

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

#11

Post by loeschg » Tue, Jun 05, 2012, 4:55 PM UTC

buerkle wrote: post #10

loeschg wrote: post #2

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? JSONSm…

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

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

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

#12

Post by triathlete » Tue, Jun 05, 2012, 5:10 PM UTC

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.

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

#13

Post by king_jester » Tue, Jun 05, 2012, 5:10 PM UTC

Dove wrote: post #9

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 i…

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.

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

#14

Post by triathlete » Tue, Jun 05, 2012, 5:12 PM UTC

loeschg wrote: post #11

buerkle wrote: post #10

Earlier quoted context omitted.

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

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

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.

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

#15

Post by huggyface » Tue, Jun 05, 2012, 5:18 PM UTC

Dove wrote: post #9

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 i…

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.

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

#16

Post by njern » Tue, Jun 05, 2012, 5:33 PM UTC

Dove wrote: post #9

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 i…

Did you ever try to give a button one or two rounded corners (not the whole object, just some of the corners)?

Turns out that for pre-3.1 it will round the wrong corners (http://code.google.com/p/android/issues/detail?id=9161), meaning you need "corrected" drawables for API level 12+

That's one example of things that definitely made the whole XML experience a little trippy for us.

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

#17

Post by Bjalle » Tue, Jun 05, 2012, 5:34 PM UTC

huggyface wrote: post #15

Dove wrote: post #9

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 i…

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…

Android shapes are great for getting basic shapes done and is a good alternative for 9-patch images. I also like the xml layout files and it's quite easy to understand. But if you are making a more complex design you will need to get those .9.png files involved.

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

#18

Post by njern » Tue, Jun 05, 2012, 5:38 PM UTC

huggyface wrote: post #4

"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,…

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

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

#19

Post by Dove » Tue, Jun 05, 2012, 5:40 PM UTC

huggyface wrote: post #15

Dove wrote: post #9

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 i…

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…

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... 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!)?

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

#20

Post by njern » Tue, Jun 05, 2012, 5:41 PM UTC

triathlete wrote: post #14

loeschg wrote: post #11

Earlier quoted context omitted.

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

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.

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.