Fwd: [mojo] Change IntentReceiver from a Service to a non-UI activity (#368)

[Jeff Brown]

Sending this to a larger audience since some important things came up on this thread.

Mojo services right now aren't tied to any real kind of context.  That's a problem if they want to interact with the user because there's no way of knowing how to even reach the user.  (Which display would it even show a dialog on?)

And in any case, popping up dialogs at arbitrary times creates a poor user experience.  I'm sure we've all been frustrated by this on desktop platforms before.

Android solves this problem in many situations by using Activities and Notifications as the starting point for user interactions.  Although Android Services can show UI (yes, even pop-up dialogs), they are strongly discouraged from doing so and we've actively clamped down on their ability to do so over the years.  This may not be the best design overall -- and it certainly has its annoying constraints -- but we have found the basic idea to be quite valuable.

So when designing new Mojo services that require user interaction, think a bit about how we will associate that user interaction with some meaningful context based on what the user is currently doing...

(We're probably going to need some new design patterns for Mojo services.)

Jeff.

---------- Forwarded message ---------
From: Jeff Brown <jeff...@google.com>
Date: Thu, Aug 13, 2015 at 9:50 AM
Subject: Re: [mojo] Change IntentReceiver from a Service to a non-UI activity (#368)
To: domokit/mojo <reply+00018f84882c7ffecbd3e13335ffe26bc4b4ea9...@reply.github.com>, domokit/mojo <mo...@noreply.github.com>

So what I am saying is basically that we're doing it wrong.  The authentication is intentionally tied to the currently running activity because it might need to show some UI and we don't want dialogs popping up randomly with no obvious link to their cause.

The idea is that the user is in an app, does something that needs auth, the app starts the auth activity, auth gets pushed on the stack, auth does its thing, then returns a result back to the app.  startActivityForResult() is like a UI based subroutine call.

Android has deliberately tied these things together so that the user has some context for the prompt which is about to appear.  It's similar for optional permissions too and many other APIs.

For Mojo too we will have to give some thought to how we empower and inform the user through interactions of this sort.  Stuff needs some kind of context.  The fact we aren't doing that in Mojo is a bug.  :)

(FWIW, the bytesToIntent function is problematic.  Intents are not intended to be serialized like that since they may contain binder objects.)

Jeff.

On Thu, Aug 13, 2015, 5:17 AM Etienne Membrives <notifi...@github.com> wrote:

Closed #368 via e190705.

—
Reply to this email directly or view it on GitHub.