Este artigo foi originalmente escrito por David Morgan com o título “The Mutability tax” e traduzido com autorização do autor.

Engenharia de software é complicada e eu sou preguiçoso. Não gosto mesmo nada de trabalho desnecessário. Por isso, se o código vai ficar cá por uns tempos, eu construo-o de forma a que seja fácil de manter.

Eu trabalho com linguagens orientadas a objetos, normalmente Dart, e uma consideração fundamental que se deve ter em tais linguagens é a de se os dados vão ser mutáveis ou imutáveis. Muitos, comigo incluído, recomendam dados imutáveis; ver, por exemplo, Effective java item 15, “minimize mutability” (“minimizar mutabilidade”).

Aqui está um trecho de código Dart que ilustra o porquê da mutabilidade poder ser problemática:

// Biggest first.
var cities = [‘Tokyo’, ‘Delhi’, ‘Shanghai’, ‘Mumbai’, ‘Beijing’];
print(‘Biggest cities of the world in alphabetical order:\n’);
DisplayAlphabetically().display(cities);
print(‘And the biggest is ${cities.first}.’);

E aqui está o resultado:

Biggest cities in the world in alphabetical order:
Beijing, Delhi, Mumbai, Shanghai, Tokyo
And the biggest is Beijing.

— Ups! A maior cidade é Tóquio, não Beijing (Pequim). O que é que correu mal? DisplayAlphabeticallyestá a falhar; modifica a lista que lhe é dada, ordenando-a:

void display(List<String> strings) {
  (strings..sort()).forEach(print);
}

Mas não é aqui que está o verdadeiro problema. É garantido que, em engenharia de software, onde quer que seja possível errar, vai errar-se. O problema é que, ao passar uma lista mutável ao método display — o qual pode ter sido escrito por outra pessoa, ou por nós num dia mau, ou copiado e colado do código com características diferentes — , criamos uma oportunidade para bugs.

Para solucionar o problema, podemos utilizar a imutável BuiltList:

// Biggest first.
var cities = BuiltList.of(
    ['Tokyo', 'Delhi', 'Shanghai', 'Mumbai', 'Beijing']);
print('Biggest cities of the world in alphabetical order:\n');
DisplayAlphabetically().display(cities);
print('And the biggest is ${cities.first}.');

— e agora sabemos que DisplayAlphabeticallynão pode modificar cities, deixando de fora toda a categoria de bugs.

Isto é um exemplo simples, fácil de solucionar e corrigir os bugs. O código do mundo real é muito mais complexo e os problemas muito mais sérios. Em particular, vejo problemas com:

• Código de UI (Interface do Utilizador), o qual normalmente é constituído por módulos folgadamente acoplados (loosely coupled) que partilham dados. A mutabilidade cria oportunidades para bugs graves, que são difíceis de resolver, implicando um intensivo trabalho de manutenção.
• Código de servidor de alta performance, o qual usa módulos acoplados de forma folgada que partilham dados para permitir paralelismo. Este é um ambiente muito diferente, mas o problema da mutabilidade é o mesmo: bugs graves que são difíceis de resolver e uma manutenção significativa.

Dados mutáveis nestas linguagens são a predefinição e funcionam bem o suficiente para casos simples; mas torna-se num problema à medida que a base de código aumenta. Por isso, é uma armadilha em que é muito comum cair. Em resumo:

Sistemas com módulos folgadamente acoplados que passam dados mutáveis entre eles ficam com o fardo da mutabilidade. Eles apoiam-se na convenção e na sorte para evitar bugs graves e difíceis de resolver, devido aos indesejados efeitos secundários da mutação. À medida que estes sistemas ficam maiores e mais complexos, a sua sorte acaba e os custos da manutenção aumentam.

Obviamente, se a mutabilidade é o problema, então a imutabilidade é a resposta! Mas esta vem com os seus próprios problemas.

O fardo da Imutabilidade

A maioria das linguagens orientadas a objetos não é, infelizmente, desenhada com a imutabilidade em mente. O caminho óbvio é construir convenções próprias e bibliotecas para dados imutáveis e, surpreendentemente, existem muitas armadilhas.

Analisemos essas armadilhas. Elas são semelhantes transversalmente a todas as linguagens orientadas a objetos mas, para efeitos deste artigo, vamos considerar Dart. A forma mais simples de ter dados imutáveis em Dart é esta:

class Customer {
  final String name;
  final int age;
  Customer({this.name, this.age});
}

Toda a gente concorda com usar os campos (fields) namee age. Mas já tivemos de escolher entre usar parâmetros posicionais (positional parameters) ou parâmetros designados (named parameters). À medida que a lista de parâmetros aumenta, é provável que se queiram parâmetros designados para legibilidade, por isso a convenção que escolhemos para o exemplo é para os usar desde o início.

O próximo problema é como criar novas instâncias imutáveis, baseadas noutras já existentes — como as “atualizar”. A predefinição, e aquilo que regularmente vemos na prática, é forçar as pessoas a usarem o construtor:

var customer = Customer(name: 'John Smith', age: 34);
var updatedCustomer = Customer(
    name: customer.name, age: customer.age + 1);

Infelizmente, o código a utilizar este construtor desta forma quebra se adicionarmos um campo:

var customer = Customer(
    name: 'John Smith', age: 34, visits: 12);

// ... later on ... whoops! This doesn't work, resets 'visits'.
var updatedCustomer = Customer(
    name: customer.name, age: customer.age + 1);

Poderíamos contornar esta situação ao criar todos os parâmetros necessários, ou como parâmetros posicionais ou usando a anotação @required , mas isto não é muito melhor: agora qualquer chamada ao construtor na base de código precisa de ser atualizada para adicionar um novo campo.

O que é que fazemos? Não podemos utilizar o construtor, precisamos de um método:

class Customer {
  final String name;
  final int age;
  Customer({this.name, this.age});
  Customer copyWith({String name, String age}) =>
      Customer(name: name ?? this.name, age: age ?? this.age);
}

Então agora podemos escrever:

var updatedCustomer = customer.copyWith(age: customer.age + 1);

— e este código continua a ter o comportamento correto se um campo for adicionado.

Infelizmente, assim que a um campo é permitido ser null, este padrão falha em Dart. Parâmetros designados opcionais sem uma pré-definição explícita simplesmente voltam a nulle não há forma de verificar se um nullfoi explicitamente passado ou se foi recebido, porque nada foi especificado:

// Doesn't work! The method can't tell that 'null' was explicitly
// passed for 'visits', so nothing is updated.
var customerWithoutVisits = customer.copyWith(visits: null);

Campos que podem ser null podem ser corrigidos ao usar um método withpor cada campo:

class Customer{
  final String name;
  final int age;
  final int visits;
  Customer({this.name, this.age, this.visits});
  Customer withName(String name)
      => Customer(name: name, age: age, visits: visits);
  Customer withAge(int age)
      => Customer(name: name, age: age, visits: visits);
  Customer withVisits(int visits)
      => Customer(name: name, age: age, visits: visits);
}

— o que, pelo menos, funciona, mas está longe de ser satisfatório. É muito código boilerplate (https://pt.wikipedia.org/wiki/Boilerplate_code) para escrever; é fácil enganarmo-nos no código boilerplate; e é lento: atualizar múltiplos campos requer uma cópia completa de objeto por campo.

Mesmo com tipos primitivos, manter objetos imutáveis em Dart manualmente não tem piada nenhuma. Este exemplo tem três campos; num sistema real, Customertem facilmente dez ou mais. Isto significa pelo menos dez métodos with, cada um a passar pelo menos dez argumentos de volta ao construtor. Ouch.

Mas o pior ainda está para vir.

Vai ser preciso suportar coleções e tipos aninhados (nested types):

class ShoppingBasket {
  final Customer customer;
  final List<Item> items;
  final List<Offer> offers;
  ShoppingBasket(
      this.customer,
      Iterable<Item> items,
      Iterable<Offer> offers)
    // Copy defensively to ensure immutability.
    : this.items = List.unmodifiable(items),
      this.offers = List.unmodifiable(offers);
  // TODO(davidmorgan): add "with" method per field.
}

De maneira a aceitar as coleções mutáveis de Dart no nosso mundo imutável, temos de os copiar defensivamente. Uma das supostas vantagens de tipos imutáveis é a de serem rápidos. Nós conseguimos torná-los lentos.

E, se avançarmos com os simples métodos withque tínhamos antes, atualizar um campo aninhado (nested field) torna-se numa tarefa:

var updatedBasket = basket
    .withCustomer(basket.customer.withName(updatedName))
    .withItems([...basket.items, newItem, newItem2]);

Podemos emendar isto com métodos de conveniência adicionais:

var updatedBasket = basket
    .withCustomerName(updatedName)
    .addItem(newItem)
    .addItem(item2);

— mas isso significaria ainda mais código boilerplate. E estaríamos mais uma vez a fazer com que cada atualização fizesse uma cópia completa, tornando os nossos dados imutáveis lentos.

A única forma de responder a todos estas questões — para fornecer dados imutáveis em Dart que sejam fáceis e rápidos de “atualizar”, que suportem campos null, e que não quebrem código existente quando são adicionados campos — é com o padrão builder. Cada tipo de dados tem um tipo adicional associado, o seu builder, o qual tem os mesmos dados mas é mutável. Usamos um builder para “construir” uma instância imutável.

Também precisamos de uma nova biblioteca com coleções de categorias baseadas em builders. Isto permite que coleções imutáveis sejam geridas sem cópias desnecessárias, por isso são rápidas.

Ao utilizar categorias de builders aninhados (nested builder classes) e builders de coleção (collection builders), o nosso código de exemplo pode ser tanto conveniente como eficiente, e as “atualizações” podem parecer-se com isto:

var updatedBasket = basket.rebuild((b) => b
    ..customer.name = updatedName
    ..items.addAll([newItem, item2]));

Infelizmente (outra vez!), o padrão builder precisa de mais código boilerplate do que qualquer outro exemplo e é extremamente difícil de obter corretamente. Existem muitas versões, muitas convenções possíveis e muitos erros possíveis de se fazer. Podemos usar o padrão builder, mas mesmo assim não suportar corretamente os campos que podem ser null; ou continuar a ter um desempenho fraco; ou digitar o código boilerplate com bugs. Tais bugs podem ser tão graves como mutabilidade acidental — a qual é, claro, pior do que a mutabilidade conhecida que tínhamos antes de mudar para dados imutáveis!

Isto traz repetição: digitar milhares e milhares de linhas de código boilerplate à mão, de forma a evitar carregar o fardo da mutabilidade, deixa-nos abertos a exatamente o mesmo tipo de bug que estávamos a tentar evitar, assim que cometemos um erro no código boilerplate.

A maneira certa de fazer imutabilidade é através de padrões builder, mas escrevê-los à mão simplesmente não vale a pena.

Imutabilidade através de Geração de Código (Codegen)

Então vamos dar a que, em linguagens orientadas a objetos que não são desenhadas para imutabilidade, a forma correta de alcançar a imutabilidade e evitar o fardo da imutabilidade é deixar outra pessoa fazer o trabalho por nós, através de uma biblioteca que origina código. Só com a geração de código (codegen) podemos reduzir o trabalho acrescido que é requerido na criação de dados imutáveis nestas linguagens.

Infelizmente (uma última vez!), a geração de código vem com os seus próprios defeitos: continua a precisar de código boilerplate para ser posta a funcionar; poderá ser preciso trabalho adicional para pôr o nosso projeto em build; e o nosso IDE (Ambiente de Desenvolvimento Integrado) pode não ser tão útil quando chega ao código gerado. Mas é o melhor que conseguimos fazer hoje. Em Dart existe a minha própria biblioteca, built_value, a qual vai mais além e pode serializar os dados; escrevi um artigo sobre isso aqui. Tem este aspeto, com o código boilerplate realçado a negrito:

abstract class Customer implements Built<Customer, CustomerBuilder> {
  String get name;
  int get age;
  @nullable
  int get visits;factory Customer(void Function(CustomerBuilder) updates) = 
    _$Customer;
  Customer._();
}

O código boilerplate é desagradável e assustador, mas é fácil de preservar: não é necessário adicionar nenhum código boilerplate quando se adiciona um novo campo, e é impossível existirem bugs no código boilerplate porque a geração de código também o verifica por nós. Alcançámos dados imutáveis sustentáveis. Aquilo que agora nos é imposto já não é tanto um fardo contínuo, mas mais uma taxa de entrada.

Em Java existe o AutoValue.Builder, que tem uma abordagem parecida e vem com um código boilerplate semelhante. A propósito disto, essa equipa fez um power point muito bom acerca do porquê desta geração de código ser necessária.

Em suma:

Em linguagens não desenhadas para imutabilidade, os sistemas que evitam o fardo da mutabilidade ao implementar estruturas de dados imutáveis à mão, por outro lado acarretam o fardo da imutabilidade. Estruturas de dados imutáveis nestas linguagens são difíceis de obter corretamente e, por definição, são inconvenientes e lentas; isto resulta num custo mais elevado de manutenção, bugs e problemas de desempenho. A maneira certa de contornar o fardo da mutabilidade nestas linguagens é usar uma biblioteca que origine e esconda o código boilerplate necessário para dados imutáveis convenientes e rápidos.

Pensamentos finais

Pode-me ser perguntado se pratico aquilo que digo; se realmente faço o trabalho adicional de usar geração de código para dados imutáveis no meu trabalho diário.

A resposta é: se vou ter de manter o código, sim, uso os dados imutáveis. Se é pequeno e “escreve uma vez, corre uma vez, apaga”, provavelmente não me vou dar ao trabalho.

Houve uma exceção recente a esta regra. Estava a trabalhar em código, nas profundezas do build em Dart; e não podemos usar facilmente codegen em código dependente de codegen. Por isso, voltei a dados imutáveis feitos à mão.

Estava demasiado preguiçoso para digitar métodos with; usei só o construtor. Depois adicionei um campo. Depois, passei um tempo considerável a corrigir bugs, porque o código existente estava a apagar o novo campo, exatamente como foi descrito neste artigo.

Isto lembrou-me do quanto desgosto de ambos os fardos da mutabilidade e da imutabilidade, e daí nasceu a ideia para este artigo.

Vamos concluir com os dois sumários para que possam coexistir ao lado um do outro.

O Fardo da Mutabilidade

Sistemas que tenham módulos folgadamente acoplados (loosely coupled) que transmitem dados mutáveis entre si, acarretam o fardo da mutabilidade. Eles dependem da convenção e de sorte para evitar bugs graves e difíceis de resolver devido a efeitos secundários indesejados da mutação. À medida que estes sistemas crescem e se tornam mais complexos, a sua sorte acaba e o custo de manutenção aumenta.

O Fardo da Imutabilidade

Em linguagens que não foram desenhadas para imutabilidade, os sistemas que contornam o fardo da mutabilidade ao implementar arquiteturas de dados imutáveis à mão, acarretam o fardo da imutabilidade. É difícil acertar nas arquiteturas de dados imutáveis nestas linguagens e são, por definição, inconvenientes e lentas; isto resulta num maior custo de manutenção, bugs e problemas de desempenho. A forma correta de evitar o fardo da imutabilidade nestas linguagens é usar uma biblioteca que faça a gestão e esconda o código boilerplate necessário para dados imutáveis convenientes e rápidos.

• David Morgan - Medium
• The Mutability Tax
• Flutter Portugal

O Fardo da Mutabilidade was originally published in Flutter Portugal on Medium, where people are continuing the conversation by highlighting and responding to this story.

We are living unique times. For most generations this is the first major pandemic we have ever faced. For our own good and those around us we are urged to maintain social distance in order to stop it. But today more than ever, we have to be resilient and creative, to be in solidarity and to stay united even if at a distance. Above all, we need to keep ourselves informed, to understand where the questions and answers are, what measures are being taken to deal with the pandemic and the enormous challenges that this fight unleashes.

So, in order to compile all this information (already published on the website created by VOST) in a single channel accessible in a few seconds and with a small number of taps, the mobile application “Estamos On” was born, available for download at Google Play Store and Apple App Store.

• Estamos ON - Covid19 - Apps on Google Play
• ‎Estamos ON - Covid19

This App was made possible due to the volunteer work of Flutter Portugal and VOST Portugal. For those who wonder what these communities or groups are or what they do, let’s get to know them a little better.

Flutter Portugal is one of the official communities that shares knowledge and promotes Google’s Flutter technology to create applications for mobile, web and desktop. The community is composed of volunteers from all over the continental and insular territory. It organizes events, such as conferences and workshops, of greater or lesser dimension, taking into account the objective and the public for which they are intended.

Flutter PT

VOST is the acronym for Virtual Operations Support Team, which in Portugal assumes itself as Digital Volunteers in Emergency Situations, that is, people committed to providing information and making the population more enlightened, informed, prepared and protected. Since October 16th, 2019, it is formally constituted as a civil protection association called VOST Portugal — Associação de Voluntários Digitais em Situações de Emergência.

VOST PORTUGAL

Both organizations share the same values — everything that is produced by the community is open sourced — which means the code is open and allows it to be viewed and reviewed by anyone. Furthermore, those who want to help can do so by contributing to the project.

The first cases of Covid-19 appeared in Portugal in early March. Their unequivocal spread led to the declaration of a state of emergency, through the Decree of the President of the Republic №14-A/2020 of March 18th. In order to turn the available information more transparent and widely accessible, the Government of Portugal launched an appeal for the need to build a portal that would aggregate all the information. This was built by VOST Portugal, which in turn requested Flutter Portugal’s help so that the mobile application could be created.

However, with one of the communication channels already developed in the form of a website, the question may arise: is there a need to create a mobile application?

Putting aside personal choice (the fact that we may like to access a website or prefer to use an app), an application gives us a quick means of communication with all users in the form of Push Notifications. As soon as there is an update on the state of emergency, new measures by the State or an update of the new case numbers, a Push Notification can quickly send the information to all users, without them having to go to the website. In future updates, new features can also be added, such as local caching so that even offline, all information is easily accessible.

Saying that the project had a short deadline would not do justice to the urgency of the situation, so it was very important to choose a technology that allowed us to deliver a robust application in the shortest possible time. Since, initially, we were only a team of 5, creating two native applications was out of the question, so we adopted Flutter. For the Flutter Portugal team the choice was easy, for several reasons:

• Flutter allows 2 applications to be created with one code base — for Android and iOS, reducing the project execution time to half;
• Each one of us had already proven the robustness of the technology, with personal projects or by the fact that it is the technology we use in our daily work;
• We are all passionate about this technology, and quite often we use our Discord to discuss ideas and ask questions to each other;
• Our team had already worked together for the Fogos.pt project, which consisted in a rewrite of the existing project to Flutter, so not only had we proven that we were able to deliver a project as a team, but we also proved that Flutter was a great choice for this kind of project.

Fogos.pt - Apps on Google Play

With the completion of this project, many lessons have been learned that we would like to share here:

• The urgency and scale of this project required fast and efficient communication, so we chose to use our Discord server for it. We have divided the communication into two channels. The first channel’s purpose, with voice and audio, was to quickly discuss all the issues of the project and ask for help from other team members. The second channel had only important announcements — new features, status of the project, what we had to do and new information from the VOST channel.

Discord - A New Way to Chat with Friends & Communities

• It was crucial that all the members of the team already knew each other and worked together. This made it easy to divide up tasks so that we always took advantage of each other’s strengths — communication with other entities, design, preparation of a testing and distribution platform or project organisation and management.
• The fact that we had direct contact with the designer Francisco Frutuoso and that he made the project available to us in Zeplin, made it easier and faster to create all the screens.

• Francisco Frutuoso - Digital Designer
• COVID19 App | Zeplin Scene

• The most important thing was that there was great mutual respect for all members of the team. This made us listen and discuss opinions, even if these were against what we would be used to. Together we grew, learned and prepared for future projects.

The willingness to help others in this time of crisis and the willingness to want to work together again is what brought this team together. Opportunities like these fill us with experience that we will apply in our job and in our life in general. We are confident that this can be replicated by other teams of programmers and designers around the world, provided there is a basis for mutual respect and a common goal.

Finally, we leave a message for Non-Profit Organizations and government bodies:

The Flutter Portugal team is here, more united than ever.

Challenge us.

Written by Gonçalo Palma and Simone Júlio

You want to help this cause? Go to the Github repository of the “Estamos On” app and see what issues are open!

vostpt/covid19-mobile

Website Flutter Portugal:

Flutter PT

Twitter Flutter Portugal:

Flutter Portugal

Join our Discord server! → http://chat.flutter.pt

Estamos On — Our Contribution was originally published in Flutter Portugal on Medium, where people are continuing the conversation by highlighting and responding to this story.

Vivemos momentos únicos. Para a maioria das gerações trata-se da primeira grande pandemia que enfrentamos. Para o bem de todos, somos instados a manter distanciamento social. Mas, hoje mais que nunca, temos que ser resilientes e criativos, ser solidários e mantermo-nos unidos ainda que à distância. Necessitamos acima de tudo de nos manter informados, compreender onde estão as perguntas e respostas, que medidas estão a ser tomadas para fazer face à pandemia e aos enormes desafios que esta luta despoleta.

Assim, com o intuito de compilar toda esta informação (já publicada no website criado pela VOST) num só canal acessível em poucos segundos e com um reduzido número de cliques, nasceu a aplicação “Estamos On”, já disponível para download na Play Store da Google e na App Store da Apple.

• Estamos ON - Covid19 - Apps on Google Play
• ‎Estamos ON - Covid19

Esta App é uma realidade devido ao trabalho voluntário da Flutter Portugal e da VOST Portugal. Para quem se pergunta o que são ou o que fazem estas comunidades ou grupos, vamos de seguida conhecê-los um pouco melhor.

A Flutter Portugal é uma das comunidades oficiais que partilha conhecimento e promove a tecnologia Flutter da Google que se destina a criar aplicações para mobile, web e desktop. A comunidade é composta por voluntários de todo o território continental e insular. Esta organiza eventos, tais como, conferências e workshops, de maior ou menor dimensão, tendo em conta o objetivo e público a que se destinam.

Flutter PT

VOST é o acrónimo para Virtual Operations Support Team, que em Portugal se assume como Voluntários Digitais em Situações de Emergência, isto é, pessoas comprometidas a prestar informação e a tornar a população mais esclarecida, informada, preparada e protegida. Desde 16 de Outubro de 2019, constitui-se formalmente como associação de proteção civil denominada de VOST Portugal — Associação de Voluntários Digitais em Situações de Emergência.

VOST PORTUGAL

Ambas partilham os mesmos valores, ou seja, tudo o que é produzido na comunidade é feito em open source, ou seja, o código é aberto, o que permite ser consultado por qualquer pessoa.

Como sabemos, os primeiros casos de Covid-19 surgiram em Portugal no início de março. A sua propagação inequívoca levou à declaração de estado de emergência, através do Decreto do Presidente da República n.º 14-A/2020, de 18 de março. De forma a tornar a informação mais transparente e acessível, o Governo de Portugal lançou um apelo para a necessidade de construir um portal que agregasse toda a informação. Este foi construído pela VOST Portugal, que por sua vez solicitou a ajuda da Flutter Portugal para que a aplicação pudesse ser criada.

Contudo, com um dos canais de comunicação já desenvolvidos sob a forma de um website, poderá colocar-se a questão: haverá a necessidade de se criar uma aplicação?

Colocando de parte a escolha pessoal de cada pessoa (o facto de gostarem mais de aceder a um website ou usar uma aplicação), uma aplicação dá-nos um meio de comunicação rápido com todos os utilizadores sob a forma de Notificações. Assim que haja uma actualização no estado de emergência, medidas novas por parte do Estado ou que saiam os números dos novos casos por dia, a Notificação consegue rapidamente transmitir a informação a todos os utilizadores, sem que estes tenham de ir novamente ao website. Em futuras actualizações, também se pode colocar novas funcionalidades, como a de cache local para que mesmo em offline toda a informação seja facilmente acessível.

Dizer que o projecto tinha um prazo de entrega curto não iria fazer justiça à urgência da situação, por isso seria fundamental escolher uma tecnologia que nos permitisse entregar uma aplicação robusta no menor espaço de tempo possível. Sendo que apenas tínhamos 5 elementos inicialmente, criar duas aplicações nativas estava fora de questão, por isso adotamos Flutter. Para a equipa Flutter Portugal a escolha foi fácil, por vários motivos:

• Flutter permite que com uma base de código sejam criadas 2 aplicações — para Android e para iOS, reduzindo para metade o tempo de execução do projecto;
• Cada um de nós já tinha comprovado a robustez da tecnologia, com projectos pessoais ou pelo facto de ser a tecnologia que utilizamos no dia a dia no trabalho;
• Todos somos apaixonados pela tecnologia, e com bastante frequência usamos o nosso Discord para discutir ideias e tirar dúvidas uns com os outros;
• A nossa equipa já tinha trabalhado em conjunto para o projecto Fogos.pt, no qual foi reescrita a aplicação nativa em Flutter, por isso não só já tínhamos comprovado que conseguimos entregar um projecto como equipa, como também comprovamos que Flutter era uma óptima escolha para este tipo de projecto.

Fogos.pt - Apps on Google Play

Com a conclusão deste projecto, ficam muitas lições aprendidas que gostaríamos aqui de partilhar:

• A urgência e escala deste projecto requereu uma comunicação rápida e eficiente, pelo que optamos por utilizar o nosso servidor Discord para o mesmo. Dividimos a comunicação em dois canais. O primeiro canal, de voz e áudio, servia para discutirmos rapidamente todas as questões do projecto e pedirmos ajuda a outros membros da equipa. O segundo canal tinha apenas anúncios importantes — novas funcionalidades, ponto da situação, o que tínhamos para fazer e novas informações do canal da VOST.

Discord - A New Way to Chat with Friends & Communities

• Foi fulcral que todos os membros da equipa já se conhecessem e tivessem trabalhado juntos. Isto fez com que facilmente se tivesse dividido as tarefas de modo a que aproveitássemos sempre os pontos fortes de cada um — comunicação com outras entidades, design, preparação de uma plataforma de testes e distribuição ou organização e gestão do projecto.
• O facto de termos um contacto directo com o designer Francisco Frutuoso e de este nos ter disponibilizado o projecto em Zeplin, facilitou e agilizou a criação de todos os ecrãs.

• Francisco Frutuoso - Digital Designer
• COVID19 App | Zeplin Scene

• O mais importante, foi que havia um grande respeito mútuo por todos os elementos da equipa. Isto fez com que ouvíssemos e discutíssemos opiniões, mesmo que estas fossem contra o que estaríamos habituados. Juntos crescemos, aprendemos e preparamo-nos para futuros projectos.

A vontade de ajudar outros nesta altura de crise e a vontade de querermos novamente trabalhar juntos foi o que juntou esta equipa. São oportunidades como estas que nos enchem de experiência que iremos aplicar no nosso emprego e na nossa vida em geral. Tal como aconteceu connosco, temos a maior certeza que isto poderá ser replicado por outras equipas de programadores e designers pelo mundo fora, desde que haja uma base de respeito mútuo e um objectivo comum.

Por fim, deixamos uma mensagem para as Organizações Sem Fins Lucrativos e órgãos do Governo:

A equipa Flutter Portugal está aqui, mais unida que nunca.

Desafiem-nos.

Escrito por Gonçalo Palma e Simone Júlio

Querem ajudar esta causa? Vão ao repositório no Github da app Estamos On e vejam quais os issues abertos!

vostpt/covid19-mobile

Website Flutter Portugal:

Flutter PT

Twitter Flutter Portugal:

Flutter Portugal

Juntem-se a nós no nosso Discord! → http://chat.flutter.pt

Estamos On — A nossa contribuição was originally published in Flutter Portugal on Medium, where people are continuing the conversation by highlighting and responding to this story.

Na Flutter Portugal acreditamos que o conhecimento tem de ser acessível a todos, independentemente do grau de conhecimento de línguas estrangeiras. Assim, vamos lançar uma pequena série de artigos que vão abrangir vários tópicos: Dados persistidos, State Management, Navegação, etc…

Este artigo foi originalmente escrito por Gonçalo Palma com o título “Mixins and Base Classes: A recipe for success in Flutter” e traduzido com autorização do autor.

Quando se desenvolve uma aplicação com múltiplos ecrãs, tendemos a reutilizar o mesmo pedaço de código em muitas classes: mostrar mensagens de erro, utilizar a mesma disposição de página e inicializar algumas dependências como, por exemplo, um Bloc. Tudo isto pode ser resolvido se estivermos a usar uma classe de base (base class) abstract, porém, e se tivermos um conjunto de características/classes que nós queremos utilizar num ecrã particular, mas não noutros? Tendo em conta que uma classe não pode ser uma filha (child) de mais do que uma classe, deveremos nós criar diferentes classes de base, tantas quanto o número de combinações que temos? É por isso que temos mixinss.

Mixins e Classes de Base: Uma introdução

Mixins deixam-nos adicionar um conjunto de “características” a uma classe, sem usar a hierarquia parent-child, permitindo-nos ter, na mesma classe, um pai (parent) e múltiplos componentes mixin. Assim, já que não é um pai da nossa classe, mixins não permitem nenhuma declaração de construtores. Podem ler mais sobre isto neste artigo de Romain Rastel, com a advertência de que o Dart 2 tem agora a palavra-chave mixin, como visto na documentação.

Mas como é que os mixins funcionam? Vamos tomar como exemplo uma absrract class Person .

Podemos utilizar esta classe como um pai, usando a palavra-chave extend, assim:

Com isto, podemos incicializar a classe e chamar o método do pai think().

Mas, e se quisermos adicionar novas funcionalidades ao Mike? E se o Mike for um programador e precisa de uma função codeque possa ser usada noutro Person, mas não seja utilizada por todos os Persons? mixins resolvem esse problema.

Primeiro, precisamos de criar uma classe mixine expor os novos métodos que queremos usar.

Com a palavra-chave withpodemos adicionar este “elemento” à nossa classe Mike:

E, como com o pai, podemos chamar todas as funções que criámos no Coder.

Agora, todas as classes que usem o mixin Coder podem efetivamente programar. No entanto, surge um problema: isto significa que, se tivermos uma classe parent Animalque tem uma child Squirrel, também podemos ter um Squirrelque consegue code()! Para prevenir esta situação, podemos “bloquear” o uso do mixinpara uma classe e todas as classes que dele herdaram a palavra-chave on:

Isto também nos dá uma ferramenta poderosa: agora podemos fazer override a métodos que estavam definidos na classe Personpara adicionar ou alterar a sua funcionalidade.

Chamar o super.think()garante que ainda estamos a chamar o código que foi definido em Person. O código acima dá-nos o seguinte output para o método thinkin. Mike:

Ao adquirir os conceitos de ambos base classes e mixins, agora podemos aplicá-los às nossas aplicações Flutter.

Mixins e Classes Base: Um exemplo Flutter prático

Como é que podemos aplicar isto nas nossas aplicações Flutter?

Tomemos como exemplo os dois ecrãs seguintes:

A nossa aplicação tem vários ecrãs com a disposição mostrada acima. Em vez de copiar e colar a appbar (barra da aplicação) e o fundo para cada ecrã, podemos resolver o nosso problema ao utilizar mixins.

Em ambos os casos, temos um título de ecrã definido; vamos criar uma base classque tem um método para fornecer o nome do nosso ecrã, chamada BasePage. Também vamos aplicar os mixins só no StatefulWidgets, já que as nossas classes vão manter e mudar o seu estado. Com isto, nós criamos duas classes para serem usadas nas nossas páginas: uma BasePagee uma BaseState<BasePage>que estendem SatefulWidgete State<StatefulWidget>, respetivamente.

Focando agora no segundo ecrã, já podemos criar o seu mixin BasicPageMixin personalizado, onde definimos o fundo e a appbar da nossa página.

Tendo em conta que o método body()não tem um corpo (body), cada classe que use este mixintem de o implementar, assegurando que nós não nos esqueçamos de adicionar um corpo à nossa página.

Na captura de ecrã acima, vemos um FloatingActionButton, mas poderemos não precisar dele para todos os ecrãs, então como é que o podemos definir? Ao declarar um novo método, fab(), que por predefinição devolve um Container. Se uma classe necessita de adicionar um FloatingActionButton, eles podem substituir este método.

Com o nosso mixincriado podemos agora aplicá-lo a uma nova página.

E, assim, só nos resta declarar um body()e um possível widget fab()para ser usado em cada ecrã, poupando-nos umas dúzias de linhas de código.

Combinar mixins

Sendo uma nova funcionalidade, alguns dos nossos ecrãs vão fazer chamadas a uma API (Interface de Programação de Aplicações) e, se ocorrer algum erro, precisaremos de exibir uma mensagem de erro na forma de um Snackbar. Além disso, decidimos utilizar a arquitectura BLoC, na qual precisamos de injetar um novo bloc de cada vez que uma página é criada. Estes dois problemas vão necessitar dos seguintes passos:

• Modificar a nossa BasePage, através da alteração do seu construtor com o novo parâmetro bloc.
• Modificar BaseState, ao adicionar um novo GlobalKey<ScaffoldState>
• Criar um novo mixinque nos deixa exibir mensagens de erro enviadas pelo blocna página, usando um Snackbar

No nosso BaseBloc, estamos apenas a expôr um Sinke um Stream , de forma a transmitir mensagens de erro.

Como nós não queremos outras interações com o bloc, o nosso HomeBlocvai só estender esta classe.

Prosseguimos, ao alterar o construtor da nossa BasePagepara incluir o objeto do bloc. Isto vai forçar-nos a mudar também todas as classes que o estendem para adicionar um bloc igualmente aos seus construtores. O parâmetro blocé usado como um tipo Genérico de modo a que cada classe que o estende possa declarar o tipo correto de bloc que está a utilizar. Isto assegura que, quando o estamos a chamar na BaseState, vamos obter o tipo correto de bloc, permitindo-nos aceder aos seus métodos.

Quanto ao BaseState, vamos declarar um scaffoldKeypara ser usado com o ScaffoldWidget para que possamos exibir a Snackbar.

Tal como visto anteriormente, uma das curiosas propriedades dos mixin é que, se estiverem ligados a uma classe, eles podem overrideos seus métodos. Isto é útil, já que no nosso StatefulWidgetpodemos ouvir ( listen) os streamsdo blocno método initState. Assim. Para exibir as mensagens de erro, podemos criar um mixinque faz override ao método initStatee fornece métodos para mostrar a mensagem de erro correta numa Snackbar.

Finalmente, podemos adicioná-lo à nossa classe HomePageao adicioná-lo depois do mixin BasicPage.

Conclusão

E lá vamos nós! ✌️ Agora podemos utilizar ambos, mixins e abstract classes, para reutilizar o código nas nossas aplicação.

Talvez não precisemos de fazer uma base UI (Interface de Utilizador) para a nossa aplicação, mas podemos usar mixins como ErrorHandlingMixinpara mostrar uma mensagem de erro ao utilizador, um feedback quando estivermos a carregar uma página ou até mostrar um ecrã com “A Aplicação está Offline”.

No entanto, criar ambas as classes base e os mixins é um processo que precisa de alguma deliberação, caso contrário poderemos estar perante um “Deadly Diamond of Death”, em que quando a chamar um método que é declarado em ambos os mixins e classes base, o compilador não sabe qual escolher. Pode ler mais sobre isto no artigo de Shubham Soni sobre mixins em Flutter.

Finalmente, e tal como sugerido por Remi Rousselet, devemos estar atentos a como o uso extensivo de mixins pode ser considerado anti-padrões, podendo-se ler mais neste artigo de Dan Abramov.

• Blog
• Mixins and Base Classes: A recipe for success in Flutter

Mixins e Classes de Base: Uma receita para o sucesso no Flutter was originally published in Flutter Portugal on Medium, where people are continuing the conversation by highlighting and responding to this story.

Na Flutter Portugal acreditamos que o conhecimento tem de ser acessível a todos, independentemente do grau de conhecimento de línguas estrangeiras. Assim, vamos lançar uma pequena série de artigos que vão abrangir vários tópicos: Dados persistidos, State Management, Navegação, etc…

Este artigo foi originalmente escrito por Pooja Bhaumik com o título “Flutter: Push, Pop, Push” e traduzido com autorização da autora.

Construir uma UI (Interface do Utilizador) é muito simples com todos os widgets que a framework disponibiliza, parte da qual abordei no meu último artigo. Mas não podemos ter somente uma aplicação linda que não faz nada funcional. Ser-nos-à pedido que naveguemos pela aplicação ou que enviemos dados para a frente e para trás entre ecrãs. Em Flutter, a navegação de um ecrã para outro é possível devido aos Navigators, um widget simples que mantém uma stack (pilha) de Routes (rotas), ou em termos mais simples, um histórico de páginas/ecrãs visitados.

Encontraremos imensos artigos que dizem como push (empurrar)para um novo ecrã, ou pop (remover) do ecrã atual, mas este artigo é um pouco mais do que isso. Este irá focar-se mais na maioria dos métodos do Navigator e descrever um caso prático para cada um deles.

Antes de começarmos…

Mencionou Routes algures, o que é isso?

Routes é uma abstração para um ecrã ou página de uma aplicação. Por exemplo, '/home'vai levar-nos ao HomeScreen (Ecrã Inicial) ou '/login'vai levar-nos ao LoginScreen (Ecrã de Login). '/'vai ser a nossa rota inicial. Isto pode soar parecido ao Routing no desenvolvimento REST API. Então '/'pode atuar como uma root (raiz).

Esta é a forma como iríamos declarar as nossas rotas na nossa aplicação Flutter.

new MaterialApp(
  home: new Screen(),
  routes: <String, WidgetBuilder> {
    '/screen1': (BuilderContext context) => new Screen1(),
    '/screen2' : (BuilderContext context) => new Screen2(),
    '/screen3' : (BuilderContext context) => new Screen3(),
    '/screen4' : (BuilderContext context) => new Screen4()
  },
)

Screen1(), Screen2(), etc são os nomes das classes para cada ecrã.

Push, push, push.

Se tem algum conhecimento sobre Data Structures (Estruturas de Dados), então sabe sobre Stacks. Se tem conhecimentos, ainda que básicos, sobre stacks, então sabe sobre push e pop.

Se não sabe, pushing é adicionar um elemento ao topo da stack de elementos e popping é remover o elemento no topo da mesma stack.

No caso do Flutter, quando navegamos para outro ecrã, usamos o método pushe o widget Navigatoradiciona o novo ecrã ao topo da stack. Naturalmente, o método popiria remover esse ecrã da stack.

Avancemos então para a base de código do nosso projeto-amostra e vejamos como é que podemos movimentar-nos do Ecrã 1 para o Ecrã 2. Podemos experimentar com os métodos ao correr a aplicação-amostra.

new RaisedButton(
   onPressed:(){
   Navigator.of(context).pushNamed('/screen2');
},
   child: new Text("Push to Screen 2"),
),

Isto foi curto.

Lá isso foi. Com a ajuda dos métodos pushNamed, podemos navegar para qualquer ecrã cuja rota é definida em main.dart. Chamamo-lhes namedRoutepara referência. O caso prático deste método é bastante direto. Para simplesmente navegar.

Pop it

Agora, quando nos queremos ver livres do último ecrã visitado, que é o Screen2neste caso, precisaríamos de remover Routes da stack do Navigator usando o método pop.

Navigator.of(context).pop();

Não esquecer que esta linha de código vai por dentro do método OnPressed.

Quando se usa uma Scaffold, normalmente não é necessário fazer pop da rota explicitamente, porque o Scaffold automaticamente adiciona um botão “back” (voltar) na sua AppBar, o qual irá chamar o Navigator.pop()quando pressionado. Mesmo em Android, pressionar o botão “back” do dispositivo faria o mesmo. Mas mesmo assim, poderemos precisar deste método para outros casos práticos, tais como pop de um AlertDialog quando o utilizador clica no botão de Cancelar.

Porquê pop em vez de fazer push de volta ao ecrã anterior?

Imaginemos que temos uma aplicação de Reserva de Hotel que lista os hotéis na localização que desejamos. Clicar numa das listas vai levar-nos a um ecrã que contém mais detalhes sobre o hotel. Escolhemos um, mas odiamos o hotel e queremos voltar à lista. Se fizermos pushde volta ao HotelListScreen, vamos estar também a manter o nosso DetailsScreenna nossa stack. Assim, clicar no botão de voltar atrás levar-nos-ia de novo ao DetailsScreen. Tão confuso!

Em vez disso devemos testá-lo. Correr a aplicação-amostra, ver a appBar no nosso Screen1, não tem nenhum botão para voltar atrás, porque é a Route inicial (ou ecrã inicial), agora clicamos em Push to Screen 2 e, em vez do botão de retornar, carregar no Push to Screen 1 em vez de Pop e, agora, ver a appBar no Screen1.

Carregar no recente botão de voltar atrás vai fazer-nos recuar ao Screen2e nós não queremos isso neste tipo de casos.

maybePop

E se estivermos na Route inicial e alguém, por engano, tentou fazer pop a este ecrã. Popping o único ecrã na stack iria fechar a nossa aplicação, porque assim não teria nenhuma rota para exibir. Nós definitivamente não queremos que o utilizador tenha uma experiência tão inesperada. É aí que o maybePop()aparece. Por isso, fica do género “faça pop só se conseguir”. Experimente, clique no botão maybePopno Screen1e não vai fazer nada. Porque não há nada para fazer pop. Agora tente o mesmo no Screen3e irá fazer pop ao ecrã. Porque pode.

canPop

É espantoso conseguirmos fazer isto, mas como é que posso saber se isto é a route inicial? Seria bom se pudesse exibir algum alerta para o utilizador em casos destes.

Ótima questão, é só chamar este método canPop()e regressará truese esta route puder ser popped e falsese não for possível.

Esperimente ambos os métodos canPope maybePopno Screen1e Screen3, e veja a diferença. Os print values para o canPopvão mostrar no separador da sua consola/terminal do seu IDE (Ambiente de Desenvolvimento Integrado).

Push um pouco mais

Voltemos a mais métodos de push. Agora estamos a aprofundar. Vamos falar sobre substituir uma rota por uma nova rota. Temos dois métodos que podem fazer isto — pushReplacementNamed e popAndPushNamed.

Navigator.of(context).pushReplacementNamed('/screen4');
                       //and
Navigator.popAndPushNamed(context, '/screen4');

Tente experimentar com ambos no Screen3da aplicação-amostra. E repare na animação de saída e entrada em cada caso. pushReplacementNamedvai executar a animação de entrada e popAndPushNamedvai executar a animação de saída. Podemos utilizar isto para os próximos casos práticos possíveis.

Caso prático: pushReplacementNamed

Quando o utilizador iniciou sessão com sucesso, e agora poderá estar no DashboardScreen, não queremos que o utilizador regresse ao LoginScreenem caso algum. Então, a rota de login deveria estar completamente substituída pela rota do painel. Outro exemplo seria ir ao HomeScreena partir do SplashScreen. Só deverá ser mostrado uma vez e o utilizador não deveria ser capaz de regressar a ele novamente a partir do HomeScreen. Em casos destes, uma vez que vamos passar para um ecrã completamente novo, poderemos querer utilizar este método para a sua propriedade de animação de entrada.

Caso prático: popAndPushNamed

Suponhamos que estamos a construir uma aplicação de Compras que mostra uma lista de produtos no seu ProductsListScreene o utilizador pode aplicar filtros no FiltersScreen. Quando o utilizador clica no botão Apply Changes, o FiltersScreen deveria fazer pop e push de volta ao ProductsListScreencom os novos valores do filtro. Aqui, a propriedade de animação de saída do popAndPushNamedseria mais apropriada.

Até ao fim…

Estamos quase no fim do artigo. Bem, quase.

Nesta secção vamos abordar os próximos três métodos pushNameAndRemoveUntile popUntil.

Caso prático: pushNamedAndRemoveUntil

Então, basicamente estamos a construir uma aplicação do género do Facebook/Instagram, em que o utilizador inicia sessão, percorre o seu feed, persegue perfis diferentes e, quando acaba, quer terminar a sessão na aplicação. Depois de terminar sessão, não podemos simplesmente fazer pushnum HomeScreen(ou em qualquer ecrã que precise de ser exibido depois de terminar a sessão) em casos deste tipo. Queremos remover todas as rotas na stack para que o utilizador não consiga regressar às rotas anteriores depois de ter terminado a sua sessão.

Navigator.of(context).pushNamedAndRemoveUntil('/screen4', (Route<dynamic> route) => false);

Aqui, (Route<dynamic> route => falsevai certificar-se de que todas as rotas anteriores à rota que foi pushed são removidas.

Agora, em vez de remover todas as rotas antes das rotas pushed, só podemos remover um certo número de rotas. Tomemos como exemplo outra aplicação de Compras! Ou basicamente qualquer aplicação que exija uma transação de pagamento.

Nestas aplicações, uma vez que o utilizador tenha completado a transação de pagamento, todos os ecrãs relacionados com a transação ou com o carrinho devem ser removidos da stack e o utilizador deve ser levado ao PaymentConfirmationScreen. Clicar no botão de retroceder deverá levá-los de volta somente ao ProductsListScreenou HomeScreen.

Navigator.of(context).pushNamedAndRemoveUntil('/screen4', ModalRoute.withName('/screen1'));

De acordo com o fragmento do código, fazemos push ao Screen4e removemos todas as rotas até ao Screen1para que a nossa stack se pareça com isto.

Caso prático: popUntil

Imaginemos que estamos a construir uma aplicação tipo Formulários Google ou uma aplicação que nos deixa preencher e organizar formulários Google. Um utilizador poderá ter de preencher um longo formulário de 3 partes, o qual poderá ser exibido em 3 ecrãs sequenciais numa aplicação móvel. Na 3ª parte do formulário, o utilizador decide cancelar o preenchimento do formulário. O utilizador clica em Cancele todos os ecrãs anteriores relacionados com o formulário devem ser popped e o utilizador deve ser levado de volta ao HomeScreenou DashboardScreen,perdendo, assim, todos os dados relacionados com o formulário (que é o que desejamos neste tipo de casos). Não estaremos a fazer push em nada de novo aqui, só a retornar a uma rota anterior.

Navigator.popUntil(context, ModalRoute.withName('/screen2'));

Onde estão os dados?

Na maioria dos exemplos anteriores, estou apenas a fazer push numa nova rota sem enviar dados nenhuns, mas um cenário assim é muito pouco provável numa aplicação real. Para enviar dados, estaríamos a utilizar o Navigator para fazer push numa nova MaterialPageRoute para a stack com os nossos dados, (aqui é userName).

String userName = "John Doe";
Navigator.push(
    context,
    new MaterialPageRoute(
        builder: (BuildContext context) =>
        new Screen5(userName)));

Para recuperar os valores no Screen5, adicionaríamos um construtor parametrizado no Screen5, desta forma:

class Screen5 extends StatelessWidget {

  final String userName;
  Screen5(this.userName);
  @override
  Widget build(BuildContext context) {
  print(userName)
  ...
  }
}

Isto significa que não só podemos usar o método MaterialPageRoutepara push,mas também para pushReplacement, pushAndPopUntil, etc. Basicamente, introduza o termo-chave nameda partir dos métodos acima descritos e o primeiro parâmetro irá agora tomar MaterialPageRouteem vez de um Stringda namedRoute.

Devolve-me alguns dados, meu

Poderemos também querer devolver dados a partir de um novo ecrã. Suponhamos que estamos a construir uma aplicação de Alarme e, para definir um novo toque para o nosso alarme, iríamos exibir uma lista de opções de áudio. Obviamente, iríamos precisar do item de dados selecionado quando a caixa de Diálogo tiver sido popped. Pode ser conseguido assim:

new RaisedButton(onPressed: ()async{
  String value = await Navigator.push(context, new MaterialPageRoute<String>(
      builder: (BuildContext context) {
        return new Center(
          child: new GestureDetector(
              child: new Text('OK'),
              onTap: () { Navigator.pop(context, "Audio1"); }
          ),
        );
      }
  )
  );
  print(value);

},
  child: new Text("Return"),)

Experimente no Screen4e verifique a consola para os print values.

Também é de notar: Quando uma rota é usada para recuperar um valor, o tipo de parâmetro da rota deve corresponder ao tipo de resultados do pop. Aqui, necessitamos de dados de String (corda), por isso usámos MaterialPageRoute<String>. Também não faz mal se não o tipo não for especificado.

Uau, isso foi muita informação

De facto, foi, e eu podia ter explicado somente os métodos e a sua implementação, mas visto que há tantos métodos Navigator, eu queria explicá-los usando cenários trazidos de aplicações do mundo real. Espero que isto vos tenha ajudado a alargar o vosso horizonte Navigator.

• Flutter: Push, Pop, Push
• Pooja Bhaumik - Medium
• Flutter Portugal

Flutter: Push, Pop, Push was originally published in Flutter Portugal on Medium, where people are continuing the conversation by highlighting and responding to this story.

Na Flutter Portugal acreditamos que o conhecimento tem de ser acessível a todos, independentemente do grau de conhecimento de línguas estrangeiras. Assim, vamos lançar uma pequena série de artigos que vão abrangir vários tópicos: Dados persistidos, State Management, Navegação, etc…

Este artigo foi originalmente escrito por Raouf Rahiche com o título “Using SQLite in Flutter” e traduzido com autorização do autor.

Dados persistidos (Persitent Data) são muito importantes para os utilizadores, já que lhes seria inconveniente estar sempre a escrever a sua informação ou esperar que a rede carregue os mesmos dados novamente. Nestas situações, o melhor seria guardar os seus dados localmente.

Neste artigo, vou demonstrá-lo, usando SQLiteem FLutter.

Porquê SQLite?

SQLite é um dos métodos mais populares para armazenar dados localmente. Para este artigo, vamos usar o pacote (package) sqflitepara acedermos ao SQLite. Sqflite é um dos pacotes mais utilizados e atualizados para ligar às bases de dados SQLite no Flutter.

1. Adicionar a dependência ao projeto

No nosso projeto, vamos abrir o ficheiropubspec.yamle procuramos por dependencies. Por baixo de dependencies, adicionamos a última versão do sqflitee path_provider(que podem ser retiradas do pub.dev).

NOTA: Nós usamos o pacote path_providerpara obter o directório comum, como o TemporaryDirectorye ApplicationDocumentsDirectory.

2. Criação de um DB Client

Agora, no nosso projeto, vamos criar um novo ficheiro Database.dart. Neste ficheiro, vamos precisar de criar um singleton.

Porque é que precisamos de um singleton: usamos o padrão singleton para assegurar que temos apenas uma class instance (instância de classe) e que providenciamos um ponto de acesso global a ele.

1- Criação de um construtor privado que possa ser usado apenas dentro da classe:

2- Preparação da base de dados

A seguir vamos criar o objeto da base de dados e fornecer-lhe um getter, que irá criar uma instância da base de dados, se já não tiver sido criada (lazy initialization, inicialização diferida).

Se não houver nenhum objeto atribuído à base de dados, usamos a função initDB para criar a base de dados. Nesta função, iremos obter o directório onde iremos armazenar a base de dados e criar as tabelas que desejamos:

NOTA: O nome da base de dados é TestDBe a única tabela que temos chama-se Client. Se não sabe o que é que está a acontecer, precisa mesmo de ir aprender sobre SQL (Structured Query Language, ou em português, Linguagem de Consulta Estruturada); é mais importante do que água.

3. Criação da Model Class (Classe Modelo)

Os dados dentro da nossa base de dados vão ser convertidos em Dart Maps, por isso, primeiro precisamos de criar as Model Classes com os métodos toMape fromMap. Não vou abordar como é que isto se faz manualmente, para isso poderemos ler este artigo de Poojã Bhaumik.

Para criar as nossas model classes, vamos usar este website. Se ainda não o tem guardado como favorito, deveria mesmo fazê-lo :)

Pode clicar aqui para ver como tudo funciona.

O nosso modelo:

4. Operações CRUD

Criar (Create)

O pacote SQFLitefaculta duas maneiras de lidar com estas operações, usando consultas (queries) RawSQLou o nome da tabela e um mapa que contenha os dados:

Usando rawInsert :

Usando insert:

Outro exemplo usando o maior ID (identificador) como um novo ID:

Ler (Read)

Obter Client através de um ID

No código acima, nós fornecemos a consulta com um idcomo argumento usando o whereArgs. Depois fazemos return ao primeiro resultado se a lista não estiver vazia, caso contrário retornamos null.

Obter todos os Clients com uma condição

Neste exemplo, usamos o rawQuerye mapeamos a lista de resultados para uma lista de objetos do Client:

Exemplo: Apenas obter os Blocked Clients

Atualizar (Update)

Atualizar um Client já existente

Exemplo: Bloquear (block) ou desbloquear (unblock) um Client.

Apagar (Delete)

Apagar um Client

Apagar todos os Clients

Demonstração

Para a nossa demonstração vamos criar uma aplicação Flutter simples para interagir com a nossa base de dados.

Vamos começar com a interface (layout) da aplicação:

Notas:

1- O FlutterBuilderé usado para obter dados da base de dados.

2- O FAB adiciona um cliente aleatório à base de dados quando é clicado.

3- É mostrado um CircularProgressIndicatorse não existirem dados.

4- Quando o utilizador clicar na checkbox, o cliente será bloqueado ou desbloqueado, de acordo com o estado actual.

Agora é bastante fácil adicionar novas funcionalidades, como por exemplo, se quisermos eliminar um cliente quando o item é arrastado (swiped), simplesmente envolvemos (wrap) um widget ListTilecom um widget Dismissibledesta forma:

Para a nossa função OnDismissedvamos usar o fornecedor (provider) da base de dados para chamar o método deleteClient. Como argumento, vamos usar o ID do item.

Refatoração (Refactoring) para usar o padrão BLoC

Fizémos imenso neste artigo, mas numa aplicação no mundo real, manter o estado (state) junto com a UI (User Interface) não é propriamente uma coisa boa. Pelo contrário, devemos sempre mantê-los afastados.

Existem muitos padrões para gerir o estado no Flutter, mas vamos utilizar o BLoC neste artigo por ser muito flexivel.

Criação do BLoC:

Notas:

1- getClientsirá obter os dados a partir da base de dados (tabela Client) assincronamente.Vamos chamar este método sempre que atualizarmos a tabela, daí o motivo para o colocar dentro do corpo do construtor.

2- Utilizamos StreamController<T>.broadcastno construtor para que nos seja possível ouvir (listen) o stream mais do que uma vez. No nosso exemplo não faz grande diferença, visto que só estamos a escutar o stream uma vez, mas é bom considerar casos em que queiramos ouvir o stream mais do que uma vez.

3- Não nos podemos esquecera de fechar o stream. Isto previne que tenhamos derrames de memória (memory leaks). No nosso exemplo, vamos fechá-lo usando o método dispose do nosso StatefulWidget.

Agora, vamos adicionar alguns métodos ao nosso BLoC para interagir com a base de dados:

E isto é tudo quanto ao nosso BLoC!

O nosso próximo passo seria encontrar uma forma de disponibilizar o nosso bloc aos nossos widgets. Precisamos de uma maneira de tornar o bloc acessível a partir de diferentes partes da árvore (tree), de modo a que o consigamos libertar da memória quando não está a ser usado.

Para tal, podemos dar uma vista de olhos a esta biblioteca, por Remi Rousselet.

No nosso caso, o bloc só irá ser usado por um widget de forma a que o possamos declarar e dispor dele do nosso stateful widget.

A seguir, precisamos de usar um StreamBuilder, em vez do FutureBuilder. Isto porque agora estamos a escutar o stream (stream dos clients) em vez de um future.

O último passo seria refatorar (refactor) o nosso código para que chamássemos os nossos métodos a partir do nosso bloc e não diretamente da base de dados:

Aqui está o resultado final:

Finalmente, pode encontrar a origem do código para este exemplo neste repo (veja o setor sqlite_demo_bloc para ver a nova versão após refatorar). Espero que tenham gostado deste artigo.

• Using SQLite in Flutter
• Raouf Rahiche - Medium
• Flutter Portugal

Como usar SQLite em Flutter was originally published in Flutter Portugal on Medium, where people are continuing the conversation by highlighting and responding to this story.

A Flutter Portugal tem o orgulho de anunciar um novo projecto: tradução para português de alguns dos mais visto artigos sobre Flutter ou Dart! Queremos que a informação seja acessível a todos os que queiram criar aplicações ou websites com a nova plataforma da Google, independentemente do seu grau de conhecimento de Inglês.

Fiquem atentos às próximas semanas pois teremos mais artigos a caminho!

Artigo original de Gonçalo Palma, Flutter and the Command Line — a Love Story

Usar um IDE (Ambiente de Desenvolvimento Integrado), como o Android Studio da IntelliJ ou o Visual Studio Code, para desenvolver as aplicações em Flutter, torna as nossas vidas mais fáceis. Com o clique de um botão podemos fazer correr a nossa aplicação, debug (depurá-la), fazer hot-reload, etc… E embora possamos ter teclas de atalho para dispensar o uso do rato, pode ser incómodo ter de mover o rato pelo ecrã. Ou, simplesmente gostamos de usar o
terminal, ou estamos curiosos sobre ele e queremos saber diferentes formas de interagir com o Flutter.

Felizmente, o Flutter vem com um CLI (Interface de Linha de Comando, ILC) que nos permite facilmente fazer as mesmas tarefas que seriam feitas em qualquer IDE, como $ flutter doctor, o qual mostra se tudo correu bem com a nossa Instalação Flutter e verifica as últimas atualizações do repositório Flutter no Github.

Comecemos então a explorar o CLI para ver o que é que podemos usar no dia-a-dia.

Explorando a secção de “Ajuda”

Usar o $ flutter help vai mostrar-nos uma longa e intimidante lista de comandos, tais como analyze, build, channel, clean, create, install, logs, pub e run, cada qual com uma pequena descrição. Mas como podemos usar cada um dos comandos?

Tal como com muitos outros CLI, podemos utilizar o útil argumento -help depois de qualquer comando para que o CLI nos mostre um pequeno ecrã de ajuda.

Neste caso concreto, se utilizarmos o seguinte comando:

$ flutter analyze — watch — no-pub

Iremos analisar o código do projeto atual do Flutter enquanto estamos a analizar continuamente qualquer mudança em todos os ficheiros (continuously, watching the filesystem for changes, -watch ) e sem obter ou atualizar as nossas dependências do pub --no-pub.

Correr os nossos Projetos

Quando estamos a desenvolver uma aplicação seja de que tipo for, aquilo de que um programador necessita é de correr o seu código. Afinal, como é que podemos admirar aquilo que produzimos (ou desesperar de cada vez que um novo bug tenta arruinar o nosso progresso)?

Para tal, tudo o que temos de fazer é usar o simples comando:

$ flutter run

O qual é simples o suficiente de utilizar, certo? Mas, às vezes, podemos ter mais do que um dispositivo (ou simulador) ligado à nossa máquina e, assim, aparece a mensagem de erro seguinte:

Por isso, façamos o que nos é dito e usemos a flag correta para o nosso dispositivo ao utilizar -d <device id>. Assumindo que o ID do nosso dispositivo é emulator-4 , podemos executar o nosso projeto para esse dispositivo ao usar:

$ flutter run -d emulator-4

Agora é que começa a ficar interessante. Digamos que os utilizadores da nossa aplicação, Flavors, e nós, temos pontos de entrada diferentes para a nossa aplicação: main.dart e main_dev.dart para flavors/schemes prod e dev.Como é que podemos executar cada um deles? Usemos o comando -help e procuremos argumentos que nos possam ajudar.

Tal como visto acima, podemos utilizar as flags --flavors e -t para nos poderem auxiliar na escolha de um Flavor e de um entry point (ponto de entrada), respetivamente. Desta forma, podemos ter dois comandos diferentes para executar a nossa aplicação:

$ flutter run -d emulator-4 -t lib/main_dev.dart — flavor dev
$ flutter run -d emulator-4 -t lib/main.dart — flavor prod

Isto vai pôr a nossa aplicação a funcionar! 🚀

Mas… Está a faltar algo.

O Flutter é conhecido pela característica de Hot Reload, à qual podemos aceder com facilidade no nosso IDE preferido, a maior parte das vezes ao clicar num símbolo ⚡. Mas como é que podemos fazer isso com a linha de comandos? A única referência ao hot reload que temos está no argumento --hot, mas este só nos permite ativar ou desativar essa função.

Se prestarmos especial atenção ao output da consola quando executamos a nossa aplicação, vemos que faz menção aos elementos de Hot Reload e Hot Restart. Só que, em vez de usar argumentos designados (named arguments), a linha de comando incita-nos a escrever cada carater de que precisemos.

Então, vamos seguir as suas instruções e clicar em r.

E como podemos fazer Hot Restart? Usando Shift + R

E é isto! Mas, que outras funcionalidades estão escondidas por detrás do comando run? Podemos vê-las ao usar a tecla h.

Então, por exemplo, se clicarmos em p, teremos uma útil sobreposição da UI (Interface do Utilizador, IU) com as diretrizes de construção para cada widget, o que se pode revelar vantajoso quando se tentam solucionar bugs desagradáveis da UI.

(Dica: Esta captura de ecrã foi feita usando a tecla s, o que guarda a imagem no diretório do projeto)

Os channels (canais) Flutter

Outro comando útil do CLI Flutter é a habilidade de mudar o atual canal Flutter. Um canal não é mais do que o ramo git no qual estamos a obter o código da fonte Flutter. Quando é que precisamos de o mudar? Quando estamos a usar ferramentas experimentais, tais como o Flutter Web ou se não podemos esperar que o bug-fix apareça no canal (channel) stable.

Depois de mudarmos o canal através do $ flutter channel master, deveremos sempre usar o comando $ flutter doctor para verificar se as ferramentas Flutter são as corretas ou se precisamos de atualizar a nossa versão do Flutter, o qual podemos fazer ao utilizar $ flutter upgrade.

Logs de Flutter

$ flutter logs -d emulator-4

Este fala por si: mostra os logs (registos) Flutter do dispositivo. Mas não só os logs de Flutter para a aplicação em execução, como também para todas as aplicações que usam o Flutter no dispositivo ligado.

Porque é que isto é útil?

• Pode ajudar-nos a verificar se na versão --release da aplicação (ou até na versão enviada para a App Store/Play Store) existem logs que nos tenhamos esquecido de esconder (pode ler mais sobre isso neste artigo sobre debugPrint).
• Pode ajudar-nos a economizar tempo para ver os logs da aplicação atual, sem necessitar de voltar a correr a aplicação.
• Se, por alguma razão, $ flutter run emite os logs do sistema juntamente com os logs de Flutter, pode abrir um novo separador terminal e executar $ flutter logs para ver apenas os registos Flutter para esse dispositivo.

Criar um Novo Projeto

Correr um novo projeto e mudar o canal de Flutter pode ser bastante divertido, mas tudo isso pode resultar em nada se não tivermos um projeto onde os testar!

Aquando da criação de um projeto, poderemos estar interessados em:

• Dar-lhe um nome;
• Nomear uma organização para o nome do pacote (package) (por exemplo, com.vanethos)
• A linguagem usada para o projeto Android (Kotlin ou Java).
• A linguagem usada para o projeto iOS (Swift ou Objective-C)

Felizmente, podemos encontrar uma solução para cada um deles nos argumentos que se seguem:

Assim, para criar um novo projeto na pasta flutter_cli_test com o prefixo do pacote com.vanethos, nome do projeto clitest e usando Kotlin e Swift, sem o AndroidX, precisamos de utilizar:

$ flutter create — org com.vanethos — project-name flutter_cli_test -a kotlin -i swift flutter_cli_test

E, se não soubéssemos como executar o nosso projeto, o Flutter guia-nos para que o executemos diretamente a partir da linha de comando, o que é bastante bom!

Criar Scripts Personalizados em Bash

Nós sabemos como criar e executar projetos e, se olharmos para a secção de Ajuda, também sabemos como limpar o nosso projeto (usando $ flutter clean).

No entanto, os nossos princípios dizem-nos que, para cada execução do projeto, devemos:

• Limpar o projeto Android
• Limpar o projeto Flutter
• Executar o Flavor dev da nossa aplicação no nosso dispositivo preferido

O que quer dizer que teremos de escrever o seguinte no terminal:

E se conseguíssemos simplesmente escrever um único comando para que a aplicação fosse executada em cada flavour?

No MacOs, poderemos ter de procurar como é que se criam scripts bash. Felizmente, Tania Rascia escreveu um ótimo artigo, no qual podemos ver que, para poder criar um script bash, precisamos de criar um ficheiro onde, na primeira linha, adicionamos o seguinte:
Assim, agora já podemos criar um simples guião bash, ao:

• Criar um ficheiro chamado dev_build.sh (podemos fazê-lo com o comando touch dev_build.sh )
• Adicionar o seguinte ao ficheiro:

Como é que o podemos fazer correr? Simplesmente chamando o ficheiro, usando:
$ sh dev_build.sh

E voilà! Agora podemos, com um só comando, limpar o nosso código minuciosamente e correr a nossa aplicação num Flavor específico!

Dica bónus: Usar o Pubx

Vamos levar o nosso amor pela linha de comando mais longe: queremos procurar pacotes e adicioná-los ao nosso ficheiro pubspec.yaml?

Embora o Flutter não permita isto de origem, podemos confiar na comunidade Flutter para vir ao encontro dos nossos desejos e assim o fez, com o pacote pubx, de Scott Hyndman.

Quer procurar um pacote específico? Use $ pubx search provider

Encontrou um pacote e quer saber mais sobre ele? Use $ pubx view provider

E, finalmente, quer adicionar dependências ao seu ficheiro pubspec.yaml a partir da linha de comando? Facilmente feito com o $ pubx add provider

Conclusão

Passámos por uma breve introdução ao CLI Flutter 💻 .

Cabe-nos escolher se esta é a opção certa para nós, ou não. Talvez gostemos de usar o terminal, talvez apenas queiramos usar o ADI e deixá-lo lidar com ele, ninguém nos deve julgar sobre isso. Porém, é sempre bom conhecer alternativas. Porquê?

• Com a linha de comando podemos executar um projeto sem o abrir
• Podemos facilmente mudar o Canal Flutter
• Podemos analisar o nosso código antes de um grande commit
• Se quisermos testar um novo plug-in/pacote rapidamente, podemos fazê-lo através de:

$ git clone https://github.com/Vanethos/stream_disposable.git
$ cd stream_disposable/examples
$ flutter run

• Pode facilmente criar builds de release para a sua aplicação, através de:

$ flutter build ios
$ flutter build appbundle

• Simplesmente parece fixe.

Digam-nos a vossa opinião! 😄Vão usar? Quais são os vossos comandos preferidos?

• Flutter and the Command Line — a Love Story
• Gonçalo Palma - Medium
• Flutter Portugal

O Flutter e a Linha de Comandos — uma história de amor was originally published in Flutter Portugal on Medium, where people are continuing the conversation by highlighting and responding to this story.