Exported Activities and Freeform Multi-Window Mode
I like to think that I’m pretty good about identifying the scary bits of these developer previews. But, sometimes I miss things, ignoring the ramifications of some warnings.
Ian Lake’s multi-window blog post hammered home one such warning. He first quoted the N Developer Preview docs:
If you launch an activity within a task stack, the activity replaces the activity on the screen, inheriting all of its multi-window properties. If you want to launch the new activity as a separate window in multi-window mode, you must launch it in a new task stack.
…and then he clarified it for people like me who missed the implication:
That means if you have an Activity that can be started by other apps, your activity will inherit the same multi-window properties as the calling Activity. This includes attributes such as minimal size.
So:
-
If you launch a third-party activity, and neither you nor that other activity start a new task for that activity, that activity is part of your task and works within the window for that task
-
If your exported activity is launched by third-party, and neither you nor that other activity start a new task for you, you will be part of that other task and you will reside in the window for that task
This does not seem so strange in practice when using split-screen mode on mobile devices. There, we are used to other activities taking over the whole screen, and saying that they now take over just our half of the screen does not seem that unusual.
IMHO, it looks far more strange in freeform multi-window mode. This is not officially released yet, but there are instructions floating around the Internet for how to get an Android N emulator or rooted device to support freeform multi-window mode.
For example, suppose that you need to have the user go into Settings to
configure something related to your app (e.g., make your app be a device
administrator). In a traditional desktop OS, if you needed to perform
an equivalent action — such as opening up the Windows Control Panel —
the result would be a separate window for that third-party app. But, by
default, opening up Settings opens it up in the window used by your
app. If you are the one starting the third-party activity, you can
steer it into its own window using FLAG_ACTIVITY_LAUNCH_TO_ADJACENT
and FLAG_ACTIVITY_NEW_TASK… but not everybody who launches a third-party
activity will think to do this. This is particularly true since,
at the moment, we do not have a way of determining if our app is in
a freeform multiwindow environment or not.
Worse, this behavior means that the controls offered by Android N for your window — such as saying that your activity is not resizeable — are not guaranteed for exported activities. If you wind up in another app’s window, your activity will be sized for that window, whether you like it or not.
If you have exported activities, ideally they support windows of all shapes and sizes. If that is impractical for your particular activity, you will need to decide what to do: change your UI/UX to accommodate windows of varying sizes, try to use task-related manifest attributes to ensure that you get a fresh window that meets your criteria, or find worse hacks that cajole Android into giving you a fresh window.
My sincere hope is that official freeform multi-window support is not that far away, such as perhaps around the time of Google I|O. I am hesitant to place a lot of stock in what I am seeing in the hacked-in freeform multi-window stuff on an Android N emulator. Freeform multi-window — a.k.a., “Android on the desktop” — bodes to be the biggest UI/UX change in Android since the advent of the tablet. Even if Android does an admirable job of covering most of the behavior without code changes, we need time to work out patterns for edge cases, such as exported activities.
In the meantime, pay close attention to when Google announces official freeform multi-window support, then budget the time necessary to ensure that your users will get a quality experience in that mode.
