DEV Community: David Serrano

My (Dark) Prediction for Android

David Serrano — Sun, 31 Aug 2025 10:38:38 +0000

This article is a more detailed follow-up to a Reddit post I recently published called “My prediction for Android”, which reflects my personal views as an Android developer, based on publicly available information and my own interpretation of current trends.

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

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.

🛠️ How to Use Multiple Windows in Flutter Desktop

David Serrano — Tue, 24 Jun 2025 14:14:06 +0000

Introduction

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.

5 Tips to Optimize Your Flutter App 🔥🚀

David Serrano — Wed, 23 Apr 2025 16:37:42 +0000

Flutter is a fantastic tool for building cross-platform applications quickly and effectively, as it allows you to launch your app for Android, iOS, Windows, macOS, and Linux — all from a single codebase. However, one of the most common criticisms of Flutter throughout its history has been its performance, especially on certain platforms like Apple’s devices. That’s why it’s crucial for you, as a developer, to have the right skills to optimize your app as much as possible, ensuring it runs fast and smoothly on the user’s device. Ideally, the user shouldn’t even be able to tell the difference between a native app and one built with Flutter.

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.

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.

👉 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:

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.

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.

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!

Your home address exposed on Google Play 😰

David Serrano — Mon, 16 Sep 2024 15:37:01 +0000

In recent months, Google Play has rolled out a new account verification process that applies to all developers. These policies require developers to provide verified information to continue distributing their apps on the platform. The objective, according to Google, is to ensure that the apps available on Google Play meet high standards of quality and reduce the risk of malicious software being distributed.

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.

Learn Flutter by creating your first Flutter app!

David Serrano — Sun, 05 May 2024 16:49:55 +0000

In this article, I'm going to introduce you to your first Flutter app. We will explore the parts of a Flutter project, their roles, and we'll cover some fundamental concepts of state, including the differences between StatelessWidgets and StatefulWidgets.

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.

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.

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!

Is it worth learning Flutter in 2024?

David Serrano — Fri, 19 Jan 2024 16:04:35 +0000

Flutter, the great cross-platform framework that allows you to create applications for mobile, web, and desktop with a single codebase. However, despite all the benefits it conveys, is it a good decision to invest time and energy in learning this technology in 2024?

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 :)

Flutter 3.16 released! Android Impeller preview, Game Toolkit Updates, iOS extensions and more!

David Serrano — Thu, 16 Nov 2023 18:54:58 +0000

We now have the new version of Flutter available, Flutter 3.16, and it's packed with cool new stuff like Impeller in preview mode for Android, support for Predictive Back Navigation for Android 14 and Material 3 as the default visual style. Also, you can now use Flutter widgets in some iOS extensions. And for the game devs, there are some sweet updates in the Flutter Games Toolkit. This is the last major update we're getting this year, and it's all about making our development faster and our projects better, so let's see in detail the most notable new features of Flutter 3.16.

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 :)

Insane new App/Game launch requirements on Android 😰

David Serrano — Mon, 13 Nov 2023 18:11:19 +0000

Google announced the other day its new plans regarding changes to the policy that governs developers and applications published on Google Play. In its tireless fight against malware, fraud and low-quality applications, Google has decided to introduce a fundamental change that can harm the dreams of many indie game or app developers, if not end those dreams completely.

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:

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:

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:

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.

Build your knowledge base with Spreading: The AI-Powered Knowledge Base Platform for Developers

David Serrano — Tue, 24 Oct 2023 11:05:09 +0000

Technology advances very quickly, and that implies that the entire flow of information, good practices, systems, and know-how that circulate within a development team, within a sector, or an entire organization also circulates quickly and dynamically.

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 :)

What Godot devs need to know about this new EU law (Cyber Resilience Act)

David Serrano — Fri, 20 Oct 2023 14:38:23 +0000

The Cyber Resilience Act, or CRA, is a new legislation that aims to establish new cybersecurity requirements for devices and software marketed in the European Union.

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.

Game Programming Patterns in Godot: The Command Pattern

David Serrano — Sat, 14 Oct 2023 13:44:04 +0000

Have you ever been playing an adventure game and suddenly lost control of your character because a cutscene starts, revealing more of the story? Or in a strategy game or map editor, have you had the option to undo a recent action?

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!

Can Godot screw us like Unity did?

David Serrano — Mon, 18 Sep 2023 19:10:55 +0000

Unity has just destroyed itself and along with it an entire community of video game developers who have put their effort, money, time and hope into it.

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.