I maintain a list of Android developer support sites
called AndGlobe. The
particular emphasis is on sites that are not in
English. Android development is worldwide and multilingual;
our support sites need to match.
If you operate, or know of, a site for asking
Android development questions and answers, that is not
listed on the AndGlobe site,
please let me know,
or follow the instructions on the GitHub repo
to contribute new sites that way.
And, of course, please link to or otherwise promote
the AndGlobe site, so Android
developers know the wider range of Q&A sites that they
can use for getting their questions answered.
—Apr 21, 2015
Subscribers now have
access to the latest release of The Busy Coder’s Guide to Android Development,
known as Version 6.6, in all formats. Just log into
your Warescription page and download
away, or set up an account and subscribe!
This update includes:
A new chapter on Android’s convoluted tasks system. This chapter
includes a review of what tasks are, what the standard behavior that
users see without any changes on our part, and what some common modifications
are to task behavior. It also covers persistent tasks and
documents-as-tasks, introduced in Android 5.0.
A new chapter on the App Runtime for Chrome (ARC), for getting
your Android app running on Chrome OS, as was profiled
earlier in this blog
An updated chapter on UI Automator, covering the new UI Automator 2.0
and its Gradle/Android Studio integration
A new chapter on Android Studio dialogs, focusing on the Project
Structure dialog and the Translations Editor.
A new section in the chapter on the Play Services SDK’s fused location
SettingsApi (to prompt users to enable locations)
requestLocationUpdates() (for periodically getting location fixes)
Minor changes for Android 5.1
A somewhat revamped chapter on
ContactsContract, as the previous
edition of this chapter was really old
The next update is planned for the first half of June. In other words,
the next update is planned for sometime after the Google I|O conference,
in case Google makes some Earth-shattering (or at least book-shattering
or author-shattering) announcements.
—Apr 16, 2015
2015 has potential to be a rather interesting year in the world of
Android development, as Google builds an ARC.
The App Runtime for Chrome (ARC) is now in a beta state, where any
developer can repackage their app to run… on Chrome OS.
Now, that may not excite you much.
There are a variety of Chromebooks and other Chromeboxen available
(though personally I am still waiting for a Chromedome to be announced).
Sales appear to be in the low tens of millions. To put that in perspective,
that means there are probably more Chrome OS users than there are users
of Froyo, but fewer than there are users of Gingerbread, based on the
April 2015 device dashboards.
Or, to put it another way, there are probably more Kindle Fire tablets
and BlackBerry 10 phones (which, BTW, can run Android apps, lest ye forget)
than Chrome OS devices. And since the ARC runtime environment is not
completely standard, getting to Kindle Fire and BlackBerry 10 may be an
easier jump for many developers.
However, what makes ARC interesting is not Chrome OS, but Chrome itself.
ARC apps can run in the Chrome Web browser, as it is one of the development
tools. So far, Google has emphasized ARC for Chrome OS, possibly as part
of building up a catalog of ARC-enabled apps. But it would seem bizarre
for Google to limit ARC to Chrome OS over the long term if it can also be
used with the “desktop” Chrome browser.
Chrome OS users are modest in number. Chrome users number in the hundreds
of millions. And while some of that will overlap with existing Android
users (who may be running Chrome on their Android devices), there will
still be countless others for whom Chrome might be their first avenue for
using Android apps.
To look at it another way, Chrome OS devices are seriously outnumbered
by OS X devices, which are outnumbered by Chrome browser users. There have
been rumors, off and on, of OS X eventually being able to run iOS apps
natively. ARC not only increases the odds that Apple might make that
move, to keep up competitively, but Google still comes out ahead if they
make ARC available for Chrome.
Now, most Android apps on Chrome probably require tweaking. Gestures that might
make sense on a touchscreen may be difficult, if not impossible, to execute
using a mouse or touchpad. Hardware that may not be available on the host
computer, like NFC, will not be available on the ARC. That’s why I think
that Google is soft-pedaling this now, to allow developers to play around
with ARC while expectations are low, as they are “only” going to be available
to Chrome OS users. Google is probably hoping that there will be a fairly
large set of ARC-ready apps by the time that they roll out ARC for public
use on desktop Chrome.
(and many of the tweaks needed for ARC will also help those apps’ compatibility
with other less-conventional environments, like TVs)
For some developers, ARC will be a non-starter or permanently uninteresting.
But for other apps and other environments, ARC could be a game-changer.
In particular, ARC powers a “write once, run on every form factor” model,
where Android handles phones, tablets, and TVs, while ARC handles desktops,
notebooks, and netbooks. Apps that require that sort of full-fleet availability,
such as bespoke apps for businesses, governments, and other organizations,
could really benefit from ARC, and may suffer less from ARC’s limitations.
While you could get ARC-style ubiquity from other tools, like Bluestacks
or Genymotion, ARC and Chrome will likely have a simpler distribution model,
if for no other reason than they will be free and, in the case of Chrome,
perhaps already installed.
If ARC sounds intriguing, your #1 problem will be the
singular lack of documentation.
Then again, you are probably used to this, as various aspects of Android
development also are under-documented. But with trial, error, and
the assistance of Android book authors with chrome domes,
you may find that ARC opens up some new opportunities for you.
Just be a bit careful using RxJava on ARC. An arc reactor
is nothing to be trifled with.
—Apr 09, 2015
I have added a pair of one-hour webinars on
my roster of webinars.
is an introduction to
RecyclerView and how to use it in lieu of a
GridView. The webinar will cover how to set up
adapters and view holders, how to respond to click events, and so on.
“RecyclerView, Beyond the Basics”
gets into more advanced topics, such as how to have more than one type
of item (e.g., headers and detail), how to support choice modes and
action modes, and how to modify the contents of a
(complete with basic animations).
Note that these, plus my 30-minute overview of
JUnit4 on Android,
will be held in a private BigBlueButton
meeting space, as I switch over to that and away from the
—Apr 01, 2015
One of the bigger reasons why developers depend upon Google Play
Services is for MapsV2, the native Android mapping engine. Lots of
developers are comfortable with just implementing MapsV2, on the grounds
that most Android devices are part of the Google Play ecosystem and
therefore can use MapsV2.
This, of course, makes manufacturers outside the Play ecosystem sad.
Some of those manufacturers have elected to provide their own mapping
solution. Amazon, for example, offers maps with an API that is very
similar to MapsV1 (the old API) and MapsV2. However, this still requires
developers to code to these distinct APIs, perhaps employing product
flavors in Android Studio and Gradle for Android to isolate the ecosystem-specific
code bits. After all, Amazon’s maps only work on Amazon hardware, so you
still need something that can work elsewhere.
One way to try to deal with this is to use a compatibility layer.
Airbnb went down this road, and last week they released
AirMapView based on their work.
AirMapView is designed to give you a map, regardless of the device that
you are running on. It tries MapsV2 and falls back to maps powered
WebView and the Web edition of Google Maps. Airbnb indicates that
support for Amazon’s mapping engine is forthcoming. I hope that somebody
contributes an OpenStreetMap extension for it as well. And, they too offer
an API that is close to MapsV2. If it works as advertised, you can get
the best possible map for a given device, without constraining yourself
to only devices that offer MapsV2.
The 1.1.2 AAR for AirMapView clocks in at ~100KB, so it will not grow
your APK too much. AirMapView is definitely a project to keep
track of, and to evaluate when it makes sense for your team. Having
the ability to support non-Play devices may prove important to you in
the long run. Anything you can do to isolate the Play-specific code
and have options for replacing it would be good, all else being equal.
—Mar 30, 2015