Mark L. Murphy's Blog, page 65

Warescription Site Downtime

The Warescription site will be upgraded to a new edition this weekend. The site will be sporadically unavailable while this is going on, though I will be aiming to keep downtime to a minimum. My apologies in advance for any particular trouble this may cause you.

Calling for More Android Developer Support Sites

About seven months ago, I launched AndGlobe, a site to collect the names and links to Android developer support sites. Here, “support sites” are defined as forums for asking questions and getting answers.

In particular, AndGlobe is designed to highlight sites that offer support in languages other than English. Android development has gotten too large to expect everyone trying to write Android apps to have as solid of a grasp of English as they do Java.

Non-English support sites help in two ways:

They provide a place for non-native English speakers to ask questions in a language that is more comfortable for them, resulting (hopefully) in better questions and better discussion to refine and answer those questions.

For questions that one of these communities cannot answer on its own, the community can serve as a “springboard” for asking the question elsewhere, such as on StackOverflow. If desired, the community can, in effect, ask the question elsewhere, pooling their skills in other languages, rather than necessarily limiting it to the skills of the original person with the question.

So far, AndGlobe has links to 19 non-English support sites, which is wonderful. However, the language range could use more breadth. For example, I have no links to sites in languages native to Korea, China, or India, and I have only one Japanese-language site. I have no links to sites in Arabic, and only one in Hebrew. I have some Russian sites, but little else from eastern Europe. And so on.

Please, if you know of question-and-answer Android development sites, beyond the ones already listed at http://www.andglobe.com, let me know about them! As is outlined on the GitHub repo for this data, there are several ways to send me updates:

Send a GitHub pull request

File an issue with the language, name, and URL

Send an email to globaldev@commonsware.com with the language, name, and URL

According to industry analysts, sometime in 2014, there will be more Android devices in use worldwide than Windows machines. A global user community needs a global developer base, and a global developer base needs multi-lingual developer support.

Thanks in advance!

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

Subscribers now have access to the latest release of The Busy Coder’s Guide to Android Development, known as Version 4.9, in all formats. Just log into your Warescription page and download away, or set up an account and subscribe!

First off, I have removed the C2DM chapter, as anyone using C2DM has hopefully migrated to GCM instead. Subscribers still using C2DM should hold onto a copy of an earlier edition in addition to downloading newer ones!

Beyond that, there are a fair number of improvements:

The chapter on sensors, retired long ago, has been rewritten and restored

There is a new chapter on using uiautomator for UI testing

The book also has a new chapter on using the fused location provider, from the Play Services enhancements announced at Google I|O 2013

The advanced ViewPager chapter was extended with a walkthrough of the usage and implementation of ArrayPagerAdapter, a more flexible fragment-based PagerAdapter implementation

The large-screen support chapter has a new version of the “EU4You” sample that uses SlidingPaneLayout (also introduced at Google I|O 2013), and the sensor sample app also demonstrates SlidingPaneLayout

The explanation of how resources are selected by the system was substantially overhauled

The coverage of Maps V2 was updated to reflect recent changes, such as being able to detect OpenGL ES 2.0 support at runtime (to fail over to another mapping option on older devices) and the deprecation of some location-tracking options

The book also sports various miscellaneous improvements and errata fixes, per usual

Also, users of the book in APK format who were encountering problems using the action bar home affordance to return to the table of contents should no longer run into that issue.

The next update (5.0!) is tentatively scheduled for mid-July.

Don't Forget Ethernet

Some developers will make decisions in their apps based upon whether or not the device is on WiFi. In many, if not all, of those cases, the developer is thinking that there is a binary choice between WiFi and mobile data.

However, there is another option: wired Ethernet.

This will be used for:

Some TV-attached devices (Google TV, OUYA, etc.) where the user elected to hard-wire their device rather than use WiFi

Some tablets, where the user has attached a USB Ethernet adapter and is using a wired connection

As an example of the latter, I was planning on using such an adapter with my first-generation ASUS Transformer Infinity for my AnDevCon Boston 2013 presentation on Maps V2. WiFi in conferences can be a bit shaky, and so I had requested a wired Internet connection. The bad news: that wired connection did not reach the Internet. The good news: the WiFi was solid, so my demos could run.

If you are making decisions based on Internet connection type, please check your code and see whether or not you are going to correctly handle the Ethernet scenario. ConnectivityManager should return TYPE_ETHERNET for such environments.

Don't Forget x86

It’s easy to think that Android runs on ARM, and that’s it. For many developers, the only reason to think about Android on x86 is for the emulator, to get something that runs nice and speedy. While there have been forays into Android-on-x86 in production, they have been few and far between: first-generation Google TV boxes, Motorola RAZR i, etc.

However, Intel isn’t giving up, and there are reports that a future Samsung tablet will rock an x86 CPU.

Developers sticking to the Android SDK don’t really need to worry about this. But those working with the NDK need to keep tabs on these sorts of reports. If popular devices start shipping with x86 CPUs, NDK-based apps should be augmented to support them. A simply change in an NDK build file is enough to add support for x86, though:

You will need to do thorough testing, to ensure your NDK code is architecture-neutral

If you are bumping up against the 50MB app size limit already, the extra x86 binary may be an issue

It is particularly important for developers creating reusable components for Android that involve NDK code adopt x86. Not only are you a gating factor in apps themselves supporting x86 for production, but x86 support in your components can help with developers wishing to test on the emulator as well.

Don't Manually Modify Your Eclipse Build Path... Except Now for R22

With the standardization of both command-line and Eclipse builds on having third-party JARs in the libs/ directory of the project, developers no longer needed to monkey with the build path in Eclipse. In fact, changing the build path in Eclipse would tend to cause more problems than it solved.

However, there’s a bug in the R22 version of the ADT Plugin for Eclipse that does require a one-time modification to your build path:

Right-click on the project in Eclipse’s Package Explorer and choose Build Path > Configure Build Path from the context menu

Switch to the “Order and Export” tab

Check the “Android Private Libraries” entry in the list, if it is not already checked

You will need to do this for all projects that have JARs in libs/, though I would recommend that you do it for every one of your projects, just so that you don’t forget about this months from now, add a JAR, and wonder why things are broken. Specifically, by “broken”, I mean that you get a bunch of NoClassDefFoundError messages at runtime.

Also, be sure to apply this fix to any Android library projects you are using (e.g., ActionBarSherlock), otherwise you may get “class hierarchy is inconsistent” errors.

Note that if you are using Maven, this step is not required, apparently. Quoting Xav Ducrohet:

Unless you’re using Maven to build using the m2Eclipse in which case Maven setups those dependencies itself and the container should not be exported.

There is an R22.0.1 in the works that should address this, though whether they will be able to address it for existing projects (as well as new projects) is unclear.

Also, I owe Streets of Boston a beer, as it was his adt-dev post that helped spearhead letting everyone know about this problem and fix.

Remember, Google Play Services is Proprietary

There are three ways in which Google delivers new APIs to Android developers:

New SDKs, tied to new versions of Android

Add-on JARs or library projects, such as the Android Suppor package

Google Play Services

In the latter case, while we still need to add an Android library project to our app, some (if not most) of the business logic is in the Play Services app, with the library simply providing a local API wrapper around the IPC to that other app.

It is obvious from Google I|O 2013 that Google is going to place new emphasis on the latter two modes of distribution. This is not to say that the Android OS will not advance – far from it. However, whereas we used to get all new capabilities via new SDK releases, more of those capabilities will be delivered independently of OS updates.

As usual, this is a double-edged sword.

Part of the stated rationale for this is to reduce fragmentation a bit. Anything added to a traditional library – such as the new DrawerLayout in the Android Support package – can be added by developers to apps running on a range of OS versions. Anything added to Google Play Services can be pushed by Google to whatever devices they choose, whenever they want.

In this respect, Google is trying to adopt an architecture a bit more like Firefox OS’s, where the true “firmware” controlled by device manufacturers is thin, with framework code distributed separately on top of it. The objective is to minimize the number of true firmware updates, allowing for more rapid innovation at the framework level, while not requiring the end-to-end ecosystem control seen with iOS.

And this would be wonderful, except for one small problem: Google Play Services is proprietary and is controlled purely by Google. That has many ramifications, including:

We do not know what the code does. Part of the interest in Android has been its open source nature, for everything from cobbling together workarounds for bugs to vetting the privacy and security. This is far less possible with a closed-source Google Play Services.

Google controls which devices get Google Play Services and when. Hence, Google will be the one to decide when older devices no longer get Play Services updates, not the users, and not the developers. Also, Google can push updates whenever they want, and those updates will immediately affect apps that use Play Services… and those updates may include bugs.

Google Play Services is not freely distributable. It, like the rest of Google’s proprietary app suite, is only available to licensees. Hence, you will not find Google Play Services on devices like Amazon’s Kindle Fire. You will not find Google Play Services in ROM mods, unless they either have somehow managed to license it or they are distributing it outside of any license.

(and if some ROM mod maintainer has successfully licensed this code, somebody let me know, as I have tried licensing it for use with a ROM mod and Google ignored me)

And, closely related to the previous issue, developers who wish to support non-Play Android devices will either need to eschew the abilities from Google Play Services, write workarounds, or reimplement them.

Google’s counter-argument – that Google Play Services would only contain code that would have been proprietary anyway – does not pass the smell test IMHO. After all, all code ever written would have been proprietary anyway, had somebody not elected to release it as open source. Even for places where the code already existed in proprietary form (e.g., the fused location provider, apparently culled from Google Maps), the rewrite to allow that code to be used by third parties would have changed it enough that the fact that it started as proprietary should have no effect on decisions going forward. And particularly in the case of the fused location provider, I have difficulty believing that there are reasons that justify having it in Google Play Services instead of the Android Support package.

Ken Kinder recently wrote a blog post about migrating from Google services, where he opened up with:

Looking back on Larry Page’s tenure as CEO, I don’t know if it’s a coincidence but it seems reasonable to believe that, unlike Eric Schmidt, Page does not believe in open standards or an open Internet.

I’m not yet ready to append “or open source” to that statement, but I am getting worried.

Uncanny App Valley: Is It Really a Cliff?

In Reto Meier’s 2013 Google I|O presentation, he referred to a concept he called the “uncanny app valley”. While most incarnations of the “uncanny valley” refer to UI, his “uncanny app valley” refers to permissions and general creepiness. Mr. Meier had a slide in his presentation depicting a generalized creepiness chart, complete with a valley representing a creepy app, and with an upslope to the right showing apps that know a lot about you but, in Mr. Meier’s eyes, are not creepy at all. In particular, Google Now was his example of a non-creepy app.

I found that to be a curious example, considering that I went to the level of disabling Google Search on my Galaxy Nexus just to get rid of Google Now, as it is entirely too creepy for my taste.

The truth of the matter is that there is no universal creepiness curve. Different people will have different attitudes towards privacy. Some will not worry a whit about it, aiming for maximum app capability. Others will find Google Now and similar apps to be too invasive.

Branding will have a lot to do with it as well. Apps from brands that users trust will be more likely to escape the “uncanny app valley” than will apps from unrecognized developers or brands that are not trustworthy. So, for example, I am willing to give Evernote a lot of permissions that I do not give out otherwise. At the same time I am still hunting for a decent Twitter client that does not ask for the sun, moon, and stars from a permission standpoint. I have greater trust in Evernote than I do in Twitter, and I have greater trust in Twitter’s own apps than I do closed-source high-permission Twitter clients from other developers.

(Murphy’s Law, of course, suggests that Evernote will get acquired by somebody I distrust at some inopportune moment…)

Hence, while Mr. Meier advocates things like location tracking to help apps deliver “magic”, that may not be in your best interests. Each additional permission that you request serves as a filter, with some percentage of your potential audience electing not to install your app due to that permission. How big that percentage is will vary, based upon permission, branding, available substitute apps, and so forth.

Savvy developers will consider allowing users to “dial in” the amount of privacy they are willing to give up, by delegating privacy-invading permissions to plugins. Since Google has demonstrated no interest in allowing users to control permissions individually per app (and since only so many people run ROM mods that offer this), plugins are a likely approach for keeping your main app light on permissions, yet allowing users to opt into additional functionality with only a bit more work on their part. Cutting the work for developers to support this sort of plugin model is on my ever-popular to-do list…

Certainly, “magic” is an app implementation metaphor of some value. However, if giving your app “magic” means raising privacy and security concerns in prospective users, consider how you can best mitigate those concerns, either by adopting a plugin model, or trying to balance exactly how “magical” your app becomes.

Android Studio Early Access Preview... and You

It’s been less than 24 hours since the Android Studio “early access preview” was released, and IMHO way too many people are trying it, based on the flood of questions coming into StackOverflow.

IMHO, to be using Android Studio today, you either need to:

Be a current user of IntelliJ IDEA, so that you know how the basic IDE should work and can see where IDEA ends, Android Studio begins, and on which side any particular problems with Android Studio lie, or

Be a very expert software developer, with experience in a variety of IDEs, above and beyond a year or more of Android programming experience

If you do not fit into one of those two buckets, leave Android Studio alone for the time being.

If you want to start getting a feel for what Android Studio will do for you, try out IntelliJ IDEA. The open source Community Edition already has a fair bit of Android development integration, just not as much as Android Studio will eventually offer. Later on, when you are fairly comfortable with IDEA, Android Studio hopefully will have matured enough that it will be worth your experimentation.

If you are an IntelliJ user, or are a seasoned veteran, and you want to start experimenting with Android Studio, be my guest. Just bear in mind that this is a 0.1 release, and as Xav and Tor mentioned in the Google I|O presentation, Android Studio is broken in many places. More so than is normal in Android, the expression “your mileage may vary” applies. You might consider trying the IDEA 13 early access preview first, as I get the impression that Android Studio is based upon it, so if IDEA 13 is giving you grief, Android Studio is likely to give you yet more grief.

Android Studio... and the Book

I am sure that the first thing that crossed your mind when you heard the announcement of Android Studio is “when will that balding guy be covering it in his book?”

Well, OK, maybe that wasn’t the first thing that crossed your mind, but it sure as $BLEEP was the first thing that crossed my mind.

Over the next several months, I’ll add some chapters covering Android Studio and the new Gradle-based build system, in a new trail in the book.

Once Android Studio is “for realz” — meaning that Google drops the “early access preview” label and starts pointing people to it in earnest — I will work on “mainstreaming” Android Studio and the Gradle-based build system coverage, notably in the tutorials. The set of chapters I write originally will remain for a while, aiming at people migrating to these new tools from Eclipse and/or the classic build system. Other chapters will be added covering advanced topics related to the new build system. However, since I have no real idea how rapidly Android Studio will move from 0.1 to “for realz”, I do not know how quickly this “mainstreaming” will occur.

Another wrinkle will be if they start shipping support for the new build system in Eclipse before Android Studio hits “for realz” status. In that case, I may wind up rolling out the new coverage in stages, updating the tutorials and such first for the new build system, then updating it later for Android Studio.

Unfortunately, this will take a lot of time, time that’s going to come out of advancing the book in other areas as quickly as I’d like. I apologize in advance for that.