Add callbacks for AppLifecycleState's to StoreConnector

[jimsimon]

So far tying into application lifecycle events has been the only thing I've needed to create StatefulWidgets for. It'd be great if the StoreConnector allowed specifying suspend and resume functions that are called with the viewmodel passed to them (similar to onInitialBuild).

Something along the lines of...

  @override
  void initState() {
    super.initState();
    WidgetsBinding.instance.addObserver(this);
  }

  @override
  void dispose() {
    WidgetsBinding.instance.removeObserver(this);
    super.dispose();
  }

  @override
  void didChangeAppLifecycleState(AppLifecycleState state) {
    if (state == AppLifecycleState.resumed) {
      widget.onResumed(latestValue);
    } else if (state == AppLifecycleState.inactive) {
      widget.onInactive(latestValue);
    } else if (state == AppLifecycleState.paused) {
      widget.onPaused(latestValue);
    } else if (state == AppLifecycleState.suspending) {
      widget.onSuspending(latestValue);
    } 
  }

Another option would be to just add didChangeAppLifecycleState and have it be passed the viewmodel:

  @override
  void didChangeAppLifecycleState(AppLifecycleState state) {
    widget.didChangeAppLifecycleState(state, latestValue);
  }

The main use case I have for using these events is for activating a lock screen when the user navigates away from the app. I suspect another use case might include refreshing data when the app is resumed. Right now I'm forced to pass the store down to any widget that needs to use it in didChangeAppLifecycleState it via constructor parameter or use StoreProvider.of(context). Ideally I'd be able to use my viewmodel instead.

[jimsimon]

If you're open to adding this feature I can open a PR for it. Feel free to close the issue if not and I'll just create a separate utility for it.

[brianegan]

Hey hey -- sorry, somehow missed this message chain :/

Hm, I can see how this is helpful, but I think we might want to be precise about the implementation.

For example, if every StoreConnector suddenly becomes a WidgetsBindingObserver, will that cause any perf issues? That might require registering a LOT more Widgets as WidgetsBindingObservers than need be.

I could see two options:

1. Provide a specific storeconnector with this extra functionality
2. Create a specific State class depending on the situation (if they pass through ANY of those callbacks, then create a State class that uses WidgetsBindingObserver, otherwise use the current implementation). The only tricky thing with that: What if someone goes from NOT providing a callback to providing a callback! The createState method would have already run and produced a State class that does not include the WidgetBindingsObserver stuff.

Thanks for the suggestion! What are your thoughts?

[brianegan]

Hey all, Gonna close this one out for now, but happy to reopen if more folks would like this functionality!