Lifecycle diagram incorrect - onGameResize called before onLoad

[jlyonsmith]

Current bug behavior

onGameResize is called before onLoad. This is different from what the lifecycle diagram shows.

Expected behavior

onGameResize is called before onLoad. This is important to know as the documentation implies that you can use onLoad to initialize components

Steps to reproduce

Add the following code to any with FlameGame class:

  @override
  void onMount() {
    debugPrint('onMount');
    super.onMount();
  }

  @override
  void onGameResize(Vector2 size) {
    debugPrint('onGameResize');
    super.onGameResize(size);
  }

  @override
  Future<void>? onLoad() async {
    debugPrint('onLoad');
    await super.onLoad();
  }

Observe the sequence of output:

Restarted application in 344ms.
flutter: onGameResize
flutter: onLoad
flutter: onMount

Flutter doctor output

❯ flutter doctor -v
[✓] Flutter (Channel stable, 3.13.0, on macOS 13.4.1 22F770820d darwin-arm64, locale en-US)
    • Flutter version 3.13.0 on channel stable at /Users/john/Projects/flutter/flutter
    • Upstream repository git@github.com:flutter/flutter.git
    • Framework revision efbf63d9c6 (9 days ago), 2023-08-15 21:05:06 -0500
    • Engine revision 1ac611c64e
    • Dart version 3.1.0
    • DevTools version 2.25.0

[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.1)
    • Android SDK at /Users/john/Library/Android/sdk
    • Platform android-33, build-tools 33.0.1
    • ANDROID_HOME = /Users/john/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 14.3.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 14E300c
    • CocoaPods version 1.11.3

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2022.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)

[✓] VS Code (version 1.81.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.70.0

[✓] Connected device (3 available)
    • iPhone 14 Pro (mobile) • 5138CE7C-4E9A-4F03-90C7-5A0C7911ED73 • ios            •
      com.apple.CoreSimulator.SimRuntime.iOS-16-4 (simulator)
    • macOS (desktop)        • macos                                • darwin-arm64   • macOS 13.4.1 22F770820d
      darwin-arm64
    • Chrome (web)           • chrome                               • web-javascript • Google Chrome 115.0.5790.114

[✓] Network resources
    • All expected network resources are available.

• No issues found!

More environment information

• Flame version: ^1.8.1
• Platform affected: ios
• Platform version affected: ios 14

Log information

None.

More information

I'd be happy to update the lifecycle diagram.

[spydon]

True, good catch!
That is actually the Component lifecycle. So the correct lifecycle (which is also verified in our tests) is:

          'onGameResize',
          'onLoad',
          'onMount',
          'update',
          'render',
          'onRemove',
          'onGameResize',
          'onMount',
          'update',
          'render',

I'd be happy to update the lifecycle diagram.

I'll assign you to the issue. :)

[jlyonsmith]

Hey @spydon I changed the diagram, and I thought I would write a simple program to validate the call sequence. What I'm seeing is the following:

          'onGameResize',
          'onLoad',
          'onMount',
          'render',
          'update',
          'onGameResize',
          'onRemove',
          'onLoad',
          'onMount',
          'render',
          'update',

This doesn't align with what you describe above. If I create a FlameGame then attach it to a GameWidget, then attach it to a different GameWidget I see the following:

1. I always see get a render before the first update (your order is reversed)
2. I get an onLoad again after re-attaching the FlameGame (you don't mention that above)
3. I see onRemove after onGameRestart and before onLoad after re-attaching, but only if I do await super.onLoad() in the onLoad callback (seems like something that needs to be documented to avoid resource leaks and incorrect behavior)

I'm concerned that I'm documenting unexpected or incorrect behavior. I completely respect that I may also be doing something wrong.

You can check out the sources for jlyonsmith/flame_test to see how I tested.

[spydon]

Are all there cases only happening when you attach it to a new GameWidget and not before?

1. That sounds really weird, especially if it only happens after attaching to a new GameWidget.
2. Are you completely sure that it is the same game instance and not a new one?
3. Is this on main? Because there was some bugs regarding onRemove that has been fixed.

[jlyonsmith]

I was hoping to dash this one off quickly, but it seems like this is going to require a little more research. Briefly, my answers to the above are:

1. Yes, I'm attaching a new GameWidget
2. Yes, it's the same instance; I'm replacing the GameWidget not the FlameGame instance
3. It's on the 1.8.2 release; I'll update my sample to use the tip of main.

The reversed update and render is odd though. I'll set breakpoints and see if I can get to the bottom of that one.

EDIT:
I tried my test code with main. Exact same behavior. I urge you to take a look. If there are tests that assert different behavior I'll get them running and see if I can find the disparity. I need to put this down for a few days, but I'll circle back.

[jlyonsmith]

OK, although I still see the render & update and onGameResize and onLoad event reversals, I'm assuming those are by design. I misread my debug output and the onRemove appears to be in the correct place, before the next onGameResize event. Submitting an PR with the documentation updates.