Mark L. Murphy's Blog, page 78

Updates on Updates

Now that Ice Cream Sandwich (ICS) has shipped, some people will be wondering when I will be updating my books to reflect ICS, the new r14 edition of the development tools, etc.

The answer is: November. Hopefully. For some books. Waffle, waffle, waffle.

Part of my difficulty is that I have no idea when the Galaxy Nexus will actually ship. The best I've heard is "November", which is a relatively large target. My guess is that they will try to release it in the US before November 24, but that's a guess, and I've been wrong before. I will not ship a book update based solely on emulator behavior, as down that road lies madness (and mad readers). And, my travel schedule complicates matters a bit. Notably, I have a metric buttload of presentations at AnDevCon 2011 II, and while I am in Burlingame, I am not out buying a phone.

If I were a betting man, I would bet that I won't be able to buy a Galaxy Nexus until November 19th or later, either because it doesn't ship until then, or I can't get a chance to buy one until then.

Here's what I can tell you:

I should ship a small update to Tuning Android Applications before AnDevCon 2011 II, as it is mostly complete and I need that material for a pair of presentations.

The Busy Coder's Guide to Android Development will be updated before The Busy Coder's Guide to Advanced Android Development. Depending on the availability of the Galaxy Nexus, they may ship almost simultaneously, or there may be a couple of weeks in between. If my guess of the Galaxy Nexus being available by November 24 is accurate, then these book updates should ship by the end of November.

Android Programming Tutorials will get a light update before year's end, to ensure everything works on ICS and the new build tools, plus update the Eclipse-specific instructions for the various changes those new tools have introduced. This book is slated for another complete overhaul in early 2012, to get fragments and the action bar covered early and used throughout most of the book, as opposed to showing up ~20 tutorials in.

Also, for those of you who have been using any of my CWAC components, they are probably in a state of disarray if you have updated to the latest tools release. Pretty much every author of an Android library project will have to update their projects. This is part of my workload scheduled for tomorrow, so stay tuned to the components' Git repositories for new commits and tags.

Ice Cream Sandwich SDK Curiosities

For every Android release, I go through the API Differences report and see what shows up, clicking on various items of interest (usually things I am covering in a book somewhere). In addition to expected changes, I frequently encounter some stuff that ought to be better publicized. Here's the crop of those from the Ice Cream Sandwich (ICS) release:

Previously, we were told to honor getBackgroundDataSetting() and not try to use the Internet from a background service if this method returned false. Now, this method is deprecated — presuambly tied to the new network/bandwidth management screen. Now, with API Level 14, we need to examine getActiveNetworkInfo() — if we are not to be using the Internet for whatever reason, this will return null, as if there was no network connection at all.

2D hardware acceleration is on by default if you target API Level 14 or higher, though you can disable it on a per-widget basis using the android:hardwareAccelerated attribute in your layouts.

If you target API Level 14 or higher, your default theme will be Theme.DeviceDefault, whose look will change based upon device manufacturers' design decisions. If you want to attempt to blend in better on the device, you will want to stick with this base theme and modify as few settings as possible (as anything you change may work on one device but not others). If, instead, you set up your application to use Theme.Holo as its base, that theme will not be modified by manufacturers, so you can feel more confident that your app will look internally consistent, particularly if you are making lots of customizations.

Fading edges on widgets are now dropped from the UI standards, so if you target API Level 14 or higher, they apparently will not appear, unless you use android:requiresFadingEdge to override this.

The contacts API got smacked around again, though at first glance it appears that the changes are only additions, so existing code will (hopefully) still work.

There is a new Switch widget, which is yet another variation on the CheckBox / ToggleButton concept. There is a corresponding SwitchPreference as well.

The Busy Coder's Guide to Advanced Android Development Version 2.1 Released

The Busy Coder's Guide to Advanced Android Development Version 2.1 is now available for subscribers.

This release adds about 30 pages, mostly covering the Loader framework and action modes (contextual operations using the action bar). There were also some minor improvements made to the fragments sample (bug fix) and the camera and content provider samples (simplification).

The next release of this book is not anticipated until after Ice Cream Sandwich is released and production hardware running it is available.

Recent Conference Presentations

Since I can't find where one of the recent conferences I attended have my slides available for download, I have uploaded all of them to SlideShare:

my keynote from droidcon UK 2011: Predictions Sure to Go Wrong (video available here)

my 50 Business Models in 20 Minutes presentation from the 2011 Android Open conference

my The Action Bar: Front to Back presentation from the 2011 Android Open conference

Market in Every Touchpoint

At Android Open, I chatted with some developer relations folk from an up-and-coming Android hardware platform manufacturer. They invited me to review a document related to their upcoming SDK launch. The document, while informative, seemed overly focused on what developers could not do with their platform, spelling out all sorts of rules and requirements, not always with solid technical explanations for them.

This manufacturer forgot one cardinal rule: EVERYTHING YOU WRITE IS A MARKETING DOCUMENT.

Here, by "marketing document", I mean that everything you write must have, as part of its mission, marketing to your target audience. If you are trying to recruit developers, everything you write must, in part, be designed to make developers be interested in and more comfortable with your firm or organization.

In this case, your product documentation, down to the last README, are marketing documents.

Simlarly, your EULA, terms of service, and similar legalese, are marketing documents. They spell out how you want your relationship to be with the developers. Too many firms simply delegate this document to "legal counsel", who usually couldn't sell snowshoes to Eskimos. As a result, most of this legal stuff suggests that the firm's relationship to developers most closely resembles shoving a fiery hot poker into a developer's sensitive bodily orifice.

This, as much as anything else, explains why open source is so popular with developers: the legalese is balanced (and typically short).

Nobody is perfect, of course. I am certain there is more I could be doing in this area myself. In my case, the very structure (low-cost, DRM-free, frequently-updated books) is designed to increase comfort, above and beyond any words on the sites.

This is one of the reasons why I fear for PhoneGap. Today, PhoneGap is excellent, because at every touchpoint, it supplies comfort, from the license to the tech ("it's just HTML/CSS/JS") to the build service. Yet, they just got aquired by Adobe, which tends to be hit-or-miss on these sorts of things. Their hits tend to be top-notch, but they screw up far too often, as many a Flash developer has noted over the years. Most likely, this is simply a facet of the sclerosis that major corporations inevitably develop, but one can only hope that PhoneGap will be able to retain their consistently pro-developer attitude as long as possible.

If you are introducing a new product or service for developers, you need to go through everything with a fine-toothed comb and ensure that, to the greatest extent possible, it makes your target market (developers) feel welcome and wanted. "All your IP are belong to us" EULAs, "you're a screw-up, so we must defend against you" guidelines, and the like are all filters — some percentage of developers will abandon you because they get turned off by the 'tude you exude.

Activities are Not Destroyed to Free Up Heap Space

If you're like me, when you read passages in the SDK documentation like:

If an activity is paused or stopped, the system can drop it from memory… by asking it to finish (calling its finish() method)

and:

(onDestroy() is called) because the system is temporarily destroying this instance of the activity to save space

you might think that Android will destroy activities to free up heap space. I envisioned Android checking free heap space from time to time, and when it fell below some threshold, it would destroy an activity that had been pushed into the background, thereby freeing up its heap space.

Apparently, that is not the case. And, to the extent that I steered you wrong on this point previously, please accept my sincere apologies.

In a recent StackOverflow answer, Dianne Hackborn of the core Android team wrote:

The only memory management that impacts activity lifecycle is the global memory across all processes, as Android decides that it is running low on memory and so need to kill background processes to get some back. If your application is sitting in the foreground starting more and more activities, it is never going into the background, so it will always hit its local process memory limit before the system ever comes close to killing its process. (And when it does kill its process, it will kill the process hosting all the activities, including whatever is currently in the foreground.)

This does not mean that you need to rush out and change your applications. However, if you are running out of heap space, or are just concerned about how much RAM you might be consuming in general, you might wish to take this behavior into account.

Here are some mitigation strategies:

Use FLAG_ACTIVITY_REORDER_TO_FRONT or the combination of FLAG_ACTIVITY_CLEAR_TOP and FLAG_ACTIVITY_SINGLE_TOP Intent flags more aggressively, to recycle your existing activity instances where possible. Note that these affect the BACK button navigation, so you will want to ensure that your changes do not harm usability of your app.

Roll your own hibernation logic for expensive activities. If an activity has been stopped for some period of time, call setContentView(null) or otherwise cut back on heap consumption. Make note that you did this, so you can restore your state if and when you return to the foreground. You might even consider finishing old activities, if you do not mind them being removed from your BACK stack (if relevant).

Use fragments, per Ms. Hackborn's suggestion in the linked-to StackOverflow answer, as dynamic fragments automatically remove their view hierarchies when they are not on-screen.

Servers Are Risky. Mobile Servers Are Riskier

The folk over at xda-developers are doing excellent detective work on various bits of crap that get pre-installed on devices. Right now the major crisis is that some HTC devices have an actual daemon, listening on a port, that will happily cough up all sorts of private data to anyone on the device who asks. This post over at the xda-developers site explains the gory details, such as they are presently known.

Lots of other people are covering the "WTF HTC?" angle on this. I'd like to point out how this is a fine example of why server daemons on mobile devices are scary.

Unless you've been living under a rock for the past decade or so, you are well aware that Web servers, mail servers, and their brethren get attacked all the time. That's why there are clear guidelines for how to harden such equipment, from firewalls to minimizing the number of daemons listening on ports in the first place.

Mobile devices generally do not have firewalls. More importantly, users are installing apps on these devices, and those apps would be inside the firewall anyway. Any app can get at any server socket you happen to open, and if somebody can spoof your protocol, your code will do the app's bidding.

While the HTC daemon is at the firmware level, it is entirely possible to create such daemons at the SDK level. ServerSocket works, and if you set up an everlasting service (perhaps using startForeground()), you can listen on whatever port you want to.

For example, back when SL4A was the Android Scripting Environment (ASE), it used an embedded Web service to enable Python and other scripting languages to invoke Android-specific logic. Initially, though, the Web service would respond to any request, and since that service would serve up details like location data, it was leaking private information. Around the time the project shifted names, they locked down this Web service using a token-based mechanism, so only authorized clients (i.e., the user's chosen scripts) would be able to get data out of the Web service.

If you are determined to implement some sort of socket daemon on Android, you need to make sure that you are properly defending against rogue clients — including ones not on the device, if you're actually binding to a real IP address instead of localhost. And, if you have not yet decided whether or not to implement such a daemon, perhaps the HTC lesson will be useful to you, and we can have a silver lining for this exceptionally dark cloud.

Kindle Fire: Preliminary Thoughts

Today, Amazon announced the Kindle Fire. Tactically, there are a few things that were mentioned in the press conference that might impact Android application developers:

The device is 169dpi, which should make it -mdpi from an Android resource perspective.

The device has its own browser (Silk) that proxies through the Amazon cloud. If you link to the browser (e.g., startActivity() on an ACTION_VIEW for an HTTP Uri), you will want to test this out to ensure there are no compatibility issues. Similarly, one would expect WebView to be unaffected directly, but that will be worth testing.

Strategically, the $199 price point, coupled with Amazon's marketing prowess, means that this device will sell quite a few units before year's end, assuming that initial reviewers indicate that it works well. Since the Fire presumably only has the Amazon Appstore, which has fewer applications on it than does the Android Market, there is an opportunity for paid applications to do well for a while, until the Appstore becomes saturated. This is similar to the case for the Nook Color, except that the Appstore has been available for developers for longer, and the Fire may well outsell the Nook simply due to Amazon's reach.

Amazon also announced other e-ink Kindles, ranging from $79 to $149, depending on whether they have a touchscreen and/or 3G. On the surface, this might seem to cannibalize the Fire. However, if Amazon does a good job of promoting the incremental benefits of the Fire (e.g., full color, games, videos, apps), the incremental price may make the Fire seem like a much better value. It will be interesting to see how this facet plays out.

b.android.com: It's Full of Stars

Jeff Gilfelt (a.k.a., readyState) posted a profane tweet a few hours back, complaining about a comment Dianne Hackborn made a few months ago:

Lots of votes for bugs just makes me want to ignore the bug. Just saying. I hate bug voting. Drives me crazy.

I certainly cannot speak for Ms. Hackborn, but I can understand her position. To paraphrase (and sanitize) Mr. Gilfelt:

Do Android developers asking people to go up-vote issues give a flying fig about the developer community? Sometimes I wonder.

To be clear, we need a way to get bug reports to the core Android developers. However, I have long felt that b.android.com was not a good tool for that purpose. While the intention is certainly noble, and the desire to "dogfood" is not completely insane, this issue tracker has failed on a few broad-brush areas:

Never use a technology that offers end-user features that you don't intend to honor (e.g., voting on issues)

Never use a technology that looks like the system of record if it isn't the system of record (i.e., the real issue tracker is internal)

Never use a technology that prevents you from explaining the use of the technology (e.g., nothing on the b.android.com page that explains what issues belong here, and from whom)

Never use a technology that requires a culture if you will not cultivate that culture (e.g., excessive debates in comments on issue trackers turning them into virtual discussion boards)

Various Android developers have not been helping the situation. "Star this issue" campaigns are one example. First, they don't really work — only 21 of the top 100 issues have been addressed in a release, and 40 out of the top 400 (note: does not count "FutureRelease"). Second, they drive a bunch of "me too" and related drivel in the comments, which will simply cause interested parties to tune out just to cut down the noise. My guess is that is what is causing Ms. Hackborn to be frustrated — not the votes themselves, but the chaff that comes along with them. Certainly I have dropped out of various issues, some of significant importance (e.g., optional permissions), due to this.

In the fullness of time, Google's choice to use a Google Code issue tracker for bug reporting appears to me to be an unfortunate choice. That being said, I can't fault engineers who dislike the way some community members have elected to try to exploit that issue tracker.

Android's Advances: Review and Preview

Ten days ago, I delivered a Webinar entitled "Android's Advances: Review and Preview" as part of the WIP Connector's "Back to School Webinars" series.

Well, OK, I sorta delivered a Webinar.

Actually, I was on a plane over the Atlantic right then, trying to get back home after a small hurricane put the kibosh on my original return flight from Oslo.

Since I was not going to be able to deliver the Webinar live, I recorded the audio (with the weak headset that I had with me, natch) and supplied that and the presentation slides to WIP. They, in turn, delivered it for me to the audience.

If you are interested in watching it, the full video is up on Vimeo, courtesy of WIP. It is probably "old hat" to those of you who are active in the Android community — the presentation was aimed at those people who had not been "tuned into" Android over the past few months and wondered what all went on while they were off doing other things.