skip to Main Content

I’m working on breaking down a large Flutter monolith into smaller, independent packages for better modularity. However, I’ve hit challenges in these areas:

  1. Database:
    How do you share a database (e.g., SQLite, Hive) across multiple packages without tight coupling?

  2. Notifications:
    What’s the best approach to handle push notifications across independent packages?

  3. Navigation:
    How can navigation be managed efficiently between decoupled packages without losing modularity?

  4. Global state (BLoC):
    How do you handle shared state across packages using BLoC, or should each package manage its own state?

Looking for advice on best practices or patterns that worked for you. Thanks!

For Navigation, I’ve tried to make own router for every package, which will be responsible for the routing in that package.
For GlobalState, I’ve tried to export every BLoC from every package and aggregate them in the mainApp, and then get the instance via Provider.
But the packages are still coupled to each other.

2

Answers


  1. I’m writing this as an answer because it’d be too clumsy as comments.

    From an SO perspective you’ve got 4-5 questions here, you might want to explore them individually 🙂

    I know nothing about Flutter and Dart specifically, but it sounds like there’s lots of technology agnostic architecture and system design ideas that could be applied to improve the objective nature of the code base. It’s hard to provide specifics given the high-level nature of your question.

    Some general things to consider:

    • Is the code arranged into logical layers? At the very least keeping UI / presentation code separate from "business logic" from data-access code? If not, that’s a good basic starting point.
    • Are you familiar with any architectural styles, such as Clean Architecture (just one example of several)? If not, take a look. Clean talks about separation of concerns that will help you with problems like how to share the database.
    • Are you familiar with SOLID?

    Packages & State

    Global state (BLoC): How do you handle shared state across packages
    using BLoC, or should each package manage its own state?

    Just in case you are not familiar with layers & layering in an application, generally speaking things within a layer can talk to one another. I’m not sure if in your case a package is a logical group (i.e. cohesive group) of classes within one layer – or more like a Vertical Slice (cuts across several layers).

    If for you, package == vertical slice, then I think typically each package would deal only with it’s own state. Be aware that sometimes concepts are shared between slices/packages – say at the database level, and therefore there might not be a simple clean way of saying something is in one package or another. All I can say is to be pragmatic and apply the KISS principle if you are in doubt.

    Prototype First

    One piece of advice, if you are applying new ideas to a large code-base, consider prototyping them out first, so that you can better ensure that:

    • You understand the idea you are applying (is it actually the right approach).
    • You understand how to apply it correctly.
    • You understand the implications of what you are doing, especially the unexpected ones. Not just the affect on the code base as a static thing, but also in terms of deployment, runtime, performance, etc.

    Keep in mind that sometimes you might be able to prototype an idea in a small test-harness, but other times you might want to take a snapshot of the entire code base and trial the change. I.e. a "throwaway" version of the code. I usually find that the first time I do something is not the best.

    Login or Signup to reply.
  2. The short answer is

    flutter create --template=package <module_name>
    

    But I recommend you to read the above answer really it’s informative and helpful

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search