I wanted to cover all the components of Flutter, but there will be many articles about flutter now. So I’m not going to talk about that and I’m going to start with the engineering of Flutter

Including the following:

  1. Write common scripts for FLUTTER
  2. Build your own component library
  3. Teach you to build an enterprise flutter development framework
  4. Common Techniques of Flutter

Package management

We will use many packages in real projects, either by ourselves or by third parties. To find the package we need, you can find it at https://pub.flutter-io.cn.

Use the package

The package usage of Flutter is similar to the NPM package. To add a package, do the following:

  1. Open the pubspec.yaml file in the apps folder and add the package under pubspec.yaml, such as css_colors.
  2. Run from the command line: Flutter pub get or click the Packages Get at the top of the pubSpec. yaml file in Android Studio/IntelliJ. In VS Code, click Get Packages located at the top of the pubspec.yaml file to the right of the action function
  3. Add the relevant import statements to the Dart code.
  4. If the package has platform-specific code (Java/Kotlin for Android, Swift/Objective-C for iOS)

Package version

To specify the version of a package, Flutter gives us several methods, such as specifying the version range:

dependencies:
 url_launcher: ^5.4. 0# caret syntax, any5.4.x versions are available. Image_picker:'5.4.3'Url_launcher:'> = 5.4.0 < 6.0.0'# specify a minimum and maximum version number plugin1: path:.. < span style = "box-sizing: border-box! Important; word-wrap: break-word! Important;//github.com/flutter/packages.gitThe path: Packages /package1 # pub tool will assume by default that package is at the root of your Git repository. If this is not the case, you can specify the position ref: v1 with the path argument3.2.# Use tag to specify versionCopy the code

If two packages declare incompatible versions of URl_launcher, they may actually still use URl_launcher in a compatible way. In this case, conflicts can be handled by adding a dependency override declaration to the pubspec.yaml file to enforce the use of a particular version.

dependencies:
  some_package:
  another_package:
dependency_overrides:
  url_launcher: '5.4.0'
Copy the code

How to apply it in actual projects

In real projects, we usually use fixed releases to avoid unknown issues with release upgrades. So we can use scripts to check that our version uses the specification

#! /bin/bash

egrep -r --include="pubspec.yaml" --exclude-dir={ios,android} "\^" -n . > non_fixed_packages.log

FAILED=`[[ -s non_fixed_packages.log ]] && echo 1 || echo 0`
if [ "$FAILED" -eq "1" ]; then
  echo "#########################################################################################"
  echo "Please remove the ^ from the package version(s) in the file(s) to use fixed version(s)"
  echo "#########################################################################################"
  cat non_fixed_packages.log
fi

rm non_fixed_packages.log
exit $FAILED
Copy the code