Avoid a never-disappearing splash screen if the engine came from somewhere else on iOS

[dnfield]

Fixes flutter/flutter#24260

Today, if a user does the following sequence, they'll end up with a blank screen:

FlutterViewController* flutterViewController =
      [[FlutterViewController alloc] initWithEngine:_engine
                                            nibName:nil
                                             bundle:nil];
  flutterViewController.splashScreenView = [[UIView alloc] init];
  [self presentViewController:flutterViewController
                     animated:false
                   completion:nil];

Where _engine is a prewarmed FlutterEngine from somewhere else.

This prevents that.

[jamesderlin]

The first-frame callback (__flutterViewRenderedCallback) would also be broken for the case with an existing FlutterEngine.

To clarify: if FlutterViewController is initialized with an existing FlutterEngine, does the splash screen not disappear only if it's been explicitly set, or does the default splash screen loaded from a storyboard/etc. also not disappear? (Based on the code, I assume it's the latter, but the change description implies the former.)

Can you also clarify exactly why the splash screen state machine is broken in this scenario? Is -installSplashScreenCallback not triggered, or is the callback from SetNextFrameCallback not triggered, or do we get stuck somewhere else?

[jamesderlin]

I think we should prefer if (booleanValue) or if (!booleanValue) instead of comparing against booleans.

[jamesderlin]

I think that ideally we should enable (or disable) the splash screen independently of how the FlutterViewController was initialized. That would be less of a cognitive burden for clients.

If we do make FlutterViewController ignore the splash screen if it's initialized with a FlutterEngine, then we should explicitly document that (and possibly make -setSplashScreen fail an assertion in that case).

[dnfield]

The problem seems to be that the the callback is never getting invoked in this case. It might be better to fix that than what I'm proposing here though.

[dnfield]

The callback is getitng invoked after all... Still trying to figure out why I get stuck with a white screen.

[dnfield]

Making a little progress: installSplashScreenViewIfNecessary gets called before the user gets a chance to actually set the splashscreen. The user then tries to set a splash screen, which is messing something up.

[jamesderlin]

Okay. But I think it'd still be good to add a way to check if the engine is rendering, and then we can avoid installing the default splash screen and can fire the first-frame callback immediately when the view is loaded.

[dnfield]

/cc @matthew-carroll - we should probably coordinate on this to determine needs for embedding in general

[matthew-carroll]

@dnfield I couldn't quite follow this thread. Can you frame the specific question(s) with regard to what the embedding should do?

[dnfield]

Sorry about that @matthew-carroll , I should have been a bit more explicit

I was mainly trying to draw attention to the last part - it may be valuable for the embedding code to know whether the rasterizer has rendered at least one frame in a synchronous manner. For this particular issue, we could have shortcircuited logic that way. However, if we add that capability it would be good to discuss if/how it might be useful on the Android side as well.

[matthew-carroll]

Sure. Feel free to schedule some time or draft a brief. On Android I believe we have a first frame callback. I thought there was one on iOS, too. We should be able to leverage that any way we'd like.