Refactoring of Embedding API

[WonyoungChoi]

Since FlutterView was added, the class relationship of the Embedding API seems to have become very complicated. Currently, FlutterApplication, FlutterService, ElmFlutterView, and NUIFlutterView all create and own the FlutterTizenEngine of the Embedder. This seems to violate SRP and OCP. This design is centered on C#, but the same is true of C++.

For this reason, Refactoring is proposed as shown in the following diagram.

IMO, First of all, In the FlutterDesktopViewCreateFromNewWindow, FlutterDesktopViewCreateFromElmParent, ..., the code that creates the view and runs the engine must be separated.

AS-IS

TO-BE

[swift-kim]

Please note that

• We can't change this part: https://github.com/flutter-tizen/flutter-tizen/blob/8ac3e60b5d652c0319a968dd22a981cc18eb475b/templates/ui-app/csharp/App.cs#L11
• We already have had a plan to implement the FlutterView class (as a wrapper of FlutterTizenView but not a common base class for ElmFlutterView or NUIFlutterView) since we started working on the FlutterEngine class.
• FlutterTizenView and FlutterTizenEngine (and their embedding counterparts FlutterView and FlutterEngine) have a special relationship. An engine is "owned" by a view and the lifecycle of the engine is managed by the view (i.e. the engine is started when the view is created and terminated when the view is destroyed). I don't think this should necessarily be the case but we just followed the Windows embedder implementation.
• The NUIFlutterView class extends ImageView and thus cannot extend FlutterView.

[WonyoungChoi]

I agree with a lot of things, but I'm even considering "Breaking Changes."

As a way not to damage the existing user interface as much as possible, we are trying to change it little by little.

[swift-kim]

If you're to make changes to the NUIFlutterView class, the sooner the better it will be, because right now it has not been documented yet and not being used anywhere.

[WonyoungChoi]

@swift-kim Yes I think so.