なぜFlutter add-to-appのためのフレームワークを作っているのか
私たちがInlayを作るきっかけとなった、add-to-appで繰り返し起こる問題。
add-to-appはFlutterの公式にサポートされた使い方ですが、既存の大規模なエンタープライズアプリにFlutterを追加する場面では、公式ドキュメントもツールも、オンラインのコミュニティの知見も十分ではないと、私たちは何度も感じてきました。
ネイティブとFlutterの境界をまたぐナビゲーションのルートをどう管理するのか。両者の間でデータをどう共有するのか。そして最初の画面を越えたら、Flutterからネイティブのアセットをどう使うのか、PoCの段階を超えてスケールするプロジェクト構成をどう作るのか。私たちがフレームワークを作ったのは、実際のプロジェクトでこれらの疑問のすべてに直面したからです。
私たちのオープンソースフレームワークであるInlayは、次の機能を提供します。
- クロスプラットフォームなナビゲーションに対する、明確な設計方針を持つ型安全なアプローチ。ネイティブからFlutter画面を開くことも、その逆も簡単になります。
- ネイティブプラットフォームと1つ以上のFlutterインスタンスの間で同じデータを共有するための、クロスプラットフォームでリアクティブな状態管理。
- エンジンのライフサイクルの自動管理。低レベルのFlutterエンジンを自分で扱う必要はありません。
このガイドでは、フレームワークと、より汎用的なパターンの両方を解説しています。私たちのフレームワークを使わない場合でも、ここで説明するアーキテクチャ上の判断と実装戦略は、あらゆるadd-to-appプロジェクトに当てはまります。