DEV Community: Pedro Massango

Too busy for friends? Try Friendship 1:1s

Pedro Massango — Fri, 26 Sep 2025 00:10:04 +0000

When I moved to Germany, I quickly realized how easy it was to lose touch with people who mattered to me. Between new personal responsibilities, career demands, and adjusting to a new culture, staying connected fell by the wayside.

Months would slip by without a real conversation. At best, I’d exchange a few short messages over social media — nothing like the deep talks we used to have.

That's when I decided to bring a professional practice into my personal life: 1:1s.

1:1s

In a work environment, 1:1s are regular check-ins between a manager and a direct report, or between colleagues, to catch up.

I adapted this idea into Friendship 1:1s.

Friendship 1:1s

Intentional 30/60 minute catch-ups with friends or family, scheduled just like any important meeting.

The impact has been incredible. Each month, I aim for at least three Friendship 1:1s. These conversations help me feel more grounded, closer to the people I care about, and better balanced in life.

If you’ve been struggling to find time for meaningful connections, give this a try. A simple scheduled 1:1 could be the difference between not keeping deeper connection with people and staying close enought to have meaniful friendships.

Make use of your Caleandar

One thing that can drastically improve this is by opening some slots on your Calendar (free on Google calendar), and then send the link to the people you want to have 1:1 with. This helps keep track of when was the last time you spoke to someone and avoids events onverlaps.

If you’ve been struggling to find time for meaningful connections, give this a try. A simple scheduled 1:1 could be exactly the thing you need to reignite the spark of friendship with the people you love and admire.

Scrolling like a Pro - Creating custom scroll behaviors

Pedro Massango — Mon, 07 Jul 2025 19:35:19 +0000

Hi there, long time no see, today I have decided to share some common tips and tricks on scrolling with Flutter

Why Customize Scroll Behavior in Flutter?

Flutter gives you powerful out of the box scroll widgets like ListView, SingleChildScrollView, and PageView. But sometimes, you need custom scroll effects to:

Remove glow on overscroll (Android)
Customize scroll physics (bouncy, clamped, paged)
Trigger animations or data loads when scrolling
Create sticky headers, parallax, or infinite scroll

Let’s see some real code life examples below:

1. Remove Overscroll Glow (Android Ripple)

By default, Android shows a glow effect on overscroll and not every company's design system follow this behavior so there is always a need to get rid of it. To remove it, override the scroll behavior globally:

class NoGlowScrollBehavior extends ScrollBehavior {
  @override
  Widget buildViewportChrome(
    BuildContext context,
    Widget child,
    AxisDirection axisDirection,
  ) {
    return child;
  }
}

Then apply it globally:

MaterialApp(
  scrollBehavior: NoGlowScrollBehavior(),
  home: MyHomePage(),
)

Or locally:

ScrollConfiguration(
  behavior: NoGlowScrollBehavior(),
  child: ListView(...),
)

2. Listen to Scroll Position

Track scroll position or trigger logic on scroll, there are different ways to achieve this and below I will share the implementation using a ScrollController:

final _controller = ScrollController();

@override
void initState() {
  super.initState();
  _controller.addListener(() {
    if (_controller.offset > 100) {
      print('Scrolled past 100 pixels');
    }
  });
}

@override
void dispose() {
  _controller.dispose();
  super.dispose();
}

Usage:

ListView(
  controller: _controller,
  children: [...],
)

3. Custom Scroll Physics (e.g., Bouncing like iOS)

ListView(
  physics: const BouncingScrollPhysics(), // or NeverScrollableScrollPhysics()
  children: [...],
)

You can also combine physics:

physics: const BouncingScrollPhysics(
  parent: AlwaysScrollableScrollPhysics(),
)

4. Scroll to a Widget programmatically

_scrollController.animateTo(
  500.0, // offset
  duration: Duration(milliseconds: 400),
  curve: Curves.easeInOut,
);

Or scroll to a widget using Scrollable.ensureVisible:

Scrollable.ensureVisible(
  context,
  duration: Duration(milliseconds: 300),
  alignment: 0.5,
);

5. Advanced: create a sticky header or a parallax effect

Use CustomScrollView + SliverPersistentHeader:

SliverPersistentHeader(
  pinned: true,
  delegate: MyHeaderDelegate(),
),

Or use packages like:

Summary

Task	Tool/Widget
Remove glow	`ScrollBehavior`
Track scroll	`ScrollController`
Customize physics	`ScrollPhysics`
Animate to scroll	`ScrollController.animateTo()`
Sticky/parallax effects	`CustomScrollView`, `Sliver` widgets

Bonus: infinite scroll example

_controller.addListener(() {
  if (_controller.position.pixels ==
      _controller.position.maxScrollExtent) {
    fetchMoreItems();
  }
});

Flutter gives you the flexibility to tune every aspect of scrolling — whether it's subtle UX improvements or complex scroll-driven required by your company's UX, you're pretty much set to implement everything with Flutter.

The beginer mindset

Pedro Massango — Sun, 02 Mar 2025 22:43:56 +0000

Recently I started learning something... again. It is always scary to jump on a new topic a feel like you know nothing about it.

I will ocasionaly share my learnings along the way here. The topics range from basic Kotlin to advanced and might touch some Spring boot or Ktor, my end goal is to become a proficient Kotlin developer by the end of this year or sooner.

Follow me if you want to follow my journey.

Announcing the Public Beta of doc-ai

Pedro Massango — Thu, 07 Sep 2023 16:25:56 +0000

I'm thrilled to introduce the public beta of doc-ai, a groundbreaking AI-powered platform designed to deeply understand and process the contents of your documents. Say goodbye to the days of endlessly skimming through pages to find that one piece of information. Now, you can simply ask a question and get precise, contextual answers directly from the text!

How Does It Work?

At its core, doc-ai.app leverages cutting-edge artificial intelligence to read and interpret documents just like a human would, but at lightning speed. Whether you have lengthy research papers, detailed reports, or comprehensive manuals, our AI can digest the content and provide you with answers in seconds.

Why Use doc-ai.app?

Save Time: No more manual searching. Get the information you need instantly.

Increase Accuracy: Receive answers that are contextually relevant, reducing the risk of misinterpretation.

User-Friendly: Designed for everyone, from students to professionals. No technical expertise required.

I invite you to try it out and experience firsthand the power of AI-driven document comprehension. Try out the public beta of doc-ai.app

Discount: 20% off for the first 15 to upgrade to premium using the following discount code: PUBLICB

Let me know your feedback!

Dart for backend: pros and cons

Pedro Massango — Mon, 03 Apr 2023 17:54:58 +0000

Dart is an object-oriented, class-based, garbage-collected programming language developed by Google. Initially designed for client-side development, Dart has evolved to become a full-stack language that can run on the backend as well. This short article explores the benefits and drawbacks of using Dart for backend development.

Advantages of using Dart for Backend Development:

Single Language for Full-Stack Development (specially when using Flutter for front-end)
Speed and Performance
Scalability
Built-in Support for Asynchronous Programming
Strong Typing

Disadvantages of using Dart for Backend Development:

Lack of Third-Party Libraries
Limited Community Support
Lack of Maturity

Those are very important things to consider, specially if you 're new to Dart and want a fast solution to build and deliver your project as it is likely that you will have to build some third-party libraries yourself.

Dart is a great option for backend development, particularly for developers who already use it for front-end development. Its speed, scalability, and support for asynchronous programming make it an attractive choice. However, it's important to consider the potential drawbacks, such as the limited third-party library support and smaller community. Despite these challenges, Google's continued investment in Dart suggests that it will continue to grow and evolve over time.

It is relatively easy to learn Dart so if time is not against you, then it is definitely worth a try.

Double click listener on Android

Pedro Massango — Thu, 22 Dec 2022 10:39:26 +0000

Some times we need to check when the user made a double click in some of our android views. To solve this problem I made a small library to handle this.
How to use?
Using Android Studio, just add this line in your build.gradle project level:

allprojects {
    repositories {
        ...
        maven { url 'https://jitpack.io' } // add this line
    }
}

Second, add this line inside dependencies on your app build.gradle module level:
implementation 'com.github.pedromassango:doubleClick:v3.0'
The class DoubleClick extends from View.OnClickListener so, just call the DoubleClick class on you onClickListener of the view that you wish to listen, and pass a instance of DoubleClickListener class to listen the events.

Button btn = new Button(this);
btn.setOnClickListener( new DoubleClick(new DoubleClickListener() {
            @Override
            public void onSingleClick(View view) {

                // Single tap here.
            }

            @Override
            public void onDoubleClick(View view) {

                // Double tap here.
            }
        });
        //  use this to define your own interval
        //  }, 100));

OBS: On the latest version you can define your own interval!
To know more, check it on GitHub:
https://github.com/pedromassango/doubleClick

Evite o padrão de repositório para operações não relacionadas à persistência

Pedro Massango — Fri, 02 Jul 2021 23:02:37 +0000

English version available here.

Hoje quero compartilhar um pouco sobre o padrão Repositório e Fachada. Tentarei explicar suas diferenças, pois parece haver alguns equívocos comuns sobre eles.

Repositório

Vamos tentar definir um repositório, a partir do dicionário: um lugar, sala ou contêiner onde algo é depositado ou armazenado. Em termos de programação, o conceito pode ser definido como uma classe responsável por lidar com operações CRUD (criar, ler, atualizar e deletar) para um modelo de domínio específico por meio do uso de uma ou mais fontes de dados.

Pela definição acima, podemos ver que devemos usar repositórios apenas para operações CRUD, o que significa que podemos ter um UserRepository e nunca umAuthenticationRepository, simplesmente porque a autenticação não descreve um conjunto de operações CRUD (assumindo que estamos falando sobre operações de login/registro).

Um erro comum que tenho visto é que algumas pessoas definem repositórios para operações de acesso ao sistema por exemplo:

abstract class AuthenticationRepository {

  Future login(String username, String password);

  Future register(String name, String email, String password);
}

Resumo #1: Apenas use o padrão de repositório para operações CRUD

Claramente, essas não são operações para armazenar/recuperar dados e, portanto, nunca devemos declará-las em um repositório. E agora? Fachadas!

Fachadas / Facade pattern

Pela Wikipedia, podemos definir uma fachada como um objeto que serve como uma interface frontal mascarando um código subjacente mais complexo.

Agora vamos definir um repositório: um Repositório é um tipo de fachada especializada em mascarar/abstrair operações CRUD complexas especificamente entre fontes de dados.

Para comparar e contrastar, fachadas são mais gerais do que repositórios - eles podem ser usados para qualquer coisa diferente de persistência. Você pode usar fachadas para abstrair interações complexas em APIs de vários bancos. Por exemplo:

// Or BankOperationsFacade.
abstract class BankOperations {

  Future payTelecomService(double amount, String cardId, String serviceId);

  Future transfer(double amount, String senderId, String recipientId);
}

// Custom implementation for XBank interaction goes here.
class XBankOperations extends BankOperations { }

// Custom implementation for YBank interaction goes here.
class YBankBOperations extends BankOperations { }

Resumo #2: Repository é um tipo mais especializado de Facade

Vamos revisar o primeiro trecho de código apresentado em nosso artigo, mas, desta vez, iremos refatorar o nome da classe para ser algo mais significativo.

// Or any other meaningful name.
abstract class AuthenticationFacade {

  Future login(String username, String password);

  Future register(String name, String email, String password);
}

Principais conclusões

As fachadas podem ser aplicadas a qualquer coisa que não seja baseada na persistência
Repositórios são para envolver a comunicação com uma ou mais fontes de dados e abstrair isso do usuário do repositório
Fachadas são mais genéricas do que repositórios.

É importante fazer uso desses conceitos de maneira adequada para evitar escrever códigos difíceis de entender e para manter uma base de código saudável.

Espero que isso ajude você de alguma forma; por favor, deixe-me saber sua opinião na seção de comentários.

Avoid Repository pattern for operations not related to persistence

Pedro Massango — Fri, 02 Jul 2021 23:01:24 +0000

Versão em Portugês disponível aqui.

Today I want to share a bit about the Repository and Facade pattern. I will attempt to explain their differences, as there seems to be a few common misconceptions about them.

Repository

Let's try to define a repository, from the dictionary: a place, room or container where something is deposited or stored. Interms of programming, the concept can be defined as a class responsible for handling CRUD (create, read, update and delete) operations for a specific domain model through the usage of one or more data sources.

By the definition above, we can see that we should use repositories for CRUD operations only, which means we can have a UserRepository and never a AuthenticationRepository, simply because authentication does not describe a set of CRUD operations (assuming we're talking about login/registration operations).

A common mistake I have seen is that some people define repositories for system access operations for example:

abstract class AuthenticationRepository {

  Future login(String username, String password);

  Future register(String name, String email, String password);
}

Take #1: Only use repository pattern for CRUD operations

Clearly those are not operations for storing/retrieving data and so we should never declare them in a repository. Then what? Facades!

Facade pattern

From Wikipedia, we can define a facade as an object that serves as a front-facing interface masking more complex underlying code.

Now let's move on to defining a repository: a Repository is a type of facade that specializes in masking/abstract complex CRUD operations specifically between data source(s).

To compare and constrast, facades are more general than repositories -- they can be used for anything other than persistence. You can use facades to abstract complex interactions within multiple bank APIs. For example:

// Or BankOperationsFacade.
abstract class BankOperations {

  Future payTelecomService(double amount, String cardId, String serviceId);

  Future transfer(double amount, String senderId, String recipientId);
}

// Custom implementation for XBank interaction goes here.
class XBankOperations extends BankOperations { }

// Custom implementation for YBank interaction goes here.
class YBankBOperations extends BankOperations { }

Take #2: A Repository is a more specialized type of Facade

Let's review the first piece of code featured in our article, but this time, we'll refactor the name of the class to be something more meaningful.

// Or any other meaningful name.
abstract class AuthenticationFacade {

  Future login(String username, String password);

  Future register(String name, String email, String password);
}

Key Takeaways

Facades can be applied to anything that's not persistence based
Repositories are for wrapping the communication with one or more data sources and abstracting this away from the user of the repository
Facades are more generic than repositories.

It is important to make use of those concepts properly to avoid writing code that is hard to understand and to maintain a healthy code base.

That's it, I hope this helps you somehow; please let me know your thoughts in the comments section.

UnconstrainedBox é seu amigo - Dica #5

Pedro Massango — Sat, 10 Apr 2021 17:03:08 +0000

[available in English here]

Olá.
Nesta dica do Flutter, quero falar um pouco sobre o widget UnconstrainedBox, você já o usou antes? Me conte nos comentários.

Para que serve?

Resumindo, é um widget que dá ao filho a liberdade de se dimensionar conforme necessário. UnconstrainedBox (como o nome sugere), não impõe restrições ao seu filho, o filho irá renderizar como se estivesse em uma tela infinita. Às vezes, ele pode transbordar quando usado com alguns widgets como PageView, então você deve ter cuidado para dar ao filho as restrições de tamanho adequadas, conforme necessário.

Aprenda pelo Exemplo

Digamos que precisamos construir um PageView onde seus filhos têm tamanhos diferentes e deve mostrar um item por vez, como você faria isso? (Deixe-me saber nos comentários).

Aqui está nosso código inicial, é apenas um PageView com três itens: um contêiner vermelho, verde e azul.

import 'package:flutter/material.dart';

void main() => runApp(MaterialApp(home: UnconstrainedBoxSample()));

class UnconstrainedBoxSample extends StatelessWidget {

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      backgroundColor: Colors.white,
      appBar: AppBar(title: Text('Unconstrained Box')),
      body: PageView(
        children: [
          Container(color: Colors.red),
          Container(color: Colors.green),
          Container(color: Colors.blue),
        ],
      ),
    );
  }
}

Aqui está a saída do código acima.

Como você pode ver, todos os três itens estão sendo expandidos para caber na página inteira, definir um tamanho personalizado para nossos filhos não funciona porque o PageView força-os a terem o mesmo tamanho (na direção de não rolagem) que ele.

Podemos contornar isso alterando a janela de visualização da página, mas isso teria um efeito colateral: outros itens também seriam exibidos e nossos filhos ainda seriam forçados a ter a mesma altura da PageView.

Vamos tentar isso, adicionar um controlador com uma fração de porta de visualização personalizada em sua visualização de página: controller: PageController (viewportFraction: .8) e o resultado é o seguinte.

Isso acontece porque PageView está impondo restrições para seus filhos. O padrão (viewportFraction: 1) significa que cada filho deve ter exatamente o mesmo tamanho de seu pai (o PageView). Cada vez que você diminui o viewportFraction, você está apenas diminuindo o tamanho de seus filhos.

UnconstrainedBox em ação!

Para resolver os problemas mencionados acima, devemos embrulhar cada criança em uma caixa sem restrições.

Observe que, embora estejamos usando uma caixa irrestrita, nosso item ainda tem as restrições de: não poder ser maior (em altura/largura dependendo da direção de rolagem) do que o PageView. A principal vantagem é poder ter filhos menores (em tamanho) que o PageView.

Lembre-se: como estamos usando uma caixa sem restrições, nosso filho deve ter tamanho, caso contrário, terá sua largura e altura definidas como zero (0).

Vamos atualizar nosso código, embrulhar seu segundo item em um UnconstrainedBox e dar ao contêiner um tamanho, nosso código agora se parece com este:

import 'package:flutter/material.dart';

void main() => runApp(MaterialApp(home: UnconstrainedBoxSample()));

class UnconstrainedBoxSample extends StatelessWidget {

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      backgroundColor: Colors.white,
      appBar: AppBar(title: Text('Unconstrained Box')),
      body: PageView(
        children: [
          Container(color: Colors.red),
          UnconstrainedBox(   // NEW
              child: Container(
                height: 400,  // NEW
                width: 250,   // NEW
                color: Colors.green,
              ),
          ),   // NEW
          Container(color: Colors.blue),
        ],
      ),
    );
  }
}

Aqui está o resultado do código acima:

Finalmente, nosso segundo filho agora tem a liberdade de se dimensionar conforme necessário, desde que não ultrapasse o tamanho do PageView. Este widget vem com algumas propriedades úteis como alignment e constrainedAxis.

alignment: permite que você alinhe o filho em seu espaço restante. O padrão é Alignment.center.
constrainedAxis: permite especificar um eixo para restringir o filho, ou seja, permite definir em que direção seu widget ainda deve ser restringido. O padrão é null, o que significa que nenhum dos eixos será restringido.

Este widget nos dá liberdade e a habilidade de construir ótimas animações e UI usando em conjunto com PageView e outros widgets.

É tudo por hoje. Curta, compartilhe e inscreva-se para obter mais dicas do Flutter. Comente se você tiver alguma dúvida ou problema.

UnconstrainedBox is your friend - Tip #5

Pedro Massango — Sat, 10 Apr 2021 17:02:56 +0000

[Disponível em Português aqui]

Hi there.
In this Flutter tip I want to talk a bit about the UnconstrainedBox widget, have you ever used it before? Let me know in the comments.

What is it for?

In short, it is a widget that gives its child the freedom to size itself as needed. UnconstrainedBox (as the name suggests), impose no constraints on its child, the child will render as if it were in a infinite canvas. Sometimes it may overflow when used with some widgets like PageView, so you must be careful to give its child a proper size constraints as required.

Learn by Example

Let's say we need to build a PageView where their children have different sizes and it should show one item at time, how would you do that? (let me know in the comments)

Here is our initial code, it is just a PageView with three items: a red, green and blue container.

import 'package:flutter/material.dart';

void main() => runApp(MaterialApp(home: UnconstrainedBoxSample()));

class UnconstrainedBoxSample extends StatelessWidget {

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      backgroundColor: Colors.white,
      appBar: AppBar(title: Text('Unconstrained Box')),
      body: PageView(
        children: [
          Container(color: Colors.red),
          Container(color: Colors.green),
          Container(color: Colors.blue),
        ],
      ),
    );
  }
}

Here is the output of the code above.

As you can see all three items are being expanded to fit the entire page, setting a custom size for our children doesn't work because PageView forces them to have the same size (in the non-scrolling direction) as itself.

We can work around this by changing the page's viewport but it would have a side effect: other items would be displayed as well and our children would still being forced to have the same height as the PageView.

Let's try that, add a controller with a custom view port fraction into your page view:
controller: PageController(viewportFraction: .8) and the result is as follow.

This happens because PageViewis imposing constraints for its children. The default (viewportFraction: 1) means that each child must have the exact same size as its parent (the PageView). Each time you decrease the viewportFraction you are just decreasing the size of its children.

UnconstrainedBox in action!

To solve the issues mentioned above, we should wrap each child into a unconstrained box.

Notice that even though we are using an unconstrained box, our item still have the constraints of: not being able to be bigger (in height/width depending on the scroll direction) than the PageView. The main advantage is to be able to have smaller (in size) children than the PageView.

Remember: since we are using a unconstrained box, our child must have size otherwise it will have its width and height set to zero (0).

Let's update our code, wrap your second item into a UnconstrainedBox and give the container a size, our code now looks like this:

import 'package:flutter/material.dart';

void main() => runApp(MaterialApp(home: UnconstrainedBoxSample()));

class UnconstrainedBoxSample extends StatelessWidget {

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      backgroundColor: Colors.white,
      appBar: AppBar(title: Text('Unconstrained Box')),
      body: PageView(
        children: [
          Container(color: Colors.red),
          UnconstrainedBox(   // NEW
              child: Container(
                height: 400,  // NEW
                width: 250,   // NEW
                color: Colors.green,
              ),
          ),   // NEW
          Container(color: Colors.blue),
        ],
      ),
    );
  }
}

Here is the output:

Finally our second child now have the freedom to size itself as needed, as long as it does not oversize the PageView's size. This widget comes with some useful properties like alignment and constrainedAxis.

alignment: allows you to align the child in its remaining space. Defaults to Alignment.center.
constrainedAxis: you can specify an axis to constrain the child, in other words this allows to define in which direction your widget should still be constrained. Defaults to null which means neither axis will be constrained.

This widget gives us freedom and the hability to build great animations and UI using in conjuction with PageView and other widgets.

That is it for today. Like share and subscribe for more Flutter tips. Comment if you have any question or issue.

Introduction to State Restoration in Flutter

Pedro Massango — Mon, 30 Nov 2020 15:07:59 +0000

This is what we have from Apple's documentation:

Preserving your app’s user interface helps maintain the illusion that your app is always running. Interruptions can occur frequently on iOS devices, and a prolonged interruption might cause the system to terminate your app to free up resources. However, users do not know that your app has been terminated and will not expect the state of your app to change. Instead, they expect your app to be in the same state as when they left it. State preservation and restoration ensures that your app returns to its previous state when it launches again.

Even though this comes from Apple, the same applies for Android apps as well. You can read the related Android documentation here. Before we procceed, note that this is all about the user experience and as developers, it is our responsability to implement and provide a good UX to our users.

Ok, now that we have some knowleadge about what is SR and why it is important, let's se how it works in Flutter.

What about Flutter?

Back in the days, this was a difficult task because we didn't have official support from the framework, basically we had to implement a cache strategy ourself, and this was not an easy task. See issue #6827 on GitHub.

In Flutter 1.22, we now have Framework support for state restoration out of the box and this comes to save us a lot of time.

Flutter give us an synchronous API for us to provide the data that represents the state of our UI to be saved every time it changes so that any time our app is destroyed, the engine already has the latest information of or UI to be saved into the OS and restored if the user comes back to our app.

New concepts, same finality

If you come from Android (like me) or iOS, you will notice that the concepts are the same, we just have different ways of doing it.

Flutter hava the RestorationManager, which is the class that is responsible of handling all the state restoration work, usually we don't need to use it directly. RestorationBucket which is used to hold the piece of the restoration data that our app need to restore its state later. RestorationScope, which is used to provide a scoped RestorationBucket to its descendants, if the restorationId parameter is null then, the restoration capability is disabled for its descedants. RestorationMixin this is used by our widget's state, he is the one we will usually use, it provides a straightfoward API to save and restore our state. And finally we have restorable properties (one for each Dart's data type), which are used to represent the data to be stored in the buckets.

How to use it?

Flutter app widgets (MaterialApp, CupertinoApp and WidgetsApp) has a RootRestorationScope built-in by default so we don't need to provide one, instead we just need to provide an id that will be used by the inner root scope. Notice that without providing the restoration scope id, the state restoration feature will be turned off so make sure you don't miss this step.

One of the advantages of providing the restoration scope id into our app widget is that it also enables the Navigator built by the WidgetsApp to restore its state (i.e. to restore the history stack of active Routes). See the documentation on Navigator for more details around state restoration of Routes.

Let's see how we can use state restoration to save (and restore) the index of the BottomNavigationBar. Here is what we need to do:

Provide a restorationScopeId to our MaterialApp (CupertinoApp and WidgetsApp also have this parameter);
Our home page state should e mixed-in with RestorationMixin (and implement its members);
Create our restorable properties and use it instead of the common Dart's data type.
Resgister our restorable properties for restoration;

And that is it, Flutter will take care of the rest.

Example

The code bellow will save the index of the bottom navigation bar if the app is killed.

import 'package:flutter/material.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      // Give your RootRestorationScope an id, defaults to null.
      restorationScopeId: 'root', 
      home: HomePage(),
    );
  }
}

class HomePage extends StatefulWidget {
  @override
  _HomePageState createState() => _HomePageState();
}

// Our state should be mixed-in with RestorationMixin
class _HomePageState extends State<HomePage> with RestorationMixin {

  // For each state, we need to use a restorable property
  final RestorableInt _index = RestorableInt(0);

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(child: Text('Index is ${_index.value}')),
      bottomNavigationBar: BottomNavigationBar(
        currentIndex: _index.value,
        onTap: (i) => setState(() => _index.value = i),
        items: <BottomNavigationBarItem>[
          BottomNavigationBarItem(
              icon: Icon(Icons.home),
              label: 'Home'
          ),
          BottomNavigationBarItem(
              icon: Icon(Icons.notifications),
              label: 'Notifications'
          ),
          BottomNavigationBarItem(
              icon: Icon(Icons.settings),
              label: 'Settings'
          ),
        ],
      ),
    );
  }

  @override
  // The restoration bucket id for this page,
  // let's give it the name of our page!
  String get restorationId => 'home_page';

  @override
  void restoreState(RestorationBucket? oldBucket, bool initialRestore) {
    // Register our property to be saved every time it changes,
    // and to be restored every time our app is killed by the OS!
    registerForRestoration(_index, 'nav_bar_index');
  }
}

How to test?

If you want to test this code (or your code during development), you will need to enable the "Don't keep activities" options in your device's Developer Options.

Open the Developer options settings, and enable the option Don't keep activities.

This will simulate the lack of memory and the device will kill all activities as soon as you leave it.

Run the code above app and tap the Settings item;
Go to the launcher by pressing the device's home button. Press the overview button and return to the app.
notice that the Settings item is still selected.

Note: You can try the same app without state restoration (find the code here), where if you run it and repeat the same steps you will notice that the index is always back to Homeonce you launch the app again. Make sure you stop and run the code code again because state restoration code is not removed with hot-reload/restart as it is tied to the host OS!

That is it for today. There is still a lot of things to talk about state restoration and I will split into more than one article so make sure you follow me (here or on Twitter) to not miss the next one.

Flutter tip (#4): run a Flutter app to a specific route

Pedro Massango — Sat, 05 Sep 2020 10:17:33 +0000

Few days ago I found an hidden gem in the main Flutter repository and shared it on my Twitter account and today I tought its better to share on my blogpost.

Have you ever wanted to run your Flutter app straight to a specific named route? yes it is possible.

This is helpful when you:

Want to test a specific page in your app and you don't want to run the whole app and navigate to that page by yourself.
Want to test deep link in your Flutter app.
(other) you may need it for many other use-cases :)

Show me the code

All you need to do is to run the flutter command with the --route parameter:

pedromassago$ flutter run --route /routeName

The --route parameter expect a string that is the route name that will be used to start your application with. In the case above the app will start with the /routeName page in your screen.

Notes

This feature is only available for Android devices at the time this post was written. There is a open issue to bring support for other platform like iOS at flutter/flutter/issues/4703. If you wan this feature on iOS you can thumbs up the issue to get it fixed sooner.

Thanks for you time! 😉