5 ms·

Pocket team's tips for aspiring Android developers: It’s not really terrifying.

100 points by stevestreza 14y ago

saket123 14y ago
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/ 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 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!
w1ntermute 14y ago
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 14y ago
  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 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. "
  - abraham 14y ago
    The Nook and the Fire are "Android" devices not Android™ devices. While related and important they are not the Android ecosystem most people talk about.
    - adambyrtek 14y ago
      I would argue that this distinction is not that important from developers' point of view, as the same application can be made available on all "flavors" of Android.
      - abraham 14y ago
        It is important from a developers point of view because those devices don't get tested by Google for API/feature conformance and so potentially are more likely to have applications not run on them correctly.
gcmartinelli 14y ago
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 14y ago
  Aha. I was wondering why they had such a Google-esque look and feel.
rogerbinns 14y ago
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 http://www.youtube.com/watch?v=xHXn3Kg2IQE
- jsolson 14y ago
  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 14y ago
    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 http://www.appbrain.com/stats/libraries/dev
baconner 14y ago
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 14y ago
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).
manmal 14y ago
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 14y ago
  There is at least one data point that supports manmal's argument: http://mikamobile.blogspot.com.au/2012/03/our-future-with-android.html http://mikamobile.blogspot.com.au/2012/03/our-future-with-an... 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-experience/#more-3686 http://www.animoca.com/en/2012/05/the-varieties-of-android-e... 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 14y ago
    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.

100 points by stevestreza 14y ago

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/ 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 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!

w1ntermute 14y ago

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 14y ago
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 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. "
- abraham 14y ago
  The Nook and the Fire are "Android" devices not Android™ devices. While related and important they are not the Android ecosystem most people talk about.
  - adambyrtek 14y ago
    I would argue that this distinction is not that important from developers' point of view, as the same application can be made available on all "flavors" of Android.
    - abraham 14y ago
      It is important from a developers point of view because those devices don't get tested by Google for API/feature conformance and so potentially are more likely to have applications not run on them correctly.

gcmartinelli 14y ago

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 14y ago
Aha. I was wondering why they had such a Google-esque look and feel.

rogerbinns 14y ago

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 http://www.youtube.com/watch?v=xHXn3Kg2IQE

jsolson 14y ago
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 14y ago
  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 http://www.appbrain.com/stats/libraries/dev

baconner 14y ago

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

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

manmal 14y ago

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 14y ago
There is at least one data point that supports manmal's argument: http://mikamobile.blogspot.com.au/2012/03/our-future-with-android.html http://mikamobile.blogspot.com.au/2012/03/our-future-with-an... 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-experience/#more-3686 http://www.animoca.com/en/2012/05/the-varieties-of-android-e... 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 14y ago
  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.