なぜFlutter add-to-appのためのフレームワークを作っているのか

私たちがInlayを作るきっかけとなった、add-to-appで繰り返し起こる問題。

add-to-appはFlutterの公式にサポートされた使い方ですが、既存の大規模なエンタープライズアプリにFlutterを追加する場面では、公式ドキュメントもツールも、オンラインのコミュニティの知見も十分ではないと、私たちは何度も感じてきました。

ネイティブとFlutterの境界をまたぐナビゲーションのルートをどう管理するのか。両者の間でデータをどう共有するのか。そして最初の画面を越えたら、Flutterからネイティブのアセットをどう使うのか、PoCの段階を超えてスケールするプロジェクト構成をどう作るのか。私たちがフレームワークを作ったのは、実際のプロジェクトでこれらの疑問のすべてに直面したからです。

私たちのオープンソースフレームワークであるInlayは、次の機能を提供します。

  • クロスプラットフォームなナビゲーションに対する、明確な設計方針を持つ型安全なアプローチ。ネイティブからFlutter画面を開くことも、その逆も簡単になります。
  • ネイティブプラットフォームと1つ以上のFlutterインスタンスの間で同じデータを共有するための、クロスプラットフォームでリアクティブな状態管理。
  • エンジンのライフサイクルの自動管理。低レベルのFlutterエンジンを自分で扱う必要はありません。

このガイドでは、フレームワークと、より汎用的なパターンの両方を解説しています。私たちのフレームワークを使わない場合でも、ここで説明するアーキテクチャ上の判断と実装戦略は、あらゆるadd-to-appプロジェクトに当てはまります。

プライバシーポリシー