[Module] AppState - Behavior Completion

[kikisaints]

AppState is the API in ReactNative that detects whether or not the app has focus (is in Foreground vs Background).

Today's Behavior on Desktop:

• active
  App is running and has focus
  App is running and does not have focus
• background
  App is running and minimized
• inactive
  Does not occur. Default scenarios where this would get triggered are Mobile-specific

Proposed Changes to Behavior on Desktop

• active
  App is running and has focus
• background
  App is running and minimized
  App is running and does not have focus
  App is running but alt-tab is being preformed
• inactive
  *Occurs when Task View is opened
  *Start menu is opened in Tablet mode

*Need to review ones with respective team and key scenario owners.

Reasoning

There are essentially 6 different states that an app can be when on desktop as opposed to mobile's 4:

(RBG is the app who's AppState we are concerned about in these examples)

• Active
  

• Not minimized, but does not have focus (another window does)
  

• Not minimized, but does not have focus (alt-tab menu does)
  

• Minimized
  

• Inactive because Task View is open
  

• Inactive in Tablet mode when Start Menu is open
  (image coming)

[MikeHillberg]

I think background conceptually maps more to the background and suspending states.

[ahimberg]

Today's behavior should be background = suspended, otherwise active. I think it might make sense to use the inactive state to mean non-active window (and not yet suspended), so apps can hook to 'active' to know they're the foreground window. OR they'll need some other way to know when they're not the active window

[MikeHillberg]

You can't actually check to see if you're in the suspend-ed state, because that requires CPU, and your threads are frozen or gone. You can ask if you're in the suspend-ing state though.

Why wouldn't an app running as background show up as background?

There's three states of an inactive window: not minimized, minimized, and task switcher. In which of these do you want to do something in app code?

[MikeHillberg]

Kiki Saintonge (@kikisaints), about terminology, we shouldn't say "active, but does not have focus". In Windows the definition of "active" means "has focus".

[ahimberg]

Right, you don't check if you're in the suspended state, but you're notified right before suspend happens. The uwp AppState module right now uses EnteredBackground/LeavingBackground events. Though I wanted to add some code to change the state to inactive when not the foreground window.

In Outlook on suspend we flush things to disk in case we get terminated after suspend. On resume (leaving suspend) we reopen connections with the server to start syncing again. And when foreground our sync engine is more aggressive (and when we have separate mail/calendar windows or modules, the one in the foreground gets priority on syncing the type of data you can see if its mail or calendar data)

[kikisaints]

MikeHillberg I fixed the terminology to be "not minimized" and simply "Active" for the others.

For this particular issue, it is more of a proposal. We don't have a tag for that yet, but I wanted to bring attention to the fact that we have many more states on desktop that we may want AppState to know about.

The proposed behavior is definitely subject to change based on what we think is better/right for the scenarios - it may also be good to have a short pitch meeting equivalent for this. Harini Kannan (@harinikmsft) thoughts?

[MikeHillberg]

Kiki Saintonge (@kikisaints), yes, I get it's an investigation and proposal, and it's great.

Andy Himberger (@ahimberg), I think we're confusing Suspending and Background. The Suspending event means your threads are going to be frozen in the next 5-7 seconds, and maybe your process terminated. The EnteredBackground event means you're app is changing from foreground to background, but will keep running there (like a Podcast app that keeps playing when you close the app window).

Inactive meaning not active but foreground makes sense to me.