Introduction

Firebase Cloud Functions is a serverless compute platform that enables developers to create backend logic in JavaScript or TypeScript. It is built on top of Google Cloud Functions, providing a scalable and flexible backend infrastructure. With Cloud Functions, developers can focus on building features and let Firebase handle the underlying infrastructure, making it an efficient and scalable way to build backend services. Cloud Functions are seamlessly integrated with Firebase, enabling developers to add value to their project directly and quickly deploy code

Firebase Cloud Functions are built on top of Google Cloud Functions, but they provide a simpler and more streamlined interface, with minimal configuration required. This is because Firebase aims to make it easy for developers to deploy backend logic without worrying about infrastructure management.

However, there are times when additional configuration is necessary, such as when restricting access to Cloud Functions. By default, Firebase Cloud Functions are public, but it’s possible to restrict access to specific users or entities. In this article, we’ll explore how to protect Cloud Functions with an API key, so that only authorized users with a valid key can call the function.

Where should we check that a user have correct authorization ?

There are various methods to secure Cloud Functions, and one approach is to check whether the user has the appropriate role within the function. While this can be effective, it may not be the most secure solution. Allowing unauthorized users to enter the function, even if they don’t have permission to call it, could pose a risk. Malicious users could attempt to access sensitive data or execute unauthorized actions.

To mitigate this risk, it’s best to have a reverse proxy in front of the Cloud Function to filter authorized users. This approach helps to ensure that only authorized users can access the function, and provides an additional layer of security against malicious attacks.

Instead of doing that :

We want to do that :

This article primarily focuses on securing calls that are not made from your app’s frontend. If you’re looking to secure Firebase resources in this context, consider using the App Check Firebase service.

Why use API keys to secure Firebase Cloud Functions?

In a reverse proxy, there are multiple techniques available to verify user authorization. One such technique is using an API key, which is relatively easy to implement. However, if we want to enhance security, we can use JWT tokens instead. This approach provides more security because JWT tokens have a limited lifetime, meaning that Cloud Functions can only be called within a specific time range. This approach helps to prevent malicious actors from using a stolen JWT token for an extended period. However, using JWT tokens requires creating and managing them, which can be a bit more complex.

On the other hand, API key authorization requires fewer steps. However, if an API key is stolen, the malicious actor can use it to call Cloud Functions as long as the key is valid. For this reason, it’s important to use API key authorization for non-critical Cloud Functions with a low level of risk. For sensitive Cloud Functions, it’s better to use an authentication method with a limited lifetime to enhance security.

Now that we have all the information we need, let’s move on to the implementation.

Implementation

Disabled public access

I have my Cloud Function, define by the following code :

export const securedHelloWorld =
    functions.https.onRequest((request, response) => {
        response.send("You are authorized to receive this Hello from Firebase!");
    });

Currently, it is not very secure because anyone can call it with a curl command, for example :

curl https://myfirebaseproject.cloudfunctions.net/securedHelloWorld

you will receive :

“You are authorized to receive this Hello from Firebase!”

The first step in securing our Cloud Function is to block public calls. We can do this by going to the GCP interface. When you create a Firebase project, it automatically creates a GCP project. To access your GCP project, the easiest way is to click on “Detailed usage stat.”

This will open your function details in GCP. Now, we need to remove the “allUsers” group from the Cloud Invoker role. This is what allows anyone to call our function. Essentially, it translates to “Ok GCP, let anyone call this function.”

If we try to call our function again with curl, we will receive the following response:

<html><head>
<meta http-equiv="content-type" content="text/html;charset=utf-8">
<title>403 Forbidden</title>
</head>
<body text=#000000 bgcolor=#ffffff>
<h1>Error: Forbidden</h1>
<h2>Your client does not have permission to get URL <code>/securedHelloWorld</code> from this server.</h2>
<h2></h2>
</body></html>

Now, our function is secured from public calls!

Create a service account

Before creating our API Gateway, we need to give permission to something to call our cloud function. Then we will associate this permission with our API Gateway to let our authorized users call the cloud function. In GCP, we do this with Service Accounts. Service Accounts are non-human accounts on your GCP project used to access specific resources. The best practice is to be as granular as possible and give as little permission as possible to each Service Account. One Service Account should only do one thing.

If you’ve never heard of Service Accounts before, this video is a good resource: What are Service Accounts?

In our case, we will need to have the right to call cloud functions, and we need to let the user who requests our function to act as this Service Account. For this, we will use the “Cloud Function Invoker” role and the “Service Account User” role.

Let’s configure this from the GCP interface:

Create the API config

Now, let’s create a reverse proxy using GCP.

GCP provides a service called “API Gateway” that enables us to create an API gateway, which is a specific type of reverse proxy.

If you’re interested in learning more about the difference between a reverse proxy and an API Gateway, check out this StackOverflow post: https://stackoverflow.com/questions/35756663/api-gateway-vs-reverse-proxy

The GCP API Gateway service work like this:

We have an API with a configuration that determines how the API behaves and a gateway that serves as an endpoint to call it. To secure our Firebase Cloud Function with an API key, we need to create a YAML file that describes our API configuration. This YAML file follows the OpenAPI standard and specifies that we want our API to redirect only authorized users, who have the correct API key, to our cloud function. This configuration can be translated into the following YAML file:

swagger: "2.0"
info:
  title: secured-api
  description: Secured API to let only authorized users to access the cloud function
  version: 1.0.0
schemes:
  - https
produces:
  - application/json
paths:
  /hello:
    get:
      summary: Receive a hello world message
      operationId: hello
      x-google-backend:
        address: https://myfirebaseproject.cloudfunction.net/securedHelloWorld
        protocol: h2
      security:
      - api_key: []
      responses:
        "202":
          description: Messages received, will be treated
          schema:
            type: string
        "400":
          description: Bad request
          schema:
            type: string
securityDefinitions:
  api_key:
    type: "apiKey"
    name: "key"
    in: "query"

That file is quite verbose, let’s summarize what it’s all about.

We can see that this YAML file defines a title and description, which are used to set the name and description of the API in GCP. The paths section specifies the endpoint that we can call. In this case, we have a configuration for the /hello path that allows for an HTTP GET request. The security section specifies that requests require an API key defined by the key api_key. The securityDefinitions section defines the type of security as an apiKey, and specifies that the API key needs to be provided in the query as the value of the key parameter. This YAML file can be used to create a secure API that only allows authorized users to access the Cloud Function.

Now that our API configuration is complete, we can proceed to create it on GCP using the following command:

gcloud api-gateway api-configs create CONFIG_ID \
  --api=API_ID --openapi-spec=path-to-yaml-file \
  --project=projectid --backend-auth-service-account=service-account-email

This command requires several arguments. The CONFIG_ID and API_ID are unique identifiers for the API and its corresponding configuration. Note that if you haven’t created an API first, it will automatically create one for you using the given ID.

It is important to note that the IDs must follow a specific format, and you should avoid using special characters or keeping them too long.

You also need to provide the path to your configuration file, your project ID, and the identifier of your service account that was created earlier. This identifier corresponds to the email address visible from the GCP console.

Finally, we need to enable the managed service associated with the API by running the following command:

gcloud services enable managed-service

You can find your managed service name at the landing page of your API Gateway’s.

Deploy your API to a Gateway

Now that we have set up everything for our API, the last thing to do is to actually deploy it on a gateway, to let users call it. To do that, we need to run the following command:

 gcloud api-gateway gateways create GATEWAY_ID \
  --api=API_ID --api-config=API_CONFIG_ID \
  --location=GCP_LOCATION --project=PROJECT_ID

Here, the GATEWAY_ID is how you want to name the Gateway. API_ID and API_CONFIG_ID are IDs that we have defined before. The project ID is still the ID of your GCP project. You also need to define a location. Here is the list of available locations:

* asia-northeast1
* australia-southeast1
* europe-west1
* europe-west2
* us-east1
* us-east4
* us-central1
* us-west2
* us-west3
* us-west4

And now, if you go back to GCP, you will see your API Gateway, and you can copy/paste the URL endpoint to try it!

Create the API Key

Now, if you try to call your endpoint with a curl command without including an API key, you will receive an error response since you need to include the API key to access the resource. Let’s create an API Key with GCP, which can be easily done in the console:

Pretty easy, right? But we should go a step further for security purposes. We need to restrict the scope of this API key to limit its power as much as possible. We must restrict its usage to only the API we defined earlier. This can also be easily done using the GCP console:

Testing and troubleshooting API key security

Everything is done! Good job! Now we have to test that everything works correctly. Here is the checklist that you need to verify:

• Calling your Firebase Cloud Function directly must fail
• Calling your API Gateway without an API key must fail
• Calling your API Gateway with the wrong API key must fail
• Calling your API Gateway with the correct API key must succeed

If these steps are valid, you have successfully secured your Firebase Cloud Function with an API key! Congrats!

To go a step further, you could monitor strange usage of your API key in order to detect if someone has stolen it. This will not be covered here, but maybe in another article we’ll see

Conclusion

That’s all for this article, I hope you have learned something and had a good time reading it. Don’t forget that an API key might not be the perfect way to secure a Firebase Cloud Function. As always, it depends on the context. If you have any ways to improve this tutorial, feel free to share them in the comments.

👏 Please clap this article if you found it useful 👏

Introduction

There is a really cool feature with Dart named dart:ffi. It’s the ability of the dart VM to run code that isn’t written in Dart. Basically, you can execute nearly everything that compiles to a shared library. A shared library is a file that is intended to be used across multiple programs. It takes the form of a dll file on the windows platform or a .so file on the Linux platform.

To glue the shared library with our Dart code, we use the dart:ffi package. It will load the shared library and get the exported functions from it. We can write our shared library code with C, C++, Rust, and theoretically anything that can be built to a shared library. In this demo, we are going to use Go.

We are going to learn how to use low level code in our Dart application.

Demo

To try this out, we are going to write a function in Go, that sums two numbers. Then we will call this function from our Dart code and print the result. It’s pretty easy, but we can learn a lot just with this little demo. Final code can be found here

GitHub - Pierre-Monier/dart_ffi_go_demo

The Go part

We need a function that makes the sum of two numbers and returns the result. In Go, it looks like this :

func Sum(a int, b int) int {
  return a + b
}

Very simple. But there is a problem, our Dart app can’t use this function like this. The reason is that Dart doesn’t know anything about the Golang int type. We must use a type system that is understandable by Dart.

To solve this, we use the C type system. It will be our common type interface. Dart knows about it (thanks to dart:ffi). So let’s rewrite our function like this :

import (
  “C”
)

func Sum(a C.int, b C.int) C.int {
  return a + b
}

We have just replaced types from int to C.int.

The last step is to export the function from the shared library. To do this, we just add a comment on top of our function :

//export Sum
func Sum(a C.int, b C.int) C.int {
 return a + b
}

And voilà, our function is ready to be used by Dart. Before that we must actually build our Go code to a shared library. It’s quite easy, just use the following command line

go build -buildmode=c-shared -o lib.a lib.go

It builds a shared library named lib.a with our file lib.go.

You can check that your function is well exported in the shared library by using the command nm -gU lib.a

Ok, perfect! We are all set up on the Go part. Now it’s time to go to the Dart side.

The Dart part

In this part we are going to do three things. First we will load the shared library, then we will pick up our function in it, finally we will call it.

Let’s create a class named FFIBridge that will be responsible for calling methods from the shared library.

class FFIBridge {}

Ok, so remember, the first thing is to load the shared library. We can do it, either statically or dynamically.

Statically means that our shared library will be bundled directly in our Dart program and loaded when it starts. The process is platform specific. You can find more info on this documentation. For the sake of simplicity, we are going to load our library dynamically.

Dynamically means that we will lazily load the shared library, when we want to use it. In order to do it, we must use the `DynamicLibrary` object, and give it the path to our shared library. Let’s add a private method named _getDynamicLibrary :

ffi.DynamicLibrary _getDynamicLibrary() {
 final libraryPath = path.join(Directory.current.path, ‘go’, ‘lib.a’);

return ffi.DynamicLibrary.open(libraryPath);
 }

Perfect, we have loaded our library like professionals. Next thing, pick up functions from it.

There is an attribute named lookup that is used to lookup for a specific function in our shared library. We are going to use it. Let’s add a _lookup attribute to the FFIBridge class, and pass it the value of the `lookup` attribute of our shared library.

class FFIBridge {
 /// Holds the symbol lookup function.
late final ffi.Pointer<T> Function<T extends ffi.NativeType>(
 String symbolName) _lookup;

FFIBridge() {
 _lookup = _getDynamicLibrary().lookup;
 }
…
}

Now we lookup for functions in the shared library. It’s a good idea to create a method in our bridge to call the shared library one. Let’s add it to the class :

int sum(int a, int b) {
 final sumFunctionInLibrary = _lookup<
 ffi.NativeFunction<ffi.Int32 Function(ffi.Int32 a, ffi.Int32 b)>>(
 ‘Sum’);

final convertedToDartSumFunction =
 sumFunctionInLibrary.asFunction<int Function(int a, int b)>();

 return convertedToDartSumFunction(a, b);
}

As you can see, we lookup for a C typed function and return it as a Dart function. We use ffi.Int32 as an equivalent to our Go C.int. Finally, we execute the function we found.

Now that we have everything set up, we can write our program.

import ‘dart/ffi_bridge.dart’;

void main() {
 final ffibridge = FFIBridge();
 final result = ffibridge.sum(2, 2);
 print(result);
}

If we execute it, we will see the number 4 printed. We did it!

Conclusion

As we had seen, dart:ffi isn’t that hard to use. Drawbacks are that we rely on the low level C type, and that we need to glue everything up.

There is a great package named ffigen that creates our FFIBridge class automatically. It uses C headers to generate the class.

If you are on a mac M1 desktop, you might be struggling to compile your code. The solution for me was to install the ARM version of Dart from here. More info about that on this stackoverflow question

Photo by Godfrey Nyangechi on Unsplash

Introduction

Waveform is a way of representing sound.

In this article, we are going to see how we can get the data needed to draw these waveforms, in a Flutter app.

For this we are going to use a tool named FFmpeg.

What is FFmpeg?

FFmpeg is a cross-platform command line used to encode and decode video. It’s a very powerful tool and one of the most complex command lines I’ve ever used.

In this article, we are going to use it to get the data needed to draw a waveform.

To use it in Flutter, we are going to use the ffmpeg_kit_flutter.

This plugin only works on Android, iOS and macOS.

But isn’t FFmpeg a “cross-platform” tool ?

Yeah, but the implementation isn’t currently done. You can read this GitHub issue about this topic.

What kind of data do we need?

Waveforms represent sound. More accurately, it represents the loudness of a sound. If it’s near zero (the center of the graph), that means the sound is very quiet.

So this

Means the sound isn’t very loud.

And this

Means the sound is very loud.

We can accomplish this in many ways.

In our case, we are going to use the peak level of the signal in dBFS. Peak level, highlight the maximum value.

If you want to show more nuance in your waveform, you should use the RMS level, more info about this topic in this article

How do we get the peak level of a sound with FFmpeg?

First thing, to get the peak level of a sound, you need a file containing the sound data.

In this article, we are going to use a cymbal sound

Fetching the file

For our example, we are going to put our cymbal sound file inside the app assets folder.

assets:
    - assets/cymbal.wav

Then we can get the file like this in our app:

Future<File> getAudioFileFromAssets() async {

  final byteData = await rootBundle.load('assets/cymbal.wav');

  final file = File('${(await getTemporaryDirectory()).path}/cymbal.wav');
  await file.writeAsBytes(byteData.buffer
      .asUint8List(byteData.offsetInBytes, byteData.lengthInBytes));

  return file;
}

It gives us a File object. Now we can use it to retrieve the information we want

Getting data from the file

Now that we have our file, we can retrieve the data.

We are going to use FFprobe. FFprobe is a part of the FFmpeg project and it’s used to get information from multimedia streams.

Here is the final command line we want to use:

ffprobe -v error -f lavfi -i amovie=/path/to/cymbal.wav,astats=metadata=1:reset=1 -show_entries frame_tags=lavfi.astats.Overall.Peak_level -of json

This is pretty intense, so I will explain it.

The -f lavfi option define a complex filtergraph.

The -v error specifies the log level and the -of json specifies that we want the output in json format.

Finally, the most interesting parts.

amovie=/path/to/cymbal.wav,astats=metadata=1:reset=1 -show_entries frame_tags=lavfi.astats.Overall.Peak_level

This is what we pass to the -i parameter. The -i parameter specifies the input data. Here with amovie we tell ffprobe that we will use an audio input.

The astats part is where the magic happens. We tell ffprobe to display information about the audio channel. The metadata and reset parameters are mandatory. metadata sets up the metadata injection, which defines the number of channels. reset defines the number of frames over which cumulative stats are calculated before being reset. By default, in ffmpeg an audio frame regroups 1024 samples.

If you want to change this number you can pass the asetnsamples to define how many samples should contain an audio frame. So if you set asetnsamples parameter to the audio file sample rate (usually 44.1kHz or 48kHz), you will fetch data every second.

All of this might sound complicated, here are some links to have a better understanding of what it is all about: https://sound.stackexchange.com/questions/41567/difference-between-frame-and-sample-in-waveform | https://stackoverflow.com/questions/3957025/what-does-a-audio-frame-contain#:~:text=An%20audio%20frame%2C%20or%20sample,44%2C100%20frames%2Fsamples%20per%20second.

We are setting metadata and reset parameters to 1. In most cases, this is what we want.

Finally, -show_entries frame_tags=lavfi.astats.Overall.Peak_level is what tells ffprobe to display the peak level information of the file. You can display a good deal of other information, just check the documentation

Implementation in Flutter

Now that we know what we are going to do, let’s start the fun part.

We are going to use the ffmpeg_kit_flutter to execute our command. It works like this:

FFprobeKit.executeAsync(command, () {
  callback executed when the command is done
});

FFprobeKit is the entry point of the FFprobe part of the plugin. In this example, we execute The executeAsync method to execute a FFprobe command asynchronously.

The result of the command is accessible from a FFprobeSession object. There are two ways of getting a FFprobeSession object. We can await the executeAsync method, or we can execute a callback when the FFprobe command is done.

Both work. In this article, we are going to register a callback when the command is done.

Here is the final code:

Future<List<double>> fetchDataFromFile(File audioFile) async {
  final audioFilePath = audioFile.path;

  final _completer = Completer<List<double>>();

  await FFprobeKit.executeAsync(
      "-v error -f lavfi -i amovie=$audioFilePath"
      ",astats=metadata=1:reset=1 -show_entries"
      " frame_tags=lavfi.astats.Overall.Peak_level -of json",
      (session) async {
    final returnCode = await session.getReturnCode();
    final output = await session.getOutput();

    if (ReturnCode.isSuccess(returnCode)) {
      _completer.complete(_outputToList(output));
    } else {
      _handleFailure(returnCode: returnCode, completer: _completer);
    }
  });

  return _completer.future;
}

As you can see we are using a Completer object to return data when our callback is executed.

When the FFprobe command is done, we get the return code and the output. We did a simple check to see if it was successful. If it’s not, we execute the _handleFailure function:

void _handleFailure({
    required ReturnCode? returnCode,
    required Completer<List<double>?> completer,
  }) {
    if (ReturnCode.isCancel(returnCode)) {
      print("ffprobe commande canceled");
      completer.complete(null)
    } else {
      final e = Exception("command fail");
      completer.completeError(e);
    }
  }

In this function, we just check that it is really a failure, and if that is the case, we make our Completer object complete with an error.

If the command is successful, we complete our Completer object with the result of the _outputToList function:

List<double> _outputToList(String? output) {
    if (output == null || output.isEmpty) {
      throw Exception("No data");
    }

    try {
      final parsedOutput = jsonDecode(output);
      final frameData = parsedOutput["frames"] as List;
      return frameData
          .map<double?>((e) {
            try {
              return (double.parse(e["tags"]["lavfi.astats.Overall.Peak_level"] as String));
            } catch (e) {
              return null;
            }
          })
          .whereType<double>()
          .toList();
    } on Exception catch (_) {
      throw Exception("Parsing failed");
    }
  }

In this function, we make sure that we have data in the output. If this is not the case, we raise an exception. Then, we try to parse the data. If the parsing fails at some point, again we raise an exception. And if everything is fine we parse the output and create a List<double> object out of it.

Here’s a short sample of the data we get with our cymbal sound file:

Cymbal sound peak level:
-0.409556
-0.099999
-1.481092
-4.157582
-4.091515
-5.026431
-6.185354
-6.70617
-7.72662
-7.750185
-7.882804
-8.599196
-10.24849
-10.57842
-10.160495
-9.912185
-10.668357
-11.534391
-11.89096
-11.727936
-11.59894
...

Conclusion

Ok, we now know how to use FFprobe to get data to draw waveforms. Now we can use this precious data to draw waveform using CustomPainter :). Hope you learn some stuff

Photo by Markus Winkler on Unsplash

Introduction

Humans make mistakes all the time.

In this article, we are going to see how we can avoid unwanted regular actions that have an impact on an external system state.

Use case

For example, imagine you are writing a super important email for a job interview. Unfortunately, you accidentally press the send button, and you send a dummy email to your future boss. Now you have to write a new email that explains why you have just sent this strange email. This is not really the perfect scenario for your future job interview.

What can we do?

In this case, it will be impossible to add an alert dialog. The goal of the app is to view and send emails. If each time you send an email you have to go through a dialog that prevents a mistake that is occurring at most 1% of the time, it will be pretty annoying.

Also, you can’t add a Ctrl+z feature. When the email is sent, it’s out of the app’s control.

You might implement logic on the server side. You can push emails into a queue. Then emails are sent after a safety delay. And during this delay, the email app can tell the server “please stop this email sending task, it was a mistake.”

This can totally work, but I see three drawbacks to this solution.

First, it requires that you have total control of the server.

Second, if you have total control on the server. Implementing this feature can take a significant amount of time and effort.

Third, it’s dependent on network calls.

Even if it has drawbacks, I think this solution is the best in most cases

In this article, we are going to see another way. Basically, we are going to set the safety delay inside the app. It might not be the perfect solution (it depends on each case), but it’s a pretty straightforward solution, easily implemented.

Cancelable to the rescue

There is a great package named async. It adds some great features on asynchronous operation.

We are going to use an object from this library named CancelableOperation. It's an object that wraps a future, and it can cancel the future operation programmatically.

It works like this:

final cancelableOperation = CancelableOperation.fromFuture(
      your future function here,
)

What we can do now is pass a Future.delay with the desired safety delay. Then, we chain the cancelable operation with the action we want to do (for example, send an email). We can also create a function which will cancel our operation

Like this:

const duration = Duration(seconds: 2);

final cancelableOperation = CancelableOperation.fromFuture(
      Future.delayed(duration),
    ).then(
      (_) => your action,
);

void undoFunction() {
      cancelableOperation.cancel();
}

Now we can pass the undoFunction to a button on a snack bar for example. So if the user makes a mistake, he can still undo it.

Final code with demo

import "package:async/async.dart";
import 'package:flutter/material.dart';

const Color darkBlue = Color.fromARGB(255, 18, 32, 47);

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

class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      theme: ThemeData.dark().copyWith(
        scaffoldBackgroundColor: darkBlue,
      ),
      home: const Scaffold(
        body: Center(
          child: MyWidget(),
        ),
      ),
    );
  }
}

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

  @override
  State<StatefulWidget> createState() => _MyWidgetState();
}

class _MyWidgetState extends State<MyWidget> {
  final _items = <String>[];

  // HERE 
  void _triggerActionWithAnUndoOption(BuildContext context) {
    const duration = Duration(seconds: 2);

    final cancelableOperation = CancelableOperation.fromFuture(
      Future.delayed(duration),
    ).then(
      (_) => _addItem("My action is done"),
    );

    void undoFunction() {
      cancelableOperation.cancel();
      _addItem("My action is canceled");
    }

    _showSnackbar(
      context: context,
      undoFunction: undoFunction,
      duration: duration,
    );
  }

  void _addItem(String item) {
    setState(() {
      _items.add(item);
    });
  }

  void _showSnackbar(
      {required BuildContext context,
      required void Function() undoFunction,
      required Duration duration}) {
    final snackBar = SnackBar(
      content: const Text('Ok, you can still undo this'),
      duration: duration,
      action: SnackBarAction(
        label: 'UNDO',
        onPressed: undoFunction,
      ),
    );

    // Find the ScaffoldMessenger in the widget tree
    // and use it to show a SnackBar.
    ScaffoldMessenger.of(context).showSnackBar(snackBar);
  }

  @override
  Widget build(BuildContext context) {
    return ListView(children: [
      TextButton(
          child: const Text("Click me :)"),
          onPressed: () => _triggerActionWithAnUndoOption(context)),
      ..._items.map<Widget>((e) => Center(child: Text(e))),
    ]);
  }
}

Drawback

This is great. The user can undo his action if he wants, without being annoyed.

A major drawback is that if the user cleans the app resources while the action is still in the safety delay, the action will not be executed.

So if the user does that

Our action might not be executed.

This is pretty logical, because we clean all resources and our desired action is still waiting to be executed.

What can we do?

We can still make it work on the app side.

For this, we will have to execute our action with a safety delay in the background.

There is a great package for this named workmanager

Only works on Android and iOS

The action will be executed in the background. That means that it will not be able to access the app resources. You can’t pass any object instance from your app. The action must be static.

First you must set up your app, for this check the documentation for the Android platform and for the iOS platform

It works like this.

First, we register a callback that is going to execute different functions based on a task name.

void callbackDispatcher() {
  Workmanager().executeTask((task, inputData) {
    print("Native called background task: $task"); //simpleTask will be emitted here.
    return Future.value(true);
  });
}

This must be at the top level of the app, or a static method of a class

We are going to create a service who are going to do three things.

• register the callbackDispatcher
• Send task on the background
• Cancel task

import 'package:workmanager/workmanager.dart';

void callbackDispatcher() {
  BackgroundService.workmanager.executeTask((task, inputData) {
    print("Native called background task:"); //simpleTask will be emitted here.
    return Future.value(true);
  });
}

class BackgroundService {
  static final Workmanager workmanager = Workmanager();
  static const String taskName = "UndoDemo";

  static Future<void> initialize() {
    try {
      return workmanager.initialize(callbackDispatcher, isInDebugMode: true);
    } on Exception catch (e) {
      print(e);
      rethrow;
    }
  }

  static Future<void> executeTaskInBackground(
      {required String uniqueName, Duration duration = Duration.zero}) async {
    return workmanager.registerOneOffTask(uniqueName, taskName,
        initialDelay: duration);
  }

  static Future<void> cancelTask(String uniqueName) {
    return workmanager.cancelByUniqueName(uniqueName);
  }
}

We use static method, this is great for our simple use case. One drawback of this is that static method are hard to mock, meaning they are hard to use in test.

First, you must update the main method to initialize the BackgroundService

void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  await BackgroundService.initialize();
  runApp(const MyApp());
}

Now we can update the function trigger by our button to make it like this

void _triggerActionWithAnUndoOption(BuildContext context) {
    const duration = Duration(seconds: 2);

    const taskUniqueName = "simpleTask";

    BackgroundService.executeTaskInBackground(
        uniqueName: taskUniqueName, duration: duration);

    void undoFunction() {
      BackgroundService.cancelTask(taskUniqueName);
      _addItem("My action is canceled");
    }

    _showSnackbar(
      context: context,
      undoFunction: undoFunction,
      duration: duration,
    );
  }

Now we have the same workflow as before, but our actions are executed in the background. So even if our user clears the app process before our action is executed, it will still be executed (in the background).

Note the debug notification who tell us that our background task was successful

Conclusion

Our solution was pretty simple and straightforward.

Now our user can make errors without much consequence. We learn what was a CancelableOperation and that we can execute tasks in the background with workmanager.

Introduction

Flavors are a way of creating different environments for our application. It allows us to specify the app configuration for each of our cases. For example, we want to create a development flavor that is going to use different API endpoints than the production flavor which will be available to customers. Flutter makes it easy, we will see how, but there is currently no out-of-the-box solution inside Flutter itself. Thanks to the awesome Flutter community, there are some pretty good packages on pub.dev to make our life easier. In this post, we will see how to set flavors to a Flutter application. Then we are going to see how we can get the best out of these flavors. We will see how it simplifies the CI/CD and how we can configure VsCode to run each flavor from the interface.

Demo App

To demonstrate the power of flavors, we are going to create a small, useless app that is only going to display its boring information (app name, package name) using package_info_plus and a GIF, which will be different for each flavor.

You can find the repo on github

The code of the main.dart file looks like this:

import 'dart:async';

import 'package:flavors_demo/flavors.dart';
import 'package:flutter/material.dart';
import 'package:package_info_plus/package_info_plus.dart';

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

class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flavors Demo',
      theme: ThemeData.dark(),
      home: const MyHomePage(title: 'Flavors Demo'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({Key? key, required this.title}) : super(key: key);

  final String title;

  @override
  _MyHomePageState createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  PackageInfo _packageInfo = PackageInfo(
    appName: 'Unknown',
    packageName: 'Unknown',
    version: 'Unknown',
    buildNumber: 'Unknown',
  );

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

  Future<void> _initPackageInfo() async {
    final info = await PackageInfo.fromPlatform();
    setState(() {
      _packageInfo = info;
    });
  }

  Widget _infoTile(String title, String subtitle) {
    return ListTile(
      title: Text(title),
      subtitle: Text(subtitle.isEmpty ? 'Not set' : subtitle),
    );
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: ListView(
        children: <Widget>[
          _infoTile('App name', _packageInfo.appName),
          _infoTile('Package name', _packageInfo.packageName),
          Image.network(
            "https://media.giphy.com/media/s9ijJ0AI4JKko/giphy.gif",
          ),
        ],
      ),
    );
  }
}

Nothing much is happening here, just displaying some app info and an Image from a classic french TV show. The result look like this:

Now we are going to add 3 flavors to our app. One for development, another one for staging, and finally, one for production.

Setting up flavors

Configuring flavors is mostly done by setting up some config files in the Android and iOS folder. It’s from my point of view, not really the most exciting part of creating an app, but thanks to the community, some have created tools to make this part easier. In this article, we are going to focus on flutter_flavorizr.

At the time I am writing this article, the latest version (2.1.2) isn’t compatible with the integration_test package. So if you want to use this package and still write integration tests, you should add the following line to your pubspec.yaml file flutter_flavorizr: <2.1.2.

Once installed, we can add the following lines to our pubspec.yaml file.

flavorizr:
  ide: "vscode"
  app:
    android:
      flavorDimensions: "flavor-type"
    ios:

  flavors:
    development:
      app:
        name: "Development Flavor"

      android:
        applicationId: "com.dev.flavorsdemo"

      ios:
        bundleId: "com.dev.flavorsdemo"
        buildSettings:
          # Development Team is visible in the apple developer portal 
          DEVELOPMENT_TEAM: YOURDEVTEAMID 
          PROVISIONING_PROFILE_SPECIFIER: "Dev-ProvisioningProfile"

    staging:
      app:
        name: "Staging App"

      android:
        applicationId: "com.staging.flavorsdemo"
      ios:
        bundleId: "com.staging.flavorsdemo"
        buildSettings:
          DEVELOPMENT_TEAM: YOURSTAGINGTEAMID
          PROVISIONING_PROFILE_SPECIFIER: "Staging-ProvisioningProfile"

    production:
      app:
        name: "Production App"

      android:
        applicationId: "com.production.flavorsdemo"
      ios:
        bundleId: "com.production.flavorsdemo"
        buildSettings:
          DEVELOPMENT_TEAM: YOURPRODUCTIONTEAMID
          PROVISIONING_PROFILE_SPECIFIER: "Production-ProvisioningProfile"

What’s happening ?

The first config we see is the flavorDimensions for Android. This is to create complex flavors that can combine with each other. Note that the value flavor-type is the default, and this is what we want in most cases. If you want to read about this topic, here is the documentation

Next we can see our array of flavors. In our case we have defined 3 flavors, development, staging and production. Each of these flavors has a different app name, a different applicationId for Android and different bundleId/buildSettings for iOS.

Other config

There are more configurations we can add. First, if you have already configured app icons with flutter_launcher_icons, you can add generateDummyAssets to false. This will prevent flutter_flavorizr to create dummy assets for each of your flavors.

If you want to set a different icon for each of your flavors, you can do that with flutter_launcher_icons. flutter_flavorizr also has this feature, just add the icon field and set it to the path of the desired icon. For example:

flavors:
    development:
      app:
        name: "Development Flavor"

      android:
        applicationId: "com.dev.flavorsdemo"
        icon: "assets/path-to-your-icon"

      ios:
        bundleId: "com.dev.flavorsdemo"
        buildSettings:
          # Development Team is visible in the apple developer portal 
          DEVELOPMENT_TEAM: YOURDEVTEAMID 
          PROVISIONING_PROFILE_SPECIFIER: "Dev-ProvisioningProfile"
        icon: "assets/path-to-your-icon"

You can also add a configuration related to Firebase. Check the documentation for more info about that

There is an IDE field to configure your IDE. But we will see that later.

Create flavors

Now that we have our flavors set up, we can create them! For that run the command flutter pub run flutter_flavorizr. This will create all the configuration files for Android and iOS. It will also generate dart files. Let's see what they are used for

flavors.dart

You can see this file like a .env file, but with more power because it’s a dart file. It’s pretty simple, you have an enum named Flavor and this enum has 3 possible values (each for one of your defined flavors). Now, to fetch a specific value for one flavor, we create a static method. Here is the generated default file:

enum Flavor {
  DEVELOPMENT,
  STAGING,
  PRODUCTION,
}

class F {
  static Flavor? appFlavor;

  static String get name => appFlavor?.name ?? '';

  static String get title {
    switch (appFlavor) {
      case Flavor.DEVELOPMENT:
        return 'Development Flavor';
      case Flavor.STAGING:
        return 'Staging App';
      case Flavor.PRODUCTION:
        return 'Production App';
      default:
        return 'title';
    }
  }

}

To define an env variable, we add something like this in our flavors file:

static String get memeUrl {
    switch (appFlavor) {
      case Flavor.DEVELOPMENT:
        return "https://media.giphy.com/media/s9ijJ0AI4JKko/giphy.gif";
      case Flavor.STAGING:
        return "https://media.giphy.com/media/XknChYwfPnp04/giphy.gif";
      case Flavor.PRODUCTION:
        return "https://media.giphy.com/media/zrCSvFfl2fP7W/giphy.gif";
      default:
        throw Exception("Unknown flavor for memeUri");
    }
  }

We just define an env variable. Now we can use it in our app like this:

Image.network(F.memeUrl)

You might be asking yourself “but how is my app going to know what flavor to use?”. This is our next step.

main-flavor.dart

In order to know which flavor to use, we need a new entry point for each of our flavors. It might be weird because we are used to only one app entry point, main.dart. Now we have three of them. In each of these new entry points, we are setting the static field appFlavor of the F class to the desired flavor.

import 'package:flutter/material.dart';
import 'app.dart';
import 'flavors.dart';

void main() {
  F.appFlavor = Flavor.DEVELOPMENT;
  runApp(MyApp());
}

For example, here in main-development.dart we are settingFto Flavor.DEVELOPMENT. This is what tells the app, "hey, please use the integration flavor this time."

Finally, we are calling the runApp function with a MyApp object instance. Note that by default it creates an App widget. This isn't the entry point widget we want. Indeed, this is a dummy widget, created byflutter_flavorizr. We need to replace this.

app.dart

This is the place where we place the root widget. We are just going to replace everything inside that file with the content of the main.dart file.

There is also a home.dart file that is generated. You can delete it safely. You can also delete the main.dart file which is no longer useful.

result

Now we can run our 3 different flavors, the result look like this:

development flavor

staging flavor

production flavor

Flavor update

The next time you want to update your flavors, you don’t want to redo everything. For this, you can run a specific processor. A processor is a specific task done byflutter_flavorizr. For example, maybe you don't want to override your dart file or recreate your app icon. For this, use the following syntax flutter pub run flutter_flavorizr -p <processor>. For example

flutter pub run flutter_flavorizr -p android:buildGradle,android:androidManifest,ios:xcconfig,ios:buildTargets,ios:schema,ios:plist

If you want to update only Android and iOS without the icon generation.

YOU MUST AVOID ANY SPACE BETWEEN EACH PROCESSOR BECAUSE IT WILL NOT WORK.

You do

 -p <processor1>,<processor2>

but don't

 -p <processor1>,  <processor2>

The full list of processors can be found here

Configure VsCode

Have you noticed this line in our flavors’ config ?

ide: "vscode"

This tells flutter_flavorizr to configure your IDE, in our case VsCode. You can also set the value to idea if you use Android Studio.

Now in the debug panel of VsCode, you can see this

With this you can run each of your flavors in every flutter mode (debug, profile, release).

This is really neat, let’s see how it works.

The classic way to run a Flutter app is flutter run. However this command assumes that you have a file named main.dart as the app entry point and no flavor configuration. To run one of our flavors, we need to do flutter run --flavor <flavor> -t lib/main-<flavor>.dart. So, to run or staging flavor flutter run --flavor -lib/main-staging.dart.

The --flavor argument specifies which flavor build config it should use. The -t argument specifies the entry point file.

Now, to run a flutter in a specific flutter mode use the flag --<flutter-mode>. So to run our production flavor in profile mode we do flutter run --profile --flavor production -t lib/main-production.dart

The debug mode is the default mode

All this stuff is already done inside the .vscode/launch.json (created by flutter_flavorizr).

Now, if we have an issue with the staging app, we can just run our app with the staging flavor in debug mode from VsCode!

CI/CD

With these well-configured flavors, the CI/CD is also simplified. To demonstrate how we can make our CI/CD job easier, let’s create a Jenkinsfile.

The goal of this article isn’t to explain how Jenkins works, so I will not speak in deep detail about how it works

We will accomplish the following things:

• run a flutter doctor command
• build a .ipa file for iOS
• build an app bundle for Android
• create artifacts from these build files

Here is the Jenkinsfile:

#!/usr/bin/groovy
def appName = "Flavor Demo"

node('someNode') {
    withEnv(["PATH=path-to-a-flutter-bin:$PATH"]) {
        def flavorName = env.BRANCH_NAME;

        if (flavorName == 'development' || flavorName == 'recette' || flavorName == 'production') {
            def appNameAndroid = appName + "-${flavorName}-" + env.BUILD_NUMBER + ".aab";
            def appNameiOS = appName + "-${flavorName}-" + env.BUILD_NUMBER + ".ipa";
            def exportPlistFile = "./ios/exportOptions.${flavorName}.plist"

            stage('flutter doctor') {
                sh "flutter doctor"
            }

            stage("Build AAB Flutter Android for flavor ${flavorName}") {
                sh "mkdir -p build_ci"
                sh """
                    flutter build appbundle --release --flavor ${flavorName} -t lib/main-${flavorName}.dart
                    cp -pr build/app/outputs/bundle/${flavorName}Release/app-${flavorName}-release.aab build_ci/flutter_app.aab
                """
            }

            stage("Build IPA Flutter iOS for flavor ${flavorName}") {
                sh "mkdir -p build_ci"
                sh """
                    export LANG=en_US.UTF-8
                    flutter build ipa --release --flavor ${flavorName} -t lib/main-${flavorName}.dart
                    xcodebuild -exportArchive -archivePath ./build/ios/archive/Runner.xcarchive -exportOptionsPlist ${exportPlistFile} -exportPath flutter_app_ios
                    mv flutter_app_ios/*.ipa ./build_ci/flutter_app.ipa
                """
            }

            stage('Creating Artifacts') {
                dir("build_ci") {
                    sh "mv flutter_app.aab ${appNameAndroid}"
                    sh "mv flutter_app.ipa ${appNameiOS}"

                    archiveArtifacts allowEmptyArchive: true, artifacts: appNameAndroid
                    archiveArtifacts allowEmptyArchive: true, artifacts: appNameiOS
                }
            }
        }
    }
}

You need to create one export.plist file for each flavor.

As you can see, we are doing the exact same thing, just with different parameters.

In this case, we are assuming that each flavors have a specific git branch. This is really useful because we know what flavor we want to process based on the branch name.

We just have to define 4 variables.

Just like with the flutter run command, we are using the -t and the --flavor to build a specific flavor.

Conclusion

What did we do?

We have created 3 different flavors for our app, configured our IDE to take full advantage of our flavors and finally, we demonstrated how we can make our CI/CD easier.

It was not that hard. In real projects, I usually get some issues with the iOS configuration. You might spend some time debugging the configuration in Xcode. It’s still better than creating it from scratch.

flutter_flavorizr is currently only working on Android and iOS. Hopefully it will handle desktop as well in the future.

You can find the demo app on github

Flutter is a cross-platform framework, built by Google to create beautiful and robust applications. It’s written in a relatively new language named Dart, also built by Google. In this tutorial, we’re going to create our first app with flutter. We’re going to create a to-do app or a counter app like every other tutorial out there. We’re going to create an APOD app. If you’re an astronomy fan you already know what I’m talking about. APOD (Astromical Picture Of the Day) is a fantastic website maintained by NASA. Every day, a new astronomical picture is uploaded, followed by a description to explain what is going on.

Our app is going to display these informations, but we’re going to do more than that. We’re going to add an option to set the daily picture as the device wallpaper.

This tutorial requires to have a functional version of Flutter installed. Also, you need an IDE (Android Studio or VsCode) with Flutter and Dart support and a mobile device or a mobile device emulator.

First step we are going to create the default Flutter with the Flutter cli tool. It’s really straightforward, just open a terminal and tap

flutter create apod_app

This will create a counter app. Now you can run the project on a device. Just go in your app with a terminal and tap

flutter run

Now the application is running on your device. It’s a simple example, but it shows up how we build a UI with Flutter. We use widget, it’s the basic of class you are going to use a lot. There is two type of widget, the StatelessWidget and the StatefulWidget. StatelessWidget are immutable, once a StatelessWidget is render by Flutter, it doesn’t change. StatefulWidget on the other hand hold a state object. This object can’t change over time and when it changes, the UI is updated. In the default app, tapping on the button call this function

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

As you can see, it calls another function named setState. This function tells Flutter that something has changed in this State, which trigger the build method. The build method is the one who display the data. It returns others widget objects.

@override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            Text(
              'You have pushed the button this many times:',
            ),
            Text(
              '$_counter',
              style: Theme.of(context).textTheme.headline4,
            ),
          ],
        ),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: _incrementCounter,
        tooltip: 'Increment',
        child: Icon(Icons.add),
      ), 
    );
  }

You must use StatelessWidget over StatefullWidget. StatelessWidget are much simpler so they render much faster. Of course, you will be forced to use StatefullWidget in your Flutter journey. But we can get rid of them in a lot of case. We are going to see that in this tutorial.

Now that we have seen the basic of Flutter, let’s get back on our project. We need to access the APOD website data. Thankfully, the NASA has made a sweet API. They also have others very cool API, you can check that out. The APOD API is really, really simple, you just have to call the right endpoint and boom, it gives you nice json data.

We are going to do things the right way, because we want to learn how to use Flutter. So we are going to create two files, a .env file and a .env.dist file at the root of the project. We should add the .env file to our .gitignore file. In the .env file add the following variable

API_URL=https://api.nasa.gov/planetary/apod?api_key=DEMO_KEY&thumbs=true

The demo key limit you to 30 requests per IP address per hour and 50 requests per IP address per day. So it’s fine for our tutorial but if you want to create a real application based on this tutorial, you should get a real API key. You can notice that we add a parameter to the URL named “thumbs”. It tells the NASA server to give us thumbnails when the astronomical picture of the day is a … video. It will be useful to detect if the pictures of the day is a video, also it will be necessary to the set has wallpaper feature.

Now we need to tell our Flutter project to use the .env file. Go to your pubspec.yml file and add this line

flutter:
   assets:
     - .env

You can add all kind of file using this method (Image, Json…). Now we need something to parse our .env file. We are going to use a library named flutter_dotenv. First go check the documentation to see what it’s all about. To install the plugin, add the dependency in the pubspec.yml file.

dependencies:
  flutter:
    sdk: flutter

  flutter_dotenv: ^2.1.0

Next you need to get the new dependency with this command

flutter pub get

Now you have add the flutter_dotenv to your project. Just import the plugin in your main file

import 'package:flutter_dotenv/flutter_dotenv.dart';

Now we can change the main function a bit to parse our .env file access the API URL

void main() async {
  await DotEnv().load('.env');
  final apiUrl = DotEnv().env['API_URL'];
  runApp(MyApp(apiUrl: apiUrl));
}

We also need to change our MyApp widget a bit, add this at the beginning of the class

MyApp({Key key, this.apiUrl}) : super(key: key);
final String apiUrl;

It defines a String attribute named apiUrl, and set this attribute to the value pass in the constructor. You can add this

print(apiUrl);

At the start of the build method, to check the value of the apiUrl. Great, we have access to the right URL, now we can make an HTTP call to get the data ! Before that, just make a little clean up. We don’t need the StatefullWidget, so you can change

MyHomePage extends StatefullWidget

to

MyHomePage extends StatelessWidget

and remove the State property. You can also change the attribute definition to

MyHomePage({Key key, @required this.apiUrl}) : super(key: key);
  final String apiUrl;
  final title = "APOD WALLPAPER";

And of course pass the apiUrl to the MyHomePage object

home: MyHomePage(apiUrl: apiUrl)

Ok great ! Now we can make an HTTP call. We are going to use another plugin named dio. It’s a high level HTTP library, it’s really the go-to solution to make an HTTP call, very easy to use with some helpers for testing. Remember, to add a plugin to our app, 3 steps. First add the dependency to the pubspect.yml file

dependencies:
  flutter:
    sdk: flutter

  flutter_dotenv: ^2.1.0
  dio: ^3.0.10

next

flutter pub get

and finally in our code

import 'package:dio/dio.dart';

Magnificent ! Now we can use this plugin in our app. We can add an attribute to our class, an attribute name _dio. This attribute will be a private member (cause of the _) and will contain a Dio object, the one we are going to use to make HTTP call

final _dio = Dio();

Let's write a function which returns the APOD website data.

Future<void> _getApodData() async {
 final json = await _dio.get(apiUrl);
 print(json.data);
 print(jYou can improve this app ! There is a lot of stuff to do. You can for example add the possibility to see the APOD content of a specific day or let the user set the picture as lock screen wallpaper. This is the GitHub repository, pull request are welcomed :)son.data.runtimeType.toString());
}

Ok so this function is doing three things. First it is awaiting the result of the get method, called on the Dio object. We need to await this result because it’s a Future. In Dart, Future is the Promise concept implementation. It will return a value, and this value might be the wanted result or an error. Next we print our result, and the type of this result.

So _InternalLinkedHashMap is not a very useable type in Dart. We want to do things the right way. That means we should implement a model class which represent the APOD API data. To create a model class in lazy mode, we are going to use this website. It’s a model generator, you pass json data, you get a Dart model. Perfect, let’s do it !

class Apod {
  String date;
  String explanation;
  String mediaType;
  String serviceVersion;
  String thumbnailUrl;
  String title;
  String url;

  Apod.fromJson(Map<String, dynamic> json) {
    date = json['date'];
    explanation = json['explanation'];
    mediaType = json['media_type'];
    serviceVersion = json['service_version'];
    thumbnailUrl = json['thumbnail_url'];
    title = json['title'];
    url = json['url'];
  }

  Map<String, dynamic> toJson() {
    final Map<String, dynamic> data = new Map<String, dynamic>();
    data['date'] = this.date;
    data['explanation'] = this.explanation;
    data['media_type'] = this.mediaType;
    data['service_version'] = this.serviceVersion;
    data['thumbnail_url'] = this.thumbnailUrl;
    data['title'] = this.title;
    data['url'] = this.url;
    return data;
  }
}

Let’s put this in subdirectory named “models” in a file named apod_model.dart. Now we just need to change the _getApodData method

Future<Apod> _getApodData() async {
    final json = await _dio.get(apiUrl);

    final data = jsonDecode(json.toString());
    final apod = Apod.fromJson(Map<String, dynamic>.from(data));
    
    _apod = apod;
    return apod;
  }

We use a method to decode the json data (jsonDecode). We must import a package in order to use it. It’s a Dart native package. At the top of your main.dart file, add

import 'dart:convert';

You can notice that we are creating a Map with the static from method. We are casting our data to avoid problems. You can also notice the _apod class attribute, we are setting the value of this attribute to the value of our created Apod object. Spoiler, but we are going to use it later :), just add another attribute to the MyHomePage class

Apod _apod;

At this stage we have a perfect useable model, now it’s time to use it ! But there is a problem. We are getting data in an asynchronous way. So we don’t have the data when the app is launching. So how to we update our UI ? Use a state ! Ok, it might work but remember, we must use state as a last resort. The goal of state is to update the UI based on user interaction. In our case, the user doesn’t have any interaction, so we must not use state.

There is a lot of very helpful widget in Flutter and guess what, there is one to solve our problem. It’s called FutureBuilder and it takes two parameters. One named future, which is a function returning Future. The second parameter is builder, a callback function called to build the UI, depending on the state of the Future.

Let’s right our new build method !

Widget build(BuildContext context) {
  return Scaffold(
    appBar: AppBar(
      title: Text(title),
    ),
    body: Center(
      child: SingleChildScrollView(child: Column(
        mainAxisAlignment: MainAxisAlignment.center,
        children: <Widget>[
          FutureBuilder<Apod>(
            future: _getApodData(),
            builder: (BuildContext context, AsyncSnapshot<Apod> snapshot) {
              Widget children;
              if (snapshot.hasData) {
                children = _formatData(snapshot: snapshot.data);
              } else if (snapshot.hasError) {
                children = _formatError();
              } else {
                children = _formatLoading();
              }

              return children;
            },
          )
        ],
      ),
    )),
  );
}

Ok, what’s going on here ? First we render a Scaffold, this widget is the base of what to draw on the screen. Next we have a Center widget use to … center his child component. SingleChildScrollView allow the user to scroll the screen. It’s useful here because the explanation text might overflow the screen. Next we have Column component which takes a children property. This widget is useful when you want to render more than one child. In our case it’s useless yeah, because we only have the FutureBuilder has a child. We can change it with a Container widget for example. Finally, we have the FutureBuilder. If you just copy and paste the code your IDE should be warning you because he doesn’t know _formatData, _formatError and _formatLoading method. These functions render widget, depending on the state of the Future, represented by the AsyncSnapshot<Apod> object. Let’s be negative, we are going to right the _formatError function. This function render a widget to tell the user that an error has occurred.

Container _formatError() {
  return Container(child: Icon(Icons.signal_wifi_off ));
}

Really simple it renders an Icon who tells the user, there is no network connection. Next, _formatLoading function render a widget to tell the user: Please wait, I’m loading data.

Container _formatLoading() {
  return Container(child: CircularProgressIndicator());
}

Again really simple ! The CircularProgressIndicator is a built-in Flutter widget, very useful. We can customize it has we want. And last but certainly not least, the _formatData function

Column _formatData({@required Apod snapshot}) {
  return Column(children: [
    Padding(
      padding: const EdgeInsets.all(20),
      child: Text.rich(
        TextSpan(
          text: snapshot.date + ": ",
          children: <TextSpan>[
            TextSpan(text: snapshot.title, style: TextStyle(fontWeight: FontWeight.bold, fontSize: 24)),
          ],
        ),
      ),
    ),
    _getMainContent(apod: snapshot),
    Padding(padding: const EdgeInsets.all(20),
    child: Text(snapshot.explanation))
  ]);
}

Ok, you can notice the @required annotation and the in braces {} parameter. In braces implement named parameter. Now we can do square(x: x). But the default is named parameter are optional. So we add the required annotation to solve this issue.

Next we are rendering Padding widget, it’s a container who add padding to his child. Next we have a _getMainContent function, we will see that in a minute. And finally a basic text, wrapped inside a Padding widget. Notice how we use the Text.rich method to render a text compose by two TextSpan

The main job happened in the _getMainContent method. Let’s see what going on out there

Widget _getMainContent({@required Apod apod}) {
  return apod.isImage() ? Image.network(
      apod.url,
      loadingBuilder: (context, child, progress) {
        return progress == null ? child : CircularProgressIndicator(
          value: progress.cumulativeBytesLoaded / progress.expectedTotalBytes,
        );
      }
  ) : YoutubePlayer(controller: _getVideoController(videoId: YoutubePlayer.convertUrlToId(apod.url)));
}

We use a specific method to render the “main content” which is the picture or video of the day. We determine if it’s a video or an image with a method implemented on the model

bool isImage() {
  return (thumbnailUrl == null);
}

Simple, if we have a thumbnailUrl, that means it is a video. In this case we render a YoutubePlayer. It’s another plugin, now you now how to install plugin in Flutter, if you have some doubts, just follow the documentation. A YoutubePlayer widget need to have a YoutubePlayerController widget. It’s used to get the video, add some option (autoplay, mute…). We render the controller with another method named _getVideoController, and yeah I like to split my code

YoutubePlayerController _getVideoController({@required String videoId}) {
  return YoutubePlayerController(
    initialVideoId: videoId,
    flags: YoutubePlayerFlags(
      autoPlay: false,
    ),
  );
}

Very simple, the hard job is done before by the YoutubePlayer plugin. The convertUrlToId method which take our apod.url and convert it to a videoId.

If the picture of the day is a real picture then we return an Image. We use the built-in Flutter widget named Image. We use a static method named network to get the image based on an URL. Next we add a loadingBuilder function to render a nice CircularProgressIndicator widget while getting the image data.

loadingBuilder: (context, child, progress) {
  return progress == null ? child : CircularProgressIndicator(
    value: progress.cumulativeBytesLoaded / progress.expectedTotalBytes,
  );
}

Something useful here is the parameter named progress. It’s an ImageChunkEvent object. This object represents progress notifications while an image is being loaded. If our object is null, then it means that the image is fully load. In this case the loadingBuilder function return the child (the image). If it’s still loading, we use our ImageChunkEvent object to give value about the loading to our CircularProgressIndicator object. By specifying the value to progress.cumulativeBytesLoaded / progress.expectedTotalBytes, we tell the user when our Image will be loaded.

We are almost finish. The last step is to implement the setHasWallpaper feature. We will need three very useful plugins. First fluttertoast, simplify how our app is displaying Toast. We are also going to use flutter_cache_manager to download the picture of the day on disk. Finally wallpaper_manager, a plugin to set picture has wallpaper.

Now we are going to update our build method to render a FloatingActionButton widget.

Widget build(BuildContext context) {
  return Scaffold(
    appBar: AppBar(
      title: Text(title),
    ),
    body: Center(
      child: SingleChildScrollView(child: Column(
        mainAxisAlignment: MainAxisAlignment.center,
        children: <Widget>[
          FutureBuilder<Apod>(
            future: _getApodData(),
            builder: (BuildContext context, AsyncSnapshot<Apod> snapshot) {
              Widget children;
              if (snapshot.hasData) {
                children = _formatData(snapshot: snapshot.data);
              } else if (snapshot.hasError) {
                children = _formatError();
              } else {
                children = _formatLoading();
              }

              return children;
            },
          )
        ],
      ),
    )),
    floatingActionButton: FloatingActionButton(
      onPressed: () => _apod != null ? _setHasWallpaper(context) : _showToast("Wait for data"),
      child: Icon(Icons.wallpaper),
    ),
  );
}

floatingActionButton is a Scaffold property, used to display a FAB. Notice how simple we do to add an Icon to this button. We bind the onPressed event to a function executing a specific function, depending on our _apod class attribute. If the MyHomePage object hasn’t fetch the APOD API wet we just display a toast to the user with this method

void _showToast(String result) {
  Fluttertoast.showToast(
      msg: result,
      toastLength: Toast.LENGTH_SHORT,
      gravity: ToastGravity.CENTER,
      timeInSecForIosWeb: 1,
      backgroundColor: Colors.grey,
      textColor: Colors.white,
      fontSize: 16.0
  );
}

Here we use the fluttertoast plugin. It’s very simple and straight forward. And finally the _setHasWallpaper function.

Future<void> _setHasWallpaper(BuildContext context) async {
  final file = await DefaultCacheManager().getSingleFile(_apod.getWallpaperUrl());
  final String result = await WallpaperManager.setWallpaperFromFile(file.path, WallpaperManager.HOME_SCREEN);

  _showToast(result);
}

So first we are downloading the APOD picture with the flutter_cache_manager plugin. Next we set the downloaded file as wallpaper thanks to the wallpaper_manager plugin. Very simple !

With all this you have now a good overview of how to use Flutter plus a cool app. If you want to compile this code to an iOS application you can ! Just make sure to follow the iOS set up of the youtube_player_flutter plugin.

You can improve this app ! There is a lot of stuff to do. You can for example add the possibility to see the APOD content of a specific day or let the user set the picture as lock screen wallpaper. This is the GitHub repository, pull request are welcomed :)