Flutter Community
Published in

Flutter Community

11 Things to Remember for Your Next Flutter Project

An extensive checklist to kick-off a new Flutter project

1. Static code analysis

I will not write messy code (source)

2. Localization (l10n)

Localization (source)

Localization is the adaptation of a product or service to meet the needs of a particular language, culture or desired population’s “look-and-feel.” — TechTarget

It is essential to build an application that feels natural to the users, e.g. using the right translations, date and currency formats, text direction. For that, localization is a fundamental tool to use. Even though you are building a single region/language application, I would still recommend you implementing localization early on, thus separating your texts from UI code. Consequently, they could be reused as well as adjusted later on without affecting the code.

3. Environments (with some flavours)

Programming environments (source)
  • An intermediate environment (testing or staging) — helps you to validate the changes in the code, test features with the “real” data (usually, a snapshot of production data is used in such environments) and verify the application before releasing it to production. If you have QA engineers in your team, this is the place for them to shine.
  • Production environment — the one that is used by real users, where data corruption is not acceptable (always do backups, please).

4. Continuous Integration and Continuous Delivery (CI/CD)

Stages of Continuous Integration (CI) and Continuous Delivery (CD) (source)

5. Backend code

Once another meme about backend (source)
  1. Using any cloud solution to speed up the development process and leaving most of the DevOps work for the cloud provider.

6. Logging, crash data and analytics

Oops, something went wrong (source)

7. Application branding

Material theming (source)

8. Project structure and state management

State management in Flutter (source)
  • Layered Architecture — relies on the idea of splitting data, business and presentation logic into separate layers. Such file structure works fine for small-to-medium projects, but I feel that these layers become more and more overwhelming when the project grows.
  • Modular Architecture (I have described this concept here) — splitting the code into modules per feature where different modules interact. This one is my favourite — it works smoothly with BLoC state management solution (TEAM BLOC, YEAH!), scales well for big projects. However, it brings some challenges, like where to put common logic, how different modules should communicate and so on.

9. Code generation

Code generation (source)

10. Testing strategy

Application testing (source)
  • Widget tests should cover all the reusable UI components. When individual components are tested properly, you could start testing individual screens but in less detail.
  • End-to-end tests, covering the main application flows and interactions with the UI. No deep-level magic — just going through some crucial workflows. The more screens they include, the better.
  • When the whole UI is ready and implemented — golden tests to ensure that UI is not affected by changes later on.

11. README file

Make a README (source)
Phew, what a ride… (source)

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store