Organizing Flutter for standalone and embedding

The flutter world is pretty straightforward if you are building new multi-channel applications. You can probably leverage 90% of the same Flutter/Dart code across your Native mobile and web applications. Flutter's out-of-the-box project organization may work with little modification.

Enterprises get a different experience when they already have iOS, Android, and web applications on different tech stacks with overlapping functionality.  Enterprises change their tech stack by incrementally replacing native or javascript functionality with Flutter modules.  The Flutter default project structure must be recast in this situation.

Organizing Flutter for Standalone and Embedded applications on YouTube

The rest of this article is converted in greater depth in the video.  The content exists here for search optimization and will be updated over time.

Default "greenfield" organization

This is the project structure for a new standalone application that can be deployed as web, Android, and iOS applications.  The shared Flutter code goes in /lib. Small standalone web, Android, and iOS wrapper code exist in the appropriate directories. Flutter covers the entire screen or fills the web browser essentially running in full screen on the target canvas.  This structure is understandable and easy to work with as long as you are running standalone applications.

The web app is packaged as static content, its own site. This means the web artifact can inserted or embedded in another website as an iFrame without any additional code.  Mobile is different by its very nature.

This project structure can also include macOS, Windows, and Linux deployable applications. I didn't include them because they clutter the image for the purposes of this narrative.


Organizing for embedding and incrementalism

The default Flutter project structure only supports one target type for each platform. I usually want two different use cases or run time variants when doing incremental Flutter replacement of an existing application.  
  1. Flutter runs inside the company's real Natvie Applications.  This requires integration and the project is configured as a Module
  2. A standalone development or test application for development, demonstrations, or other uses. This project is configured as an Application
Note Flutter Web operates differently from the iOS and Android projects.  The web app is pretty much the same whether it runs standalone or inside another application.  It runs as a standalone application inside an HTML element or in an iFrame.  Nothing fancy is happening here.
  1. lib/package where all the real Flutter code is.
  2. /modules that are embedded in existing or 3rd part mobile applications. They require their own flutter configuration
  3. /apps Standalone applications that consume the flutter package in the first step. They may be destined for production or may only be used by developers and testers
The packaged Flutter/Dart code can be relatively referenced inside the source tree. This lets us isolate and embed/use the Flutter code without having to publish the package as an artifact.  We treat the Applications, the Modules, and the library as a small mono repository.

See Breaking Down the House - I mean Flutter Projects for a sample project structure


Future discussions include inserting Flutter views into Mobile applications where the Flutter component fills only part of the canvas.


Revision History


Popular posts from this blog

Understanding your WSL2 RAM and swap - Changing the default 50%-25%

Installing the RNDIS driver on Windows 11 to use USB Raspberry Pi as network attached

DNS for Azure Point to Site (P2S) VPN - getting the internal IPs