Activities and fragments

What are the equivalent of activities and fragments in Flutter?

In Android, an Activity represents a single focused thing the user can do. A Fragment represents a behavior or a portion of user interface. Fragments are a way to modularize your code, compose sophisticated user interfaces for larger screens, and help scale your application UI. In Flutter, both of these concepts fall under the umbrella of Widgets.

To learn more about the UI for building Activities and Fragements, see the community-contributed medium article, Flutter For Android Developers : How to design an Activity UI in Flutter.

As mentioned in the Intents section, screens in Flutter are represented by Widgets since everything is a widget in Flutter. Use a Navigator to move between different Routes that represent different screens or pages, or maybe just different states or renderings of the same data.

How do I listen to Android activity lifecycle events?

In Android, you can override methods from the Activity to capture lifecycle methods for the activity itself, or register ActivityLifecycleCallbacks on the Application. In Flutter, you have neither concept, but you can instead listen to lifecycle events by hooking into the WidgetsBinding observer and listening to the didChangeAppLifecycleState() change event.

The observable lifecycle events are:

• inactive — The application is in an inactive state and is not receiving user input. This event only works on iOS, as there is no equivalent event to map to on Android.
• paused — The application is not currently visible to the user, not responding to user input, and running in the background. This is equivalent to onPause() in Android.
• resumed — The application is visible and responding to user input. This is equivalent to onPostResume() in Android.
• suspending — The application is suspended momentarily. This is equivalent to onStop in Android; it is not triggered on iOS as there is no equivalent event to map to on iOS.

For more details on the meaning of these states, see the AppLifecycleStatus documentation.

As you might have noticed, only a small minority of the Activity lifecycle events are available; while FlutterActivity does capture almost all the activity lifecycle events internally and send them over to the Flutter engine, they’re mostly shielded away from you. Flutter takes care of starting and stopping the engine for you, and there is little reason for needing to observe the activity lifecycle on the Flutter side in most cases. If you need to observe the lifecycle to acquire or release any native resources, you should likely be doing it from the native side, at any rate.

Here’s an example of how to observe the lifecycle status of the containing activity:

import 'package:flutter/widgets.dart';

class LifecycleWatcher extends StatefulWidget {
  @override
  _LifecycleWatcherState createState() => _LifecycleWatcherState();
}

class _LifecycleWatcherState extends State<LifecycleWatcher> with WidgetsBindingObserver {
  AppLifecycleState _lastLifecycleState;

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

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

  @override
  void didChangeAppLifecycleState(AppLifecycleState state) {
    setState(() {
      _lastLifecycleState = state;
    });
  }

  @override
  Widget build(BuildContext context) {
    if (_lastLifecycleState == null)
      return Text('This widget has not observed any lifecycle changes.', textDirection: TextDirection.ltr);

    return Text('The most recent lifecycle state this widget observed was: $_lastLifecycleState.',
        textDirection: TextDirection.ltr);
  }
}

void main() {
  runApp(Center(child: LifecycleWatcher()));
}