Hacker News Reader

Comment by Zigurd | Hacker News Reader

What I would add to this is:

Understand component lifecycle. Understand it well enough to know you have to design your app around it, because you can't subvert it. Do this first. Do not write code before you understand this. A good way of understanding this is to override all the lifecycle methods in Activity and log them, then watch what happens. Understand that Android can "destroy" both individual component instances and whole processes. Understand that you can't thwart "destroy" by holding a reference.

Understand Android's support for a data model in a sql database, abstracted by ContentProvider, and how to build an observer pattern around this.

Understand Android's support for concurrency, enough that you know the limitations.

View on HN

When you say "data model" are you talking about object persistence? I was under the impression android didn't provide built in object persistent.

That's a great question. If you look at the set of classes that enable you to build an observer pattern on top of databases in Android - Cursor, Adapter, and View, you see that you can skip the ORM and POJOS in most cases where you are simply displaying data, with some minor processing that can happen in the Adapter.

This works well in Android where each process's maximum heap is something between 16 and 48MB, and keeping your data model in a database is a way of continuously persisting it.

There are exceptions. You probably would not want to build a CAD program this way. Instead you would take the performance hit to rebuild your POJOs after the component they are contained in gets reaped.

It occurs to me I answered your question only obliquely: Android doesn't have ORM. It does have a database stack that makes ORM unnecessary in most cases.

Your profile link to the Android book indicates that you know what you're talking about.

As someone who has a decent grasp on the lifecycle part, could you sprinkle the other two points with a link or two? Or .. a general direction? "Enough to know the limitations" for example is .. hard to follow-up on.

The limitations of AsyncTask are hard to put in two sentences. It starts with AsyncTask referring to an Activity. Now let's say you create a configuration change by rotating your device, and the Activity you had is destroyed. There begins the tale of woe. Here is a good writeup: http://andreas-kluck.blogspot.com/2012/02/asynctask-and-asyn...

thanks! i'm starting to venture into android development now and getting some quick terse advice from an expert is helpful

Reply on news.ycombinator.com