Handle app lifecycle events: `Pause`, `Resume`, etc

[kevinaboos]

• [ ] On Event::Pause and Event::Resume, save and restore the state of the dock
  • This part is waiting on #422 to be merged in.
  • Only if desktop view is active. We don't need to do this for mobile view
• [ ] On Event::Resume, we should do a full app redraw to ensure that all elements get re-drawn.
  • Pause and Resume are only delivered on mobile. So for desktop platforms, we need to perform the full app redraw on the Foreground event.

[WaterWhisperer]

Hi @kevinaboos ,

I'm a new contributor learning Rust and I'd like to try to work on this issue! I've implemented the handling for the Pause, Resume, and Foreground lifecycle events.

I have a quick question regarding a potential contradiction in the requirements for the Pause event. The issue description states:

On Event::Pause ... save ... the state of the dock

• Only if desktop view is active. We don't need to do this for mobile view

It also mentions:

• Pause and Resume are only delivered on mobile.

This is a bit confusing, as the Pause event is mobile-only, but the condition to save state seems to be related to a "desktop view".

My understanding is that the main goal here is to save the state on mobile platforms when the app is paused to prevent data loss. Based on that, my current implementation saves the app state on the Pause event, specifically for mobile platforms.

Here is a screenshot and snippet of my implementation:

Could you please confirm if my approach is correct, or if I misunderstood the requirement about the "desktop view"?

Thank you for your guidance!

[kevinaboos]

Hi @WaterWhisperer, thanks for the comment/question, and welcome! Apologies for the delay in my response, I'm traveling this week (attending the Matrix conference, coincidentally).

This is a bit confusing, as the Pause event is mobile-only, but the condition to save state seems to be related to a "desktop view".

Ah, so Pause may end up occurring on desktop platforms too, depending on how we implement it within Makepad. Currently I don't think it does trigger on desktop platforms, but it could in the future. In any case, there shouldn't be any difference in how we handle the Pause even, whether or not it occurs on mobile.

Also, while we refer to the two different view modes as "desktop" and "mobile", they should really be called "wide-screen" and "narrow-screen", since it is possible to have both views be shown on both desktop & mobile platforms. For example, if you shrink the window to be narrow on macOS, you'll get the narrow "mobile" view, and similarly if you have an Android foldable/table or an iPad, you'll get the widescreen "desktop" view. Sorry for the confusion there.

So, you shouldn't need any platform-specific cfg here; in general we don't want any platform-specific code within Robrix at all.

My understanding is that the main goal here is to save the state on mobile platforms when the app is paused to prevent data loss.

Yep, exactly right! I would say that applies to not just mobile but all platforms.

Based on that, my current implementation saves the app state on the Pause event, specifically for mobile platforms.

That's a good start. The only issues I see with your current implementation are:

1. We don't want it to be only done on Android, but rather on all platforms.
2. We'd also want to actually restore the state that we saved during the Pause event too.

Also, an implicit part of this issue is testing (and potentially modifying) Makepad to ensure that the Pause and Resume events actually get delivered on all platforms. Personally I have only tested them out on Android, but we would also want to ensure those events occur on iOS. Of course you don't personally have to tackle that yourself, but it's something I'd like to be covered by this issue in general.

Another aspect of this would be to (ideally) avoid redundantly saving/restoring the same app state multiple times. This would entail tracking when we have saved/restored the app state in order to determine if it's necessary to save/restore it again in the next lifecycle event. For example, the Shutdown and Background events are not always guaranteed to be fired by the underlying Android system, so of course we have to save the state proactively within the Pause event. However, if those events do end up being fired, we would want to skip re-saving the whole app state again if nothing has changed between the first save during Pause and the subsequent Background or Shutdown events. And then the same logic should be applied for restoring state in the Foreground and Resume events too.

[kevinaboos]

Oh, and I forgot about the main thing we also want to do on certain lifecycle events: stop and start the sync service.

[WaterWhisperer]

Hi @kevinaboos,

Thank you for the detailed explanation! I've updated the implementation based on your feedback:

• Saves state on Pause and stops sync service
• Restores state on Resume/Foreground and restarts sync service
• Avoids duplicate saves in Background/Shutdown if already saved

I'll submit a PR shortly. Note: I don't have access to iOS devices for testing, but the code should work uniformly across platforms as intended.

Thanks again for your guidance!