11 things to remember about the next Flutter project

The original

Medium.com/flutter-com…

The body of the

Creating a new Flutter project is a good thing — fresh code base, no legacy code (not yet), empty security, the latest version of your favorite software package, and so on. But at the same time, you should make key decisions at the beginning of the project that will lay the foundation for the future, such as tools, packages, file structures, state management solutions, test plans. Otherwise, the project will end up being just another bowl of spaghetti and meatballs. To avoid this, I have prepared a list of the most important elements of the project that, in my opinion, should be decided as soon as possible. I hope it helps you, so * * happy reading!

Static program analysis

I will not write messy code (SOURCE source)

Linter is a static analysis tool that identifies and flags programming errors, warnings, and style flaws in your code so you can fix them. This is one of the easiest things to implement in the context of Flutter, and one of the most useful things to keep code clean.

There are many different rules you can follow for your code, but I recommend you use a predefined rule that already follows best practices based on the Dart style guide:

The dart – lang. Making. IO/linter/lint…

The dart. Dev/guides/lang…

lint;
flutter_lints Flutter;
very_good_analysis.

Regardless of which package you choose, you can add or remove any specific static analysis rules in the AnalysisServices _ options. yaml file.

2. Localization (L10N)

Localization [source](marcosantadev.com/wp-content/…

What is localization (L10N for short)?

* Localization is the adaptation of a product or service to meet the “look and feel” needs of a particular language, culture, or desired population

It is necessary to build an application that feels natural to the user, such as using correct translations, date and currency formatting, and text orientation. Therefore, localization is a basic tool. Even if you are building a single region/language application, I still recommend that you localize as early as possible to separate the text from the UI code. As a result, they can be reused and adjusted without affecting the code.

Flutter Documentation neatly explains the process of internationalizing an application. If the default seems too complex, or if you need some useful extensions and helper methods, there are popular third-party packages, such as Easy_localization, that can help you with the localization process.

3. Environment (with some flavor)

Source of Programming environments

I bet you’ve heard of at least one case from your environment (no pun intended) when someone corrupted data or deleted an entire user table in production. Trust me, it’s not fun. Therefore, it is a good practice to create different environments for your projects:

* The (local) environment is designed to drive you crazy: experiment in code, change data directly in the database, use shortcuts and hard-code authentication tokens or provide simulation data. Have fun and provide these features

Helps you validate changes in your code, test features with “real” data (typically in this environment using snapshots of production data), and validate your application before releasing it to production. If you have quality assurance engineers on your team, this is where they shine
* Environment used by real users where data corruption is not acceptable (always back up)

Having such an environment helps you safely experiment and validate features before these changes reach users.

Now, the other part — taste. No, no, we’re not talking about something sweet, salty, or sour — that’s just another term used in programming to describe different build variants of an application. For example, you want to make ICONS and titles, API endpoints, or any other configuration different for each particular environment. To do this, you need to define a different “flavor” that is used when building applications for a particular environment. Here is some information on how to create flavours for Flutter.

4. Continuous integration and continuous delivery

Continuous integration phase (CI) and Continuous delivery integration phase (CD) Source source

After introducing a different environment, the natural next step is to automate the process of building, testing, and publishing the application. CI/CD is a fairly complex topic in its own right, and I’m not an expert in it by any means, so I suggest searching for additional resources on how to automate the different phases of application development.

However, there are many NoOps solutions that are compatible with Flutter, so you can easily automate your development process:

Appcircle;
Codemagic Codemagic;
Bitrise;
VS App Center (there is no Flutter integration yet, but there are resources to help you set everything up)

* Any of these solutions can solve the problem — in short, choose one that fits your needs and budget.

5. Back-end code

(Another backend meme)

Have you implemented the back end in any special or less fancy programming language? Fine, you can skip this step, but I still recommend looking at some cloud solutions for future reference.

In the simplified version, the back-end portion of the application has two options:

Implement a custom back-end solution using whatever programming language and framework you like, but deal with all DevOps later to make your code and data accessible from within the application
Use any cloud solution to speed up the development process and leave most of DevOps to cloud vendors

If you find the second option attractive, choose from some of the cloud platforms that support Flutter:

Google Firebase;
AWS Amplify;
A woman’s name; Supabase.

The cloud platform provides authentication, databases, storage, API options, and many other features for your applications. Any of the above is a good choice if you just need to validate the idea and build MVP quickly without spending a lot of time on a mature back-end solution.

6. Logging, crash data and analysis

Oops, there’s a problem.

Logging is underrated * * Here, I said it! Everything is fine until something goes wrong and you need to know about it. There is always a gray area when we discuss what should and shouldn’t be recorded. But one thing is always clear: you need to know when your application crashes and what’s causing the problem. The more data you collect about the event, the easier it will be to find and solve the problem.

Services like Sentry, Firebase Crashlytics, Datadog, Datadog can help you record your most important data, crash reports, and even set up notifications when your application or related services fail.

Another type of logging is collecting user data for analysis purposes. When you’re building a new and potentially first-class product, it’s critical to understand what users want, how they behave, and how they use the application. To this end, various analysis tools can be integrated into your Flutter application, such as Firebase Analytics, App Center Analytics and many more.

Application branding

Material Theming (Source source)

One of the main goals of any app or brand is to gain recognition. Use the right color palette, logos, ICONS, design elements, content, fonts, and sometimes even layout to make your product stand out. This is the branding of your application, and having the basics ready at the beginning will save you a lot of time throughout the project.

If you have your UI prototypes or design components ready, now is the time to transfer them to your application and define themes —- colors, fonts, shapes, and so on. For convenience, a nice guy named Mike Rydstrom created an excellent package for this flex_COLOR_scheme scheme.

8. Project structure and status management

Flutter State Management

Yes, the controversial one. To be clear, there is no such thing as “best country management solution” or “best application architecture” — and if anyone thinks otherwise, keep in mind that they might as well pour the milk into the bowl before pouring the cereal. That’s the worst part — * I can’t teach you the best way. I can only offer a few options or share my preferences.

A few file structure options for the next Flutter project:

* A clear separation of concerns, whether it lasts. To be honest, I don’t like it. I felt that there was too much abstraction in the concept and that it could slow down the development process
* Layered Architecture relies on the idea of dividing data, business, and presentation logic into different layers. This file structure works fine for small to medium sized projects, but I think as the project grows, these layers become more and more overwhelmed
Modular Architecture (I have described this concept here) * Division of code into modules of distinct functions so that the different modules interact with each other. * This is one of my favorite * it’s aligned with the Group Country Management Solution (TEAM BLoC, YEAH!) For a large project, the scale is large. However, it also presents some challenges, such as where to put common logic, how should different modules communicate, and so on

On the issue of state governance in Flutter, I think we’ve reached the point where we can devote an entire session to this issue, but there’s no final answer in hindsight. I just want to add that pick the one you feel most comfortable with. You can find a comprehensive list of options here.

9. Code generation

Code generation (source)

If you want to simplify some steps and save some development time, you can use code generation in your project. Code less, deliver more! Code less, deliver more

There are a number of different tools available, whether dealing with localization, assets, parsing JSON, generating model classes, implementing service locators, routing, or dealing with immutable state. The only thing to do is investigate the available tools and packages and choose the best ones to meet your project needs.

For a quick Flutter project startup, I recommend checking out the Very Good CLI. This will save you a few hours of configuration (unfortunately, I’ve learned the hard way).

Also, last month I gave a talk on Code Generation — * It could be the beginning of the journey for Flutter code generation, so check it out!

10. Test strategies

Application Testing (Source source)

Is it good or bad to cover 100% of your code with tests? Sure, that’s great, but at what cost? Think of it this way, and you risk falling into a doomed pit where you spend more time writing tests than developing features. To avoid this, you need a testing strategy.

* Don’t get me wrong — covering code with tests is a good thing, and the more hidden areas of code are, the safer they are when implementing new features. It’s just that, in my opinion, you should find the balance where testing still gives you more value compared to the time it takes to write tests. For example, here’s my testing strategy:

Business logic (services, repositories, BLoCs) should be covered 85-100% in The business logic (services, repositories, clusters) should be in the Unit/Integration tests unit/integration tests — this is the most important part of any application, so I see a lot of value in testing;
Widget Tests should include all reusable UI components. When the individual components are properly tested, you can start testing the individual screens, but don’t go into too much detail
End-to-end tests, covering the major application flows and interactions with the UI. There is no deep magic — just some critical workflow. The more screens they contain, the better
* When the entire user interface is ready and implemented — * Golden tests ensure that the UI is not affected by future changes

To be honest, I still find the happy medium in testing, but trust me, you’ll get better in project after project.

11. Readme document

Make a README

You heard me right, the file. README files are the most important documents on a project, especially when working on a team.

Have you just introduced a new solution that requires code generation? Did you just add a useful bash script to automate this process? Have you implemented a global logger that must be used anywhere in your project? * We can’t read your thoughts * This is mentioned in the README file!

There wasn’t much documentation (at least I hadn’t encountered that), just a lack of information about the project and the code. All commands to generate, test, and run code, various file structure decisions, diagrams, external tools and services, and information about different environments (without SECRET KEYS) should be here and kept in a separate place. It’s a boring job, but a very rewarding one!

Phew, what a ride… This is a nice car… Source. The source)

That’s it! Thanks for taking the time to read this article.

Did I miss something? Mention it in the comments! What is your checklist when building a new Flutter application?

ducafecat.tech/
github.com/ducafecat
Ducafecat WeChat group
B station space.bilibili.com/404904528

The issue of

Open source

GetX Quick Start

Github.com/ducafecat/g…

News client

Github.com/ducafecat/f…

Strapi manual translation

getstrapi.cn

Wechat discussion group Ducafecat

A series of collections

The translation

Ducafecat. Tech/categories /…