AndGlobe: Another Call For More Sites

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

The Busy Coder's Guide to Android Development Version 6.6 Released

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 provider, covering SettingsApi (to prompt users to enable locations) and 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

Getting on the ARC

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

RecyclerView Webinars

I have added a pair of one-hour webinars on RecyclerView to my roster of webinars.

“RecyclerView Basics” is an introduction to RecyclerView and how to use it in lieu of a ListView or GridView. The webinar will cover how to set up RecyclerView 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 RecyclerView (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 soon-to-be-defunct Dozeo.

Apr 01, 2015

Maps Sans Play Services

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 by 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

Older Posts