The Busy Coder's Guide to Android Development Version 6.3 Released
Subscribers now have access to the latest release of The Busy Coder’s Guide to Android Development, known as Version 6.3, in all formats. Just log into your Warescription page and download away, or set up an account and subscribe!
This update includes:
Moving coverage of Android Studio and Gradle for Android to 1.0. This includes overhauling the first couple of tutorials to deal with the new Android Studio setup process. This also includes warnings that Google has discontinued Eclipse support.
Initiated coverage of Material Design. Right now, the focus is on the core themes, the impacts of
Theme.Material on widgets and the action bar, and the application of tints. Additional Material Design technical coverage, such as
elevation and its relationship to things like
RelativeLayout, will come in future updates. However, the focus of the book will be on engineering aspects, not design aestethics, as I have the design acumen of your average hamster.
Overhauled the AppCompat chapter to update it for the now-current release. This not only includes the new Material-ish action bar but the AppCompat tints of select
Moved the chapters that touch on Play Services to the new granular dependencies. In particular, this involved modifying all of the Maps V2 samples (and the associated chapter), to cover
getMapAsync(). I also removed the action bar list navigation from the Maps V2 samples, as action bar navigation has largely been deprecated.
Updated the coverage of greenrobot’s EventBus, particularly moving to the latest version and switching to
NoSubscriberEvent instead of ordered events to handle “update the UI or raise a
Removed the Nokia X chapter, may it rest in peace.
Various bug fixes and other minor improvements.
The next update is tentatively slated for late January 2015.
Note that a few items are targeted for removal next year:
Eclipse instructions in the tutorials will probably be removed in mid-2015. Eclipse information elsewhere will remain, perhaps switching to covering the Eclipse Andmore distribution. However, I am only going to maintain tutorials for official IDEs, because maintaining the tutorials is a pain in various body parts.
The ActionBarSherlock chapter will be pulled sometime in early 2015, as the project is formally deprecated.
—Dec 18, 2014
Manufacturers, Keep Your Hands Off My Zygote
As I often say, Android being open source is a double-edged sword.
(actually, I’m thinking that perhaps it is a more topologically-complex sword with lots and lots of edges, but I digress…)
Open source allows lots of people to get involved in creating Android devices, not limited to traditional form factors like phones. On the other hand, the ability for manufacturers to tinker with Android leads to compatibility problems. That in itself is not a problem… unless the manufacturer also wants app markets like the Play Store and Amazon AppStore for Android, and the compatibility problems have the potential to affect lots of apps.
One area of compatibility issues that has become more prominent is manufacturers messing with the zygote.
The zygote is a process, created when Android boots up, that contains the runtime (Dalvik or ART), framework classes and other JARs, and native libraries. When our app’s process is created, it is forked from the zygote. This is so Android can leverage the Linux kernel’s copy-on-write memory sharing, so the memory footprint of each of our processes is mostly limited to our own classes and other JARs, our own native libraries, and whatever we allocate on the heap.
Developers used to other environments will recognize the terms “DLL hell” and “JAR hell”. Any place where libraries are shared, changing those libraries affect all consumers of those libraries. The primary spot on Android where we get these effects is in the zygote, as our own classes and libraries are (usually) isolated per app.
Hence, when manufacturers change what is in the zygote, compared to what is normal for that version of Android, compatibility issues can result, such as:
This is on top of Google’s under-the-surface and largely-undocumented zygote contents, such as the stripped-down edition of Legion of the Bouncy Castle that led to the development of Spongy Castle. That, at least, is fairly common across devices.
Sometimes, it would appear that manufacturers modify the zygote to have some library available in common for all their own apps. That is what I have to assume the rationale was for Samsung’s addition of
appcompat-v7 to the zygote. This is simply sloppy, trading off the compatibility of countless apps to save a handful of KB of disk space.
Sometimes, the changes might be to address bug fixes that their own apps happen to trip over. This could be the reasoning behind the higher SQLite versions that LG and others have employed. That is certainly cool, though a bit more transparency would be helpful, and the fixes could still introduce compatibility problems.
Device manufacturers need to be very careful when altering what is in the zygote. Android is open, and device manufacturers have the freedom to alter what they want. Freedom to implement does not mean freedom from responsibility, though. Manufacturers that want apps from third-party developers need to ensure that the zygote the manufacturer uses is compatible with the zygote that third-party developers are expecting.
In other words, not all zygotes are created equal.
—Dec 11, 2014
A Presentation Sabbatical
I am going to be taking a sabbatical of sorts from presentations at conferences, meetups, and the like.
In the past year, I have delivered 16 such presentations, including a pair of half-day workshops. I have probably done ~40 presentations dating back to the beginning of 2012. And, since I don’t like repeating myself, most of those presentations were newly crafted for that event, or were substantial rewrites from past presentations.
While delivering presentations helps me to be useful to the Android developer community, I do need a bit of a break to “recharge the batteries”, as it were.
I will eventually return to submitting papers for conferences and such, but probably not until at least the latter half of 2015, and perhaps beyond. There are a few things that I want to get done first. When I return to presenting, I will probably start with events in the local area first, before getting to events on the US West Coast or overseas.
I apologize to anyone who is disappointed in me due to my sabbatical plans.
—Dec 10, 2014
Dealing with the Bulk-Closed Android Issues
Somebody (“e…@google.com” for many of them) closed ~11890 issues out at http://b.android.com, marking them as “Obsolete”.
Some of the issues are old, others not so old — it seems like they were bulk-closed if they were opened on December 4th 2013 or earlier. They are not tied to any particular piece of hardware. Personally, I have had issues closed that ranged from bug reports to enhancement requests. Curiously, none of my many documentation bugs seemed to be closed.
While some of the closed issues are indeed “Obsolete”, I can state positively that some are not. Whoever decided to do this rage-closing of issues seems to have done so algorithmically, not tied to whether or not the issue is actually “Obsolete”.
For example, this feature request, to have
FileProvider served from assets, is still outstanding, as
FileProvider still does not have that as a feature. While I provided that sort of functionality in my
FileProvider could still be outfitted with that functionality. After all, about 4.5 years after I first published my
WakefulBroadcastReceiver, which fills the same niche.
If you opened or are otherwise invested in one of the issues that were bulk-closed, please re-evaluate whether the issue is still valid or not. For example, this issue of mine is truly obsolete, insofar as action bar list and tab navigation are now deprecated, and Google’s philosophy is that bugs in deprecated code are perfectly legitmate.
If you find issues that were marked as “Obsolete” and are definitely still valid, please re-open them. If the originals were widely-starred, consider posting a comment in the now-closed issue pointing to the reopened issue. That way, those still following the concern can follow the new issue, and those seeing the new issue can find the context from the original. Also, this will help us minimize duplicate reopened issues. For example, I opened this issue and cross-linked it with its now-closed counterpart. I will be handling other issues of mine over the next few weeks, if others don’t beat me to them.
I have no problems with Google taking steps to clean up the Android issue tracker. I think it could have been handled with more aplomb. And, as usual, developers in the community have to repair the damage.
—Dec 08, 2014
My Mistakes with CWAC-Camera
My CWAC-Camera library is an attempt to make taking pictures with Android’s
Camera API somewhat easier, to hide a lot of the fiddly bits with previews and so forth.
It also serves as an abject lesson in the problems with writing reusable libraries, as I made mistakes along the way… mistakes that will now require me to pretty much rewrite the library from scratch.
I envisioned the library as being a wrapper around
Camera, rather than being a clean abstraction around the act of taking pictures and recording videos. As a result, I exposed bits of the
Camera subsystem, notably
Camera.Parameters. Google has now deprecated the
Camera API, replacing it with
android.hardware.camera2. A cleaner abstraction would also make it easier to blend in other camera APIs (e.g., SONY’s remote camera stuff) that might not show up under
I envisioned the library as being a replacement for the
Intent actions, as third-party camera apps definitely vary in how well they support those actions. However, I did not more forcefully restrict the scope to be just that functionality, and I did not design an API around extensibility. As a result, when requests came in for new functionality, either the functionality had to be in the library, or the functionality would not exist. This was rather frustrating, as it meant a lot of extra code in the library for scenarios that are not really all that near any itches that I was really seeking to scratch. A camera library, more so than many libraries, needs a small core with an extension model that allows other developers to add plugins to the library to handle their own itches without having to re-develop the core.
My lack of scope control and extensibility also makes it very difficult to rewrite the implementation without breaking the API. Of note, some devices seem to not like it if you change the camera parameters on the fly, and that’s difficult for me to fix within the confines of my current API.
I suck at JavaDocs. I’m much more fond of long-form prose than short-form method and parameter descriptions.
I still need a library for my core use case: replacing the
Intent actions. But I cannot rely upon
Camera for the long term — if device manufacturers have inconsistent
Camera support now,
Camera support will only decline now that
Camera is deprecated. And, I really need to address the extensibility issue, as otherwise this library will be an unmaintainable mess for the long term.
So, in mid-December, I’ll begin rewriting the library. This will take some time, as the new
android.hardware.camera2 API seems to be your typical under-documented Android API. I will work on patching a few bugs in the existing library, particularly ones that do not involve API changes, but for the time being, significant work on the existing library is frozen pending the rewrite.
The rewritten library will share some common aspects with the existing one:
CameraView, for example. I am even looking to add a drop-in replacement for
Intent actions, to make it easier to move to a library from relying upon third-party camera apps. However, the other aspects of the API are going to change, hopefully for the better. I will provide instructions to help those migrating from the old to the new API as the new library starts to stabilize.
In other words, stay tuned for further developments.
—Dec 01, 2014