Year: 2015

Code for detecting when you leave an Android app

Further to Detecting whether an Android app is stopping (or starting), I implemented code to decide when you are leaving or entering my game Rabbit Escape.

The relevant class is called Lifecycle2SoundEvents. (Yes, it’s a terrible name. Yes, I spent a long time trying to name it, and this is the best I came up with.)

And the tests, which are in TestLifecycle2SoundEvents, look like this:

@Test
public void Press_the_home_button_api10_causes_pause()
{
    Tester t = new Tester( activity1 );

    t.in.onSaveInstanceState( activity1 );
    t.in.onPause( activity1 );
    t.in.onStop( activity1 );

    // When we press home, we must at least pause (really we stop)
    t.assertPaused();
}

which I was reasonably pleased with, because they match my original blog post Order of Android Activity lifecycle events fairly well, without too much noise.

Mocks are Bad, Layers are Bad

In which I argue that mocks are a code smell, and layers lead to increased coupling:

Mocks are Bad, Layers are Bad (in ACCU‘s Overload Journal issue 127)

I also suggest some ways to avoid both mocks and layers, including Classical TDD, Selfish Object, Refactor to Functional and, of course, the Unix Philosophy. I work through a code example to demonstrate some of these things.

I also suggest that frameworks and inheritance hierarchies are bad, but the title was getting too long already.

You can also get the PDF of Overload 127.

Prediction result: corporate Linux

Ten years ago I predicted that 30% of corporate desktops would be Linux or similar open source desktops.

It’s very hard to find any accurate (or even confident) numbers, but it seems clear I was wrong.

This month, NetMarketShare puts Linux usage at 1.28%, and w3schools puts Linux usage at 5.2%.

I think companies almost certainly use Linux more than home consumers. Certainly, my own company has a very large section of its population using Linux – all users who have access to sensitive information are required to use it to increase security.

But, I would be very surprised if levels were at 30%.

Linux desktop usage does continue to creep upwards though, while everyone is distracted looking at phones and tablets. At some time there may be a tipping point.

Detecting whether an Android app is stopping (or starting)

I am writing an Android app (called Rabbit Escape), and I want it to start playing music when the user enters the app, and stop when the user leaves.

Not as easy as it sounds because Android largely doesn’t think in apps, but Activities.

Update: real-life code for this is here: Code for detecting when you leave an Android app.

In my previous post Order of Android Activity lifecycle events I tracked the methods that get called on activities on my two test devices when the user does various actions. There was some variation between devices, but we can determine some useful rules.

First, let’s enumerate what we need to detect.

The user leaves by:

  • pressing “home” at any time
  • pressing the power button when the app is running
  • pressing “back” when in the first activity
  • launching an external activity (e.g. web browser)

The user enters by:

  • starting the app (e.g. from the home page, or the “running apps” panel)
  • pressing the power button when the app has been suspended
  • pressing “back” when in an external activity launched by us

From the previous post we can work out these rules:

  • When the user is entering, onResume is always called (on the activity that will be current)
  • When the user is leaving, onStop is always called (on the current activity), except when pressing the power button (to turn off) where you may only see an onPause call.
  • When the user is moving between activities, onResume is always called on the new activity, and onStop is always called on the old one. The onResume call is always before onStop

Thus, if we are OK with leaving ourselves running when the power button is pressed, we can detect leaving and entering the app using the code below.

If we need to stop something when the power button is pressed too, it seems we must be prepared to stop it when we receive onPause, and immediately restart it if we receive onResume, hoping that doesn’t cause a problem (e.g. a break in the music).

// All activities have these two methods:
@Override
public void onResume()
{
    super.onResume();
    LeavingOrEntering.activityResumed( this );
}

@Override
public void onStop()
{
    super.onStop();
    LeavingOrEntering.activityStopped( this );
}

// And we detect leaving and entering like this:
class LeavingOrEntering
{
    private static Activity currentActivity = null;

    public static void activityResumed( Activity activity )
    {
        if ( currentActivity == null )
        {
            // We were resumed and no-one else was running.
            notifyEntering() // Start the music!
        }
        currentActivity = activity;
    }

    public static void activityStopped( Activity activity )
    {
        assert currentActivity != null;

        if ( currentActivity == activity )  
        {
            // We were stopped and no-one else has been started.
            notifyLeaving(); // Stop the music!
        }
        currentActivity == null;
    }
}