Getting Started with Android Development | Hacker News Reader

Getting Started with Android Development

alexlod.com

99 pointsfalava26 comments

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.

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

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.

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

Only using 2.2 APIs at this stage would only hurt the development of your app. Targeting 4.1 and using the support package gives you full access to Fragments and Loaders while still supporting the older SDK versions.

And no one will be able to run it for 2 years.

Though looking at developer.android.com it does seem that it would be safe to target 2.3 as a minimum.

http://developer.android.com/about/dashboards/index.html

Unlike with iOS where it is easier for users to upgrade their OS if their phone supports it, Android version upgrades come most often when people upgrade their phone and that means at the end of a 2 year contract for most people.

Targeting the most recent Android version seems like a poor way to get people to use your app.

The Android Support Package enables you to back-port apps written for the latest API level and using a Fragment-based UI implementation all the way back to Android 1.6.

Note the: Targeting 4.1 and using the support package gives you full access to Fragments and Loaders while still supporting the older SDK versions.

Sure, if you target 4.1, you can't necessarily use every single new feature in Android on older devices. However, from a design/UI point of view, Android's backports of many new features (and projects like ActionBarSherlock) such as the action bar means you can design for 4.1 and have the code work with many previous versions.

I agree with the grandparent post: design for 4.1 and set 2.2 as a minimum. In cases where you want to use new APIs, you can use conditional classloading techniques.

Both you and the blog author are misunderstanding what targetting an API means. You can target 4.1 and still have your app run on 2.2 or lower. As others said, many of the new APIs have been backported to earlier versions. And targeting newer APIs have many additional benefits. As an Android Developer, you should always use the newest SDK and target the newest API. But still try to design for older versions.

Read: http://developer.android.com/guide/topics/manifest/uses-sdk-...

Yes, and please use/support the fantastic http://actionbarsherlock.com/

There's also the ViewPagerIndicator library.

Jake Wharton really has done the Android world a massive favour.

I'm just about to get started learning how to develop for Android and I thank you for posting this link. The article seems very helpful for beginners.

I think reading most guides on the developer.android.com website is the best way to start developing on Android. The SDK also includes sample codes that are worth looking at for good practices on various tasks.

I would have to agree with this.

Although I've been developing on android since the beta SDK in 2008..

Seconded and thirded. The linked article makes a few mistakes that would be avoided if the author paid some attention to the Android guide. Which is extremely common for third party tutorials. The Android guide is great and is often updated. There's ton great resources like videos and tutorials. It's by a huge margin the best place to learn android.

I would advise anyone beginning Android development to avoid third party tutorials as much as you can. Only use those if you cannot find a specific topic you need in the Android guide.

Duly noted. Thank you for the tips!

I'm also starting to learn Android. Being an Emacs user I tried android-mode, then Intellij IDEA and Eclipse. At the end I decided to settle on Intellij IDEA (Java is way more bearable with a good IDE.) Is there any drawback to not using the "official" google dev. environment (Eclipse+ADT)?

Emacs user here, Lisper, and Android developer.

Don't fight it: learn Eclipse+ADT and Java, and yeah Emacs M-. is F4 in Eclipse ;-)

Getting Eclipse going was the real "fight".

Using Emacs and the bare SDK tools works just fine for me, and is easy to do.

I've always used emacs and the SDK as well. It seems to work ok, though I've never been one for IDEs.

Eclipse felt too heavyweight on the netbook I use to code. (I still find it amusing that emacs is the light-weight solution).

I haven't built any complex Android apps so far but I've found IntelliJ's Android support to be very good. The only thing I've really missed so far is the visual layout tool in Eclipse but IntelliJ does give you realtime previews of your layout so it's not too hard doing things in XML.

Most Android devices are now on 2.3, not 2.2. And Eclipse is getting pretty aggravating lately.

Assuming [this](http://developer.android.com/about/dashboards/index.html) is your source, I'd note that it "is based on the number of Android devices that have accessed Google Play within a 14-day period".

I suspect that it's only loosely correlated to the number of devices in the wild running that version, but very tightly correlated to the users likely to download an app that you write.

Since the Play/Market app periodically checks the servers to look for any app updates it's fair to say that Google's numbers comprise just about all devices running Google Play which is probably 99% of devices. The only notable device without Play is the Kindle Fire which is running Gingerbread 2.3.4

Reply on news.ycombinator.com