簡単に概要だけまとめました!LT15分枠のもののみ一旦感想を入れています。タイトル通りですが、既存のネイティブで開発したアプリケーションに対して、Flutterで作成したViewを活用法についてです。GitHubにWikiがあるようなので、それも載せておきます。感想:既にネイティブで開発し、それなりのコードベースの場合は、このアプローチ法が多くなるのかなと思いました。プラグイン開発を行わない場合でも、iOS/Android固有の知識は一定必要やはりプラットフォーム固有のUIを実装したい場合には、Flutterだけだと厳しいという現実があると思いました。既存アプリに対するアプローチがもっと増えることに期待です。開発速度が早い(リプレイスを2ヶ月でできた。リプレイス後の開発速度は3倍になった。Android単体のアプリでもFlutterの方が簡単に作れた。感想:開発速度早い!と率直に思いました。リプレイス後の開発はFlutterで完結できて、開発速度もあがるのを考えると、プラットフォーム固有のUI等が少ないアプリの場合は、リプレイスするのも手だな思いました。概要:以下のブロックパターンに棲み分けを行なった。Bloc)なぜブロックパターンを適用しようと思ったのか1ブロックごとに処理がまとまるため、構造が単純かつコード数が短くなる。(しかしファイル数は多くなる。)2スコープの範囲が明確のブロックに切り分けるため、ブロック自体が疎結合になる。保守性・可読性があがる。まとめ・作られたブロックの数は26個(多い?少ない?開発者としてはこんなもんかなという感じ)・各々のブロックの使い方を見極めて、スコープを明確化、構造化できれば保守性が大きく向上する。感想:とても参考になりました!自分がFlutterのコードを書く時はどうしても長く読みづらいコードになっていました。共通処理をファイル分けしていこうとは思っていたのですが、どの程度、どの範囲で分けていくのかが明確ではなかったので今回のパターンを参考にブロックパターンを組んで行ければ良いと思いました。Tabs(Android)→SFSfariViewController(IOS)オススメのプラグイン3のflutter_inappbrowser機能が豊富なのでいろんな実装が可能とのこと。可読性の高いものにできるのオススメ→Dartの可読性がよくない時がある。概要:どんな案件にはまったのか1ひとりでIOS、Androidの対応をしなければならない→Flutterがマルチプラットフォーム2デザインはこだわらない。プラットフォーム固有のUIいらない。→マテリアルWidgetそのまま使えば満足3非機能要件もそんなに気にしない。アプリ等リリースしたり、リプレイスしたりと様々なことができていてやっぱりFlutter使いこなしたら便利だなと思いました。上げていきたいともいます。今回は有意義な時間を誠にありがとうございました。upLoginユーザーは見つかりませんでした。