Android app is closing before mixpanel can flush

Question

You have to call flush() in your Activity onDestroy()

Like this:

@Override
protected void onDestroy() {
    mMixpanel.flush();
    super.onDestroy();
}

Notice you call flush() before calling super.onDestroy();, otherwise the activity lifecycle will continue and your call might never be on time, this way the destroy process will at least start after the flush.

It works for me.

It's kinda clumsy (MixPanel should have done a better job) because you might not know what activity the user is leaving your app from and to counteract that problem you have to put that code in your base activity (inherited by all your activities) therefore, causing a flush every time you change activities, which -in turn- defeats the purpose of queueing events…

UPDATE: It's true that the last events may not be flushing even tho Mixpanel recommends to do the above (they probably never thought about it, but since the SDK is open source, we might want to take a look)

In spite of Mixpanel's quality, I recommend calling flush() as early as possible. You can even call flush in the onStop() method of every activity (before super.onStop()) and that way you make sure each Activity flushes its events every time it's stopped.

Although this may defeat the purpose of the mixpanel network friendly queuing, it may e the only way (without resorting to strange hacks) to keep the events synced.

Because of all this, I took a look at mixpanel's source code (which I had checked out) and they also have a method to define the flush frequency:

/**
     * Sets the target frequency of messages to Mixpanel servers.
     * If no calls to {@link #flush()} are made, the Mixpanel
     * library attempts to send tracking information in batches at a rate
     * that provides a reasonable compromise between battery life and liveness of data.
     * Callers can override this value, for the whole application, by calling
     * <tt>setFlushInterval</tt>.
     *
     * @param context the execution context associated with this application, probably
     *      the main application activity.
     * @param milliseconds the target number of milliseconds between automatic flushes.
     *      this value is advisory, actual flushes may be more or less frequent
     */
    public static void setFlushInterval(Context context, long milliseconds);

Maybe reducing this number might help.

The default value seems to be:

// Time interval in ms events/people requests are flushed at.
public static final long FLUSH_RATE = 60 * 1000;

What flush() does, is just post a message to the worker thread always running.

The Worker thread intercepts this here:

else if (msg.what == FLUSH_QUEUE) {
      logAboutMessageToMixpanel("Flushing queue due to scheduled or forced flush");
      updateFlushFrequency();
      sendAllData();
   }

After updating the FlushFrequency (based upon the current systemTime), it sends the data using HTTP.

I can see why if your main process is dying (last activity) this code may not execute in time…

Last but not least, if you switch to use the library in source code (as opposed to just using the jar), you can change in MPConfig the value of:

public static final boolean DEBUG = false;

to get a lot of logging (among those are the flushes and posts to server). Might help to see what events are actually being sent to the server (and when).

There is also an upper limit to the number of queued items before que queue is forced to flush:

// When we've reached this many track calls, flush immediately
public static final int BULK_UPLOAD_LIMIT = 40;

This is seen in the queue code:

if (queueDepth >= MPConfig.BULK_UPLOAD_LIMIT) {
   logAboutMessageToMixpanel("Flushing queue due to bulk upload limit");
   updateFlushFrequency();
   sendAllData();
}

Good luck :)