Developing for Android V: The Rules: Language and Libraries

The 5th in the series from Google/Android developers - Developing for Android V: The Rules: Language and Libraries.  This covers some core Java language and libraries.

tl;dr : This article I think starts to really dive into where traditional Java methodologies fails when running on Android, and you need to look at what is provided for you by the framework to achieve the same task while minimizing performance impacts.

• Use Android-Appropriate Data structures - for smaller collections, use android (ArrayMap/SparseArray) which avoids autoboxing
• Use Parcels not Java Serialization - Also talks about Persistable Bundles
• Use JSON/XML for web services, use SQLite or SharePreferences to store the data
• Avoid JNI - but if you don't here are some tips
• Favor Primative Types.

I really don't have much to add to what they go over in this article, but I think Engineers with a Java background could gain quite a bit of information just from this one post that will probably help them in the future. It discusses Bundles, SharedPreferences, SQLite, PersistableBundle, JNI, and several collection classes on Android which should be used if possible. ArrayMap, SimpleArrayMap, SparseArray, SparseBooleanArray, SparseIntArray, SparseLongArray, and LongSparseArray.

What did I learn from this post? Probably to spend a bit more time when using collections, and see if I can find an Android specific one that suites the use case better.

Developing for Android, IV: The Rules: Networking

Google developers are at it again with part 4 in their who knows how many part series with Developing for Android, IV: The Rules: Networking

tl;dr: One of the largest consumers of battery is network / data transmission.

• Be stingy when and how often you get your data. 
• Use tools like GCM, JobScheduler/GCM Network Manager. 
• Don't ever poll. 
• Don't sync everything.
• Don't assume the network is up
• Use exponential backoff when requests fail
• Develop for the low end network - slow / packetloss. 2G networks
• Create mobile specific APIs which return the data that the user needs. 

Expanding on these bullet points, I think one which is overlooked the most, and probably requires the most work, is having mobile specific APIs. It may be fine for your website to make 5 different requests to look up data to render on a page, but if you have a native app, tailor the API to a single call, and only return the data that is needed by the client. I don't know how many times I have seen APIs where I have to request a second API to get some little bit of data that could have been included in the first, but I have to download a 80KB json file, and parse it just to get the single field. The other recommendations are fine, and can usually be handled by the mobile engineer. Getting the resources to customize / write new APIs for mobile can be a much larger challenge. Expend your engery on it, it will make your life much easier down the line, and make your users much happier. 

Post I/O : Developing for Android I

The first 'real' post in the series entitled : Developing for Android, I: Understanding the Mobile Context lays out some important considerations for mobile.

I highly recommend that any mobile developer; seasoned as they may, take some time to digest this article. It is pretty high level, but gives a pretty good overview of why you should be aware of the mobile context.  It really outlines how mobile computing is different than desktop or server computing..

tl;dr : Mobile devices have servere limitations different from desktop / server compute. Not taking into consideration Memory, CPU, GPU, Low End Devices, Frame Rates, GC, UI Thread, Storage, Network can cause not only poor app performance, but also cause poor device performance.

First Post - Post Google I/O 2015

Just wanted to introduce myself, and why I am starting this blog.. I have been an Android developer since Android 1.0 released.. Stood first in line at my local T-Mobile store so I could buy the G1 when it released. I have co-founded a couple of successful startups, and done some work for a device manufactuer on AOSP. But the reason I started this was to try and keep track of Android Tools / Tips / Tricks that I find useful. I see so many I have a hard time keeping up, and hopefully this will help out.

I just got back from Google I/O 2015, and while I enjoyed myself, I felt a bit left out from all the technical sessions due to the size limitations, so I have been trying to collect some of the information and stash it away here with some commentary. 

Google and their engineers and Developer Relations have decided to make 100 posts (post I/O) around Android Development: I will share each one, and try to tl;dr each and try to mark each one in importance.

Introduction : tl;dr :  This series of articles could be called "Android Programming for Java Developers,” or “Mobile Development for Server and Desktop Developers” because it is meant to point out practices that are necessary for writing good Android apps ... In particular, developers used to writing Java code for non-mobile environments will need to learn new patterns of development."