This seems a bit brittle to me, since anyone adding new members probably will need to remember to update this method.

One alternative would be to wrap all of these members within another struct, and then you can just clobber that struct with a default-initialized one.

If this were pure C++, I'd even consider doing something like *this = FlutterEngine(); (and explicitly saving/restoring members we want to preserve), but I don't know how that'd work with Objective-C++.

Agreed - I'll clean this up...

I've moved most of these to a method with a comment - I also found a couple that weren't necessary in there. The basic problem is that MessageChannels get the Engine pointer and retain it - and we don't have a nice, non-breaking way to deal with that via a WeakPtr or something because it's part of the public Objective-C API. I know this approach still isn't quite ideal, but hopefully it's better.

I haven't fully digested this, but my initial impression is that this feels clunky. My instinct is that we shouldn't need to keep track of this explicitly with proper ref-counting and strong/weak references.

That is, could FlutterViewController always own its reference to the FlutterEngine, everything else that doesn't need to keep the engine alive could use weak references, and anybody that does want to keep the engine alive could be responsible for retaining their own reference to the FlutterEngine?

(Is it important that we be able to shut down the engine without deallocating it?)

The problem is that we end up with a cyclic reference in the case where FlutterViewController initializes its own engine. Basically, it creates the engine (and it needs a strong reference to the engine), and then tells the engine to use it (weakly). When some external action that dismisses the view controller happens, it doesn't currently notify the engine that it can be dismissed - and so it never gets deallocated.

Just notifying the engine that it's not visible isn't enough either, because the engine currently assumes that once it's started it should never stop unless deallocated - but we end up with a circle of references that prevents that from happening. Basically, we should be treating a deallocating of the view controller as something that needs to shut down the engine IFF the engine is owned by the view controller.

In other words, a FlutterEngine is built such that it will keep running whether it has a FlutterViewController or not. But in this case, we want to tell it to stop running once the FlutterViewController is gone.

Stated that way, I'll try to see if I can alternatively add a parameter or initializer to FlutterEngine that would ask whether it should be allowed to run headless or not.

random blast from the past: didn't we do this on init already? Why do we need to do it again?

I believe it was because the channels could get reset between there and here

how would it though. Looking at the code, it only happens on destroyContext and based on the doc, the object is in an unusable state until it's deallocated. This second setupChannels seems redundant.

I can't remember now and I can't see a code path where this happens. I think we can probably kill one of these - I suspec tthe one in the initializer is wrong because actually using a channel before the engine is launched would be an error.

SG, thanks for double checking