In today’s action, I wrote a new Google Cloud Messaging (GCM) server interface to the GCM Cloud Connection Server (CCS) via XMPP. GCM CCS offers several benefits over GCM HTTP including one of my key requirements, bidirectional messaging.

My app server didn’t yet have a XMPP interface, so I followed Google’s sample and plugged in Smack. Then the fun began. I immediately started getting exceptions (see Smackdowns below). These varied based on state and configuration, but basically the result was the same: the GCM CCS server was abruptly closing the connection during authentication. How rude; Smack was getting smacked down.

I dug in but ran into several red herrings. For example, Smack’s stream headers didn’t match Google’s doc (no tag close); Google’s doc is wrong. I debugged Smack, tried different Smack versions, tried other XMPP clients, tweaked configurations, studied XMPP protocols and SASL authentication, and updated authentication parameters and allowed IPs. Ultimately, I had a minor error in one of the authentication parms. I found it by Base64-decoding the auth value in Google’s example and comparing it to my own traces.

This would have been a quick fix if CCS had just given an authentication error message rather than just slamming the door. It must be a security thing. Oh well, on to the next adventure.

Smackdowns 

No response from the server.: 
	at org.jivesoftware.smack.NonSASLAuthentication.authenticate(NonSASLAuthentication.java:73)
	at org.jivesoftware.smack.SASLAuthentication.authenticate(SASLAuthentication.java:357)
	at org.jivesoftware.smack.XMPPConnection.login(XMPPConnection.java:221)

java.net.SocketException: Connection closed by remote host
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.checkWrite(Unknown Source)
	at com.sun.net.ssl.internal.ssl.AppOutputStream.write(Unknown Source)
	at sun.nio.cs.StreamEncoder.writeBytes(Unknown Source)
	at sun.nio.cs.StreamEncoder.implFlushBuffer(Unknown Source)
	at sun.nio.cs.StreamEncoder.implFlush(Unknown Source)
	at sun.nio.cs.StreamEncoder.flush(Unknown Source)
	at java.io.OutputStreamWriter.flush(Unknown Source)
	at java.io.BufferedWriter.flush(Unknown Source)
	at org.jivesoftware.smack.util.ObservableWriter.flush(ObservableWriter.java:48)
	at org.jivesoftware.smack.PacketWriter.writePackets(PacketWriter.java:168)

java.io.EOFException: no more data available - expected end tag  to close start tag  from 
                                      line 1, parser stopped on END_TAG seen ...... @1:344
	at org.xmlpull.mxp1.MXParser.fillBuf(MXParser.java:3035)
	at org.xmlpull.mxp1.MXParser.more(MXParser.java:3046)
	at org.xmlpull.mxp1.MXParser.nextImpl(MXParser.java:1144)
	at org.xmlpull.mxp1.MXParser.next(MXParser.java:1093)
	at org.jivesoftware.smack.PacketReader.parsePackets(PacketReader.java:279)

I’ve been waiting months for a “ready for prime time” version of Android Studio. Its move from “Preview” to “Beta” (version 0.8) on June 26 became my signal to dive in deep and use it for real work. After all “beta” in Google terms usually means a level of quality some products don’t achieve with years of “GA” releases.

Android Studio inherits many of its benefits from IntelliJ. I like the speed and stability, the quality of the development and rendering tools, the productivity, the rich static code analysis, and all the other benefits that come from its IntelliJ underpinnings.  I’ve bounced back and forth between Eclipse keymaps and IntelliJ defaults, but settled on the IntelliJ’s, with the cheat sheet on hand. “When in Rome,” don’tchaknow, although I haven’t yet joined the Darcula side. Even from a few days’ use, I’m sold on IntelliJ and certainly don’t miss Eclipse’s crashes and stalls.

I’m also pleased with the Gradle-based build system and AAR support. After fighting with Maven plugin bugs, apklib hacks, and other Eclipse-Maven clashes, it’s refreshing to have a build system that is elegant, is backed by Google, and just works. The factoring of content across build.gradle files, manifests, etc., is clean and DRY, and the Android-specific checks guide you toward best practices.

The main downside is that there is no automatic nor incremental build as with Eclipse, so builds are slower and many errors aren’t discovered during editing. Build speed will likely improve as it exits beta (perhaps with the help of parallel builds), but the rest is just the IntelliJ way.

Still, I’m happy with both IntelliJ and the Android Studio so far. Now if I could only switch from MyEclipse to IntelliJ for server-side code…

I recently needed to add an inactivity timer to a pair of new apps. If the user was logged in but inactive past a configurable period, the app should display an error when resumed and return to the login screen. It must be non-intrusive and not interrupt any foreground apps. It could not require a background service.

For Android, this fit well into the standard activity architecture. In particular, well-behaved activities should normally remain quiet when paused and should finish themselves rather than be killed by some other activity.  So I created the following simple utility class to enable this.  The primary hooks are:

• initialize – Called when the first (main) activity starts.
• startMonitoring – Called when the user logs in.
• monitor – Called from each activity’s onResume.  I added it to my common fragment superclass.

It also has an optional requestExit to request an immediate exit based on some other criteria.

The deus ex machina is the simple activity.finish().  This ripples through all active activities so that they politely exit whenever the sShouldExitNow flag is set.

public class UserActivityMonitor {
 
    private static long sUserTimeoutMillisecs = 5 * 60 * 1000;	// Default to 5 minutes
    private static boolean sIsMonitoring = false;
    private static boolean sShouldExitNow = false;
    private static long sLastActionMillisecs = 0;
 
    /**
     * Initialize monitoring. Called at app startup.
     */
    public static void initialize(long timeoutMillisecs) {
        sUserTimeoutMillisecs = timeoutMillisecs;
        sIsMonitoring = false;
        sShouldExitNow = false;
        sLastActionMillisecs = 0;
    }
 
    /**
     * Start monitoring user activity for idle timeout.
     */
    public static void startMonitoring() {
        sIsMonitoring = true;
        sLastActionMillisecs = System.currentTimeMillis();
    }
 
    /**
     * The given activity is at the foreground.
     * Record the user's activity and, if necessary, handle an exit or timeout request.
     * If timed out, start the postTimeoutActivity (if provided) on a new task.
     */
    public static void monitor(Activity currentActivity, Intent postTimeoutActivity) {
        if (sShouldExitNow) {
            // Calls here will ripple through and finish all activities
            currentActivity.finish();
        } else {
            if (sIsMonitoring) {
                checkForIdleTimeout(currentActivity, postTimeoutActivity);
            }
        }
        sLastActionMillisecs = System.currentTimeMillis();
    }
 
    /**
     * Request to exit the app by triggering all activities to finish.
     */
    public static void requestExit() {
        sShouldExitNow = true;
    }
 
    /**
     * Check for an inactivity timeout.
     * If we have timed out, display a message, finish the activity,
     * and set the "should exit now" flag so that other activities quit.
     * If timed out, start the postTimeoutIntent (if provided) on a new task.
     */
    private static void checkForIdleTimeout(final Activity activity,
                                            final Intent postTimeoutIntent) {
        if (User.getCurrentUser().isLoggedIn() && sLastActionMillisecs > 0) {
            long idleMillisecs = System.currentTimeMillis() - sLastActionMillisecs;
            if (idleMillisecs > sUserTimeoutMillisecs) {
                // The first time we detect a timeout, display a popup message
                UiUtils.showError(activity.getString(R.string.msg_timeout),
                        activity.getString(R.string.msg_timeout_title), activity, 
                         new IErrorDisplayListener() {
                            @Override
                            public void onResponse(int buttonClicked) {
                                sShouldExitNow = true;
                                activity.finish();
                                if (postTimeoutIntent != null) {
                                    postTimeoutIntent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK |
                                            Intent.FLAG_ACTIVITY_CLEAR_TASK);
                                    activity.startActivity(postTimeoutIntent);
                                }
                            }
                        });
            }
        }
    }
}

After many Android app versions with perfectly-good icons, it came time to replace them: new launcher icons, new store listing graphic, new action bar icons, and in some cases, removing the icon from the action bar altogether.

For the latter, I preferred an easily-customized manifest entry:

android:icon=”@color/transparent”

This worked nicely for local and ad-hoc installs. So I was surprised when publishing to the Google Play store failed with the obscure yet common error:

Your APK cannot be analyzed using ‘aapt dump badging’.  Error output:

Failed to run aapt dump badging: Error getting ‘android:icon’ attribute: attribute is not a string value

You wouldn’t know it from the message nor from any online suggestions, but that @color/transparent trick was the root cause. So instead I created a 1×1 transparent PNG (ic_empty.png) and used it instead:

android:icon=”@drawable/ic_empty”

BTW, when it’s “icon update” time, I’ve found the quickest way to get scaled icons is to create the 512×512 web version, and point the New Android Application wizard at it.  It’ll create the mdpi, hdpi, xdpi, and xxhdpi sizes for you.

The recent 22.6 Android Developer Tools (ADT) update broke quite a few things: AVD creation and editing, ProGuard, performance, etc.  Rather than revert to 22.3 like many folks, I decided to muddle through with some work-arounds and hold out for the fixes in 22.6.1.

Well, 22.6.1 has arrived and at least fixed the AVD issues, but ProGuard still fails with:

Error: Unable to access jarfile ..\lib\proguard.jar

Fortunately, working around that bug is easy: simply edit proguard.bat and provide an absolute path to the JAR.

Enabling Up (ancestral) navigation in Android apps is straightforward for the typical case: just specify parent activities in the manifest and send setDisplayHomeAsUpEnabled(true). But non-typical cases (like dynamic parents) require extra steps.

Today I implemented some non-typical cases and experimented with overriding action bar callbacks, tweaking the back stack, etc. But in most cases I simply wanted up navigation to behave like back navigation whenever there was no fixed parent defined. For that, I developed a simple recipe:

@Override
public boolean onOptionsItemSelected(MenuItem item) {
	switch (item.getItemId()) {
		case android.R.id.home:
			if (NavUtils.getParentActivityName(getActivity()) != null) {
				NavUtils.navigateUpFromSameTask(getActivity());
			} else {
				getActivity().onBackPressed();
			}
			return true;
		default:
			return super.onOptionsItemSelected(item);
	}
}