

Pocket team's tips for aspiring Android developers: It’s not really terrifying. - stevestreza
http://getpocket.com/blog/2012/06/pockets-tips-for-aspiring-android-developers-its-not-really-terrifying-and-in-fact-quite-enjoyable/

======
rogerbinns
Something else for new Android developers is to realise that Android apps are
structured completely differently than iOS or desktop apps (if you follow best
practise).

Instead of a single main() entry point, consider your app to be a mashup of ui
(activities), data (content providers), processing (services), broadcast state
(receivers) etc. You can just as easily incorporate those components from
other apps as from your own. You don't have to do most things yourself - eg to
include Dropbox/Facebook/Twitter/Google or your own account system you can use
the AccountManager instead of building your own credentials user interface
(the sign of an iOS ported app).

If your app will be talking to a server, along the lines of providing a user
interface to view data and make changes, with the underlying data flowing over
REST or something similar then watch this talk which talks about best
practises. It is especially a good idea to remember that mobile platforms can
arbitrarily kill applications at any time for any reason, and the same can
happen to the network. Consequently you need to record what is going on in a
local database to be resilient. Talk is from Google I/O 2010 but applies
today: <http://www.youtube.com/watch?v=xHXn3Kg2IQE>

~~~
jsolson
So, I spent some time trying to implement the architecture proposed in that
talk. I kept finding myself adding just tons and tons of more or less
boilerplate code. This felt wrong to me. Surely there must have been a better
way.

Fortunately, Google released the source for the Google I/O app, built using
the same architecture. What did I discover? A giant pile of boilerplate code
to accomplish very little in terms of actual functionality. Moreover, this was
for an app which fit pretty well into the relational model (small objects with
few relations each).

It may be current best practice, but there has to be a better way.

~~~
rogerbinns
Unfortunately it is very easy to end up with boilerplate code when using Java.
It isn't a direct fault of the language but rather that Java developers hate
making decisions so you end up with endless layers of abstraction and
indirection. (Immortalized as FactoryFactoryFactory.)

You may find this list of libraries used in Android apps useful. There are
several that cover this architecture pattern if you want to use them (eg data
access, networking, format parsing):

<http://www.appbrain.com/stats/libraries/dev>

------
w1ntermute
Good to see someone (of relative authority) pushing back against the FUD
spread by iOS fanboys, such as the likes of Marco Arment & co. Android
development is not something to be afraid of, and thankfully a lot of
developers are finally coming to that realization, and it seems that with the
release of Android versions of previously iOS-only apps like Flipboard,
Instagram, and Instapaper, the final vestiges of differences between the two
markets have disappeared for users.

~~~
g0atbutt
I have to disagree. Marco recently laid out his (very rationale) reasons on
why it took so long for Instapaper to hit Android. I encourage you to give it
a read - <http://www.marco.org/2012/06/06/instapaper-for-android>.

Choice quote from the article: "Simply put, Instapaper needs to be on popular
reading devices. That category now includes at least three 7” Android tablets,
probably with more to come. I realized last winter that I needed to address
this demand, but I couldn’t do it myself. "

~~~
nl
A lot of people see that as the worst form of hypocrisy.

Marco writes articles post with a headline "Why I hate Android"[1]. Then when
it turns out that (despite his attitude) people are making money on Android he
decided to jump on board.

[1] <http://www.marco.org/2012/01/10/why-i-hate-android>

~~~
taligent
Well those people are simply naive.

Many developers have hated the platforms they have developed on but do so
because the platform allows them to make money.

It's worked this way since the beginning of industry i.e. decades.

~~~
fpgeek
> Many developers have hated the platforms they have developed on but do so
> because the platform allows them to make money.

The hate isn't the hypocrisy. Plenty of people, for example, hate Windows and
develop for it without being hypocrites.

The hypocrisy is extensively claiming that the platform in question _isn't_
profitable ("terrible development economics", "unlikely to recover those
costs" [referring to development costs"), etc.), playing up issues like
fragmentation and generally arguing in almost every way possible to other
developers that you shouldn't be on this platform... and then turning around
and jumping on board anyway.

In fact, given the timeframe Marco talked about (last winter), it is entirely
possible he was publicly arguing against Android development while Instapaper
for Android was being developed. I can understand why he'd do that from a
business perspective: Marco wouldn't want to tip off competitors to his change
in thinking (note that Readability launched on Android and ReadItLater had
gone radio-silent before relaunching as Pocket during the period in question),
but that doesn't make him less of a hypocrite.

------
baconner
Its nice to see an article that challenges the bizzare notion that you have to
have a gigantic stack of physical devices to develop a quality android app.
This very closely mirrors my experience developing for android except of
course for the wild success bit.

I started my first app the day I got my n1 and until this year when i added a
transformer prime to cover ics and tablets that's the only device I used save
the emulator. In that time I supported every device 2.1 - 4.x including
tablets with just the emulator. Fragmentation has just never caused much of a
problem for me.

My user base isn't huge (4000ish) so it could be that scaling up would bring
the fragmentation issues out of the woodwork. Nice to know that it doesn't at
least in this case.

------
JamesCRR
I'm the guy (from OpenSignalMaps) who found the 3997 Android devices, but I
also love developing for Android. I think 3997 devices is very cool and just a
tiny-tiny bit terrifying. So I love this post. Buying a low-end device is a
great policy policy for two reasons. 1.the market for low end android devices
is growing faster than for high-end devices. So if you want global traction
that's what you should target. 2. If your device works well in Cupcake at
320x240 it's probably going to be even better on ICS at 1280x720. My three
favourite devices for developing: HTC Hero (low-end although actually pretty
great), Nexus One (workhorse), Galaxy Nexus (system is surprisingly buggy, but
still super fast).

------
gcmartinelli
Not that I disagree with anything, but it is good to keep in mind that Pocket
is funded by Google Fund. edit: Google Ventures

~~~
OzzyB
Aha. I was wondering why they had such a Google-esque look and feel.

------
manmal
Of course they did not have any compatibility problems - the Pocket app is a
textbook example of an app, you could find something like this in demo
examples. Make no mistake, I love the design - it's perhaps the best design of
an Android app yet. BUT, you can't compare it to any game or video playback
app - it does not have to handle native libraries or fight with gazillion
different screen aspects. It might not even contain a single custom drawn view
(don't know about the "reader" view). Everything in Android is a fluid layout,
and if you only use these layout components, everything should be fine on most
devices. Pocket is even able to avoid very large images, which tend to crash
older devices if they exceed available native bitmap storage. So.. yes, most
apps won't need testing on ~4000 devices - if it runs on the emulator, it
should be fine (make sure to severely limit memory there).

But don't dare to leave the well-tread pathways, or get ready to buy 100 or
more devices (obviously that's an estimation :)).

~~~
2muchcoffeeman
There is at least one data point that supports manmal's argument:
[http://mikamobile.blogspot.com.au/2012/03/our-future-with-
an...](http://mikamobile.blogspot.com.au/2012/03/our-future-with-android.html)

Perhaps they are bad developers.

The guys with the 4000 Android devices explain what they are trying to do
here: [http://www.animoca.com/en/2012/05/the-varieties-of-
android-e...](http://www.animoca.com/en/2012/05/the-varieties-of-android-
experience/#more-3686)

Both of these are game developers. So I think that at the moment the type of
app you are developing may effect how easily it is to get good compatibility.
Also the type of markets you want to tap may matter.

~~~
manmal
Yep - the more specialized and low-level it gets, the more stuff will break on
devices you have not tested - that's what I mean.

UPDATE: Perhaps I should tell about my background here: I have been developing
Android apps since 1,5 years now, among them an app for my master thesis which
makes heavy use of OpenGL. One xample of what can break: If you load OpenGL
textures, you should choose a texture size of 2^n pixels - or at least I found
out when they did not show up in some of my test devices. Some newer devices
showed the non-2^n-px texture (500x500) without problems, but older did not
display anything. Now imagine you code a game or interactive info display - is
that the kind of issue you want to have? You won't run into this issue on iOS,
because there are only so many OpenGL drivers.

Apps like Pocket do not touch these issues, they don't do "hard" things.

------
saket123
Finally some great advise. I will like to add my experience to it. When I
first started developing on Android (around a year and half ago) I had just a
HTC Hero which my employer then (I was interning) bought on CL. I had to share
this phone with a fellow developer. Using just that one device we managed to
make an app which totally blew away its IOS counterpart . Then one of my
friends bought Motorola Atrix . This phone was first phone with such a high
resolution (~275 ppi) as far as I can remember with slightly different aspect
ratio. When I loaded my app on this phone everything worked perfectly. It was
a realization that Android provides so many tools and ways like 9 patch
images, different assets folder, layout mechanism which makes handling such
differences easy. All you need to do is to get out of single screen mentality
(or 2) and think more like a web developer developing for different browsers
and screens.

My experience so far has been (I have around 40 apps on Android Market) unless
OEMs do something stupid or have bugs and you are not handling some platform
bugs (these are rare but can get quite annoying) especially from 2.1 to 2.2
and 2.3 to 4.0, you should be fine.

In some instances I had to use jar-jar (<http://code.google.com/p/jarjar/>)
for common libraries like GSON (json parser) since some OEMS (I think it was
some phones from HTC) were modifying the implementations and it was resulting
in errors in my app.

Lets talk about look and feel. Android has a very vibrant open spurce
community. If you want to follow design guidelines
(<http://developer.android.com/design/index.html>) (you should, even though
you are not needed to) , just use open source libraries like action bar
sherlock , android theme generator and you can achieve 95% identical look and
feel between 2.3 and 4.0. You can always grab the holo theme assets from
Android 4.0 source (which is shipped with SDK) and create your own holo theme
(if you are using holo for Android 4.0).

Lastly, you can always use support library to get fragment functionality.
Fragments are most important defragmentation tool. Some other niceties like
Loader manager are also part of support package.

Enjoy developing on Android!

