You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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?
Kiki Saintonge (@kikisaints), about terminology, we shouldn't say "active, but does not have focus". In Windows the definition of "active" means "has focus".
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)
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?
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.
Last we landed on this, if I'm remembering correctly, was that it was out of scope for the initial "standing up" of RNW (meaning version 0.58-0.59) but I think I could go for a second pitch for this - thoughts?
Last we landed on this, if I'm remembering correctly, was that it was out of scope for the initial "standing up" of RNW (meaning version 0.58-0.59) but I think I could go for a second pitch for this - thoughts?
Yep, that all makes sense. I think this is just not implemented, but I wasn't sure if there were changes desired to AppState to capture the additional events a UWP might require. If not, you can clear your assignment and "needs PM design" and we'll queue this up for dev.
Activity
MikeHillberg commentedon Mar 13, 2019
I think background conceptually maps more to the background and suspending states.
ahimberg commentedon Mar 14, 2019
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 commentedon Mar 14, 2019
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 commentedon Mar 14, 2019
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 commentedon Mar 14, 2019
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 commentedon Mar 14, 2019
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 commentedon Mar 14, 2019
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.
3 remaining items
kikisaints commentedon Sep 28, 2020
Chris Glein (@chrisglein) I don't think this was implemented yet, but it is a React Native Core feature so we should probably support it.
Last we landed on this, if I'm remembering correctly, was that it was out of scope for the initial "standing up" of RNW (meaning version 0.58-0.59) but I think I could go for a second pitch for this - thoughts?
chrisglein commentedon Sep 28, 2020
Yep, that all makes sense. I think this is just not implemented, but I wasn't sure if there were changes desired to AppState to capture the additional events a UWP might require. If not, you can clear your assignment and "needs PM design" and we'll queue this up for dev.