Forem: Vincentius Westley

Master Multiple Density Image Assets in Flutter: Boost Your App’s Visuals!

Vincentius Westley — Tue, 08 Oct 2024 03:19:39 +0000

As the mobile landscape continues to evolve, the range of screen sizes and resolutions across devices has expanded significantly. From compact smartphones to expansive tablets, ensuring that your application’s visuals remain sharp and consistent across all these devices is crucial. This is where the concept of multiple density image assets comes into play, especially in the context of Flutter—a popular framework for cross-platform mobile development.

📄 Understanding Screen Density and Image Assets
Before getting into the details of Flutter it’s important to understand the basics of screen density and image assets:

Screen Density (DPI): Density refers to the number of pixels within a given physical area of the screen, typically measured in dots per inch (DPI). Devices with higher screen densities have more pixels per inch, which makes their displays sharper and clearer.
Image Assets: These are the visual elements (like icons, buttons, and background images) used in an app. To appear sharp on screens with different densities, these assets need to be provided in multiple resolutions.

Why Multiple Density Image Assets Matter
1. Enhanced Visual Quality: High-resolution devices demand high-quality images to avoid appearing pixelated. By providing multiple density image assets, you ensure that your images look sharp and clear on any device, regardless of its screen density.

2. Optimized Performance: Using the appropriate image for each screen density can significantly improve performance. Loading images that are too large for a given screen’s resolution wastes memory and processing power, leading to slower performance and higher power consumption. Multiple density assets allow Flutter to select the most suitable image, optimizing both memory usage and performance.

3. Consistent User Experience: Ensuring that images look consistent across various devices is crucial for a seamless user experience. Whether your app is being used on a low-resolution screen or a high-resolution one, users should have a consistent visual experience. Multiple density image assets help achieve this by providing the right image for each screen type.

4. Scalability Across Devices: As new devices with varying screen resolutions are released, having multiple density assets makes your app scalable and future-proof. It ensures that your app can easily adapt to new hardware without requiring significant changes or additions to your image assets.

Implementing Multiple Density Image Assets in Flutter
Flutter simplifies the process of handling multiple density image assets through its asset management system. Here’s a step-by-step guide on how to implement them effectively:

1. Preparing Image Assets

For each image asset, prepare multiple versions at different resolutions. Commonly, these are:

1x for baseline resolution (mdpi)
1.5x for low-density screens (hdpi)
2x for medium-density screens (xhdpi)
3x for high-density screens (xxhdpi)
4x for extra-high-density screens (xxxhdpi)

For example, if you have an icon named logo.webp for a baseline resolution, you should also provide logo@1.5x.webp, logo@2x.webp, logo@3x.webp, and logo@4x.webp.

📄 - In this example, I'm using WebP for all the images because WebP offers better image compression. It's a good idea to use WebP for your images too. To learn more, visit this link.

2. Organizing Assets in the Project

Organize these assets in your Flutter project’s assets directory. A typical structure might look like this:

assets/
  - images/
      - logo.webp
      - 1.0x/
        - logo.webp
      - 1.5x/
        - logo.webp
      - 2.0x/
        - logo.webp
      - 3.0x/
        - logo.webp
      - 4.0x/
        - logo.webp

Defining Assets in pubspec.yaml

In your pubspec.yaml file, list the image assets. Flutter will automatically detect and use the appropriate resolution based on the device’s screen density:

flutter:
  assets:
    - assets/images/logo.webp

Using Assets in Your Flutter Code

When you need to use these assets in your Flutter widgets, simply refer to the base asset name. Flutter’s asset resolution system will automatically select the most suitable image:

Image.asset('assets/images/logo.webp');

Best Practices for Managing Multiple Density Assets
1. Asset Compression: Optimize your images for size without sacrificing quality. Tools like Respresso can help compress images while maintaining their visual fidelity and also splitting your image to all density.

2. Regular Updates: As new devices with higher resolutions are released, ensure that your assets are updated accordingly to support these new screens.

3. Testing on Multiple Devices: Always test your app on a variety of devices and screen densities to ensure that your assets render correctly and the user experience remains consistent.

⛔ Trade-offs of Implementing Multiple Density Image Assets

While multiple density image assets offer some benefits, they also come with certain trade-offs that developers should consider:

Increased App Size
In Flutter providing multiple versions of each image for different screen densities will inevitably increase the overall size of your app. This can be a concern for users with limited storage or slow download speeds. Large app sizes can also affect your app’s ranking and reviews, as users often prefer smaller, quicker-to-download apps.

📄 - The way multiple image densities are handled differs between native apps and Flutter. In native apps, using different densities can reduce the app's download size because only the appropriate density images are downloaded for each device. However, in Flutter, all image densities are included in the app package, which means the app download size isn't reduced by splitting images based on density.

Development and Maintenance Overhead
Managing multiple versions of each image can increase the complexity of your development process. You need to ensure that all images are updated consistently across all densities, which can be time-consuming. This also requires designers and developers to work closely together to maintain image quality and consistency across different resolutions.

Balancing Trade-offs
When deciding whether to implement multiple density image assets, consider the nature of your app and your target audience:

- High-End Visuals: If your app relies heavily on visual quality (e.g., a graphic-rich game or a photo editing app), investing in multiple density assets is crucial despite the increased app size.

- Performance Optimization: For apps that prioritize performance and efficient resource use, multiple density assets can reduce CPU load and power consumption, making the app more responsive.
**

App Size Constraints**: If your app is targeted at regions with limited internet connectivity or users who are sensitive to download sizes, you might choose to use fewer resolutions or use methods that deliver assets as needed.

✨ Conclusion
Implementing multiple density image assets in Flutter is a strategic choice that balances visual quality, performance, and app size. By providing the right assets for each screen density, you ensure your app looks sharp and performs well across a variety of devices. However, this comes at the cost of increased app size and development complexity.

As a Flutter developer, it’s essential to evaluate your app’s specific needs and user demographics when deciding how to manage image assets. Whether you choose to implement multiple density image assets for optimal performance or streamline assets to minimize app size, the decision should align with your app’s goals and user expectations. By carefully considering these factors, you can deliver a high-quality user experience while maintaining efficient app performance.

Master Multiple Density Image Assets in Flutter: Boost Your App’s Visuals!

Vincentius Westley — Mon, 01 Jul 2024 08:04:57 +0000

📄 Understanding Screen Density and Image Assets
Before getting into the details of Flutter it’s important to understand the basics of screen density and image assets:

Screen Density (DPI): Density refers to the number of pixels within a given physical area of the screen, typically measured in dots per inch (DPI). Devices with higher screen densities have more pixels per inch, which makes their displays sharper and clearer.
Image Assets: These are the visual elements (like icons, buttons, and background images) used in an app. To appear sharp on screens with different densities, these assets need to be provided in multiple resolutions.

1. Preparing Image Assets

For each image asset, prepare multiple versions at different resolutions. Commonly, these are:

1x for baseline resolution (mdpi)
1.5x for low-density screens (hdpi)
2x for medium-density screens (xhdpi)
3x for high-density screens (xxhdpi)
4x for extra-high-density screens (xxxhdpi)

For example, if you have an icon named logo.webp for a baseline resolution, you should also provide logo@1.5x.webp, logo@2x.webp, logo@3x.webp, and logo@4x.webp.

📄 - In this example, I'm using WebP for all the images because WebP offers better image compression. It's a good idea to use WebP for your images too. To learn more, visit this link.

2. Organizing Assets in the Project

Organize these assets in your Flutter project’s assets directory. A typical structure might look like this:

assets/
  - images/
      - logo.webp
      - 1.0x/
        - logo.webp
      - 1.5x/
        - logo.webp
      - 2.0x/
        - logo.webp
      - 3.0x/
        - logo.webp
      - 4.0x/
        - logo.webp

Defining Assets in pubspec.yaml

In your pubspec.yaml file, list the image assets. Flutter will automatically detect and use the appropriate resolution based on the device’s screen density:

flutter:
  assets:
    - assets/images/logo.webp

Using Assets in Your Flutter Code

When you need to use these assets in your Flutter widgets, simply refer to the base asset name. Flutter’s asset resolution system will automatically select the most suitable image:

Image.asset('assets/images/logo.webp');

2. Regular Updates: As new devices with higher resolutions are released, ensure that your assets are updated accordingly to support these new screens.

3. Testing on Multiple Devices: Always test your app on a variety of devices and screen densities to ensure that your assets render correctly and the user experience remains consistent.

⛔ Trade-offs of Implementing Multiple Density Image Assets

While multiple density image assets offer some benefits, they also come with certain trade-offs that developers should consider:

Balancing Trade-offs
When deciding whether to implement multiple density image assets, consider the nature of your app and your target audience:

- Performance Optimization: For apps that prioritize performance and efficient resource use, multiple density assets can reduce CPU load and power consumption, making the app more responsive.
**

App Size Constraints**: If your app is targeted at regions with limited internet connectivity or users who are sensitive to download sizes, you might choose to use fewer resolutions or use methods that deliver assets as needed.

Reduce Your Flutter App Size: Pro Tips for Measuring and Optimizing Efficiency!

Vincentius Westley — Wed, 19 Jun 2024 02:43:21 +0000

When creating mobile apps, a competent mobile engineer must consider the applications' quality as well as its functionality to ensure that users have a positive experience. This goes beyond simply producing a product that functions as intended.

Some of the things we need to pay attention are, performance, application size, stability, security, compatibility, scalability, and maintenance. In this post, we'll talk about one component of quality: application size. Specifically, we'll go over how to measure the size of our app and optimize it to the perfect user size.

🛠 Measuring Flutter app size

To begin analyzing and measuring the size of our Flutter applications, we can use the Flutter analysis tool by passing the --analyze-size parameter when building. In this example, I'm going to illustrate how to analyze it on the Android app bundle, and then the command we can do is

flutter build appbundle --analyze-size --target-platform=android-arm64

Leave it until it's done, and we'll get the app size breakdown (Android App Bundle) on our app.

The tool displays a high level summary of the size breakdown in the terminal, and leaves a *-code-size-analysis_*.json file. To do a deeper analysis, we can use the results generated by our JSON file on Dart Dev Tools. To do it first, we need to activate and run Flutter Dev Tools by performing the following command

flutter pub global activate devtools; flutter pub global run devtools

When we run the Flutter dev tools, we can open the Flutter dev tools on our localhost at http://127.0.0.1:9100/.

After that, go to the "App Size Tooling" section and do the JSON file import that we have generated previously.

Here we can see in detail the size distribution of our applications, which makes it easy for us to determine which parts are our focus in doing app size optimization.

📊 Optimizing Flutter app size

Once we've done measuring on our application, we can proceed to optimize. With the details we got from the measuring, we could focus on optimizing parts that have significant sizes.

In the example of this application, we can see that the largest contributor size is lib, followed by assets, and finally dex.

Optimizing Dex File
DEX file is a compiled file format for the Dalvik Virtual Machine, which is the virtual machine that Android used to run applications. DEX stands for Dalvik Executable, and these files have a .dex extension. They contain compiled code written in the Java programming language that can be executed on the Android platform. In the context of Flutter, while your primary code is in Dart, any integration with Android's native functionality will involve DEX files for the Java/Kotlin components.

On applications that aren't too complex and don't use a lot of third-party libraries, dex files should not be that big. From there, we can optimize dex files in our application. There are several ways to reduce the size of our DEX files, such as:

1. ProGuard/R8 Obfuscation and Shrinking

ProGuard and R8 are tools provided by Android to help shrink, obfuscate, and optimize your code. R8 is the default compiler for Android that includes ProGuard’s capabilities.

In your gradle.properties file, ensure ProGuard or R8 is enabled:

android.useProguard=true

Enable code shrinking and obfuscation in build.gradle:

buildTypes {
    release {
        minifyEnabled true
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
    }
}

2. Enable Multidex

MultiDex facilitates the separation of code into smaller modules. This can be combined with App Bundles or Split APKs to optimize which parts of the app are downloaded and installed on the user’s device. For instance, if parts of your app are only needed by certain users, these can be separated into different DEX files, potentially reducing the download size for users who don’t need all features.

In your build.gradle file, ensure multiDexEnabled is enabled:

android {
    defaultConfig {
        multiDexEnabled true
    }
}
dependencies {
    implementation 'androidx.multidex:multidex:2.0.1'
}

3. Split APKs

In your build.gradle file, ensure you include different ABIs (Application Binary Interfaces).

android {
    splits {
        abi {
            enable true
            reset()
            include 'armeabi-v7a', 'arm64-v8a', 'x86', 'x86_64'
            universalApk false
        }
    }
}

After doing some optimization, we can go back to build analysis on our application to see the differences that occur after implementation.

Here you can see that after implementation, our dex files experienced a significant decline of about 59.57% from 9.4 MB to 3.8 MB.

Optimizing Assets File

Next is assets. Assets are often the cause of the swelling of an application. The use of inappropriate asset images, such as images with too large resolutions, which are actually not needed on applications, becomes a common cause.

In the problem example of this time, we assume all the images already have the appropriate measurement that is needed in an application. Then what can we do to optimize our file assets? After checking back, the asset used in this project is to use image assets with extensions jpg and png. We can change this standard to the latest extension that is more optimum in terms of compression, namely WebP.

WebP is designed to provide better image compression with an image quality equivalent to or better than other image formats.

WebP Advantages:

Better Compression Quality:
WebP typically provides smaller file sizes with equal or better image quality compared to other image formats such as JPEG and PNG.
Transparency:
WebP supports alpha transparency, which allows it to be a good alternative to the PNG image format.
Animation
WebP supports animation, making it a good alternative to the GIF image format.

After making changes to the image format in our application, we can rebuild the image size and see how much of a decrease happens to our assets.

Before:

After:

After we checked back on the analyzing tools, it turned out there was an asset-size increase, not a decrease. Don't worry, it turns out when we use WebP they might appear to have a larger size when analyzed with flutter analyze. This might seem counterintuitive since one of the main advantages of WebP is its superior compression compared to other image formats like PNG or JPEG.

The flutter analyze tool might interpret the size of the WebP images differently than other image formats. It might consider the uncompressed or maximum size of the image when calculating the size, leading to the appearance of a larger size.

So how do we know if the optimization of changes to our app is either to optimize our app size or to add more content to our app? Here we can take advantage of the Google Play app size analyzer, where Google Play does provide app download size breakdowns.

Here you can see that after implementation, our assets files experienced a significant decline of about 48.67% from 12 MB to 6.16 MB.

🌟 Conclusion

By measuring app size on our app, we can figure out the size distribution that happens on our application, and it makes it easy for us to focus on what needs to be optimized based on the breakdown size of our app.

📄 References

Measuring your app's size

Unlock Seamless App Environments with Flutter Flavors: A Must-Know Guide!

Vincentius Westley — Thu, 04 Apr 2024 05:57:49 +0000

In an era of so much rapid development in this field of technology, efficiency and speed in the development of a mobile application are very important. In this article, I will discuss the flavor of Flutter that makes mobile application development more simple and seamless, as well as the solution to the problem of efficiency and speed in the development of mobile applications that we are facing today.

🔍 Navigating the Challenges

Imagine you, as a mobile developer, are asked to create a complex application. You are asked for your application to have several versions for several target users. For example, in an application that already exists in the Play Store and App Store, you are required to create three applications: applications that are used for global users, applications used for testers, and the last application used for developers.

If you create the three applications manually, imagine how tricky and time-consuming the development process is. You need to customize the UI, change the source of your data, and build it one by one for every required application. In some cases, you may even need more than three of the same applications in different environments.

Here's the flavor role that can help simplify and shorten the problem that was discussed earlier: With Flutter Flavor, you just need to create one source code; all you need to do is just configure whatever environment you're going to make and whatever content or assets that you'll make dynamic on each application in a different environment. So implementing Flutter Flavor will not only speed up and simplify the development process, but it will also reduce the risk of errors that will occur if you separate ingredients manually.

🔧 How it works?

In this current case, we will try to differentiate the application name, application logo, and base URL API for every application variant. This configuration will later be encapsulated in every flavor file you create, which will then be dynamically accessible to your source code in real time.
To illustrate how Flutter Flavor works, first we need to name our three applications as more clear and understandable environments by engineers; usually, these three environments will be separated into "production, staging, and development.”

Production
This environment will be used for the entire final user that will be using your application, which will be on the Play Store and App Store.
Staging
This environment will be used for application testing that also reflects production data without interfering with original production data.
Development
This environment will be used for developers, where developers develop applications and also experiment.

The way it works is that you need to define the three environments described; each environment needs a configuration file that contains contents that you’re going to create dynamically (in this case, the name of the application, the application's logo, and the API base URL). Then you have to do the configuration on each native platform (Android and iOS), so that the native platform that you build will later know the three platforms that you have created.

After making the configurations on the native platform, you also need to configure the IDE that you use (Android Studio or Visual Studio Code) so the IDE knows every environment you’ve created, which later will make it easier for you when running or debugging your applications (you just need to choose the environment that you’re going to run).

💻 Implementation

Let's demonstrate the implementation of flavors in a Flutter project using the example outlined above:

Step 1: Create Flavor Configuration Files

flavor_config.dart

import 'package:flutter/material.dart';

// Define an enum for every environment you want to create.
enum Flavor { prod, staging, dev }

// Add more values as needed.
class FlavorValues {
  final String apiBaseUrl;
  final String appIcon;
  final String appName;

  FlavorValues({
    required this.apiBaseUrl,
    required this.appIcon,
    required this.appName,
  });
}

class FlavorConfig {
  final Flavor flavor;
  final String name;
  final Color color;
  final FlavorValues values;
  static late FlavorConfig _instance;

  factory FlavorConfig({
    required Flavor flavor,
    // Color is an optional value that will be used for the flavor banner.
    // Flavor banner is one way to identify the environment you used.
    // You can remove this line of code if you don't need it.
    Color color = Colors.blue,
    required FlavorValues values,
  }) {
    _instance = FlavorConfig._internal(flavor, flavor.name, color, values);
    return _instance;
  }

  FlavorConfig._internal(this.flavor, this.name, this.color, this.values);

  static FlavorConfig get instance {
    return _instance;
  }

  // Method to check your current environment in your realtime code
  static bool isDevelopment() => _instance.flavor == Flavor.dev;

  static bool isStaging() => _instance.flavor == Flavor.staging;

  static bool isProduction() => _instance.flavor == Flavor.prod;

Step 1.5 (Optional): Create Flavor Banner Configuration Files

flavor_banner.dart

import 'dart:io';

import 'package:flutter/material.dart';

import 'flavor_config.dart';

const double _kHeightBanner = 12.0;
const double _kOffsetBanner = 40.0;
final double _kSizeTriangle =
    _kOffsetBanner + 0.707 * _kHeightBanner * (Platform.isIOS ? 2 : 3);

class FlavorBanner extends StatelessWidget {
  final Widget child;
  final BannerConfig? bannerConfig;

  const FlavorBanner({
    Key? key,
    required this.child,
    this.bannerConfig,
  }) : super(key: key);

  @override
  Widget build(BuildContext context) {
    // You need to make sure your flavor banner doesn't show up in production.
    // If you want to show the banner in production, delete this line below.
    if (FlavorConfig.isProduction()) return child;
    BannerConfig config = bannerConfig ?? _getDefaultBanner();

    return Stack(
      children: <Widget>[
        child,
        _buildBanner(
          context: context,
          bannerConfig: config,
        ),
      ],
    );
  }

  BannerConfig _getDefaultBanner() {
    return BannerConfig(
      bannerName: FlavorConfig.instance.name,
      bannerColor: FlavorConfig.instance.color,
    );
  }

  // Creating banner allies so the banner will not be too long and overlap the UI.
  String getBannerAlias(String bannerName) {
    switch (bannerName) {
      case "production":
        return "PROD";

      case "stage":
        return "STAGE";

      case "dev":
        return "DEV";

      default:
        return "";
    }
  }

  Widget _buildBanner({
    required BuildContext context,
    required BannerConfig bannerConfig,
    BannerLocation location = BannerLocation.topStart,
  }) {
    return CustomPaint(
      painter: BannerPainter(
        message: getBannerAlias(bannerConfig.bannerName),
        textDirection: TextDirection.ltr,
        layoutDirection: TextDirection.ltr,
        location: location,
        color: bannerConfig.bannerColor,
      ),
      child: ClipPath(
        clipper: _TriangleClipper(location: location),
        child: Container(
          width: _kSizeTriangle,
          height: _kSizeTriangle,
          color: Colors.transparent,
        ),
      ),
    );
  }
}

class BannerConfig {
  final String bannerName;
  final Color bannerColor;

  BannerConfig({required this.bannerName, required this.bannerColor});
}

class _TriangleClipper extends CustomClipper<Path> {
  _TriangleClipper({
    required this.location,
  });

  BannerLocation location;

  @override
  Path getClip(Size size) {
    final path = Path();
    if (location == BannerLocation.topStart) {
      path.lineTo(size.width, 0);
      path.lineTo(size.width, Platform.isIOS ? 0 : size.height / 4);
      path.lineTo(0, size.height);
      path.lineTo(0, 0);
    }
    if (location == BannerLocation.topEnd) {
      path.lineTo(size.width, 0);
      path.lineTo(size.width, size.height);
      path.lineTo(0, Platform.isIOS ? 0 : size.height / 4);
      path.lineTo(0, 0);
    }
    if (location == BannerLocation.bottomStart) {
      path.lineTo(0, 0);
      path.lineTo(size.width, size.height);
      path.lineTo(0, size.height);
      path.lineTo(0, 0);
    }
    if (location == BannerLocation.bottomEnd) {
      path.lineTo(size.width, 0);
      path.lineTo(size.width, size.height);
      path.lineTo(0, size.height);
      path.lineTo(size.width, 0);
    }
    return path;
  }

  @override
  bool shouldReclip(CustomClipper<Path> oldClipper) {
    return false;
  }
}

Step 2: Create a mains file for every environment you’ve created

main_prod.dart

import 'main.dart';
import 'utils/flavor_config.dart';

void main() async {
  FlavorConfig(
    flavor: Flavor.prod,
    values: FlavorValues(
      apiBaseUrl: "https://apibaseurl-prod.com",
      appIcon: "assets/images/app_icon_prod.png",
      appName: "Application Production",
    ),
  );

  // Call your main method in here
  initializeApp();
}

main_staging.dart

import 'utils/flavor_config.dart';
import 'main.dart';

void main() async {
  FlavorConfig(
    flavor: Flavor.staging,
    values: FlavorValues(
      apiBaseUrl: "https://apibaseurl-staging.com",
      appIcon: "assets/images/app_icon_staging.png",
      appName: "Application Staging",
    ),
  );

  // Call your main method in here
  initializeApp();
}

main_dev.dart

import 'utils/flavor_config.dart';
import 'main.dart';

void main() async {
  FlavorConfig(
    flavor: Flavor.dev,
    values: FlavorValues(
      apiBaseUrl: "https://apibaseurl-dev.com",
      appIcon: "assets/images/app_icon_dev.png",
      appName: "Application Dev",
    ),
  );

  // Call your main method in here
  initializeApp();
}

and your original main.dart will looks like this

import 'package:flutter/material.dart';
import 'package:flutter_flavor_implementation_example/presentations/home_page.dart';
import 'package:flutter_flavor_implementation_example/utils/flavor_banner.dart';
import 'package:flutter_flavor_implementation_example/utils/flavor_config.dart';

void initializeApp() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: FlavorConfig.instance.values.appName,
      theme: ThemeData(
        colorScheme: ColorScheme.fromSeed(seedColor: Colors.deepPurple),
        useMaterial3: true,
      ),
      builder: (_, child) {
        return FlavorBanner(
          child: child ?? const SizedBox(),
        );
      },
      home: HomePage(title: FlavorConfig.instance.values.appName),
    );
  }
}

and your home_page.dart will looks like this

import 'package:flutter/material.dart';
import 'package:flutter_flavor_implementation_example/utils/flavor_config.dart';

class HomePage extends StatefulWidget {
  final String title;

  const HomePage({super.key, required this.title});

  @override
  State<HomePage> createState() => _HomePageState();
}

class _HomePageState extends State<HomePage> {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        backgroundColor: Theme.of(context).colorScheme.inversePrimary,
        title: Text(widget.title),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            Text(
              'You currently running the app using ${FlavorConfig.instance.name} env',
            ),
            Text(
              "\nYour current environment base url is \n${FlavorConfig.instance.values.apiBaseUrl}",
              textAlign: TextAlign.center,
            ),
          ],
        ),
      ),
    );
  }
}

Make sure, after following all the steps above, you have all the required files and your project structure looks like this:

Step 3: Setting up flavor in iOS by configuring the schemes
In this step, you will configure iOS bundle schemes and bundle identifier

Open your project in Xcode (ios/Runner.xcworkspace).
In your Runner Project, add -production suffix in the current configuration. To rename the configuration, simply double-click the configuration and make sure it looks like this:
Now, you need to duplicate every configuration for every flavor you have by selecting the Add (+) icon and duplicating the configuration. Make sure you duplicate the correct configuration. In order to make Debug-staging you need to duplicate it from Debug-production not Release-production or Profile-production and it applies to all configurations. After you duplicate all the configuration for every flavor, make sure your configuration looks like this:
Now in your Runner Targets, go to Build Settings, search for Product Bundle Identifier, and edit your bundle identifier by adding .staging and .dev suffix to your bundle identifier. We will exclude production because the production environment doesn't need the suffix.
After that, if you wanted to make your application name different between every flavor, you needed to go to Runner Targets, then go to Build Settings, and find Product Name. Change it to your desired application name.
After you change your Product Name, to apply the changes to your app name, go to your Info.plist. (Runner > Runner > Info). Update the Bundle Display Name value to $(PRODUCT_NAME).
Now, you need to rename your current scheme to production and also create two more schemes (staging and dev). You can rename your current scheme by opening Product > Scheme > Manage Schemes from the menu And then duplicate your Runner scheme. Make sure you name it production with lowercase because it is case-sensitive. After you duplicate your current scheme, you can safely delete it by using the Remove (-) icon in the left-bottom
Now, for the staging and dev you can create a new scheme by selecting Product > Scheme > New Scheme from the menu. Make sure it targets the Runner, and is also named with lowercase.
After that, you need to manage your staging and dev schemes so they target the correct configuration. To do that, you need to go to Product > Scheme > Manage Schemes from the menu. Select the staging scheme, and select the Build Configuration to correct the configuration you created. For example, in Run Menu, you need to change the Build Configuration to Debug-staging, and then in the Profile Menu, you need to change it to Profile-staging and apply it to all the menus. Do the same with the dev scheme.

Step 4: Setting up flavor in Android by configuring the bundle

Inside your Flutter project, navigate to android/app/build.gradle.
Create a flavorDimension to group your added product flavors. Gradle doesn’t combine product flavors that share the same dimension.
Add a productFlavors object with the desired flavors along with values for dimension, resValue, and applicationId or applicationIdSuffix.

defaultConfig {
  ...
}

buildTypes {
  release {
    ...
  }
}

// Add these lines of code.
flavorDimensions "app"
productFlavors {
    production {
        dimension "app"
        versionCode flutterVersionCode.toInteger()
        versionName flutterVersionName
        resValue "string", "app_name", "Flavor"
    }
    staging {
        applicationIdSuffix ".staging"
        dimension "app"
        versionCode flutterVersionCode.toInteger()
        versionName flutterVersionName
        resValue "string", "app_name", "Flavor Staging"
    }
    dev {
        applicationIdSuffix ".dev"
        dimension "app"
        versionCode flutterVersionCode.toInteger()
        versionName flutterVersionName
        resValue "string", "app_name", "Flavor Dev"
    }
}

Then, in your AndroidManifest.xml update your android:label to @string/app_name

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.vincwestley.flutter_flavor_implementation_example">
   <application
        android:label="@string/app_name"
        android:name="${applicationName}"
        android:icon="@mipmap/ic_launcher">
        <activity
            android:name=".MainActivity"
            android:exported="true"
            android:launchMode="singleTop"
            android:theme="@style/LaunchTheme"
            android:configChanges="orientation|keyboardHidden|keyboard|screenSize|smallestScreenSize|locale|layoutDirection|fontScale|screenLayout|density|uiMode"
            android:hardwareAccelerated="true"
            android:windowSoftInputMode="adjustResize">
            <!-- Specifies an Android theme to apply to this Activity as soon as
                 the Android process has started. This theme is visible to the user
                 while the Flutter UI initializes. After that, this theme continues
                 to determine the Window background behind the Flutter UI. -->
            <meta-data
              android:name="io.flutter.embedding.android.NormalTheme"
              android:resource="@style/NormalTheme"
              />
            <intent-filter>
                <action android:name="android.intent.action.MAIN"/>
                <category android:name="android.intent.category.LAUNCHER"/>
            </intent-filter>
        </activity>
        <!-- Don't delete the meta-data below.
             This is used by the Flutter tool to generate GeneratedPluginRegistrant.java -->
        <meta-data
            android:name="flutterEmbedding"
            android:value="2" />
    </application>
</manifest>

Step 5: Setting up your IDE launch configurations

5.1: Android Studio with UI

In your Android Studio Menu Bar, select Edit Configuration
Update your main.dart configuration to main_prod.dart, also change the Dart entrypoint to your main_prod.dart file location, and change the Build flavor value to production.
For staging, duplicate your main_prod.dart configuration.
Update all the configuration to target staging values: name, entrypoint, and build flavor.
Do the same for the dev configuration.

5.2: Android Studio Manually
In the root directory of your project, add a folder called .run. Inside the .run folder, create a file named main-prod.dart.run.xml, main-staging.dart.run.xml, and main-dev.dart.run.xml.

main-prod.dart.run.xml

<component name="ProjectRunConfigurationManager">
  <configuration default="false" name="main-prod.dart" type="FlutterRunConfigurationType" factoryName="Flutter">
    <option name="buildFlavor" value="production" />
    <option name="filePath" value="$PROJECT_DIR$/lib/main_prod.dart" />
    <method v="2" />
  </configuration>
</component>

main-staging.dart.run.xml

<component name="ProjectRunConfigurationManager">
  <configuration default="false" name="main-staging.dart" type="FlutterRunConfigurationType" factoryName="Flutter">
    <option name="buildFlavor" value="staging" />
    <option name="filePath" value="$PROJECT_DIR$/lib/main_staging.dart" />
    <method v="2" />
  </configuration>
</component>

main-dev.dart.run.xml

<component name="ProjectRunConfigurationManager">
  <configuration default="false" name="main-dev.dart" type="FlutterRunConfigurationType" factoryName="Flutter">
    <option name="buildFlavor" value="dev" />
    <option name="filePath" value="$PROJECT_DIR$/lib/main_dev.dart" />
    <method v="2" />
  </configuration>
</component>

5.3 Visual Studio Code
In the root directory of your project, add a folder called .vscode, Inside the .vscode folder, create a file named launch.json. In the launch.json file, add a configuration object for each flavor. Each configuration has a name, request, type, program, and args key.

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "prod",
      "request": "launch",
      "type": "dart",
      "program": "lib/main_prod.dart",
      "args": ["--flavor", "production", "--target", "lib/main_prod.dart" ]
    },
    {
      "name": "staging",
      "request": "launch",
      "type": "dart",
      "program": "lib/main_staging.dart",
      "args": ["--flavor", "staging", "--target", "lib/main_staging.dart" ]
    },
    {
      "name": "dev",
      "request": "launch",
      "type": "dart",
      "program": "lib/main_dev.dart",
      "args": ["--flavor", "dev", "--target", "lib/main_dev.dart" ]
    }
  ],
  "compounds": []
}

By following the steps above, you’ve implemented a Flutter flavor that will make it easier for us to do application management with multiple dynamic data points. It will also make it easier for us to do maintenance and provide flexibility as well as efficiency in the development process.

🔥 App Demo

You can check out the full source code here: Github

You will have three different apps for the singular code with different data and configurations.

⭐ Conclusion

Flutter flavor makes mobile application development more simple and seamless, as well as the solution to the problem of efficiency and speed in the complex development of mobile applications that need to implement multiple environments. Implementing Flutter Flavor will not only speed up and simplify the development process, but it will also reduce the risk of errors that will occur if you separate ingredients manually.

📄 References

Create flavors of a Flutter app