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 developers 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.
