Cyril Mottier

“It’s the little details that are vital. Little things make big things happen.” – John Wooden

API 16 (Jelly Bean) Review

Yesterday afternoon I tweeted about the differences in the Jelly Bean release (API 16). Some of you replied to my tweet and asked me to write about these changes. Here is a brief review of the API differences of API 16. Obviously, I won’t talk from a user point of view but rather from a developer point of view by giving you my feelings about these API changes.

API 16 is clearly a minor update. If you look attentively to the API diff documentation, you will notice there has been just a few packages, classes and methods added. However, being a minor update doesn’t mean it is useless. Indeed, what I particularly appreciate about this release is it makes the API more consistent and clearer. Google obviously spent some time making the API more logical and hence easier to understand and use. The list below gives you a set of changes that brings uniformity and clearness to the framework.

  • From non-final to final: Prior API 16, View Property such as ALPHA, or ROTATION_X were not final. This was obviously a huge mistake because these properties was not intended to be modified (see my Google+ post). When I noticed it, I warned some of the framework engineers and I’m glad to see they fixed it even if it may break some applications.

  • Methods renaming: In order to always have consistency between getters and setters, some methods have been renamed. For instance, setAlpha(int) on ImageView is now setImageAlpha(int).

  • Added getter and setter: Prior API 16, it was sometimes impossible to do things in Java while it was completely possible from XML. For example, the size of a scrollbar wasn’t modifiable from Java but it was from XML. Some getters/setters have also been added to ensure all View attributes have a setter and its getter counterpart. In general, you can now set and get all attributes from a widget (ie object that extends View)

  • Deprecation of some classes: There has been a lot of criticism on the fact Renderscript rendering pipeline is now deprecated. I actually think Google made a mistake not informing developers that the graphic part of Renderscript was experimental at the first release. However, some widgets such as the Gallery are now deprecated and I think that’s a really good point. I really believe advanced widgets like the Gallery are not supposed to exist in the framework. For my point of view, a framework is not supposed to provide everything a developer need. It has to provide very simple but powerful APIs that let you, developers, create whatever you want whenever you want. A simple framework is easier to apprehend and understand and relieves Google of maintaining a too large/complex API. This deprecation (deprecation doesn’t mean it has been removed) is a good start and I hope Google will continue to remove/depreciate classes that should never has been there.1

While reading the entire API differences, I’ve also discovered several interesting changes:

  • A new display density has been introduced: DENSITY_XXHIGH which corresponds to 480 pixels per inch. It clearly demonstrates Google is thinking about Android in a long-term manner and starts to prepare the system to future screen densities. Personally I think this will be the last added density (no need to have a higher density on any device) but I can’t wait to see a Nexus device using it!

  • LongSparseArray has been made public or more specifically unhidden (it has always been in the Android source code). SparseArray<E>s, SparseBooleanArray and SparseIntArray are really great to avoid auto-boxing/auto-unboxing problems in maps. Prior API 16, the LongSparseArray was hidden. As a result, it is now possible to have maps in which keys are longs. This make me believe, the pool API (PoolManager, Poolable, etc.) that lets you easily create a pool object mechanism may be unhidden some day…

  • You can now synchronize your custom animations with the display vertical synchronization (vsync). This can be done using the Choreographer class directly or one of the new View methods (also available in the support library through the ViewCompat class): postOnAnimation(Runnable) and postInvalidateOnAnimation(). I applied it to my implementation of the fly-in app menu and I got to admit I love the result!

  • ViewPropertyAnimator now includes 3 more methods making the animation framework crystal clear and easier to use. Indeed, you can know define a start and/or action directly from it via with[End|Start]Action(Runnable). The API also includes a new withLayer() method. Thanks to this method chaining feature, creating, applying properties and starting an animation has never been so simple.

  • The WebView framework has also been updated because a new WebView.FindListener has been added. it lets you be notified as find-on-page operations progress. The outdated getZoomControls() method has also been completely removed. Here again, it brings clearness to the framework and remove redundancy (zoom controls can be disabled/enabled using WebSettings.setBuiltInZoomControls (boolean))

The minor Jelly Bean release clearly moves Android forward. I sincerely love the work Google has made on this release and hope they’ll continue to follow the path they’ve taken. Lots of developers may complain at first about the introduced changes and deprecations but this is for the good of Android. Google is preparing Android for the future. You, as a developer should stop complaining, get use to it and adapt yourself. Do not forget Android is now a 6 years-old system. Legacy is not something we can ignore.

  1. My personal point of view about what a framework should be is also the explanation of why the fly-in app menu shouldn’t be part of the SDK. The Android SDK contains everything you need to create a stunning fly-in app menu. Stop asking Google integrating it in the SDK. That’s something that should be clearly done by Android developers and optionally by third-party libraries. From time to time I really believe Android developers are pretty lazy. They prefer spending time on begging Google to help them rather than actually developing. Look at the permissive and powerful framework, read the documentation, etc. You have the power of Android in your hands: you just have to use it!