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.

—May 19, 2013

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.

—May 16, 2013

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.

—May 15, 2013

The normal rule for resource set qualifiers, like -large or -land, is that only those that match the device’s current configuration will be used. One oft-mentioned exception to this rule are density resource set qualifiers, like -hdpi and -xxhdpi, where Android will choose from another “near” resource set if there is no exact match.

This latter capability was always described in the context of drawable resources, where Android has the ability to “convert” a resource from one set to another, such as downsampling an image. Therefore, I had assumed that this resource set trickery was a feature of drawable resources.

It’s not.

It’s a feature of the density resource set qualifiers.

(probably many of you already realized this, or guessed better than I did)

So, for example, if you have an app with res/values/strings.xml and res/values-xxhdpi/strings.xml, and you request a string resource on an -xhdpi device, my assumption was that you would get the one from res/values/strings.xml. After all, you do not match the density, and Android cannot really convert a string between densities, so you would get the default. In reality, at least on Android 4.2, you get the one from res/values-xxhdpi/strings.xml. Android applies the same rules for choosing a resource set based on density for strings as it does drawables.

Now, in truth, you should not run into this very often. Outside of maybe some game apps, having layouts or menus or preferences that vary by screen density is a strong code smell. But if you are tweaking dimension resources using density resource sets (for cases where the straight-up dp conversions do not quite give you what you want), or similar situations, just bear in mind that all resources, not just drawables, are affected by the way density resource set qualifiers are used.

Many thanks to Morrison Chang, whose answer and comments on StackOverflow triggered my research in this area.

—May 06, 2013

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

This is a smaller update than normal, in terms of topics:

• A new chapter was added on developing for the OUYA game console (many thanks to Al Sutton for his assistance!)

• New large-screen samples, showing alternative ways of implementing the master-detail pattern, as riffs on the original EU4You sample

• Expanded coverage of advanced ViewPager tricks, including using Jake Wharton’s ViewPagerIndicator and supporting “Plume-style” columns on large screens and pages in a ViewPager on smaller screens

• Updated coverage of Presentation, including an even simpler sample that takes advantage of my CWAC-Presentation project

• New material on creating custom views and containers, including a ReverseChronometer and explanations of the implementation (and usage) of the AspectLockedFrameLayout and mirroring classes from my CWAC-Layouts project

• Updated everything to ActionBarSherlock 4.3.1

• Began the slow process of replacing all fill_parent with match_parent, now that nobody should have a build target lower than API Level 8

• Added part dividers to the PDF for the core chapters and each of the trails

The next update is tentatively planned for mid-June, though this may change depending upon what happens at Google I|O.

—May 03, 2013