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 Widget
s.
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 Widget
s since everything is a widget in Flutter. Use a Navigator
to move between different Route
s 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 toonPause()
in Android. -
resumed
— The application is visible and responding to user input. This is equivalent toonPostResume()
in Android. -
suspending
— The application is suspended momentarily. This is equivalent toonStop
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()));
}