Quick Notes On Dockter’s 2015 BABBQ Talk on the Android Gradle Build System

Hans Dockter gave a talk about the Android Gradle build system at Big Android BBQ 2015(No bbq for me … saw it on youtube … woo hoo) 

Dockter addresses the issue of Android build performance in the last half of the talk. A few of my takeaways, for what they’re worth:

  • Android developers should try an upgrade to Gradle 2.8
  • Build times are slow mostly because of dexing and pre-dexing. There’s nothing Gradle can do to improve dexing time, per se.
  • Right now, a clean build deletes your pre-dexed libraries. So, they must be re pre-dexed each time. But, in the future, there will be an optimization where pre-dexed versions of libraries necessary to your project are cached resiliently. So, even if you clean your project, their dexed versions persist.
  • Future improvements in the Android toolchain or Gradle for Android will include incremental dexing and concurrent dexing.

Dockter also mentioned the possibility of caching pre-dexed libraries on a CI Server so they’d be available to all developers in the organization. (Or something like that.)

I wonder if teams that use a third party, CI server in the cloud will also be able to take advantage of this sort of optimization. 

Why I Try Not to Implement Parcelable

The short answer is: Parcelable implementations are overly complicated and brittle,  I’m bad at finding and fixing “Unmarshalling unknown type code” errors and I’m tired of being surprised by them.

There are hundreds of questions about Parcelable errors on StackOverflow. I’ve had my fill of trying to implement solutions (e.g. proguard configuration adjustments, read/write out of order, etc) and then hoping that the errors stop happening.

If my app runs in a single process and I want to pass some arbitrary custom object to an Activity or Fragment, I’ll create a singleton and store the object as a property on that singleton. Then my Activity or Fragment can get that custom object by calling a “get” method on the singleton. (Of course, it’s important to keep that singleton from holding on to excessive amounts of memory.)

Anyway, the official documentation apparently says we should avoid using Parcelable unless we have to pass an object instance to another process.

And, even in that case, there are questions about the performance gains attributed to Parcelable as compared to Serializable. 


Saving State in a Compound Control

If you’re writing an android compound control and you want to save state between config changes, you may want to tell the Android SDK to butt out.

That is, you may want your compound control to be fully in charge of saving and restoring the states of its internal views.

Why would you want to do that – why not just let the Android SDK save and restore those interior view states?

Because in order to correctly save the states of those interior views, the Android SDK needs each of them to have unique ids.

And when does that become problematic?

When a client of your compound control puts multiple instances of it into a single one of their layouts. In this case, the interior views will all get the same ids or no ids at all. (Unless you want to deal with a certain amount of awkwardness in code.)

So, if, for example, your compound control consists of a LinearLayout which wraps some other stock views, it can be desirable for your LinearLayout to tell Android to simply avoid saving the states of those interior views. You can do this by calling dispatchFreezeSelfOnly and dispatchThawSelfOnly.

A helpful example of this is Charles Harley’s Lock Combination Picker on GitHub.

A discussion about how BaseSavedState should be used to save the state of your compound view is found in this StackOverflow question.

Browzacado Is Dead

Sorry. The Google Play Store has informed me that my ad-free, free, non-profit avocado browser app for Android violated the terms and conditions of the store. They have suspended the app.

I meant neither to offend nor to exploit UC Riverside’s excellent avocado database. I only wanted to make it available in a more convenient format for mobile devices. I wish the fine team that created and maintains the UCR Avocado database all the best. I encourage anyone from that UCR team who is interested in having UCR take ownership of the app’s Android Studio project and source code to contact me to facilitate a transfer. Cheers.

Moving on …

CMS50FWLib Test App Privacy Policy

This privacy policy governs your use of the software application CMS50FWLib Test App (“Application”) for mobile devices that was created by Albert Braun. The Application is designed to test the CMS50FWLib open source library.

User Provided Information

The Application obtains the information you provide when you download and install the Application.

Automatically Collected Information

The Application collects certain information about the way you use the Application. But, it does not persist heart rate, oxygen level or other data generated by the CMS50FW pulse oximeter.

Does the Application collect precise real time location information of the device?

This Application does not collect precise information about the location of your mobile device.

Do third parties see and/or have access to information obtained by the Application?


What are my opt-out rights?

You can stop all collection of information by the Application easily by uninstalling the Application. You may use the standard uninstall processes as may be available as part of your mobile device or via the mobile application marketplace or network.

Data Retention Policy, Managing Your Information

The Application itself may retain User Provided data for as long as you use the Application and for a reasonable time thereafter. Please note that some or all of the User Provided Data may be required in order for the Application to function properly.


We do not use the Application to knowingly solicit data from or market to children under the age of 13 or anyone else.


We are concerned about safeguarding the confidentiality of your information. We provide physical, electronic, and procedural safeguards to protect information we process and maintain. For example, we limit access to this information to authorized employees and contractors who need to know that information in order to operate, develop or improve our Application. Please be aware that, although we endeavor to provide reasonable security for information we process and maintain, no security system can prevent all potential security breaches.


This Privacy Policy may be updated from time to time for any reason. We will notify you of any changes to our Privacy Policy by posting the new Privacy Policy at http://http://www.albertcbraun.com/cms50fwlib-test-app-privacy-policy/.

Your Consent

By using the Application, you are consenting to our processing of your information as set forth in this Privacy Policy now and as amended by us. “Processing” means using cookies on a computer/hand held device or using or touching information in any way, including, but not limited to, collecting, storing, deleting, using, combining and disclosing information, all of which activities will take place in the United States. If you reside outside the United States your information will be transferred, processed and stored there under United States privacy standards.

Contact us

If you have any questions regarding privacy while using the Application, or have questions about our practices, please contact us via email at me@albertcbraun.com


WifiDLite is my experimental, alpha-version, open-source Android library which tries to make it easier to do basic WiFi Direct tasks.

The idea is to encapsulate away some of the nuts and bolts of programming Wifi Direct on Android and offer a simpler API for Wifi Direct tasks.

For example, WifiDLite spares you the work of getting an instance of WifiP2pManager, initializing it to get a Channel object, and implementing a specialized BroadcastListener.

Instead you simply get and initialize the WifiDLite singleton in your app’s onCreate, and then dispose of it in onDestroy.

The most experimental part of the library is the worker thread which periodically “rediscovers” peers on the WiFi Direct network. The default interval (set in the DefaultConfiguration object) is 10 seconds. The idea is to discover repeatedly so that, as other Android devices become available to the WiFi P2P network, your client code becomes aware of them shortly afterwards.

Of course, in theory, this is totally unnecessary because the Android platform automatically updates the internal BroadcastReceiver implementation with a WIFI_P2P_PEERS_CHANGED_ACTION when these event occurs. But … I thought I’d try explicitly forcing discovery to see what happens. (This feature may be removed in the future.) Aside from this experimental background thread, everything, including the client programmer’s calls to WifiDLite methods, should happen on the UI thread.

The source is offered as an Android Studio project on GitHub, which includes both the WifiDLite library (aar) project, and source code for the demo app. The demo app is also available on Google Play.

The pre-built Android Archive (aar) file is now available on jCenter (thanks to Blundell), which makes it easy to use the library in Android Studio. For example, add this line to the dependencies block in your app’s build.gradle to download and include version 0.1.1 of the library in your Android Studio project:

compile(group: 'com.albertcbraun.wifidlite', name: 'wifidlite-lib', version: '0.1.1', ext: 'aar')

More code samples are found in the demo app and in the ReadMe on GitHub.


UPDATE: On 02/11/2015, Google removed this app from the Google Play Store.

If you’re interested in identifying different avocados or avocado trees, Browzacado is a free, ad-free android app I wrote to make it easy to display a list of avocado varieties by search criteria.  It’s basically a mobile friendly front-end to the excellent, public avocado web pages published at UC Riverside.

You can filter a listing of avocado varieties by any one of the following criteria:

  • Color When Ripe
  • Parentage
  • Flower Type
  • Shape
  • Skin Texture

The app downloads an appropriate and informative image when you click on an avocado variety in results listing.