avatarsimbu

Summary

The article discusses the implementation of Micro Apps in Flutter, detailing the process of extracting startup screens and logic into a separate package called digestable_prologue to streamline the main application digestibleme.

Abstract

The author of the article, which is hosted on Medium, explores the concept of Micro Apps within the Flutter framework, drawing inspiration from Martin Fowler's ideas on Micro Frontends. The article elaborates on how the author previously discussed packaging code for sharing across applications and now extends this concept by creating smaller, manageable applications that can be composed together. The author chose not to use the flutter_micro_app package due to its complexity in cross-application routing and communication, opting instead for a simpler approach using packages. The startup screens and logic were moved to a new package, digestable_prologue, which was then integrated back into the main application, digestibleme. This separation allows for a cleaner main app with a focus on its core features and ensures loose coupling between the startup code and the main app. The article also addresses the importance of keeping package versions synchronized to avoid errors and demonstrates how to check and update package versions using Flutter's package management commands.

Opinions

  • The author finds the flutter_micro_app package to be overly complex for their needs, particularly in terms of routing and communication between applications.
  • Moving the startup code into a separate package is seen as beneficial for reducing clutter and maintaining focus on the main app's features.
  • The author values separation and loose coupling in their application architecture for scalability and maintainability.
  • There is an emphasis on the importance of aligning package versions across different parts of the application to prevent runtime errors.
  • The author recommends using the flutter pub deps command to verify package dependencies and suggests automating version increments to avoid discrepancies.
Join Medium to view all my articles.

Flutter — Micro Apps

…a recent trend of breaking up frontend monoliths into many smaller, more manageable pieces, and how this architecture can increase the effectiveness and efficiency of teams working on frontend code…

From Micro Frontends by Martin Fowler

In an earlier article I talked about packaging code to share it with other applications.

Micro Apps(Frontends) takes that a step further allowing me to compose applications from applications.

I wanted to be able to share the startup screens and logic to detect the device, set the theme based on brightness mode etc.. with other applications.

I looked at a package flutter_micro_app, but I felt it introduced too much additional code, especially around cross application routing and comms.

The simplest approach was to use packages and move the screens into a new package called digestable_prologue.

Ta Da

New package digestable_prologue, with all the start up screens moved from digestibleme:

digestable_prologue application files

Then added back to digestibleme:

Including the digestable_prologue package in digestableme app.

And wired up in main:

Using digestable_prologue in digestibleme

Note, Riverpod is used to override the tab items when the application starts which is what the new app package will used once it finishes bootstrapping the app and that’s it!

XP

Separation and coupling

Moving the startup code, meant that digestibleme the main app is less cluttered with a focus on its features and only has a loose dependency on the startup application.

The feature tests for each are now separate which is important for scale and maintainability.

digestable_prologue feature tests.
digestibleme feature tests

Keeping package versions inline

When the reference to the version in simbucore differed in digestibleme and digestable_prologue I got an error that was not very helpful:

Failed assertion: line 4268 pos 12: '!_dirty': is not true.

So you need to be careful and make sure that packages that are depended on multiple times by parts of your application are the same version.

If you remember to bump the version or automate the increment you can check with:

flutter pub deps

If not you can find the git check id using the upgrade command:

flutter pub upgrade simbucore

simbucore 0.0.1 from git https://gitlab.com/simbu-mobile/simbucore.git at 85f703

Links

Flutter
Programming
Mobile
Microservices
Packaging
Recommended from ReadMedium