As most of you probably know by now, Google has recently announced that any Android app will need to be verified by Google before it can be installed on a certified Android device, even if the installation happens outside Google Play.

I have been developing Android applications for more than a decade, and I have witnessed firsthand all the “small” changes Google has rolled out over the years. In my view, these changes are slowly but surely destroying the idea of a truly open Android as we once knew it.

Beyond this concerning requirement, we are starting to see evidence that bootloaders may no longer be unlockable in the future. On top of that, Google has stopped releasing the device trees for the Pixel 10 series devices, which makes it much harder for custom ROMs to be ported to these devices. And then there is the growing push for Play Integrity, a technology that essentially forces you to run an app on a certified device with Play Services installed. When you put all these pieces together, the picture becomes very, very concerning.

The recent controversy

By making Android safer, we're protecting the open environment that allows developers and users to confidently create and connect. Android's new developer verification is an extra layer of security that deters bad actors and makes it harder for them to spread harm.

Starting in September 2026, Android will require all apps to be registered by verified developers in order to be installed on certified Android devices.

This is how Google introduced its new policy to every Android developer, regardless of whether they publish on the Play Store or not. From that moment on, if you want to install an app on a certified Android device, it will first have to pass Google’s verification process. And let me be clear here: that’s the overwhelming majority of Android devices in existence.

The verification process itself is very similar to what already exists inside Google Play. Developers basically have to provide identity documents and personal information so that Google can confirm who you are as an individual, or verify your legal identity if you are representing a company.

Google says this measure is “for user safety”. And while I do think that on some level this can help reduce the distribution of malware on Android devices, I think there’s more to this story than what we’re being told.

First, let’s clarify what a “certified Android device” actually is: it’s any version of Android that has been authorized by Google, where Google Play Services and the Play Store are pre-installed. In other words, almost every phone and tablet you can buy. You can see the list of certified brands here.

So yes, I can see how this might reduce the spread of malicious apps, since knowing the real identity of a developer can discourage bad actors. But at the same time, this effectively ends the privacy of many legitimate developers who contribute to the Android ecosystem, people who don’t write malware and who simply don’t want to hand over this type of personal information.

It also raises serious concerns about which types of apps may get banned. Think of apps that provide functionality outside of what Google officially allows, like some emulators or similar. This could easily extend to any app that Google —or anyone powerful enough to pressure Google— decides is “unacceptable”. And that takes us into the realm of political and geopolitical pressure, censorship, and ultimately turns Android into a closed ecosystem... almost exactly like Apple’s.

Yes, it’s true that many custom ROMs such as GrapheneOS or CalyxOS would remain outside of this system, meaning that users of these ROMs could still sideload any app they want without Google’s verification. But the real issue is that many developers may choose not to (or may not be allowed to) pass through this verification process. And in doing so, they risk losing exposure to a massive user base, along with the incentive to keep building apps for Android at all.

In other words, if a developer suddenly loses 99% of their potential audience, what real incentive do they have to keep building apps? This is why I believe the measure could indirectly hurt the entire custom ROM ecosystem as well.

No more unlockable bootloaders?

This trend could already harm custom ROMs by reducing the amount of software available to run on them, making life harder for their users. But the challenges for custom ROMs do not end there.

For those who may not know, in order to install a custom ROM such as LineageOS or GrapheneOS on an Android device, the bootloader must be unlockable. If the manufacturer decides to disable this option, then that device will only ever be able to run the stock operating system and nothing else. And as I mentioned earlier, some manufacturers, like Samsung, are already moving in this direction.

There are several reasons for this. It is very likely that manufacturers are under pressure from large institutions: banks, streaming services, and content providers with strict licensing requirements, to make sure their devices cannot easily be modified. A phone that allows custom ROMs makes it more difficult to enforce DRM and protect licensed content. There are also commercial motivations: manufacturers do not want to deal with warranty claims from users who bricked their phones while flashing custom software. And of course, there are the strategic interests of controlling the ecosystem itself.

In any case, if this trend continues and more manufacturers ship devices without unlockable bootloaders, custom ROMs could eventually cease to exist.

Device trees and components removed from AOSP

As if the situation were not already bad enough, there is more. In recent years Google has been steadily removing more and more components from AOSP. AOSP stands for Android Open Source Project, which is the open-source foundation of Android and the basis for all ROMs—including the “certified” ones. What Google has been doing is moving components out of AOSP and into their own proprietary repositories, which forces custom ROM developers to find their own replacements.

More recently, with the launch of the Pixel 10 series, Google announced that it would no longer be releasing the device trees for these models. A device tree is essentially the source code that describes the hardware: Android itself, drivers, and other key components that are required to run the operating system in that device. Without it, any ROM that wants to support the Pixel 10 will need to rely on reverse engineering.

To give you an idea of how complex reverse engineering can be: if I hand you a text file with clear instructions, all you need to do is follow them. But if I give you the same file scrambled with a secret code, and I don’t give you that code, you first have to decipher it before you can even start following the instructions. As you can imagine, the task suddenly becomes much, much more difficult.

About the adoption of Play Integrity

Finally, I want to talk about Play Integrity. This is a Google Play API that Android developers can currently choose to implement. What it does is basically ensure that your app only runs on a certified Android device with Play Services properly functioning.

Many apps already use this protection. For instance, the official ChatGPT app by OpenAI has it enabled, and it simply won’t run on a device without Play Services.

Right now this technology is optional, and it is up to each developer to decide whether or not to adopt it. But I would not be surprised if, over time, more and more pressure is applied to make adoption widespread, or perhaps even mandatory for all apps distributed through Google Play. To be clear, this is not the case today, and I am speculating here. Still, if this scenario were to materialize, it would mean that custom ROMs could no longer run any app that relies on this protection.

Conclusion

As you can see, the outlook is quite grim. The only realistic way I see this being stopped is through regulatory intervention. In Europe, for example, there are already laws like the Digital Services Act and especially the Digital Markets Act, which require so-called “gatekeepers” such as Google to allow the distribution of apps through alternative stores and sideloading. If Google’s verification process were to become too restrictive, it could very well attract the attention of European regulators.

In any case, I predict a very dark future for Android. I know my perspective may sound pessimistic, and I sincerely hope the future turns out brighter than what I am imagining. But as of now, I fear that Android is on the verge of abandoning the very freedom that once defined it.

One of Flutter’s key strengths is its ability to run on virtually all major platforms today. And while I often focus on mobile and web examples here on this blog, it’s important not to overlook the fact that Flutter is also a perfectly viable option for Windows, macOS, and Linux.

In fact, the latest major release, Flutter 3.32, introduced some quality-of-life improvements that are definitely worth exploring. So today, we’re going to take a look at working with multiple windows in Flutter desktop.

This won’t be a traditional tutorial. I’m trying out a more relaxed format where I’ll walk you through small but essential code snippets that show how to work with multiple windows. That said, if you’re looking for a more step-by-step guide, don’t worry, here you can access the complete source code, so you can run it and study it in detail.

The desktop_multi_window plugin

Before we dive into the implementation, let’s take a moment to understand how Flutter currently handles multiple windows on desktop.

Out of the box, Flutter doesn’t offer a fully abstracted or official solution for managing multiple windows. If you want to do it manually, you will need to write platform-specific code: creating new native windows and manually instantiating a second FlutterEngine for each one. It’s not exactly beginner-friendly, and definitely not ideal for cross-platform apps trying to stay within Dart code as much as possible.

That’s where the desktop_multi_window plugin comes in. This package wraps all of that complexity and gives us a clean API for creating and managing windows on Linux, macOS, and Windows, without having to dive into C++, Objective-C, or Windows APIs.

Under the hood, though, each of those windows runs its own separate Flutter engine, and they still rely on native code to communicate with each other. That’s why we use Flutter’s familiar MethodChannel system to pass messages between them. So, throughout the video, you’ll see things like MethodCall, invokeMethod, and similar patterns being used to send data back and forth.

Hopefully, the Flutter team will eventually introduce a more official and streamlined way to handle multi-window setups directly from Dart. But until then, this plugin is quite mature and works well for most practical use cases.

Create a class that represents a window

The first thing I recommend when working with multiple windows is to create a class that holds the properties related to each individual window. In my sample project, I created a class called WindowInfo, and here’s its basic structure:

class WindowInfo {
  final int id;
  final String name;
  final WindowController controller;

  WindowInfo({
    required this.id,
    required this.name,
    required this.controller,
  });
}

At the very least, you’ll want to store the window’s id and a WindowController, which will let you later close it, bring it to focus, or perform any other actions. I also added a name field to make identification easier. Depending on the kind of app you’re building, you can extend this class with any additional data you find useful to better manage your open windows.

In my project, I keep an array of these objects in memory so I can easily work with them later on.

Creating Windows

Let’s start by looking at how we can create new secondary windows from a main window.

Future<void> _createWindow() async {
    try {
      // Set window details
      final name = 'Window $_windowCounter';
      final windowConfig = {
        'name': name,
      };

      // Create the new window
      final windowController = await DesktopMultiWindow.createWindow(
        jsonEncode(windowConfig),
      );

      // Configure the window using the controller
      windowController
        ..setFrame(const Offset(100, 100) & const Size(800, 600))
        ..setTitle(name)
        ..show();

      // Add to our tracking list
      setState(() {
        _windows.add(
          WindowInfo(
            id: windowController.windowId,
            name: name,
            controller: windowController,
          ),
        );
        _windowCounter++;
      });
    } catch (e) {
      if (mounted) {
        ScaffoldMessenger.of(
          context,
        ).showSnackBar(SnackBar(content: Text('Failed to create window: $e')));
      }
    }
}

We begin by wrapping the whole operation in a try-catch block. That’s because anything related to window management can potentially fai, so better to be safe.

We’re going to prepare the data for the new window. Since we’re ultimately working with the native layer, DesktopMultiWindow relies heavily on plain JSON strings.

So first, we store the window’s name in a variable, and then we create a map that includes a "name" property.

Then we call DesktopMultiWindow.createWindow(), which launches the new window. This returns a WindowController object, which we can use to interact with the window later on.

Next, we configure some properties, position, size, title, and finally call show() to display it.

The final part of the method stores the window’s data in an array, so we can interact with it later. In my example, I’m using setState() just to keep things simple, but I recommend using your favorite state management solution in a real-world project.

Closing windows

Now let’s take a look at how we can close a secondary window when it’s no longer needed.

Future<void> _closeWindow(int windowId) async {
    try {
      // Find the window controller for this window ID
      final windowInfo = _windows.firstWhere((w) => w.id == windowId);

      // Use the controller's close method
      await windowInfo.controller.close();

      setState(() {
        _windows.removeWhere((w) => w.id == windowId);
      });
    } catch (e) {
      if (mounted) {
        ScaffoldMessenger.of(
          context,
        ).showSnackBar(SnackBar(content: Text('Failed to close window: $e')));
      }
    }
}

We start with a try-catch block, just like we did when creating windows. Then we look for the WindowInfo object that matches the window ID we want to close. This gives us access to the corresponding controller.

Once we have that, we simply call its close() method. That’s all it takes to close the actual native window.

After closing it, we also want to keep our internal list of windows clean, so we remove the corresponding WindowInfo from the array.

And finally, if anything goes wrong during the process, we show a quick message to the user using a SnackBar, or whatever error handling method you prefer.

Send messages to a secondary window

Let’s take a look at how to send messages from the main window to a secondary one.

Future<void> _sendMessageToWindow(int windowId) async {
    try {
      final response = await DesktopMultiWindow.invokeMethod(
        windowId,
        'message_from_main',
        'Hello from main window!',
      );

      if (mounted) {
        ScaffoldMessenger.of(
          context,
        ).showSnackBar(SnackBar(content: Text('Response: $response')));
      }
    } catch (e) {
      if (mounted) {
        ScaffoldMessenger.of(
          context,
        ).showSnackBar(SnackBar(content: Text('Failed to send message: $e')));
      }
    }
}

We start by using DesktopMultiWindow.invokeMethod(), which allows us to send a message directly to another window by its ID.

The first argument is the ID of the target window. The second is the method name, in this case, "message_from_main". And the third is the data we want to send, which is just a string message.

This method returns a response from the secondary window, if any. In this example, we display that response using a SnackBar, but you could use it however you like.

To receive messages in the secondary window, we first register a method handler during the initState() of our widget:

@override
void initState() {
    super.initState();

    // Listen for messages from the main window
    DesktopMultiWindow.setMethodHandler(_handleMethodCall);
}

This sets up the method that will handle incoming calls from other windows, typically from the main window.

Now here’s what the actual handler method looks like:

Future<dynamic> _handleMethodCall(MethodCall call, int fromWindowId) async {
    if (call.method == 'message_from_main') {
      final message = call.arguments.toString();

      ScaffoldMessenger.of(context).showSnackBar(
        SnackBar(content: Text(message)),
      );
      return 'Message received by secondary window ${widget.windowId}';
    }
    return null;
}

Inside this function, we check if the method is "message_from_main". If it is, we extract the message, display it using a SnackBar, and return a response indicating that the message was received.

This is the response that the main window gets back when it calls invokeMethod().

This simple setup lets each secondary window listen for commands or data from the main window, and respond if needed. And of course, you can add as many method types as your app requires.

Send messages to the main window from a secondary window

We have already seen how the main window can send messages to secondary ones. Now let’s quickly complete the picture by allowing secondary windows to send messages back to the main window.

This is all done in the same way, using DesktopMultiWindow.invokeMethod():

await DesktopMultiWindow.invokeMethod(
  0, // 0 is usually the ID of the main window
  'message_from_secondary',
  'Hello from window ${widget.windowId}',
);

The only difference here is that we’re targeting window ID 0, which represents the main window.

On the main window side, we handle this message with a method handler registered during initState():

@override
void initState() {
  super.initState();

  // Listen for messages from secondary windows
  DesktopMultiWindow.setMethodHandler(_handleMethodCall);
}

And here’s the handler itself:

Future<dynamic> _handleMethodCall(MethodCall call, int fromWindowId) async {
  if (call.method == 'message_from_secondary') {
    final message = call.arguments.toString();

    ScaffoldMessenger.of(context).showSnackBar(
      SnackBar(content: Text(message)),
    );

    return 'Message received by main window';
  }
  return null;
}

With this, you now have full two-way communication between windows using simple method calls and arguments.

Focusing a window

Let’s wrap up this overview by showing how to bring a specific window to the front.

Future<void> _focusWindow(int windowId) async {
    try {
      // Find the window controller for this window ID
      final windowInfo = _windows.firstWhere((w) => w.id == windowId);

      // Use the controller's show method to bring window to front
      await windowInfo.controller.show();
    } catch (e) {
      if (mounted) {
        ScaffoldMessenger.of(
          context,
        ).showSnackBar(SnackBar(content: Text('Failed to focus window: $e')));
      }
    }
}

First, we search for the WindowInfo object that matches the ID of the window we want to focus. That gives us access to its controller.

Then we simply call show() on the controller. Internally, this brings the window to the foreground if it’s already open. It’s an easy way to programmatically focus or activate any window you’ve previously created.

And that’s all it takes.

Conclusion

Today we explored how to manage multiple windows in a Flutter desktop app using the desktop_multi_window plugin. We looked at how to create and close windows, how to send messages back and forth between them, and how to bring any window into focus when needed.

Hopefully this gave you a solid overview of how multi-window support works in Flutter and how to integrate it into your own projects.

Thank you very much for reading this article to the end. I hope you have a wonderful rest of your day, goodbye.

I’ve been working with Flutter since the framework was still in its beta phase, and over the years, I’ve picked up quite a few tricks that help me achieve this goal. In this article, I want to share with you the five most important aspects I believe you should keep in mind when it comes to optimizing your Flutter application.

So without further ado, let’s dive in!

Avoid creating methods that return Widgets

One of the most common mistakes I see among Flutter developers —especially those who come from other frameworks or are just getting started— is creating methods that return widgets. While this might seem like a harmless shortcut to keep your code organized, it actually has a direct negative impact on your app’s performance.

Text createTextWidget() {
  return Text('Widget created inside a method.');
}

The reason is simple: every time Flutter’s build method runs and hits that method, it will create a brand-new widget instance. Even if nothing has changed, Flutter has no way of knowing that the widget is the same, because you’re giving it a freshly created object every single time. As a result, you lose Flutter’s ability to optimize the widget tree and avoid unnecessary rebuilds.

Let’s take a look at an example of this problem:

class ExampleWidget extends StatefulWidget {
  @override
  State<ExampleWidget> createState() => _ExampleWidgetState();
}

class _ExampleWidgetState extends State<ExampleWidget> {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: ListView(
        children: [
          for(int i = 0; i < 100; i++)
            _buildListItem('Item $i'),
        ],
      ),
    );
  }

  Widget _buildListItem(String title) {
    return ListTile(
      title: Text(title),
    );
  }
}

At first glance, this code looks clean and functional. However, every time Flutter rebuilds ExampleWidget, it will call _buildListItem() for every single item in the list, generating new widget instances even if the list hasn’t changed at all.

If your app refreshes this layout 60 times per second, you might think that Flutter would need to build 100 widgets for each refresh — that is, a total of 6,000 builds. However, Flutter applies plenty of optimizations under the hood. In this example, each list item ends up being built around 300 times.

The proper solution: extract the widget into a dedicated class.

Instead of building the list items through a method, it’s better to define a separate widget class for each item. This allows Flutter to compare widget instances properly and optimize rebuilds.

Let’s refactor the previous example:

class ExampleWidget extends StatefulWidget {
  @override
  State<ExampleWidget> createState() => _ExampleWidgetState();
}

class _ExampleWidgetState extends State<ExampleWidget> {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: ListView(
        children: [
          for (int i = 0; i < 100; i++)
            _ListItem(title: 'Item $i'),
        ],
      ),
    );
  }
}

class _ListItem extends StatelessWidget {
  final String title;

  const _ListItem({required this.title});

  @override
  Widget build(BuildContext context) {
    return ListTile(title: Text(title));
  }
}

Now, Flutter can treat each _ListItem as an independent widget. If the parent rebuilds, Flutter won’t recreate every list item unnecessarily — it will only update what’s needed.

If we go back to how many times Flutter builds each widget in the list, previously, Flutter was building each one around 300 times. Now, thanks to this small change, Flutter only needs to build the items in the list about 57 times. It’s also worth noting that other optimizations are happening under the hood here, especially with the ListView widget.

👉 As a rule of thumb, you should almost never create widgets inside methods. Instead, extract them into their own classes, even private ones within the same file; to help Flutter do its job efficiently. Your widget tree will be cleaner, your app will perform better, and you’ll make life easier for both yourself and the framework.

Prefer using ListView.builder() over passing a list of widgets

When rendering lists in Flutter, a common approach is to pass an array of widgets directly to the children parameter of ListView. While this works fine for small lists, it quickly becomes a problem as your list grows.

return Scaffold(
  body: ListView(
    children: [
      // Long list of widgets...
    ],
  ),
);

That’s because Flutter will instantiate all those widgets in memory immediately, even if most of them aren’t visible. This increases memory usage and slows down your initial build.

It’s true that Flutter won’t call the build() method for every widget right away — it only builds what’s visible plus a small buffer for smooth scrolling. However, since all widget instances already exist in memory, you’re still paying the cost upfront.

Let’s take a look at an example of this problem:

class WorkingWithListsWrong extends StatelessWidget {
  final List<String> items = List.generate(10000, (index) => 'Item $index');

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: ListView(
        children: [
          for (final item in items)
            ListTile(title: Text(item)),
        ],
      ),
    );
  }
}

In this example, we’re generating 10,000 items and passing them directly to ListView. Flutter will try to instance all 10,000 widgets immediately, even though the user will only see a small handful of them at any given time. This is a recipe for performance issues, especially on lower-end devices.

The proper solution: use ListView.builder()

To avoid this problem, simply use the builder constructor. Flutter will only create the widgets as they’re needed, keeping memory usage low and scroll performance smooth.

Here’s how you can refactor the previous example:

class ExampleWidget extends StatelessWidget {
  final List<String> items = List.generate(10000, (index) => 'Item $index');

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: ListView.builder(
        itemCount: items.length,
        itemBuilder: (context, index) {
          return ListTile(title: Text(items[index]));
        },
      ),
    );
  }
}

Now, instead of instantiating 10,000 widgets up front, Flutter will only instantiate the ones that are currently visible. This simple change massively improves performance, especially with large lists.

👉 As a rule of thumb, whenever you work with lists of dynamic or large data sets, you should always prefer ListView.builder() over passing an explicit list of widgets. It’s a small change that has a big impact, keeping your app fast and responsive, even as your data grows.

Avoid heavy logic and repeated calculations inside build()

One of the best ways to keep your Flutter app fast and responsive is to keep the build() method as light as possible. Remember: build() can be called many times during the lifecycle of your widget — much more often than you might expect. If you place heavy operations inside build(), you’re forcing Flutter to repeat that work over and over again.

But it doesn’t stop there. Even lightweight operations can become problematic if you repeat them unnecessarily inside the same build() method. Flutter executes everything inside build() line by line, so if you call the same calculation multiple times, it will recompute it every single time.

Let’s look at an example of this problem:

class ExampleWidget extends StatefulWidget {
  @override
  State<ExampleWidget> createState() => _ExampleWidgetState();
}

class _ExampleWidgetState extends State<ExampleWidget> {
  final List<int> numbers = List.generate(10000, (index) => index);

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        Text('Max number: ${_findMax()}'),
        Text('Is 5000 in the list? ${numbers.contains(5000)}'),
        Text('Max number again: ${_findMax()}'),
      ],
    );
  }

  int _findMax() {
    return numbers.reduce((a, b) => a > b ? a : b);
  }
}

In this example:

• _findMax() is called twice in the same build(), causing the calculation to run two times unnecessarily.

• numbers.contains(5000) is an expensive operation for large lists.

• Every time the widget rebuilds, these calculations will happen again.

The proper solution: compute once and reuse

The solution is simple: compute your values once, store them in local variables, and reuse them throughout build().

Here’s the improved version:

class ExampleWidget extends StatefulWidget {
  @override
  State<ExampleWidget> createState() => _ExampleWidgetState();
}

class _ExampleWidgetState extends State<ExampleWidget> {
  final List<int> numbers = List.generate(10000, (index) => index);

  @override
  Widget build(BuildContext context) {
    final maxNumber = _findMax();
    final contains5000 = numbers.contains(5000);

    return Column(
      children: [
        Text('Max number: $maxNumber'),
        Text('Is 5000 in the list? $contains5000'),
        Text('Max number again: $maxNumber'),
      ],
    );
  }

  int _findMax() {
    return numbers.reduce((a, b) => a > b ? a : b);
  }
}

Now, even if build() is called multiple times, each expensive operation only runs once per build. This keeps your UI fast and avoids redundant work.

But, we can do it even better: move calculations to initState():

class ExampleWidget extends StatefulWidget {
  @override
  State<ExampleWidget> createState() => _ExampleWidgetState();
}

class _ExampleWidgetState extends State<ExampleWidget> {
  final List<int> numbers = List.generate(10000, (index) => index);
  late int maxNumber;
  late bool contains5000;

  @override
  void initState() {
    super.initState();
    maxNumber = _findMax();
    contains5000 = numbers.contains(5000);
  }

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        Text('Max number: $maxNumber'),
        Text('Is 5000 in the list? $contains5000'),
        Text('Max number again: $maxNumber'),
      ],
    );
  }

  int _findMax() {
    return numbers.reduce((a, b) => a > b ? a : b);
  }
}

With this approach, the heavy calculations happen only once during the widget’s lifecycle. Even if the widget rebuilds multiple times (for example, because of unrelated UI updates), the values are already stored and reused, keeping your build() method clean and extremely fast.

👉 As a rule of thumb, avoid placing heavy logic inside build(), and always compute your values once per build, or even better, once per widget lifecycle (if possible).

Use Isolates for heavy computations

Flutter runs your app’s code in a single thread called the main isolate. This thread handles both your app’s logic and its UI rendering. If you perform heavy computations on the main isolate, such as image processing, large data parsing, or complex mathematical calculations, you risk blocking the UI thread, leading to janky animations, delayed interactions, or even complete freezes.

To avoid this, you can offload heavy tasks to a separate Isolate. Flutter provides this mechanism specifically to help you run CPU-intensive work in parallel without impacting the smoothness of your app.

Imagine you’re applying a filter to an image inside your build() or right after loading it on the main thread:

class ExampleWidget extends StatefulWidget {
  @override
  State<ExampleWidget> createState() => _ExampleWidgetState();
}

class _ExampleWidgetState extends State<ExampleWidget> {
  late Image filteredImage;

  @override
  void initState() {
    super.initState();
    _applyFilter();
  }

  Future<void> _applyFilter() async {
    final image = await loadImage(); // Simulated image loading
    final result = applyHeavyFilter(image); // Heavy operation on main thread
    setState(() {
      filteredImage = result;
    });
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: filteredImage != null
          ? filteredImage
          : const Center(child: CircularProgressIndicator()),
    );
  }

  // Simulated functions
  Future<Image> loadImage() async {
    await Future.delayed(const Duration(milliseconds: 100));
    return Image.asset('assets/image.png');
  }

  Image applyHeavyFilter(Image image) {
    final now = DateTime.now();
    while (DateTime.now().difference(now).inMilliseconds < 2000) {
      // Simulate heavy work
    }
    return image;
  }
}

In this example, applyHeavyFilter() simulates a heavy synchronous operation running on the main isolate. During this time, the app’s UI is blocked, and the user cannot interact with it.

The proper solution: use an Isolate

Let’s improve this by moving the heavy operation to a separate isolate. This way, the UI remains smooth while the processing happens in the background:

class ExampleWidget extends StatefulWidget {
  @override
  State<ExampleWidget> createState() => _ExampleWidgetState();
}

class _ExampleWidgetState extends State<ExampleWidget> {
  Image? filteredImage;

  @override
  void initState() {
    super.initState();
    _applyFilter();
  }

  Future<void> _applyFilter() async {
    final result = await compute(applyHeavyFilter, 'assets/image.png');
    setState(() {
      filteredImage = result;
    });
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: filteredImage != null
          ? filteredImage!
          : const Center(child: CircularProgressIndicator()),
    );
  }
}

// Top-level function for compute
Image applyHeavyFilter(String assetPath) {
  final now = DateTime.now();
  while (DateTime.now().difference(now).inMilliseconds < 2000) {
    // Simulate heavy work
  }
  return Image.asset(assetPath);
}

By using the compute() function, you offload the heavy task to a background isolate. Your main UI thread stays free to handle animations and user interactions.

👉 When your app needs to handle heavy operations like image processing, data parsing, or complex calculations, offload that work to an isolate. It keeps your app responsive and smooth, providing a much better user experience.

Optimize your images for performance

Images are often one of the biggest factors affecting your app’s performance. Poorly optimized images can lead to long loading times, high memory usage, and even frame drops if they’re not handled carefully.

There are three main things to consider when using images in your Flutter app:

1. Use multiple resolutions of your images

Flutter supports 1x, 2x, and 3x image variants. This allows you to provide lower-resolution images for low-density screens and higher-resolution images for high-density screens. Flutter automatically selects the correct image based on the device’s pixel density.

If you don’t provide these variants, Flutter will scale your image, but it might load unnecessarily large images on devices that don’t need them, wasting memory and processing power.

For example, if you only include a large image in your assets like this:

Image.asset('assets/images/large_image.png')

And your image is 3000x3000 pixels, even devices that display it at much smaller sizes will load the full-resolution asset. This increases memory usage and slows down your app.

The correct approach is to provide proper resolution variants following Flutter’s conventions:

assets/images/large_image.png       // 1x — 300x300 px
assets/images/2.0x/large_image.png  // 2x — 600x600 px
assets/images/3.0x/large_image.png  // 3x — 900x900 px

Flutter will automatically pick the right image based on the device’s screen density, giving you better performance without sacrificing image quality.

2. Use the right image format

Different formats serve different needs:

• PNG for images requiring transparency or sharp edges (like icons).

• JPEG for photos and complex images with lots of colors.

• WebP for modern, highly compressed images that support both transparency and photos.

Choosing the right format ensures a good balance between quality and file size.

3. Compress and size your images properly

No matter the format, always compress your images and use the correct resolution. Avoid using images straight from design tools or cameras at full resolution. For example, if your design only displays an image at 300x300 pixels, there’s no need to load a 3000x3000 pixel asset. Oversized images consume unnecessary memory and slow down your app.

👉 Images are a critical part of your app’s performance. By providing proper resolution variants, choosing the right formats, and compressing your assets, you’ll reduce your app’s memory usage and improve loading times, all while keeping your UI crisp and fast on every device.

Final thoughts

And that’s my top 5 tips to help you improve your Flutter app’s performance. If you found this article helpful, feel free to check out my YouTube channel as well, where I talk about Flutter development, new versions of the framework, and plenty of other topics that you’ll definitely find interesting!

Thank you for reading all the way to the end, I hope you have a beautiful rest of your day!

While these changes are intended to improve the platform's security, they have caused concerns for some developers, especially independent developers with personal accounts, myself included. The most significant worry is related to the new requirement for personal developers to publicly disclose their home address in their developer profile, which can be seen by anyone. For indie developers and individuals who value their privacy, this is understandably alarming.

In this article, I will try to explain in a simple way what this whole issue is about, what potential problems it implies for small developers, and finally I will try to give some clues on how to try to handle this situation better.

Understanding Google Play verification process

The Google Play account verification process is designed to identify developers and make apps within the platform safer and more trustworthy.

For individual developers with a personal account, Google mandates that you verify your identity by submitting documentation such as an official ID and a proof of address. The key challenge lies in the fact that personal developers must use their residential address for this verification. This address is then made publicly available if your app includes in-app purchases, which can be unsettling for many.

Here’s a breakdown of how the process works:

Personal Accounts:

• Identity Verification: You are required to provide a government-issued identification document (e.g., a passport or driver’s license).

• Address Verification: You must submit a document showing your residential address, such as a utility bill, bank statement, or lease agreement. Unfortunately, virtual office addresses or PO boxes are not accepted for personal accounts.

• Public Disclosure: If you offer in-app purchases, both your name and full home address will be visible on your Google Play profile. If not, only your name and country will be shown.

Organization Accounts:

• For developers using organization accounts, the process is slightly different. Businesses can use a registered business address rather than a personal address, providing an extra layer of privacy. This option makes it easier for companies to maintain privacy while complying with Google's policies.

In contrast to other platforms like Apple’s App Store, which allows more flexibility with virtual office addresses in some cases, Google Play has adopted a stricter stance. As a result, many personal developers are now in a difficult position, needing to expose sensitive information or explore costly alternatives to comply with the rules.

The problem: why personal developers are worried

One of the biggest concerns for developers with personal accounts with this new verification process is the public disclosure of sensitive information. For developers using a personal account, Google requires them to verify their home address, which, in some cases, is made visible to the public. This can be alarming, as it raises privacy and safety issues, especially for individuals who work from home.

Many developers feel uncomfortable with their home addresses being available online for anyone to see. This is especially problematic for indie developers, freelancers, or those who prefer to keep their personal and professional lives separate. In online forums and developer communities, there have been multiple discussions about these concerns, with some developers sharing their frustrations about the lack of alternatives, such as using virtual offices or PO boxes.

While organization accounts allow developers to use a business address, personal accounts don’t offer this flexibility. This forces many developers to either disclose their home address or consider other costly solutions, such as forming a business just to meet the verification requirements.

Alternatives to using a home address

Based on my own experience and the experience of other developers I have discussed this issue with, it appears that this new personal account verification process does not allow the use of alternative addresses, such as virtual offices or PO boxes. These services allow you to rent a professional address for business correspondence without revealing your home location. However, sending to the review team your contract with one of these services, or any document that proves that it is actually legitimate for you to operate with that address, will cause your document to be rejected due to not being one of the documents accepted in the personal account verification process.

So the question is, is there any alternative?

Unfortunately, if you're using a personal account, the options are limited. Some developers have attempted to redirect utility bills to alternative addresses, but this approach depends on your location and whether it's feasible in your case. Otherwise, forming an organization or business may be the only way to use a business address legally for verification purposes.

Converting to an Organization account

Switching to an organization account can provide a key benefit for developers who are concerned about privacy: it allows you to use a business address instead of your home address, which is required for personal accounts. This can help protect your personal information from being publicly visible on your Google Play profile. However, forming a business comes with its own set of challenges. Depending on where you live, the cost of starting a company can be quite high, which may not be practical for indie developers or those working on a small scale.

Additionally, running a business introduces legal responsibilities like handling taxes and managing paperwork, which can add complexity and administrative burdens.

It’s also worth noting that in the near future, a new policy will come into effect: for certain types of services, developers are required to register as an organization. This includes apps related to financial services (e.g., banking, loans, cryptocurrency), health and medical apps, VPN services, and government apps. If your app falls into one of these categories, you must create an organization account to comply with Google’s policies. In these cases, switching to an organization account is not just a matter of privacy but also a regulatory requirement.

Practical workarounds for personal developers

For developers who can’t or don’t want to switch to an organization account, the options for protecting your privacy while complying with Google’s policies are limited but not impossible. Although Google doesn’t currently allow virtual offices or PO boxes for personal accounts, there are still a few workarounds you can try to avoid using your home address.

One potential workaround is to redirect certain types of utility bills or other official documentation to an alternative address. For example, if you have access to a secondary property or a family member’s address that you can legally use, you might be able to switch your billing details to that location. Once you have a utility bill or another acceptable document tied to this alternative address, you can submit it for Google’s verification process.

Another option could be renting a co-working space or shared office that provides you with an address and utility services. In some cases, co-working spaces issue utility statements or receipts that can be used for verification.

These workarounds might not be feasible for everyone, and while they don’t offer the same long-term solution as converting to an organization account, they could provide a solution to meet Google’s requirements while protecting your privacy as a personal developer.

Conclusion

In summary, Google Play’s new verification requirements have introduced challenges for personal developers, particularly around the public disclosure of home addresses. While these policies aim to improve transparency and safety on the platform, they have raised valid privacy concerns. For many indie developers, the options are limited—either comply with the rules as they are or explore costly alternatives like switching to an organization account.

However, practical workarounds, such as using alternative addresses for documentation, may offer some relief for those who are not ready to make the leap to an organization account. Regardless of the approach you choose, it’s important to stay informed and prepared if you still have to start this verification process.

I hope this article has been helpful to you, and I regret that I can't offer more definitive solutions to this issue. I hope that in the future, Google will reconsider its policies to better balance transparency and security with the privacy and well-being of developers.

I hope you have a beautiful rest of your day, goodbye.

If you haven't installed Flutter yet, here are some step-by-step videos that will guide you through the process of installing Flutter on Mac, Windows, and Linux.

Creating a basic Flutter app

Let's start by creating a basic application. You can do it from the menus of your favorite code editor, although I always prefer to do it from the terminal:

flutter create flutter_test_app

This command will create a basic counting app that, when executed, allows us to increment a numerical value by clicking on a button:

The goal of this sample code is to give you a first introduction to Flutter. We are going to go little by little to understand this template that is already given to us.

The pubspec.yaml Configuration File

The first thing we are going to look at is the pubspec.yaml file:

This file contains essential application metadata, enumerates all dependencies, and includes various configuration settings. If you open it, you will find comments for each section that explain their purpose. However, for clarity, we'll remove these comments to keep the file straightforward and briefly overview each segment:

name: flutter_test_app
description: "You can add a description for your project here."
publish_to: 'none'
version: 1.0.0+1

environment:
   sdk: '>=3.2.6 <4.0.0'

Let's clarify the meaning of each parameter:

• name: This represents the project's name. It serves as an "internal" identifier and is not the name presented to your users.

• description: This field allows you to provide a brief outline of your project's purpose.

• publish_to: This setting is primarily relevant for package development. Since this article focuses on basic concepts, we'll leave it unchanged.

• version: Here, you can specify your project's version using semantic versioning followed by an additional integer. This practice enables version control directly from this file, which then applies across platform-specific projects. The trailing integer typically corresponds to the versionCode in Android projects.

• environment: This specifies the compatible Dart SDK version range for your application. If in the future you want to use new versions of the Dart SDK you might be interested in modifying it, but for now, we leave it as is.

dependencies:
  flutter:
    sdk: flutter
  cupertino_icons: ^1.0.2

dev_dependencies:
  flutter_test:
    sdk: flutter
  flutter_lints: ^2.0.0

The next part focuses on the application's dependencies, which are categorized into two types: those incorporated into the app's final package (dependencies) and those used during development but not included in the final app package (dev_dependencies). To grasp this distinction, let's examine the flutter_lints package as an example. This package aids in static code analysis, which is performed locally on your machine. There's no need for it to be part of the final app package distributed to users.

After adding flutter_lints to your dev_dependencies and running flutter pub get, you can analyze your code according to the lint rules specified by flutter_lints using the command flutter analyze. This command checks your code for issues based on the linting rules defined by the package.

For finding new packages, Flutter developers often visit https://pub.dev. Say you want to do a network request to a remote server using the http package, you can simply add it to your dependencies and then execute flutter pub get to fetch the package and make it ready to use.

Alternatively, you can use the command flutter pub add http to not only download but also automatically add the http package to your dependencies. To add a package to dev_dependencies, you would use flutter pub add --dev package_name.

Experimenting with these methods can help you determine the most comfortable way to manage packages in your Flutter application.

flutter:
  uses-material-design: true

Towards the end of the file, there's a section labeled "flutter," featuring the uses-material-design: true setting. This particular setting informs Flutter that our application will utilize the Material Design style, providing a suite of visual, interaction, and motion design guidelines developed by Google.

As you advance more into Flutter development, you'll encounter a range of additional configurations that can be applied within this file to further personalize themes and other aspects of your app.

Additionally, it's worth mentioning the pubspec.lock file, a crucial component of Flutter projects. This file is automatically generated by Flutter when you run commands like flutter pub get or flutter pub add. Its primary purpose is to record the exact versions of each dependency used in your project at the time these commands are executed. This ensures that your project remains consistent and stable, even if dependencies are updated in the future. By tracking these versions, the pubspec.lock file helps to prevent the "it works on my machine" problem by ensuring that every developer working on the project uses the same versions of dependencies, thus minimizing conflicts and compatibility issues.

Platform-Specific Projects in Flutter

Within a Flutter project, beyond the pubspec.yaml and pubspec.lock files, you'll notice several directories named after platforms. These directories are android, ios, macos, linux, and windows. These aren't just folders; they're complete native projects for their respective platforms.

Flutter's strength lies in its ability to provide a multi-platform development framework, hiding the complexities of platform-specific implementation details. Yet, the existence of these platform-specific projects is crucial for Flutter to operate seamlessly across different environments.

There are instances when you'll need to dip into native development within these directories. This is often the case when certain functionality can only be achieved with platform-specific code. It's in these scenarios that modifications to the native parts of a project become necessary.

It's important to note that you're not required to maintain all these directories if your app doesn't target all supported platforms. For instance, if your focus is solely on Android and iOS, you can safely remove the macos, linux, and windows directories.

Conversely, should you decide to expand your app's availability to additional platforms not initially included in your project, Flutter simplifies this expansion. Using the flutter create command with the --platforms option, you can add the necessary platform projects. For example, if you start with a project only supporting Android and iOS and later decide to include support for macOS, Linux, and Windows, you can execute flutter create --platforms=macos,linux,windows . This command creates the required directories for the new platforms to be supported.

Your app's source code: the lib directory

We have already seen the main files and directories of a Flutter project, although it is true that I have not listed them all, for now I have described the most relevant ones that you should know from the beginning. Now let's jump to the lib directory, the place where all the Dart code that makes up your application resides.

When you create a new project, Flutter automatically generates the main.dart file within the lib folder. This file contains the source code responsible for the counter app that you see if you run the project. If you enter, you will see some comments that explain each section. As before, we are going to eliminate these comments and we are going to explain each part little by little:

import 'package:flutter/material.dart';

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

The first line introduces an import of material.dart. This import is essential because, by default, we use Material widgets to construct the user interface.

Following that, we encounter the main() method. Every Dart application, Flutter included, requires an entry point, which is provided by the main() function. Within this function, we call runApp(), enabling the application to launch. We pass it an instance of MyApp, which is the next widget we come across in the file:

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

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        colorScheme: ColorScheme.fromSeed(seedColor: Colors.deepPurple),
        useMaterial3: true,
      ),
      home: const MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

This snippet introduces the MyApp widget, serving as the foundational element of your application. It's at the top of the widget hierarchy, essentially acting as the root from which all other widgets will branch out. Flutter apps are structured as a vast tree of widgets, where each widget may be a parent or a child to others. Here, MyApp stands as the initial node in this interconnected structure.

MyApp is defined as a class that extends StatelessWidget. StatelessWidgets are characterized by their lack of internal state—they don't manage any data that changes over time. Consequently, a StatelessWidget does not rebuild itself in response to internal data changes. Further details on this will be provided as we progress.

Every StatelessWidget must implement the Widget build(BuildContext context) method. This method is where the app's user interface is constructed. In this example, we create a MaterialApp widget within this method. MaterialApp facilitates the development of an app following Material Design guidelines, including aspects like the app's title and theme.

The home attribute specifies the widget that will be displayed when the app starts. Here, it's set to MyHomePage, which is the widget that comes next in the file:

class _MyHomePageState extends State<MyHomePage> {
  int _counter = 0;

  void _incrementCounter() {
    setState(() {
      _counter++;
    });
  }

  @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>[
            const Text(
              'You have pushed the button this many times:',
            ),
            Text(
              '$_counter',
              style: Theme.of(context).textTheme.headlineMedium,
            ),
          ],
        ),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: _incrementCounter,
        tooltip: 'Increment',
        child: const Icon(Icons.add),
      ),
    );
  }
}

MyHomePage is a widget similar to MyApp, but it inherits from StatefulWidget instead of StatelessWidget. This distinction introduces two related classes: MyHomePage itself, which sets up the widget, and _MyHomePageState, a class that manages the widget's state, extending State.

The reason _MyHomePageState starts with the underscore symbol (_) is to indicate that this class must be private within this file.

In the state class, we're obliged to implement the Widget build(BuildContext context) method again. However, this time it's within the state class, where we define a widget tree that composes the counter interface:

• Initially, a Scaffold widget lays out the basic structure of our screen, considering elements like system navigation bars.

• An AppBar acts as the top navigation bar, where we specify a title and modify the background color using themes.

• The Scaffold's body comprises a Center widget, which ensures its content is centered on the screen. Inside the Center, we place a Column for vertical arrangement of widgets. This column contains two Text widgets: one displays a static message, and the other shows the dynamic _counter value, styled with the current theme.

• The floatingActionButton property of the Scaffold employs a FloatingActionButton widget. Positioned at the bottom right, this button is tasked with increasing the counter each time it's pressed.

Understanding State Management in Flutter

Now that we have seen roughly everything that is in the main.dart file, let's understand in a simple way how Flutter manages the state.

As I said before, the _MyHomePageState class is responsible for managing the state of the MyHomePage widget. In this case, we have an application with a numerical value that increments when a button is pressed. This is the state. Specifically, the variable that is defined at the beginning of the class:

  int _counter = 0;

  void _incrementCounter() {
    setState(() {
      _counter++;
    });
  }

When we invoke the _incrementCounter() method, it calls the setState method and within it the value of the _counter variable is incremented. By calling the setState method we are updating the state, telling Flutter that it has changed and causing the build method to run again, but this time with the updated state. Later, in the second Widget of type Text, the _counter variable is read to display the value on the screen.

This is a very simplified explanation of state management in Flutter, let's perform an experiment, add the following line just before build returns the Scaffold:

  @override
  Widget build(BuildContext context) {

    print('State refresh'); // <-- Add this new line

    return Scaffold(

Now run the application again and look at the output log. You will see the String "State refresh" printed when you run the application, but also when you modify the value of the counter.

As you can see, this is the simplest way to manage the state of your application in Flutter. In addition, you have also been able to observe the role of the build method and its importance when composing the interface based on state changes.

Your first app in Flutter: key concepts

If this is your first contact with Flutter, it is possible that at this point you are a little saturated with so much information, don't worry, I am going to list the key points that we have seen throughout the article.

• A Flutter project contains a pubspec.yaml file. It defines several configuration parameters as well as the list of packages that are used by the project.

• A Flutter project can contain several subdirectories named after a platform such as android or ios, these are the native projects that Flutter uses to run on each platform.

• Inside the lib directory we find the source code of the project, this is where we will write our files in Dart code to create our application.

• At its core, a Flutter app is structured as an extensive hierarchy of widgets. Widgets can be of two types: StatefulWidget, which holds state (variables that can change over time), and StatelessWidget, which does not hold state.

• We can alter the state of a StatefulWidget by using the setState method.

These are broadly the main basic points that you should know if you are getting started in developing applications with Flutter.

I hope this article has been useful to you. Do not hesitate to follow this blog and my YouTube channel if you want to continue learning about application development with Flutter, as well as stay up to date with news and other topics of interest about this magnificent framework.

Thanks for reading this far, happy coding!

If you have asked yourself this question lately, it is because in some way you are interested in Flutter, either for the mere fact of learning, because perhaps you are evaluating it for a possible project, or perhaps because you wonder if you could make a living as a Flutter developer working for companies.

My name is David, I have been a Flutter programmer since this framework was in beta, and in this channel, I teach and inform on everything related to Flutter development.

Before we start let me answer the question of whether it is worth learning Flutter in 2024, and the answer is that it depends. It depends a lot on what you are looking for. If you do it to learn new things, or if you are evaluating it for a possible project of yours, then yes, it is worth it. Now, if all you are interested in is finding a job, then perhaps you could consider other options.

Now that I have answered the main question in short, let me expand this information in more detail to understand if it is really a good idea to learn Flutter in 2024.

What makes Flutter different?

Let's understand for a moment the strengths and distinctive points of Flutter to be able to make a future projection of where this framework is headed:

• Flutter allows you to develop for Android, iOS, web, Linux, macOS, and Windows with a single codebase.

• Flutter has a feature called "hot reload", which allows you to see the changes you make to the code instantly on your device, significantly shortening development times.

• Flutter contains a rich library of visual elements, many of them based on the Material design guidelines and many others based on Cupertino, the visual style of iOS and macOS. Additionally, by installing third-party packages it is possible to emulate the visual style of Linux or Windows, among others.

• Flutter compiles to native code, which significantly increases its performance. The result is fast and light applications, which have nothing to envy of purely native development.

• Flutter uses Dart, a programming language that is easy to learn, powerful, strongly typed, null-safe, and with many interesting capabilities for all types of environments.

• Flutter has a strong and growing community due to its recent popularity and also Google's efforts to promote its use. This means that developers have a rich ecosystem of resources, including documentation, tutorials, YouTube channels like this one, forums, etc. where to ask for advice if you have any problem.

Now that we are clear about the strengths of Flutter, let me tell you in which cases I recommend learning Flutter in 2024 and in which cases I don't.

Why you should learn Flutter

Let's consider several scenarios in which I encourage you to learn Flutter:

→ To learn new skills

Diving into Flutter is a fantastic way to broaden your technical horizons. If what interests you is simply the joy of learning, then Flutter will meet your expectations. With its unique approach to UI design, efficient code structure, and the use of Dart, learning Flutter can significantly enhance your understanding of mobile app development, opening doors to other facets of the industry, and helping you improve your programming skills.

→ To evaluate it for a potential project

If you're considering various frameworks for an upcoming project, getting hands-on with Flutter can be incredibly insightful. Its ability to deliver high-performance, visually appealing apps across multiple platforms from a single codebase makes it a strong contender. By learning Flutter, you can effectively assess its fit for your project's specific needs, such as user interface requirements, development timeline, and overall performance expectations.

→ To create prototypes quickly

When it comes to turning ideas into tangible prototypes quickly, Flutter is a game-changer. Thanks to its vast widget library and hot reload feature, you can rapidly iterate designs and functionalities. This speed and flexibility are crucial in the early stages of development, where visualizing and modifying ideas quickly is key to successful project development and stakeholder communication.

→ To cut costs migrating from native to cross-platform

Transitioning from native app development to a cross-platform approach can be a strategic move to reduce costs and development time. Flutter stands out in this transition due to its single codebase feature, which eliminates the need to maintain separate codes for iOS and Android. This consolidation not only reduces initial development costs but also simplifies ongoing maintenance and updates, making it a cost-effective solution for long-term app development.

→ For education purposes

Whether you’re a student, educator, or self-learner, Flutter is an excellent educational tool. It’s designed to be intuitive and easy to learn, making it accessible for beginners. At the same time, its comprehensive capabilities offer depth for advanced learners. Flutter’s growing popularity also ensures that learners are gaining skills that are in demand in the current job market, providing a practical edge to their educational pursuits.

In each of these scenarios, Flutter's versatility, efficiency, and comprehensive features make it a standout choice for anyone looking to expand their app development skills.

Why you shouldn't learn Flutter

In the real world there are no generalities but rather each case is particular, for that same reason after seeing the specific cases in which I recommend learning Flutter, let's now see in which cases I recommend thinking carefully about it.

→ To make a living... in regions where there is no demand

Flutter is a great framework for creating applications, but it competes with other very good technologies such as React Native, which has been on the market longer, and also competes in a way against native development. If your only intention is to learn Flutter as a means of earning a living, then at least make sure that the region you live in is in demand for this type of technology. In some cases you may find that the demand for Flutter developers is low compared to the demand for native developers, for example. In this specific case, I would recommend that you choose wisely in which technology you are going to invest your time and energy.

If, on the other hand, after having done a search for the current demand you see that there are quite a few companies that are demanding Flutter programmers, then in that case it could be a good career path.

→ For applications requiring a high level of performance

This point sounds contradictory given that in the previous section I told you that Flutter has practically native performance. Let me qualify it:

For "normal" applications, without very specific performance requirements other than the mere fact that it runs fast and smoothly, then Flutter is a great candidate. However, at this point I am not talking about those types of applications. At this point I am referring to applications that have performance requirements well above average, we are talking for example about video editors, graphics engines, etc.

In this specific case, if your application is going to require this intensive level of performance, it is preferable that you consider building it natively, perhaps programming the most critical parts in C++ or Rust.

→ For apps that require a lot of native integrations or low-level features

Flutter offers a fantastic bridge to connect the parts written in Dart with the native part of the application. In this way, even if we are creating an application with Flutter, it is possible to code some parts directly in the native language, then we can take advantage of its performance and integrations that are only available at the native level.

Now, if your application is going to be full of these integrations, to the point that we are going to have to use this communication bridge all the time, I think it would be better to write it directly natively.

If the native bridge is required frequently, then the primary benefits of Flutter are largely negated. In such scenarios, you're not truly engaging in cross-platform development, nor are you fully committing to native development. Therefore, in these situations, I would advise opting for a fully native approach.

→ If there is already in-house knowledge of native programming

If your team already possesses significant expertise in native development, it might be more prudent to leverage this existing knowledge rather than immediately adopting a new technology.

While Flutter is user-friendly and relatively easy to master, it still demands time and dedication to learn. If your company or organization already has the capability to develop applications using native languages, it could be beneficial to carefully consider the advantages and disadvantages of introducing Flutter. This thoughtful evaluation can guide a more informed decision about whether to integrate Flutter into your development process.

Conclusion

As you can see, the decision to invest time and effort into learning a technology like Flutter depends on your specific goals and needs. If, after conducting your research, you choose to learn Flutter, remember that this blog offers articles on Flutter development that could assist you during your learning journey.

Thank you for reading this article. I hope you found it informative and helpful. Should you wish to share any thoughts, I would be delighted to read them in the comments section.

Happy coding :)

Impeller in preview mode for Android

The new rendering engine of Flutter, Impeller, is now available in preview mode for Android on the stable channel. This version introduces a Vulkan backend designed to enhance the performance of Flutter apps on Vulkan-capable devices. The update shows significant improvements in frame rasterization times, leading to less jank and higher framerates.

However, Impeller is still not expected to work well on older devices that do not have Vulkan support. The Flutter team is still working on the backend for OpenGL so we will have to wait a little longer to see good performance on these types of devices.

You can now try Impeller on devices that support Vulkan by passing the --enable-impeller flag to the flutter run command or by adding the following section to the project's AndroidManifest.xml under the <application> tag:

<meta-data
  android:name="io.flutter.embedding.android.EnableImpeller"
  android:value="true" />

Besides working on the Vulkan Backend, the Flutter team has been working hard to improve text performance in Impeller for both Android and iOS. They've made changes that help manage text better and reduce slowdowns, especially in apps with a lot of text. This has made these apps smoother and more responsive. Additionally, the team has focused on fixing various issues and enhancing overall quality and stability for users on both platforms. They've been really proactive, addressing a lot of user feedback and making numerous updates to improve the overall experience.

Material 3 is now the default visual style

Starting with the 3.10 release in May 2023, Flutter's Material library has been updated to align with the latest Material Design guidelines. This update includes new components, themes, and refreshed visuals for existing components. Previously, to use these updates, developers had to opt-in by setting a theme flag. But now, with this new release, the Material 3 visual style is the default setting on Flutter apps.

If you prefer the older Material 2 version, you can still opt out of Material 3 by setting the useMaterial3 property in your MaterialApp widget to false. However, it's worth mentioning that Material 2 will eventually be deprecated. Some widgets in Material 3 are completely new implementations, so when upgrading, you might notice changes in your app's UI. To address this, you should manually migrate to the new widgets.

Remember that Flutter also offers a demo application where you can experiment with all the Material 3 components and compare them with the previous version. The look of Material 3 components is mainly defined by the color and text themes set in the app's ThemeData. Developers can create a Material 3 color scheme easily with tools that generate pleasing and accessible color schemes, either from a base color or even from the dominant colors in an image.

Predictive Back Navigation in Android and iOS app extensions

In this latest Flutter update, there are exciting enhancements for both Android and iOS platforms. On the Android side, a significant improvement has been made to the mouse scroll wheel support. Before this update, using a mouse scroll wheel on Android tablets or foldables was a bit clunky, requiring considerable movement for any scrolling action on the screen. Now, Flutter has enhanced this feature, ensuring that scrolling with a mouse feels more natural and matches the scroll speed typical on Android devices.

Another key update for Android is the introduction of predictive back navigation, a feature from Android 14. This feature allows users to use the back gesture on their device to quickly see the home screen behind the current screen. Flutter's integration of this feature brings a more intuitive and consistent user experience, aligning with the latest Android functionalities.

On the iOS front, Flutter has expanded its capabilities to include some iOS app extensions. This means that developers can now use Flutter widgets to design the UI for certain types of iOS app extensions. However, this functionality is not universal across all types of app extensions, as some might have API limitations or memory restrictions.

Exciting news about the Flutter Games Toolkit

Flutter has seen a significant rise in its use for casual game development over the past few years. A large number of games, ranging from simple puzzles to complex arcade games, have been created using Flutter.

To further support game developers, Flutter is now releasing a major update to its Flutter Casual Games Toolkit. This update includes a variety of new resources aimed at helping developers progress from initial concepts to fully launched games. The toolkit now offers more genre-specific templates, such as those for card games and endless runner games, and integrates various services like Play Games Services, in-app purchases, ads, achievements, Crashlytics, and multiplayer support.

New Flutter Favorites packages!

Flutter's community and tools are always growing and changing, and with that, the Flutter Favorite program has been refreshed and updated! This is an exciting time for developers as the Flutter Ecosystem Committee has recently recognized a selection of packages as new Flutter Favorites. These include our beloved flame game engine, the macos_ui package to make your macOS applications look native, and the wonderful riverpod state manager package.

Keep an eye out for future Flutter Favorites as this program continues to spotlight exceptional packages and plugins. If you want to nominate a package or plugin to this program to become a Flutter Favorite you can do so by sending an email to the committee at flutter-committee@googlegroups.com.

What's new in Flutter DevTools

Flutter's DevTools has introduced a new extensions framework that offers several exciting possibilities. Now, package authors can create custom tools for their packages, which will show up directly in DevTools. They can also make use of existing DevTools frameworks and utilities to build powerful tools. For Dart and Flutter developers, this means they'll have access to specialized tools that are tailored to their specific app development needs, based on the app's dependencies. Authors of popular packages like Provider, Drift, and Patrol have started building this ecosystem, and you can use their DevTools extensions right now.

In addition to these extensions, the latest DevTools release brings a bunch of improvements and new features. Highlights include the addition of support for DevTools extensions and a new "Home" screen that offers a summary of your connected app. Other improvements focus on enhancing overall performance, the robustness of hot restarts, text selection and copying behavior, as well as polishing the network profiler response viewer.

Conclusion

These are just a few of the key updates in Flutter version 3.16. With the Material 3 update almost fully implemented, and Impeller showing great performance on iOS, we're now looking forward to seeing how it performs on Android and other platforms. Meanwhile, the Flutter team is continuously working hard, adding new features and making performance enhancements. We will also keep an eye on the latest developments in Flutter's packages and plugin ecosystem.

For more in-depth information on all these updates and more, you can check out the official blog post. Thanks for sticking with this summary to the end, and I hope you have a wonderful rest of your day.

Happy coding :)

In this article published on the official Android Developers Blog, we can see a summary of these changes. To start, Google is going to start asking for identity verification information for all developers who publish games or applications on Google Play, but this is not the particular change I want to talk about in this article.

If we go to the next point we can read the following:

Developers with newly created personal Play Console accounts will soon be required to test their apps with at least 20 people for a minimum of two weeks before applying for access to production. This will allow developers to test their app, identify issues, get feedback, and ensure that everything is ready before they launch.

This means that if you have created a developer account on Google Play after November 13, 2023, or if you plan to create one, you will necessarily have to go through a two-week testing phase in which you will be responsible for finding 20 people who want to test your application or game. This will be an essential requirement to be able to launch your application or game in production, that is, make it available to all Google Play users.

Now, what exactly is this minimum of 20 testers? Well, 20 people will have to give you their Google email address so that you can add them as testers of your application, they will have to download your app or game, and they will have to test it. And how much will they have to test it? Does it help if each of those 20 people downloads it and tries it for 5 minutes once? As far as I know, the Google Play team has not yet provided more details about it, but if we go to this official documentation page we can read the following:

If you have a newly created personal developer account, you must run a closed test for your app with a minimum of 20 testers who have been opted-in for at least the last 14 days continuously.

The question here is: what exactly does this continuously mean? Does this mean that these 20 testers will have to be testing your app or game each day of those 2 weeks? Does this mean that there has to be a certain number of openings for it to count as valid testing?

These are all questions that unfortunately we do not know for now. And why does Google do this? Well, in the statement that I mentioned previously, we can read:

Developers who regularly use Play's app testing tools before publishing release higher-quality apps and games, which can lead to higher ratings and more success on Google Play. In fact, apps that use our testing tools have on average 3 times the amount of app installs and user engagement compared to those that don't.

Well, it seems that what Google intends here is to put an end to the appearance of hundreds of applications that do not contribute anything to the ecosystem and that, supposedly, reduce the general quality of the software that we can find on Google Play.

And now I want to focus on an important factor: this will only affect the applications or games of developers who have a personal account. If you have a company account, this restriction will not affect you, you will be able to deploy applications and games without them having gone through any mandatory testing phase.

Some individuals have started to highlight the concern that the current efforts might undermine the capacity of independent developers to launch new apps and games. While I acknowledge that numerous releases may be of subpar quality, it's important to remember that there are very good applications and games that started precisely this way, with very humble beginnings but that little by little managed to cover an existing need in the market.

Furthermore, although we are told that this will only affect newly created personal accounts, I would not be surprised to see this policy also extended in the future to any product from any developer, old or new, who wants to launch a new application or game on Google Play.

I don't know about you, but I can't easily have 20 people to ask them to test my applications continuously for two weeks; and probably most indie developers neither. It's quite likely that if this policy is implemented in this way, businesses will begin to emerge, I cannot say whether legitimate and safe or not, but for a modest price will provide us with a group of paid testers with whom we can test new applications. In the end, it will be a new stopper for new developers, who will have to take into account this initial investment without knowing if their application or game will have any kind of success or not.

In my opinion, I completely understand that Google wants to have safe and useful applications in its store, however, this does not seem like the right way to achieve it. If you want to discourage the creation of junk apps then you could do what Apple does: ask for an annual fee for developers who want to publish in your store. Right now to be a Google Play developer you have to pay an initial fee of $25. This is a one-time payment that is made at the beginning and gives you the possibility of being a developer without ever paying anything else. To publish in Apple's AppStore you have to pay a fee of $99 annually, meaning that every year you will have to pay that money. This means that only those who have a minimum of interest and desire to create good products agree to publish in the store, even if they are small indie developers.

The truth is that I feel that being an Android developer is getting harder and harder every day, every year more and more policies are approved that restrict the ability we have to innovate and create new products. Furthermore, we have decisions like this that make creating applications or games on Google Play an exhausting task as time passes. I predict a future on Google Play dominated by corporations, those large companies with the capacity to cope with all the dedication that is necessary to stay up to date with new policies and to adapt applications to the increasingly numerous restrictions. All this while small developers go elsewhere. It is this group of indie developers who provide creativity, who provide novelty, and keep the ecosystem fresh. I have been doing this for more than 10 years and it is a shame to see the decline that Google Play and Android in general are having.

However, this is just my personal opinion. Tell me what you think of these changes in the comments section if you want. Thank you for reading until the end, I hope you have a nice rest of your day.

Finding the necessary information quickly and accurately can become a challenge if you do not have the necessary tools, and that is why in today's article I am going to talk to you about Spreading: an AI-powered knowledge base platform for developers, which makes it easy to build a self-service knowledge base for your customers and developers.

This article is sponsored by ZEGOCLOUD, a leading company in the development of high-quality products for businesses and developers. Spreading is its new product based on artificial intelligence that can help you build your knowledge base quickly and easily, and the best part is that is 100% free, so you can instantly build a self-service knowledge base with Spreading to your customers now!

But first of all, let's see what exactly a knowledge base is and what functions it performs.

What is a knowledge base and why do I need one?

At its core, a knowledge base is a centralized repository for information, a structured compendium of insights and answers. Think of it as an encyclopedia for your product, service, or platform, where all pertinent details, from FAQs to intricate technical explanations, reside.

A knowledge base serves as a pivotal resource not only for developers but also as a strategic advantage for product owners. By equipping developers with essential information, it paves the way for superior and more robust applications, elevating the user experience. This centralized information hub leads to a noticeable drop in support-related queries, enabling the support team to address difficult challenges. It further creates a channel for user feedback, aiding product enhancement based on real-world insights. Additionally, by presenting a thorough knowledge base, brands position themselves as industry frontrunners, emphasizing their dedication to the developer community and their commitment to excellence.

Now that we have a basic understanding of what a knowledge base is and what it is for, let's see how Spreading can help us create one.

Introducing Spreading: the all-in-one AI knowledge base builder

To start seeing how Spreading can help us, let's first go to its registration page to create a 100% free account with which we can start testing the product.

We are going to create a page by clicking on the button located at the top right titled Add a page:

A new file will appear, we click on it to open it, and then we click on the button located at the top right titled Edit to start editing it.

At this point, there are different ways in which Spreading can assist us in creating our document. Let's imagine that we want to create an explanation document on how to generate a sales report on our platform. In order to work on this document, we will first need a base template of the points to explain.

To do this, let's click on the Generate outline button:

Then we will have to choose the type of documentation to generate, we are going to choose User guide since what we want is for this document to serve as an explanation of how to do something to a specific user. As for the target audience, let's imagine that this feature of our product is sales-oriented, so we will choose Sales so the AI adapts the language appropriately:

The next step is to give the artificial intelligence a little more context so that it knows what it has to explain. We are going to add context information and click on the Generate button:

And in this simple way, we now have a base template on which to start working on our document:

Exploring more features Spreading has for document generation

We now have a base on which to start working. This document is still a text document, so we could just start typing. However, we are going to save some time by having the integrated AI auto-generate more content for us.

Continuing with the example, suppose we want to explain what benefits generating a sales report can have. For the AI to help us, we can simply enter a guide text, then select it and click on the AI button to see what options we have:

In this case, I have chosen the option of expanding the information provided. In this way, the AI will generate a richer text with more details:

Once this text is generated, we can make it longer if we consider it necessary and insert it into the document

Advantages of Spreading for creating developer documentation

Another quite interesting function of Spreading is the help it gives us to generate documentation with code examples aimed at software developers.

Let's see it better with an example. We are going to generate a blank document and we are going to write the / character so we can see the list of available options. Let's choose Code Block. A blank code block will open:

At this point, we can help ourselves with the integrated AI to perform various functions. For example, one of the most important features of a developer-oriented knowledge base is to expose a code example and explain what it is for. To do this we can copy the code example within the block, then enable the AI in the button located at the top right and ask it to explain to us what that code is for.

The AI suggests an explanation that we could add to improve the understanding of the code block:

If we click on the insert button, we will have auto-generated an entire explanation of the code provided automatically:

Conclusion

As you can see, creating a knowledge base is very quick and easy with Spreading. From its ease of use to the variety of built-in features it includes, both text customization and styling, to the built-in artificial intelligence features, as well as the fact that it is completely free, make this product very important to take into account if you want to be as efficient as possible when you have to create your knowledge database.

Thanks to ZEGOCLOUD for sponsoring this article, I hope you found it useful and informative.

See you in the next article.

Happy coding :)

But what impact can the CRA have in terms of video game development, and more specifically, what impact can it have on Godot or your game if you consider selling it in any European country?

In this article I am going to try to delve a little deeper into this topic, but, before going into detail, I would like to clarify two things:

• First: at the time of writing this article, all we know is what is written in a draft of this new law, so everything discussed here is subject to change.

• Second: I am not a legal expert, I am simply going to try to explain in simple terms what I have been able to find out and give my opinion about how it could affect the video game development industry.

So without further ado let's try to figure out what CRA is, and what impact it could have on Godot and in games published in the EU.

What is the Cyber Resilience Act, or CRA?

Introduced by the European Union, the CRA seeks to elevate cybersecurity standards for digital devices and software intended for the EU market.

Both manufacturers and developers who market devices or software in the European Union, without taking into account their global location, must ensure the security of such digital products so they reach the market with fewer vulnerabilities and ensure that relevant quality standards are taken seriously. In addition, it's also intended that users can take this quality into account when consuming products with digital elements.

A significant shift of the CRA is its focus on software developers rather than the companies that use this software. The rationale? Developers are in a prime position to address vulnerabilities at their source, making software inherently safer.

However, not all software is seen as equal under the CRA. Based on its use and potential risks, software is divided into three categories.

• Non-critical products: It is estimated that the vast majority of products will be in this group. In my opinion, both Godot and video games would fall into this group.

• Critical Class 1: This level includes software with higher-risk functions such as password managers, VPNs, network management systems, or remote access software.

• Critical Class 2: Reserved for products that have the highest level of risk: operating systems, public key infrastructure and digital certification, general-purpose microprocessors or routers.

Depending on its classification, software may face varying obligations. These range from comprehensive risk assessments to ensure software doesn't have known vulnerabilities and is configured for security by default, to extensive documentation detailing the product's design, vulnerabilities, and compliance with EU cybersecurity standards.

Additionally, while non-critical software developers can self-certify their products, those in the Critical Class categories must undergo assessments by external EU-certified auditors.

When vulnerabilities are detected, especially those under active exploitation, developers have a tight 24-hour window to report them to the European Union Agency for Cybersecurity.

Now that we have a general idea about what the CRA is and what new obligations it imposes, let's see what impact it can have on Godot and games released in European territory.

How will the CRA impact Godot and games published in the EU?

In my opinion, based on the three groups of products discussed above, everything would seem to indicate that both video game engines and the video games themselves would fall within the group of non-critical products; given that its impact in terms of risk seems to be less pronounced than the products considered critical by this new rule.

But even as a non-critical product, both the Godot development team and any video game maker might not be exempt from the obligations that the CRA imposes. This act implies that developers, even of non-critical software, carry out a compliance self-assessment.

This self-assessment is essentially a commitment to ensure that their software complies with the cybersecurity standards outlined by the CRA. It means ensuring there are no known vulnerabilities, providing security patches, and maintaining a secure by default approach.

However, given the open-source nature of Godot, much like other free projects, this can generate additional complexities. This is because this type of software is distributed freely, without exhaustive control of who it is distributed to or for what reasons, therefore it can be harmful to impose this level of obligations on someone who simply delivers software freely without any type of cost.

For other open-source projects considered higher risk such as Linux distributions, the implications of the CRA could be more profound. Given their consideration as critical products, these projects could face much stricter regulations; which could discourage a company from delivering software as free software given this level of complexity and responsibility.

So far, everything seems to indicate that those projects considered "non-commercial" would be exempt from this rule, however, there are those who consider that an open-source project, if it receives financing even through donations on a regular basis, could be considered as commercial software and would have to comply with the CRA. Without a doubt Godot, given that it is frequently financed through altruistic donations, could fall into this group if this were confirmed.

As for video games marketed in Europe, they would undoubtedly also fall within the scope of the CRA as non-critical products, so they would be under the obligations discussed above.

Conclusion

As we reach the end of our deep dive into the CRA's potential implications, it's essential to remember that what we've discussed is based on the current draft of the act.

This means the provisions, classifications, and requirements can still change before the act is finalized and put into effect. The legislative process is both dynamic and responsive, and feedback from stakeholders, including the open-source community, can shape the final form of the act.

Throughout our exploration, we've uncovered the potential challenges the Godot team might face, from the intricacies of self-assessments to the added layers brought on by its open-source nature. But with every challenge, there lies an opportunity.

In this context, it’s an opportunity for the Godot community to rally together, employ enhanced security practices, and continue producing the remarkable software that countless developers rely on.

We'll continue to watch the development of the CRA, always hopeful and confident that the spirit of open-source collaboration will thrive, adapt, and lead the way into a secure, innovative future.

You've probably come across these situations many times, but have you ever wondered how they're coded? Is all that extra logic stuffed into the Player class?

In this article, I'll dive into a popular design pattern that's super handy for these scenarios: the Command pattern.

This design pattern lets us wrap a request as an object, offering a range of flexibilities and capabilities I'll walk you through. I have created this example in which we can control a character, making him move and attack.

But I want that when he meets this wolf, I want an AI to take over, approach the wolf, and attack. Think of this as a cutscene where we want the main character to act out a specific part of the story. This could be followed by some kind of dialogue or anything else.

Now, you might think about cramming all this logic into the Player class. But that's not ideal since it mixes responsibilities and further bloats one of the typically largest classes in gaming, which is the Player class.

This design pattern is eloquently detailed in a book called "Game Programming Patterns". I highly recommend reading it, since it provides an exhaustive review of several design patterns in software development applied to video game development, with code examples, explanations and insights on each pattern. While it's available online if you prefer physical copies as I do, here's a link for you to purchase it in case you are interested (Disclosure: As an Amazon Associate I earn from qualifying purchases).

So if you are interested in learning how to use this design pattern in Godot to achieve cleaner, tidier, and more efficient code, keep reading!

Creating the Commands

Command

In the example I created, I am using the classic method to control the character, for example, if I want to get the input value to move it left or right:

var movement_input = Input.get_action_strength("move_right") - Input.get_action_strength("move_left")

Or if I want to detect if the attack key has been pressed:

Input.is_action_just_pressed("attack")

The idea is to replace all of this so that this logic is outside of the Player class.

To do this, the first thing we must create is the Command class:

class_name Command
extends Object


func execute(player: Player, data: Object = null) -> void:
    pass

This class defines an execute() method in which it receives a Player instance and an optional "data" argument. The goal of this method is to execute the appropriate action on the Player. Note that at this point we are coupling this Command to the Player, making it unable to be used by any other entity. I do this to keep this tutorial as simple as possible, but in a real case instead of the Player, you could receive a base class from which all your actors inherit.

MovementCommand

Now we are going to create the command that will allow the player to move:

class_name MovementCommand
extends Command


class Params:
    var input: float

    func _init(input: float) -> void:
        self.input = input


func execute(player: Player, data: Object = null) -> void:
    if data is Params:
        player.move(data.input)

We create the MovementCommand class that inherits from Command, and we set a Params class where we are going to indicate the direction of movement using a float value, -1 for left, 0 for staying still, and 1 for moving to the right.

In the execute method what we have to do is call the appropriate Player method to perform the move.

AttackCommand

We do the same for the attack command, but in this case it won't be necessary to create any class parameters since we do not need to know anything else:

class_name AttackCommand
extends Command


func execute(player: Player, _data: Object = null):
    player.attack()

Creating the controllers

Now that we have the necessary commands created, we need something to issue them. I'm going to call this concept "Controller". The idea is to have a base class, and extend it to allow the player to control the character, and another to make the AI control it.

PlayerController

Let's start by creating the PlayerController base class:

class_name PlayerController
extends Node


var player: Player

var movement_command := MovementCommand.new()
var attack_command := AttackCommand.new()


func _init(player: Player) -> void:
    self.player = player

As you can see, this class maintains a reference to Player and instantiates each of the relevant commands. We make this class inherit from Node since we are going to have to interact with the game loop.

HumanController

This is when you will see how everything takes shape. We create HumanController with the following content:

class_name HumanController
extends PlayerController


func _physics_process(_delta):
    var movement_input = Input.get_action_strength("move_right") - Input.get_action_strength("move_left")

    if Input.is_action_just_pressed("attack"):
        attack_command.execute(player)
    else:
        movement_command.execute(player, MovementCommand.Params.new(movement_input))

The idea will be to add this node as a child of the Player, this way we can detect the user's input and execute the appropriate command. To do this, we will first have to create a container for this or any other controller:

Now we will add the following logic to the Player class:

# Maintain a reference to the current controller
var _controller: PlayerController

# Reference to the container that will contain the controller node
@onready var _controller_container = $ControllerContainer

# By default, we create a HumanController
func _ready() -> void:
    set_controller(HumanController.new(self))

# We added this method to allow changing the active controller
func set_controller(controller: PlayerController) -> void:
    # Delete all previous controllers
    for child in _controller_container.get_children():
        child.queue_free()

    _controller = controller    
    _controller_container.add_child(_controller)

At this point, if everything has gone well, we should be able to run the game and control the main character as we did before.

AiController

Next, we are going to create another class that inherits from PlayerController, but this time we will create a custom AI that will send the following commands:

class_name AiController
extends PlayerController


var _init_time: int = 0
var _is_attack_end: bool = false


func _ready():
    _init_time = Time.get_ticks_msec()


func _physics_process(_delta):
    var current_time = Time.get_ticks_msec() - _init_time

    if current_time < 3000:
        movement_command.execute(player, MovementCommand.Params.new(0.0))
    elif current_time < 3900:
        movement_command.execute(player, MovementCommand.Params.new(1.0))
    elif not _is_attack_end:
        attack_command.execute(player)
    else:
        movement_command.execute(player, MovementCommand.Params.new(0.0))

# In this example, the player class will tell this controller that 
# the attack has ended. As I say, it's a quick example, 
# there are better ways to manage this.
func on_attack_end():
    _is_attack_end = true

In this example, the code that I have put inside _physics_process() is completely orientational. I recommend that you use more sophisticated mechanisms so that your AI is accurate, but I think you can already see the benefit that the Command pattern brings us.

Let AI take control

The last step we have left is to decide at what point the AI will take control of the character. For example, we could create an Area2D and add the following script to it:

extends Area2D


func _on_body_entered(body):
    if body is Player:
        body.set_controller(AiController.new(body))

When the character touches this area, the controller will be changed from HumanController to AiController, and from that point on it will be our logic that will control the character's actions.

The benefits of the Command pattern

As you have seen, we have just managed to decouple the control of the character from the Player class. Through this mechanism we can obtain other benefits, not only being able to control the player in the cutscenes, but also for example that the player begins to control an enemy, or conversely that an enemy begins to control the player.

Furthermore, one of the most widespread uses of this pattern is to be able to redo actions. If you think about it, we're encapsulating each action in a Command object, so we could store all of these objects and then be able to go back and redo actions already performed.

I hope you found this article useful, we'll see in the next one.

Happy coding!

I think that by now we are all aware of the magnitude of the tragedy: Unity is going to start charging a runtime fee of $0.2 every time a player installs a game. If the player installs your game 10 times? You pay 10 times that amount. If the player installs a pirate copy of your game? You pay for that pirated copy. If you have a mobile game and your profit margin is less than this 0.2$, which is not uncommon in the mobile industry, you're going bankrupt.

Studios of all sizes, as well as indie developers, are looking for other video game engines to be able to port their current games or as potential candidates for future projects. All this in search of a technology that can be trusted to continue working in a safe, predictable and sustainable way.

However, Unity has not only destroyed itself and its community but has managed to sow a wave of distrust toward the corporations and groups that control these engines. If Unity has done it and I decide to move to another engine, what stops the group that controls that new engine from doing the same to me in the future too? Will we always be subject to the decisions of a small group of greedy people who will control our livelihood without being able to do anything about it?

In this article, I intend to address this topic, especially concerning the open-source Godot video game engine. If you chose this engine over Unity, stay with me because I'm going to explain why Godot is probably miles away from being able to do as much damage to the community as Unity has done. Let me explain to you why.

Why is Godot's case different from Unity's?

To answer the question of why Godot is less likely to screw you than Unity, we must first understand what the contractual relationship is between a Unity user, and Unity Software Inc., the company that develops the engine.

When you download Unity Hub and proceed to install any of the versions of the engine, you accept the terms of service that they provide you. This document defines the contractual relationship between you, as a Unity user, and the company that develops it.

These terms of service include a provision that allows Unity Software Inc. to alter these terms. This may include the option to alter their rates for using the engine. It remains to be seen if how they have made these changes is completely legal, but it could be said that, unless you have agreed to a special contract with Unity and you are governed by the terms of the standard service, they can make these types of modifications unilaterally. So to be clear: yes, they can screw you any time they feel like it.

To make matters worse, the terms of service before the current version allowed you to take advantage of the terms of service in force concerning the year of release of a certain version of the Unity editor, that is, one could continue using last year's Unity version, along with the terms of service in effect last year, and that new changes to the current terms will not affect you. However, this clause was eliminated, so we could say that the current situation has been premeditated and what they've done has been done so that all developers have to pay the new runtime fee without being able to do anything.

What is the contractual relationship between you and Godot?

Now let's see under what legal basis you are offered and allowed to use the Godot open-source game engine.

When you download and use Godot, you do so under the project's open-source license, in this case, the MIT license; which can easily be found in the open repository in the LICENSE.md file.

The MIT license is known as, if not the most, one of the most permissive and least restrictive licenses in the entire open-source software ecosystem. It only takes up 20 lines and allows you to do practically anything:

• Use the engine for free.

• Make video games or any other type of software with it and then distribute it, sell it, or for whatever.

• It does not force you to maintain the same license in the derivative works (that is, the games you make with it). You can make completely proprietary games with it.

• You can even take the engine, rename it and sell it as is.

As you can see, the MIT license is designed so that you can do almost anything in almost any way. So as long as Godot is distributed under this license, one can safely use it without being afraid of hidden fees, price changes, or anything else that could turn your studio upside down from one day to the next.

Now, the question that arises next is: what if the license changes? How likely is it that Godot will no longer have the MIT license? What if it stops being open-source? Can a company acquire it?

Why I doubt Godot will deviate from the MIT license

First, let's understand what the implications are of changing the license of an open-source project: to begin with, each of the contributions that each contributor has made throughout the life of the project belongs to them. That is, the copyright of the code that you provide when you contribute to an open-source project belongs to you, which in turn you license to the end user through the license chosen by the project.

This means that from a copyright point of view, Godot belongs to every one of its contributors. Therefore, for the project to change licenses, every one of them would have to accept that license change.

At the time of writing, there are a total of 2203 people who have contributed to the engine, so all of these 2203 people should agree and accept a new license for the engine.

This is something that can certainly happen. In fact, this is exactly what happened with the Bevy engine, in which a total of 246 contributors agreed to relicense the engine, as explained in this blog post. However, in this case it was done for the good of the engine and its users.

Imagining a situation in which more than 2,000 Godot contributors agree to change the engine license and start screwing the community and its users seems quite surreal to me and unlikely to happen. Let's understand that we are not talking about greedy executives looking for money, but about technology enthusiasts who enjoy using the engine for free and contributing code to it.

You can fork the engine and create a copy for yourself

However, let's put ourselves for a moment in the worst-case scenario: all Godot contributors agree and decide to change the license to one that is much more restrictive or that somehow prevents you from continuing to create commercial games with the engine.

The solution in this case would also be relatively easy: fork the engine, create a copy for yourself and bypass the new license. It's that simple.

It would not be ideal, since you would not be able to access the new contributions and new features that would be released, but at least it would give you a window of time in which to maneuver and look for alternatives.

In any case, I think the probability of something like this happening is very small.

Godot, like many other open-source projects, is run by people with a very different profile from that of an executive who joins a company to get rich. Don't get me wrong, I'm not saying that using Godot is 100% safe and that in no case can anything bad happen to you, I'm just giving my opinion and my arguments as to why I think it's unlikely that a similar situation like the one that is happening with Unity will occur, and if it did happen, I believe that the resulting damages would be smaller and much more controllable.

In any case, this is my opinion, and as a Godot user, if I have to highlight something positive about the current horrible Unity situation, it is the boost this is going to give to the engine.

When one door closes, another opens, and I think the door that is opening now with Godot is very hopeful and will be beneficial for everyone in the years to come.

In this article, I am going to explain how to comply with this new policy using Google's own CMP, which is a free library that, although it has its flaws, will at least allow us to comply with this new regulation.

Through this Flutter tutorial you will learn how to do the following:

1. How to ask for consent the first time the user starts the application

2. How to allow the user to modify their privacy preferences per the GDPR

3. How to manage the expiration of consent to request it again when necessary

To implement this, you only need to have the google_mobile_ads plugin installed. If you already display ads in your app, you should have this plugin already. While there are other plugins for showing this consent message, the latest google_mobile_ads versions come with the right SDK, so there's no need for third-party plugins.

Create the AdMob UMP message in the console

The first step we must take is to create the consent message in the AdMob interface. If you already have this message created then simply go to the next step.

Access the AdMob console, and go to the Privacy & messaging section:

Here you will see the different types of messages that you can create. Press the first button at the bottom right to create your message:

In the next screen, press the Create message button to start creating your message.

You will be presented with a form with several options. First, choose all the apps that you want to apply this message to. Here you should choose the applications that serve ads to users from the European Union. Keep in mind that if you want to apply different styles (colors, fonts) you will have to create more than one message.

Then choose the languages in which you want to display the message, and the consent options:

If you have doubts about which option is right for you, you should consult with a lawyer specialized in this topic. For my applications I have chosen the option Consent, Do not consent, or Manage options to ensure that I offer a clear, easy and free way for my users to not consent to the use of data; but as I say, I am not a lawyer and this is not legal advice, so please consult a professional who can guide you in your particular case.

The last step will be to choose whether we want to show this message only in regions subject to the GDPR or worldwide.

Once created you will be able to view and configure your message. At this point, I advise you to navigate through the interface since there are several configuration options, including the selection of colors, languages, spacing, etc. Simply configure the message to your liking so that it looks good in your application.

ℹ If you have more questions about the process of creating the privacy message, I recommend that you look at the official AdMob guide, where you will find the details of all the settings.

Create a class that manages the GDPR dialog

The Google UMP SDK can be integrated directly into any point of your application, however in this tutorial what we are going to do is create our own class that will manage it and then a screen that will use this class.

The reason I do it this way is that the first time a user starts your app after downloading it is a sensitive moment, and I think showing this message right at the beginning gives a bad user experience.

On the other hand, each successive app launch will require us to look at the consent status and see if we need to display the message, this can happen for various reasons:

1. The first time the user opened the app, the device had no internet connection, so the message could not be displayed

2. The message has been modified and must be displayed again

3. Consent status has expired

In these cases, we are going to have to show the message right when the application starts.

To cover all these needs, what I do is create a class that specializes in displaying this message and a screen that uses it. This gives us the flexibility to be able to display this message in different situations that you will see throughout this tutorial.

Create an initialization_helper.dart file with the following content:

import 'package:google_mobile_ads/google_mobile_ads.dart';

class InitializationHelper {
  void initialize() {
    final params = ConsentRequestParameters();
    ConsentInformation.instance.requestConsentInfoUpdate(params, () async {
      if (await ConsentInformation.instance.isConsentFormAvailable()) {
        // Here we'll load the consent form
      }
    }, (error) {
      // Manage error
    });
  }
}

In this method, we request the consent status, and if a form is available we will proceed to display it. The isConsentFormAvailable() method will only return true in cases where there is a form to display, if the user is outside of the countries subject to the GDPR this method will return false, although this behavior may vary depending on how you have configured the message.

Now we will create a private method that loads and displays the message:

  void _loadConsentForm() {
    ConsentForm.loadConsentForm((consentForm) async {
      final status = await ConsentInformation.instance.getConsentStatus();
      if (status == ConsentStatus.required) {
        consentForm.show((formError) {
          // Call this method again, if the user has already selected an
          // option the message will not be displayed again.
          _loadConsentForm();
        });
      }
    }, (FormError? error) {
      // Handle error
    });
  }

If you've noticed, this library doesn't use Futures to do asynchronous work but instead uses callbacks. This is not a very "Flutter" way of doing things, so we're going to "Flutterize" it using a Completer. In addition, we are going to add another method that will be in charge of initializing the consent-dependent components:

import 'dart:async';

  // [...]

  Future<FormError?> _loadConsentForm() async {
    final completer = Completer<FormError?>();

    ConsentForm.loadConsentForm((consentForm) async {
      final status = await ConsentInformation.instance.getConsentStatus();
      if (status == ConsentStatus.required) {
        consentForm.show((formError) {
          completer.complete(_loadConsentForm());
        });
      } else {
        // The user has chosen an option,
        // it's time to initialize the ads component.
        await _initialize();
        completer.complete();
      }
    }, (FormError? error) {
      completer.complete(error);
    });

    return completer.future;
  }

  Future<void> _initialize() async {
    await MobileAds.instance.initialize();

    /**
     * Here you can place any other initialization of any
     * other component that depends on consent management,
     * for example the initialization of Google Analytics
     * or Google Crashlytics would go here.
     */
  }

We are now going to also use a Completer in the initialize() method, and also manage the initialization of the components:

  Future<FormError?> initialize() async {
    final completer = Completer<FormError?>();

    final params = ConsentRequestParameters();
    ConsentInformation.instance.requestConsentInfoUpdate(params, () async {
      if (await ConsentInformation.instance.isConsentFormAvailable()) {
        await _loadConsentForm();
      } else {
        // There is no message to display,
        // so initialize the components here.
        await _initialize();
      }

      completer.complete();
    }, (error) {
      completer.complete(error);
    });

    return completer.future;
  }

The next step is to create a screen that the previous class will use to manage consent. We will place a loading to give feedback to the user that something is happening while the consent status and message are loading:

Create the file initialize_screen.dart with the following content:

import 'package:admob_consent_dialog/initialization_helper.dart';
import 'package:flutter/material.dart';

class InitializeScreen extends StatefulWidget {
  final Widget targetWidget;

  const InitializeScreen({required this.targetWidget});

  @override
  State<InitializeScreen> createState() => _InitializeScreenState();
}

class _InitializeScreenState extends State<InitializeScreen> {
  final _initializationHelper = InitializationHelper();

  @override
  void initState() {
    super.initState();

    _initialize();
  }

  @override
  Widget build(BuildContext context) => const Scaffold(
        body: Center(
          child: CircularProgressIndicator(),
        ),
      );

  Future<void> _initialize() async {
    final navigator = Navigator.of(context);

    WidgetsBinding.instance.addPostFrameCallback((_) async {
      await _initializationHelper.initialize();
      navigator.pushReplacement(
        MaterialPageRoute(builder: (context) => widget.targetWidget),
      );
    });
  }
}

Where to display the AdMob consent dialog

We can now use the created elements in the appropriate places. This varies from application to application, but as a suggestion, I can tell you what I do:

1. The first time the user opens the application, the first thing I show them is an onboarding screen where I explain the strengths of my application. Once the onboarding is complete, I direct the user to the InitializeScreen, passing the main screen of my application in the targetWidget parameter.

2. If this is not the first time the user opens the application, the first screen I show is InitializeScreen, in case it is necessary to show the message again.

It is important to keep in mind that the message will only be displayed according to the configuration we have chosen. For those users residing in countries not subject to the GDPR, what they will see is simply a short screen with a central loading. In iOS, if we have also configured the IDFA explanatory message, it may be displayed.

To verify that the implementation you have made works correctly we can alter the ConsentRequestParameters object in initialization_helper.dart as follows to simulate a location:

final params = ConsentRequestParameters(
  consentDebugSettings: ConsentDebugSettings(
    debugGeography: DebugGeography.debugGeographyEea,
    // Or DebugGeography.debugGeographyNotEea to simulate outside of the EEA
  ),
);

I recommend that you do the following tests to verify that everything is going well:

1. Launch your newly installed app by forcing the location to be within the European Union: The message should be displayed.

2. Launch your newly installed app by forcing the location to be outside the European Union: The message should not be displayed (unless you have set it to worldwide).

3. Launch your newly installed app by forcing the location to be within the European Union, but REMOVE the internet connection, the message will not be able to be displayed. Then reconnect to the internet and start the application, the message should be displayed at startup.

Another thing you should try is to reset the consent state, you can do this by running the following:

ConsentInformation.instance.reset();

Restart the app and verify that the message appears.

Allow the user to modify their privacy options

The GDPR dictates that users must be able to modify any previously made choices, so we should add a button somewhere in our app (I have it in the settings screen, specifically in the legal section, next to the privacy policy) so that the user can reopen this consent message and modify their preferences.

To do this we will have to create a new method that allows us to open the consent dialog, but that has a somewhat different behavior from the previous initialization method.

Add this method to initialization_helper.dart:

Future<bool> changePrivacyPreferences() async {
  final completer = Completer<bool>();

  ConsentInformation.instance
      .requestConsentInfoUpdate(ConsentRequestParameters(), () async {
    if (await ConsentInformation.instance.isConsentFormAvailable()) {
      ConsentForm.loadConsentForm((consentForm) {
        consentForm.show((formError) async {
          await _initialize();
          completer.complete(true);
        });
      }, (formError) {
        completer.complete(false);
      });
    } else {
      completer.complete(false);
    }
  }, (error) {
    completer.complete(false);
  });

  return completer.future;
}

If you look, this method is very similar to the previous one, but in this case once the user has made a decision we do not try to open the dialog again.

Allowing the user to change their privacy preferences only makes sense for users in countries subject to the GDPR. If you look at the official Google SDK documentation you will see that we are not provided with any explicit method to check this, however all parameters, including whether the user is under the GDPR, are stored in the local preferences by the SDK.

Specifically, the IABTCF_gdprApplies key contains a value of 1 if the user is under the GDPR. However, the problem of accessing this value can come if you use a plugin like shared_preferences. This plugin, undoubtedly the most famous in the Flutter world for saving/reading local preference values, has the drawback that in its default configuration it adds a prefix to all keys. For that reason, if you try to access the value I mentioned, you will get a null, even if that value exists.

In this case, I recommend using any other mechanism to read the preferences without anything altering the keys. For this tutorial, I am going to use async_preferences, a plugin created by me that does not alter the keys used in the preferences in any way. You can install it using this command:

flutter pub add async_preferences

Below I show you an example code of a very simple settings screen where one of the options allows the user to reopen the consent dialog:

import 'package:admob_consent_dialog/initialization_helper.dart';
import 'package:async_preferences/async_preferences.dart';
import 'package:flutter/material.dart';

class SettingsScreen extends StatefulWidget {
  const SettingsScreen({super.key});

  @override
  State<SettingsScreen> createState() => _SettingsScreenState();
}

class _SettingsScreenState extends State<SettingsScreen> {
  final _initializationHelper = InitializationHelper();

  // We will use a Future to read the setting that
  // tells us if the user is under the GDPR
  late final Future<bool> _future;

  @override
  void initState() {
    super.initState();

    _future = _isUnderGdpr();
  }

  @override
  Widget build(BuildContext context) => Scaffold(
        appBar: AppBar(
          title: const Text('Settings'),
        ),
        body: FutureBuilder(
          future: _future,
          builder: (context, snapshot) => ListView(
            children: [
              // Show it only if the user is under the GDPR
              if (snapshot.hasData && snapshot.data == true)
                ListTile(
                  title: const Text('Change privacy preferences'),
                  onTap: () async {
                    final scaffoldMessenger = ScaffoldMessenger.of(context);

                    // Show the consent message again
                    final didChangePreferences =
                        await _initializationHelper.changePrivacyPreferences();

                    // Give feedback to the user that their
                    // preferences have been correctly modified
                    scaffoldMessenger.showSnackBar(
                      SnackBar(
                        content: Text(
                          didChangePreferences
                              ? 'Your privacy choices have been updated'
                              : 'An error occurred while trying to change your privacy choices',
                        ),
                      ),
                    );
                  },
                ),
            ],
          ),
        ),
      );

  Future<bool> _isUnderGdpr() async {
    // Initialize AsyncPreferences and checks if the IABTCF_gdprApplies
    // parameter is 1, if it is the user is under the GDPR,
    // any other value could be interpreted as not under the GDPR
    final preferences = AsyncPreferences();
    return await preferences.getInt('IABTCF_gdprApplies') == 1;
  }
}
`

Conclusion

As you can see, both in order to comply with the different privacy laws and to comply with the AdMob policy, there are many factors to take into account and several actions to take.

I hope this indicative tutorial has been useful to you, remember that it is simply an example of how to do it, and in your case you should adapt the solution that I propose here to your application.

We'll see in the next article,

Happy coding!

If you have been reading some of the articles on my blog, you will have seen that I often talk about macOS or the Mac Mini. And this is because this is the preferred machine that I use for the development of multiplatform apps, however, my main operating system, the one I use "by default", the one I use for personal and professional management, the one I use for my tech experiments, is, and has been for the past decade, Linux Mint.

And I say all this because this popular Linux distribution has earned through its own merits the fact that I consider it one of the best operating systems ever created, with all due respect to other Linux distributions.

Linux Mint was created in 2006, so at the time of writing this article is now 17 years old! I think is time to give some credit back and tell you why, from my point of view, Linux Mint is probably one of the best platforms for the vast majority of people, both those looking to switch from Windows or macOS and also those open-source, distro-hopping, passionate tech enthusiasts looking for the definitive distribution. Without further ado, let me tell you why Linux Mint is my ultimate Operating System.

"It just works"

Have you heard this sentence before? It just works 🍏? The first time I experienced this feeling in the Linux world was with Linux Mint, and since then I have not experienced it again with any other distribution.

Like many people, I took my first steps in the world of Linux with Ubuntu, the well-known "user-friendly" distribution with which many people jump from Windows to GNU/Linux. My experience was terrible at that time, display errors, unexpected crashes, terrible performance... a very bad impression if you are new to the Linux universe. We are talking about more than 10 years ago, I am completely unaware of the current state of Ubuntu, but at least at that time and for me it was completely unusable.

Everything changed when I installed Linux Mint on an old laptop that I was about to retire and that I decided to give to my father. I knew perfectly well that if I handed him over the old laptop with Windows installed, it would take a matter of months for it to be filled with spyware and shady stuff, and ultimately the performance of the machine would gradually decline until it was unusable. That's why I searched for an "easy-to-use Linux distribution" and one of the results was Linux Mint. I downloaded it, installed it on the laptop and handed it over to my father. This happened over 7 years ago and to this day my father is still using this same machine with the same Linux Mint installation that I did for him at that time.

After that, at work, I was still using Ubuntu... but I was curious to install myself this same distribution that I had the pleasure of "tinkering" on the old computer that I gave to my father...so I decided to install it and from that moment I was able to see how the Linux universe could be a smooth experience, without errors, where everything worked as expected and where one could work in peace.

In my opinion, Linux Mint is one of the distributions that works best "out of the box", and there are plenty of other people who seem to think the same way since it is currently ranked as the third most popular distro according to DistroWatch.

Minimalist experience

The user experience at the level of the desktop interface and basic programs in Linux Mint is beautiful, friendly and simple. Specifically, I'm talking about the Cinnamon edition, which is the default desktop of Linux Mint. Along with this modern interface, one can also choose the Mate desktop, more robust and traditional; or Xfce, much lighter.

The Cinnamon desktop is effectively reminiscent of the traditional Windows experience, with a taskbar located at the bottom, and a "Start" menu that appears when you press the button located at the bottom left. In the center we have the open windows and on the left a set of controls where the date and time are, access to the quick network panel, Bluetooth, etc.

Of the most widely used and well-known Linux desktops environments that most resemble Cinnamon is KDE, even though Cinnamon is actually a fork of Gnome 3. Cinnamon's goal is to provide a simple and elegant user interface that is easy for newcomers to use, but also powerful enough for advanced users.

In the latest releases, the Linux Mint development team decided to "modernize" the look of this desktop environment and made several changes which, in my opinion, have helped to further improve the smooth and elegant look of this distro. Specifically in version 21.1 they renewed the look and feel of the system by modifying colors and icons, and changing the traditional green that came by default to blue, although of course if you liked green you could configure it without problems.

Recently version 21.2 have gone further in its efforts to make things easy and allows you to choose the appearance and theme of the desktop quickly and easily by choosing between light, dark or mixed mode, a theme and an accent color. Of course, if customization is your thing, you still can choose among the myriad of available themes. Something that is greatly appreciated since it simplifies its use for new users while maintaining its high level of customization for more advanced users.

In conclusion, Linux Mint's default desktop, Cinnamon, is an elegant, simple and easy-to-use desktop environment, with just the right customization options but without being overwhelming; with colors that make a nice contrast and modern look.

Robust, stable, solid

Linux Mint has a traditional philosophy regarding which versions of the software to use. It is positioned securely in terms of the programs it integrates and the packages that make up the system, which means that it will prioritize stable versions that have been highly tested and are known to work; versus newer versions that include more functionality but have been in production for less time.

This feature is certainly not for everyone. However, if what you are looking for is a distribution that tries to be as stable as possible, Linux Mint is for you since stability is one of its main goals.

It achieves this first of all by basing itself on the latest LTS (Long Term Support) version of Ubuntu as a base. From here, two versions are usually released per year, of which some of them are established as LTS versions, which will only receive critical or security updates.

In my opinion, this conservative model of dealing with new software is highly recommended if you want your machine to work and can't afford to have things breaking every now and then, or every time you upgrade. In all these years that I have been using Linux Mint, I have to say that I have hardly had any technical problems, everything has worked as expected except for a few exceptions, and that is saying a lot considering that we are talking about a complete operating system that is free of charge, carried out by a small team of people that is financed based on donations from the community and some sponsorships.

Despite all this, if you have any technical or stability problems with the system, you can always seek help in the official forum where there is a wide community of people who will try to help you and give you support at no cost for any problems you may have.

As I mentioned earlier in this article, the stability of Linux Mint is in my opinion one of its strengths, since when I'm working I can't afford to be distracted by system errors or spend time fixing bugs that shouldn't be there.

The philosophy of Linux Mint

To conclude this article on Linux Mint, I want to emphasize an element I view as fundamental - the philosophy driving the project.

Linux Mint is a free and open-source project made up of a collection of programs and utilities that predominantly utilize the GPL license. This allows both individuals and corporations to utilize Linux Mint for personal and commercial objectives. The vast majority of the software included in the project can be freely used, copied, and altered in accordance with the open licenses it abides by.

Furthermore, Linux Mint is community-driven. The development team maintains consistent communication with the community, incorporating direct feedback to enhance the project.

Beyond all these, Linux Mint also stands as a great operating system with regard to the privacy it affords its users. Linux Mint does not employ tracking technologies to assemble personal profiles for commercial use or for any other purpose.

Given all of the above, I believe it's clear why I regard Linux Mint as an excellent resource for anyone who values freedom and privacy.

Conclusion

I hope I have been able to show all the virtues that this Linux distribution has, and why many people could benefit from using it.

If you use Windows and are fed up with all the bad stuff about it, I highly recommend you take a look at Linux Mint.

If you're a Linux fan and haven't tried it yet, what are you waiting for?

I hope this article helps spread the word about this great operating system, and if, on the contrary, you have been using it for a long time and you are as passionate about it as I am, I would suggest that you consider contributing in some way to the project so that it continues to grow and benefit thousands of people.

I hope this article has been illustrative to you, do you think that what I have exposed here coincides with your experience? What other Linux distributions do you think could rival Linux Mint? Leave me your comments below and I will gladly read them to start a debate.

See you in the next article!

Let's do a quick summary of all the basic filesystem operations that we can do with Flutter:

📽 Video version available on YouTube and Odysee

List common directories

By using the path_provider plugin we can get the path to common directories designed for different purposes:

import 'package:path_provider/path_provider.dart';

// Put cache files in this directory
final temporaryDirectory = await getTemporaryDirectory();
// For files that our app uses but are not exposed to the user
final appSupport = await getApplicationSupportDirectory();
// For user-generated files
final appDocuments = await getApplicationDocumentsDirectory();

Create a file

Let's create a random file in the temporary directory and write something inside:

final Directory tempDir = await getTemporaryDirectory();
final File file = File('${tempDir.path}/sample_file.txt');

await file.writeAsString('Sample content to write');

Delete a file

The delete method is just as crucial as the create method, as it helps clear out old files and thus saves valuable storage space.

final Directory tempDir = await getTemporaryDirectory();
final File file = File('${tempDir.path}/sample_file.txt');

await file.delete();

Create a directory

Now let's say that I want to create a new file, but within a certain directory:

final Directory tempDir = await getTemporaryDirectory();
final Directory newDirectory =
    Directory('${tempDir.path}/sample_directory');

// Always check that the directory exists
if (await newDirectory.exists() == false) {
  await newDirectory.create();
}

final File file = File('${newDirectory.path}/sample_file.txt');
await file.writeAsString('Sample content to write');

Remove a directory

Now let's do the reverse and delete the directory:

final Directory tempDir = await getTemporaryDirectory();
final Directory newDirectory =
    Directory('${tempDir.path}/sample_directory');

await newDirectory.delete(recursive: true);

List files

Sometimes you need to list all files within a directory to get some of its stats:

final Directory directory = await getTemporaryDirectory();
final List<FileSystemEntity> files = directory.listSync();

for (final FileSystemEntity file in files) {
  final FileStat fileStat = await file.stat();
  print('Path: ${file.path}');
  print('Type: ${fileStat.type}');
  print('Changed: ${fileStat.changed}');
  print('Modified: ${fileStat.modified}');
  print('Accessed: ${fileStat.accessed}');
  print('Mode: ${fileStat.mode}');
  print('Size: ${fileStat.size}');
}

Read file

Let's open a file to see its content:

final Directory tempDir = await getTemporaryDirectory();
final File file = File('${tempDir.path}/sample_file.txt');

final String fileContent = await file.readAsString();

Copy file

Now, let's generate a duplicate of the previously created sample file:

final Directory tempDir = await getTemporaryDirectory();
final File file = File('${tempDir.path}/sample_file.txt');

final File copy = await file.copy('${tempDir.path}/copy_file.txt');

Rename file

Next, let's change the name of the file we just copied:

final Directory tempDir = await getTemporaryDirectory();
final File file = File('${tempDir.path}/copy_file.txt');

await file.rename('${tempDir.path}/new_name.txt');

Synchronously manage file operations

So far, I've demonstrated how to handle files asynchronously, which is the preferred method. However, if for some reason Futures aren't an option for you, synchronous file operations are also possible:

final Directory tempDir = await getTemporaryDirectory();
final File file = File('${tempDir.path}/sample_file.txt');

file.writeAsStringSync('New content to add');

Error handling

All file system operations should be performed safely since they are prone to throw exceptions. For simplicity, the previous examples did not include this, but it's critical to always encapsulate your I/O operations within a try-catch block:

final Directory tempDir = await getTemporaryDirectory();
final File file = File('${tempDir.path}/sample_file.txt');

try {
  await file.writeAsString('New content to add');
} catch (e) {
  // Handle IO error
}

Conclusion

Dart and Flutter simplify working with files, as demonstrated above. I hope this summary was useful and clear.

Happy coding!

📽 Video version available on YouTube and Odysee

Let's say you have a method that does the following:

• Downloads an image from the internet

• Create several copies of the image but resize them

• Shows the original image and the copies on the screen

Specifically, it would be a method like this:

Future<List<File>> _createImages(String url, int count) async {
  // Downloads the image
  final response = await http.get(Uri.parse(url));
  final List<File> files = [];

  // Save the image in the cache directory
  Directory tempDir = await getTemporaryDirectory();
  File file = await File('${tempDir.path}/image.jpg')
      .writeAsBytes(response.bodyBytes);
  img.Image? image = img.decodeImage(file.readAsBytesSync());

  // Generate copies with 50% less size than the previous
  for (var i = 0; i < count; i++) {
    if (image == null) continue;

    img.Image resizedImage = img.copyResize(image,
        width: (image.width * 0.5).round(),
        height: (image.height * 0.5).round());
    List<int> resizedImageData = img.encodeJpg(resizedImage);

    file = await File('${tempDir.path}/image$i.jpg')
        .writeAsBytes(resizedImageData);
    files.add(file);

    image = img.decodeImage(file.readAsBytesSync());
  }

  // Return the generated files paths
  return files;
}

For this to work, this method is called within a FutureBuilder, and once it gets the result it displays it as follows:

FutureBuilder<List<File>>(
  future: _createImages(_url, 4),
  builder: (context, snapshot) {
    if (snapshot.hasData) {
      // Show all the images within a list
    } else {
      // Show a loading while processing the images
      return const Center(
        child: CircularProgressIndicator(),
      );
    }
  },
)

If you attempt to execute this code, you'll notice the user interface becomes sluggish, possibly even unresponsive. Additionally, the frame rate experiences a significant decrease:

The reason for this is that even though Flutter provides us with a mechanism to execute asynchronous code via Futures, both synchronous and asynchronous code is actually executed on the same thread. Taking into account that working with images is expensive, part of the CPU load in carrying out these processes makes the fluidity of the application suffer, resulting in the image freezing for a few seconds until the image processing is over.

How to move intensive computation to a Flutter background thread with compute()

The compute() method is intended to make it easier to work with background threads in Flutter. Specifically in the context of Flutter, these threads are called Isolates, and although we can call and use them in different ways, in today's example we will see how the Flutter API handles all these tasks when working with compute().

First, we are going to modify the previous method that downloads the image so that it can work correctly in a background thread. Specifically, we will create a class that represents its parameters, we will also have to pass the temporary directory as a parameter, since background threads have problems when executing platform code:

// Create a class that bundles the parameters
class CreateImagesParams {
  final String url;
  final int count;
  final Directory directory;

  CreateImagesParams({
    required this.url,
    required this.count,
    required this.directory,
  });
}

// This MUST be a top-level function now
Future<List<File>> createImages(CreateImagesParams params) async {
  final response = await http.get(Uri.parse(params.url));
  final List<File> files = [];

  File file = await File('${params.directory.path}/image.jpg')
      .writeAsBytes(response.bodyBytes);
  img.Image? image = img.decodeImage(file.readAsBytesSync());

  for (var i = 0; i < params.count; i++) {
    if (image == null) continue;

    img.Image resizedImage = img.copyResize(image,
        width: (image.width * 0.5).round(),
        height: (image.height * 0.5).round());
    List<int> resizedImageData = img.encodeJpg(resizedImage);

    file = await File('${params.directory.path}/image$i.jpg')
        .writeAsBytes(resizedImageData);
    files.add(file);

    image = img.decodeImage(file.readAsBytesSync());
  }

  return files;
}

Isolates have a completely separate memory space from other threads, so they cannot access instances created from another thread. For that reason, we will have to create a top-level function (a static function would also work).

We will also make some modifications to the rest of the widget:

@override
Widget build(BuildContext context) {
  return Scaffold(
    appBar: AppBar(title: const Text('WITH Compute')),
    body: FutureBuilder<List<File>>(
      future: _createImages(),
      builder: (context, snapshot) {
        if (snapshot.hasData) {
          // Show all the images within a list
        } else {
          return const Center(
            child: CircularProgressIndicator(),
          );
        }
      },
    ),
  );
}

Future<List<File>> _createImages() async {
  // We call compute() with a reference to the top-level
  // function, as well as an instance of its parameters
  return compute(
    createImages,
    CreateImagesParams(
      url: _url,
      count: 4,
      directory: await getTemporaryDirectory(),
    ),
  );
}

If you try to execute this code now, despite the processing time for all the images being approximately the same, you will notice that the UI does not freeze. The loading widget we have implemented continues to spin throughout. This is because we have shifted the resource-intensive task to a background thread, allowing the main thread to maintain a smooth interface movement.

Conclusion

Flutter incorporates different ways of working with threads. As I have already commented in the article, these are called Isolates and they can be called directly, controlling each of the steps of their life cycle. However for simple tasks that only run for a few seconds and then complete it is better to use the compute() method, since it abstracts us from the relevant management of those threads.

You can find the complete project shown in this article here.

I hope you have found this article useful, see you at the next one!

This kind of technology usually involves a significant amount of work behind it. Not only do you need to understand how to implement and manage costly audio and video servers along with their respective video streaming technologies, but you also need to know how to properly integrate it into your frontend app, all while keeping latency to a minimum.

For this reason, ZEGOCLOUD, a company I've been working with for some time, provides state-of-the-art solutions in this field, offering you these capabilities without the need to worry about infrastructure costs or dedicating effort to integrate them into your app. With their UIKit, you can add another widget to your Flutter application that will automatically connect to your system and enable you to incorporate video conferencing functionality into your app in just a few minutes.

To do this, I'm going to show you the steps one by one that you need to follow to accomplish it. The first step is to visit the official ZEGOCLOUD website and sign up. Everything I'm going to explain here can be tried with a free account, without the need to add any payment method. This way, you can evaluate the service and see it in action without any cost.

Create the project in the ZEGOCLOUD Dashboard

The first thing you should do is create a project. You can do it by clicking on the "Create" button in the upper right corner, in the "Projects" section:

Next, you will be prompted to select the use case for your project. As you can see, there are numerous options to choose from; in this instance, we will select "Video Conference":

Let's give the project a name:

You have two options: one is to use their SDK for a fully custom implementation, where you can decide exactly how to interact with their services. The other option is to use a UIKit, which allows you to add a widget and have all the functionality implemented, including the visual interface.

Since we want to add this functionality as quickly as possible, we'll choose the "Start with UIKits" option:

Then we can choose the platform on which we want to work, for this tutorial we will do it on a Flutter application:

Everything is ready, press the "Save & Start to integrate" button and your project will be ready to be implemented.

Now you can view your project's configuration. You'll see your AppID and AppSign. Save these values, as you'll need them later to connect your app to the project you just created.

Add a Video Conference feature to your Flutter app

Now the fun part! Create a new Flutter application and add the following dependencies:

flutter create --platform android,ios flutter_video_conference
cd flutter_video_conference
flutter pub add zego_uikit_prebuilt_video_conference
flutter pub add uuid

The zego_uikit_prebuilt_video_conference plugin incorporates the UIKit for adding the Video Conference feature. We'll also add uuid to generate random identifiers for this example.

Before start developing, we must do some setup. Start by changing the following variables in android/app/build.gradle:

compileSdkVersion 33
minSdkVersion 22
targetSdkVersion 33

To add this feature, we must add the following permissions to android/app/src/main/AndroidManifest.xml:

<uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
<uses-permission android:name="android.permission.RECORD_AUDIO" />
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.CAMERA" />
<uses-permission android:name="android.permission.BLUETOOTH" />
<uses-permission android:name="android.permission.MODIFY_AUDIO_SETTINGS" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.READ_PHONE_STATE" />
<uses-permission android:name="android.permission.WAKE_LOCK" />

We should do the same for iOS. Open ios/Podfile and modify the last part of the file with the following addition:

post_install do |installer|
  installer.pods_project.targets.each do |target|
    flutter_additional_ios_build_settings(target)

    # Add this block
    target.build_configurations.each do |config|
      config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] ||= [
        '$(inherited)',
        'PERMISSION_CAMERA=1',
        'PERMISSION_MICROPHONE=1',
      ]
    end
  end
end

Declare the permissions in ios/Info.plist:

<key>NSCameraUsageDescription</key>
<string>Camera access is required to create a Video Conference</string>
<key>NSMicrophoneUsageDescription</key>
<string>Microphone access is required to create a Video Conference</string>

Great! Now everything is ready to start developing. Copy and paste the following Dart code in your lib/main.dart file. I've added several comments to the code so you can fully understand what I'm doing and how you can extend it further if you want:

import 'package:flutter/material.dart';
import 'package:uuid/uuid.dart';
import 'package:zego_uikit_prebuilt_video_conference/zego_uikit_prebuilt_video_conference.dart';

void main() {
  runApp(const App());
}

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

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Video Conference',
      theme: ThemeData(
        colorScheme: ColorScheme.fromSeed(seedColor: Colors.deepPurple),
        useMaterial3: true,
      ),
      home: const MainScreen(),
    );
  }
}

class MainScreen extends StatefulWidget {
  const MainScreen({Key? key}) : super(key: key);

  @override
  State<MainScreen> createState() => _MainScreenState();
}

class _MainScreenState extends State<MainScreen> {
  // This is the ID of this conference. We'll use this harcoded value
  // for now, but you should use a custom ID managed by your system
  // in order to manage all conferences.
  final String _conferenceId = 'my_conference';

  late final String _userId;
  late final String _userName;

  @override
  void initState() {
    super.initState();

    // We will create a random ID for now. But you should
    // use the ID that you already use for your users, 
    // and the username that each of them have.
    _userId = const Uuid().v4();
    _userName = 'user_${_userId.substring(0, 7)}';
  }

  @override
  Widget build(BuildContext context) {
    return SafeArea(
      // You just need to add this widget in order to
      // add the functionality to your app.
      child: ZegoUIKitPrebuiltVideoConference(
        // Add the AppID and AppSign that you saw before in
        // the project configuration in the Dashboard
        appID: your_app_id,
        appSign:
            'your_app_sign',
        userID: _userId,
        userName: _userName,
        conferenceID: _conferenceId,
        config: ZegoUIKitPrebuiltVideoConferenceConfig(),
      ),
    );
  }
}

Execute this code on two devices if possible. You will observe that you can engage in a video conference with your colleagues.

If you are looking for deeper requirements with video call SDK, ZEGOCLOUD also has a fully customized video calling SDK to meet your requirements.

And just like that you can have this feature implemented without the hassle of managing servers. Thanks to ZEGOCLOUD for sponsoring this article, and don't hesitate to go to their website to see more information about their services.

Happy coding!

The event began with the unveiling of the new 15-inch MacBook Air, followed by the Mac Studio upgrade featuring the M2 Max and M2 Ultra chips, and concluded with the announcement of the new Mac Pro powered by the M2 Ultra chip. Additionally, they introduced a new product, the Vision Pro, which are augmented reality glasses that will surely give a lot to talk about in the coming weeks.

However, this blog focuses on software, so in this article, I will provide a summary centered on software news for developers, including new APIs and the most notable changes announced that can potentially open new ways to develop new features for your apps.

📽 Video version available on YouTube and Odysee

Posters: visual identities for your contacts

We begin with the new major release of the OS that powers the iPhone: iOS 17. The first new feature announced is the addition of the Posters functionality for the calling app. This feature allows us to customize the interface when we receive a call from a contact. It lets us set the image and adjust the text, similar to how the wallpaper is customized. This configuration is also used in the contacts app, to maintain the same design whether we are viewing a contact's information or initiating a call with them. We can use this feature through the CallKit API, for instance, in a Voice over IP (VoIP) application, by displaying the image previously assigned by the user for a specific contact when they make a call.

With this new feature, users can assign visual identities to their contacts, which will be consistently displayed across system applications and third-party apps alike, enhancing their overall experience.

SharePlay: bring your device closer and share

The next feature is the possibility to share content via the SharePlay API with the simple gesture of bringing your device closer to another. In the presentation, Apple demonstrates how it can be used to quickly share your contact information with another person, or how to send images or videos. With SharePlay, we can implement sharing functions that work simply by bringing one device closer to another. For example, if we want to recommend a YouTube video to a friend, it would be enough to have it open and bring it closer to their phone, or imagine wanting to share an article from a news app or social network with another person. Through this new API, we can carry out any option to share data or content with another user much faster and with fewer actions, with the simple gesture of bringing the devices closer.

The new suggestions API

In this presentation, Apple has announced a new app that we will see from iOS 17: Journal. With this app, we will be able to maintain a personal diary in which we can record anything we want about our lives. What's notable here is that in the presentation, it is mentioned that this app uses the new Suggestions API, which allows for a series of suggestions based on other user data, such as locations or photos, to suggest things to write about. Developers will also have access to this API, and I imagine it can be used in a similar way, I mean: I assume that through this API, we can leverage user-generated content to provide suggestions based on their previous inputs. It's not entirely clear to me how it will be used, and I have my doubts about the privacy that this API will be able to maintain, but we will see all of this as soon as we start working with this new API.

HealthKit for iPad 17

We move on to the operating system that powers the iPads: the new iPadOS 17. One of the innovations introduced is the ability to use the HealthKit API on these tablets. Just like in iOS, through this API we can interact with data related to the user's health and fitness. We can collect, analyze, and process this data, for instance in apps related to weight tracking, step monitoring, health apps, or sports apps.

Create WebApps from Safari

In this presentation, Apple also unveiled the next major release of its desktop operating system: macOS Sonoma. In this section, I will highlight a few new features that caught my attention in the new version of Safari.

Now any user can create WebApps from Safari. In this case, it's not something new that you as a developer can use, since you don't have to make any changes for it. Any user can decide to turn any webpage into an application that will integrate seamlessly with the rest of the applications installed on the Mac. The user can set its name, the image will be the main icon of the website and then it will automatically appear on the Dock. From then on, this website can be used as if it were another application installed on the system.

Another feature worth noting is that Safari finally catches up with other browsers by adding the ability to create profiles. This allows users to separate cookies, bookmarks, history, and other browsing data by creating different profiles. This feature can be very useful, for instance, to separate the accounts that you use for work from the accounts that you use for your personal projects.

Continuity Camera API

To finish this list of news, I'm going to talk about the possibility of using the Continuity Camera API in applications for tvOS. With the help of this API, developers can utilize the iPhone camera within a tvOS app, enabling it to function as a camera. If you happen to be a programmer working on this operating system and have eagerly awaited a solution to incorporate camera functionality, your wait is over. During the Apple presentation, they showcased the seamless integration of the iPhone camera into a FaceTime call using this very API.

Conclusion

So, here you have a super quick rundown of the coolest updates I found for app development on Apple devices. You should check out the whole Keynote to expand on this information and to find out about the rest of the news presented at WWDC 2023.

Until next time!

However, if you're thinking about building a chat system for your app, you've probably already recognized the vast array of features you'll need to develop, from designing one-on-one chats and group chat architecture to user management, message sending and notifications, as well as considering privacy and security aspects, and so on.

For this reason, in this article, I provide you with a quick tutorial on how to add pre-built chat functionality to your application using ZEGOCLOUD, a company specializing in offering video and audio streaming services, as well as chat services in this case. I've been working with this company for a few months now, and I know for a fact that using their SDK, it's possible to bypass all the complexity I mentioned earlier and build your chat system quickly and easily.

How to add Chat functionality to your Flutter app

Let's start with the tutorial, first go to their official page and sign up. You can sign up and create a test project to test the service completely free of charge without entering any payment method. Once you have done it, click on "Create your project":

Then we will have to select which is the use case of our project, we will select "In-app Chat".

Then we will simply have to give it a name, you can choose the one you want:

Once the project has been created, click on it to see the configuration information. On this screen you will see two values: AppId and AppSign. You will need to use these values later to connect your application to the project you just created.

Now go to Service Management, In-app Chat and activate the functionality:

Perfect. We already have everything ready. Next, I'm going to create a base app from which you could start building your chat system.

Adding chat functionality to a Flutter app

Let's start by creating a new app for Android and iOS:

flutter create --platforms android,ios flutter_chat_app

For the chat functionality, we need to add the zego_zim dependency:

flutter pub add zego_zim

Next, you'll see a large block of code. If you run it, you'll be able to send messages from one device to another. You can find detailed explanations of each step in the form of comments:

import 'package:flutter/material.dart';
import 'package:zego_zim/zego_zim.dart';

void main() {
  runApp(const App());
}

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

  @override
  Widget build(BuildContext context) {
    return const MaterialApp(
      debugShowCheckedModeBanner: false,
      title: 'Flutter Chat App',
      home: ChatScreen(),
    );
  }
}

/// This class will help us to represent the information
/// of the messages within our app.
class Message {
  final String content;
  final String userId;
  final String userName;

  Message({
    required this.content,
    required this.userId,
    required this.userName,
  });
}

class ChatScreen extends StatefulWidget {
  const ChatScreen({super.key});

  @override
  State<ChatScreen> createState() => _ChatScreenState();
}

class _ChatScreenState extends State<ChatScreen> {
  // Make sure you protect these values correctly, ideally you should
  // get them from your secured backend after the user has logged in.
  static const _appId = your_app_id;
  static const _appSign =
      'your_app_sign';

  // For this example we are going to hardcode the ID of user A
  // and user B. It is important that in your chat system you use
  // your own identifiers, for example the ones you are already
  // using to identify users.
  static const _userAId = 'userA1234';
  static const _userBId = 'userB1234';

  // Set this variable to true on one device and false on
  // another to simulate different users.
  final bool _isUserA = true;

  late final ZIM _zim;
  late final ZIMAppConfig _appConfig;
  late final ZIMUserInfo _userInfo;
  late final Future<void> _future;

  final List<Message> _messages = [];

  final TextEditingController _controller = TextEditingController();
  final FocusNode _focusNode = FocusNode();
  final ScrollController _scrollController = ScrollController();

  @override
  void initState() {
    super.initState();

    // Initialize the ZIMAppConfig with your appId and appSign
    _appConfig = ZIMAppConfig()
      ..appID = _appId
      ..appSign = _appSign;
    _zim = ZIM.create(_appConfig)!;

    final id = _isUserA ? _userAId : _userBId;

    _userInfo = ZIMUserInfo()
      ..userID = id
      ..userName = 'user_$id';

    // For now we will use a FutureBuilder that will log the user.
    _future = _initialize();
  }

  @override
  void dispose() {
    _controller.dispose();
    _scrollController.dispose();
    _zim.logout();
    _zim.destroy();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) => FutureBuilder(
        future: _future,
        builder: (context, snapshot) {
          Widget bodyWidget;

          //In case of error we show a message on the screen
          if (snapshot.hasError) {
            bodyWidget = Center(
              child: Container(
                padding: const EdgeInsets.only(left: 24.0, right: 24.0),
                child: const Text(
                  'An error occurred while trying to initialize the chat.',
                  textAlign: TextAlign.center,
                ),
              ),
            );
          } else if (snapshot.connectionState == ConnectionState.done) {
            bodyWidget = Column(
              children: [
                // Show the list of message
                Expanded(
                  child: ListView(
                    controller: _scrollController,
                    children: [
                      for (final message in _messages)
                        Align(
                          alignment: message.userId == _userInfo.userID
                              ? Alignment.centerRight
                              : Alignment.centerLeft,
                          child: Container(
                            padding: const EdgeInsets.all(8.0),
                            child: _MessageEntry(
                              message: message,
                              isOwnMessage: message.userId == _userInfo.userID,
                            ),
                          ),
                        )
                    ],
                  ),
                ),
                // Send a message
                Container(
                  padding: const EdgeInsets.all(12.0),
                  color: Colors.grey[200],
                  child: Row(
                    children: [
                      Expanded(
                        child: TextFormField(
                          controller: _controller,
                          focusNode: _focusNode,
                          decoration: const InputDecoration(
                              hintText: 'Write a message here'),
                        ),
                      ),
                      ElevatedButton(
                        onPressed: () {
                          _focusNode.unfocus();
                          _sendMessage(_controller.text);
                          _controller.clear();
                        },
                        child: Row(
                          children: const [
                            Text('SEND'),
                            Padding(
                                padding: EdgeInsets.only(left: 4.0),
                                child: Icon(Icons.send)),
                          ],
                        ),
                      ),
                    ],
                  ),
                )
              ],
            );
          } else {
            bodyWidget = const Center(
              child: CircularProgressIndicator(),
            );
          }

          return Scaffold(
            appBar: AppBar(
              title: const Text('Flutter Chat App'),
            ),
            body: bodyWidget,
          );
        },
      );

  /// In this method we will login the user and we will also
  /// set up a listener to receive messages from the other user.
  Future<void> _initialize() async {
    await _zim.login(_userInfo);

    ZIMEventHandler.onReceivePeerMessage =
        (ZIM zim, List<ZIMMessage> messageList, String fromUserID) {
      for (ZIMMessage message in messageList) {
        switch (message.type) {
          case ZIMMessageType.text:
            message as ZIMTextMessage;
            _addMessage(
              Message(
                  content: message.message,
                  userId: message.senderUserID,
                  userName: 'user_${message.senderUserID}'),
            );
            break;
          case ZIMMessageType.command:
            message as ZIMCommandMessage;
            break;
          case ZIMMessageType.image:
            message as ZIMImageMessage;
            break;
          case ZIMMessageType.file:
            message as ZIMFileMessage;
            break;
          default:
        }
      }
    };
  }

  /// This method will send a message to the other user.
  Future<void> _sendMessage(String message) async {
    final scaffoldMessenger = ScaffoldMessenger.of(context);

    final textMessage = ZIMTextMessage(message: message);
    final sendConfig = ZIMMessageSendConfig()
      ..priority = ZIMMessagePriority.low;

    final pushConfig = ZIMPushConfig();
    pushConfig.title = "New message";
    pushConfig.content = message;

    sendConfig.pushConfig = pushConfig;

    try {
      await _zim.sendMessage(
        textMessage,
        _isUserA ? _userBId : _userAId,
        ZIMConversationType.peer,
        sendConfig,
      );
      _addMessage(Message(
        content: message,
        userId: _userInfo.userID,
        userName: _userInfo.userName,
      ));
    } on Exception catch (_) {
      scaffoldMessenger.showSnackBar(
        const SnackBar(
          content: Text(
            'An error occurred while trying to send a message',
          ),
        ),
      );
    }
  }

  void _addMessage(Message message) {
    setState(() {
      _messages.add(message);
      _scrollController.jumpTo(_scrollController.position.maxScrollExtent);
    });
  }
}

/// This widget will be the visual representation of
/// each message within the message list.
class _MessageEntry extends StatelessWidget {
  final Message message;
  final bool isOwnMessage;

  const _MessageEntry({required this.message, required this.isOwnMessage});

  @override
  Widget build(BuildContext context) => SizedBox(
        width: 200.0,
        child: Container(
          padding: const EdgeInsets.all(8.0),
          decoration: BoxDecoration(
            borderRadius: const BorderRadius.all(Radius.circular(8.0)),
            color: isOwnMessage ? Colors.blue[800] : Colors.blue,
          ),
          child: Column(
            mainAxisSize: MainAxisSize.min,
            crossAxisAlignment: CrossAxisAlignment.start,
            children: [
              Text(
                message.userName,
                style: const TextStyle(
                  color: Colors.white,
                  fontSize: 10.0,
                  fontWeight: FontWeight.bold,
                ),
              ),
              const Divider(
                color: Colors.white54,
              ),
              Text(
                message.content,
                style: const TextStyle(color: Colors.white),
              ),
            ],
          ),
        ),
      );
}

And there you have it! This straightforward tutorial has demonstrated how to incorporate chat functionality into your Flutter application by utilizing the powerful ZEGOCLOUD SDK. I sincerely hope that you found this guide to be informative and beneficial, as it aims to provide you with a solid foundation for swiftly implementing a chat system within your app.

I wish you the best of luck in your future endeavors, and I look forward to sharing more valuable insights with you in the future. Until next time, happy coding!

Stick with me as I'm going to give you a hyper-quick tour of all these improvements so you can get an overview of the best of the best in Flutter 3.10.

📽 Video version available on YouTube and Odysee

Impeller is production-ready on iOS

In Flutter 3.10, Impeller replaces Skia and becomes the primary rendering engine on iOS. This new rendering engine brings improved performance to our animations and eliminates the troublesome shader compilation issues that caused janky animations and an unpleasant visual experience. To achieve this, Impeller utilizes a tessellation algorithm that bypasses the need for shader compilation during graphics rendering.

Impeller harnesses the advanced capabilities of next-generation GPUs to render various shapes and colors on the screen seamlessly, ensuring a consistently high framerate. It has been meticulously crafted from the ground up to cater specifically to the requirements of Flutter.

In Flutter 3.10, Impeller is the default rendering engine for all iOS apps developed with Flutter. Furthermore, the Flutter team has revealed their ongoing efforts to bring Impeller to Android, with a preview version slated for future releases.

Dart 3

Flutter 3.10 introduces an exciting addition: Dart 3, the latest major release of the programming language driving Flutter. Dart 3 brings a significant enhancement by completely removing non-null-safe code, ensuring a fully protected and problem-free experience in this 100% safe language, eliminating the pitfalls typically associated with nullable languages.

Furthermore, Dart 3 introduces numerous language enhancements, including the introduction of Patterns. This feature makes it easy to work with structured data. The official Dart 3 blog post provides a practical demonstration of a function that conveniently returns two values simultaneously.

(String, int) userInfo(Map<String, dynamic> json) {
  return (json['name'] as String, json['height'] as int);
}

Consequently, there will be no need to encapsulate multiple values within a collection or create a dedicated class for that purpose.

Additionally, the updated switch statement allows for the orderly deconstruction of structured patterns, while new class modifiers like interface class and sealed class offer expanded capabilities.

Please tell me in the comments section if you are interested in me creating a comprehensive article exploring these enhancements and demonstrating how you can leverage them to your advantage.

Improvements for Flutter for Web

In relation to Flutter for the web, noticeable improvements have been made to enhance application loading speed. One key achievement is the substantial reduction in the size of Canvaskit, the largest component in Flutter for the web, now reduced to one-third of its previous size. Additionally, unused fonts can now be removed, further reducing the overall weight. Flutter 3.10 introduces comprehensive support for seamlessly embedding pure HTML elements within the application. Furthermore, the inclusion of fragment shader support empowers developers to create stunning visual effects using familiar Dart code.

In addition to all this, the Flutter team remains dedicated to ensuring seamless integration between Flutter and the new WebAssembly standard, commonly known as WASM. This involves enabling the inclusion of garbage-collected languages like Flutter within the standard. Initial tests have already demonstrated a remarkable performance boost of up to three times. With the eventual distribution of WASM to the general public, this exciting addition holds great promise for web applications developed using Flutter.

New Material 3 widgets

This latest version of Flutter continues its efforts to enhance support for Material 3. It introduces the option to create color schemes based on either a base color or an image. Significant enhancements have been applied to various widgets, including DropdownMenu, NavigationDrawer, TabBar, SnackBar, and others, aligning them with the updated Material 3 design guidelines. Additionally, widget support for iOS/macOS has been improved. Users can now utilize Apple's spell-checking feature within editable text widgets, along with the addition of a new checkbox and radio button design that complements Cupertino aesthetics. Furthermore, there are animation improvements specific to Apple platforms.

Speaking of Apple, this Flutter version now enables wireless debugging directly to iPhones and iPads, a functionality previously available only in Xcode.

To witness all of these improvements in action, you can explore the official sample showcasing Material 3 features.

Enhanced DevTools

This version also introduces several enhancements to the development tools, empowering developers to analyze and optimize their apps' performance effectively.

Notably, the memory page has received new features. The addition of the Diff tool enables the comparison of memory usage before and after specific interactions, providing insights into the impact of those interactions. Furthermore, improvements have been made to streamline heap exploration directly from the console.

The DevTools user interface has been updated with Material 3 widgets, enhancing usability and maintaining consistency with the latest design guidelines. Additionally, the open-source tool Perfetto has been integrated, replacing the older trace viewer. Perfetto excels in managing large datasets and introduces features like pinning threads of interest, dragging and selecting multiple timeline events, and utilizing SQL queries to retrieve specific timeline data.

Flutter now supports SLSA level 1

Ensuring security is a critical aspect when working with open-source code. That's why Flutter now supports Supply Chain Levels for Software Artifacts (SLSA), level 1. This implementation enables Flutter's build scripts to operate on trusted platforms. Furthermore, the release workflow for each new version of Flutter undergoes a rigorous approval process involving multiple engineers. Additionally, both beta and stable releases now come with provenance, meaning that trusted sources have constructed the final artifact that developers will utilize to build Flutter applications on their machines.

These measures are in response to recent security attacks and vulnerabilities observed in other open-source projects, such as the NPM ecosystem. The Flutter team is proactively taking steps to enhance the security of the ecosystem, making it more robust and reliable for developers and end users alike.

Conclusion

So far, I have briefly covered the key highlights of the notable improvements in Flutter 3.10. If you wish to delve deeper into these details, I highly recommend reading the official blog post on Flutter 3.10 and the blog post on Dart 3. Additionally, I suggest watching the comprehensive collection of recently uploaded Flutter videos on YouTube.

Thank you for reading thus far! Until next time!