DEV Community: Kokou AGBAVON

Behind every widget, there are an element and almost always a render object.

Kokou AGBAVON — Tue, 19 Sep 2023 08:30:00 +0000

DISCLAIMER: This is a sneak peek of what I learned on my Journey to Dive deep into the Flutter Framework. Everything said here was found on the web and in the Flutter framework project on GitHub. If a concept is incorrectly explained, feel free to mention it kindly in the comments section. To dive deeper into all the concepts introduced here, refer to the sources section.

Widget: the central tower of a Flutter application.

Everything in Flutter is a Widget; it’s the first amendment you must adopt on your journey to becoming a qualified Flutter developer. Widgets help us describe the user interface of our application.

Widgets tree

Every Flutter app is, from some perspective, primarily a tree of widgets. The simplicity of its APIs and the variety of its catalogue make widgets the main element of the framework's attractiveness. From the primary widget in the main file to the last icon, each element that appears on the screen is linked by a tree structure.

To be stateful or not? That's the question.

StatelessWidget is used for part of the user interface that relies only on the properties passed to its constructor. Conversely, StatefulWidget is used for interfaces that can change dynamically or depend on some internal data (aka state).

Talking about StatefulWidget, let's have a quick reminder of the life cycle of a StatefulWidget.

createState: Create the state of the Widget. This method is called whenever a StatefulWidget is being inserted at a location in the widgets tree.
initState: Perform the widget state initialization. This method is called after the widget is inserted into the widgets tree.
didChangeDependencies: Called to notify that at least one of the widget's state dependencies has changed. This method always triggers the rebuild of the widget. It is therefore the ideal place to carry out operations that are too expensive to be included in the body of the build method; and which will be executed at each rebuild.
build: Responsible for building the user interface given a particular location (BuildContext).

At this stage, the Widget is built for the first time. Two methods can trigger a rebuild of the user interface represented by this widget.

setState: This powerful trick helps us rebuild our user interface, to reflect our new state. Internally it notifies the widget that its state object has changed.
didUpdateWidget: This method is called when the widget configuration (e.g. class properties) changes. It helps associate (under certain circumstances) the new widget with the same State object.

A widget's life ends when it is removed from the widget tree, and its resources released.

deactivate: This method is called when the widget is removed from the tree. At this step, the widget can either be reinserted in the tree at another location or removed forever.
activate: This method is called before a widget is reintroduced in the widget tree after its removal.
dispose: It's the last stage. The widget won't be reinserted in the thee, so its resources can be safely released.

Under the hood of a Widget.

The second thing you learn the day you want to dig a little deep under the hood of the framework is that a Widget mainly describes the configuration of an Element. If you take a look at this Element, it is described as the instantiation of a Widget at a particular location in the tree.

Element: the essential companion of every Widget.

An Element is the companion of every widget. It’s responsible for how the view description we provide with our widget is painted and mounted (in our widget tree). It keeps track of where widgets are located in the tree, alongside other widgets.

As we know, widgets are immutable. So when a widget changes (meaning its properties values changed and a rebuild was triggered), there are two cases :

The new widget has the same runtime type and key as the old one: in this case, the element remains associated with the new widget.
Otherwise, the element is removed from our tree, and a new element is created and associated with the new widget. This element can now be mounted in our tree and appear on the screen.

Our Element extends a class that we are more familiar with, BuildContext.

BuildContext: the widget location handler.

He is soberly described as a handler of the location of a widget in the widget tree. In other words, he helps the widget figure out where it is located in the tree of widgets.

It is an abstract class that exposes useful methods and properties (mounted, size., …) about our widget. Each widget has its own BuildContext.
Because it handles the location of a widget in the tree, the BuildContext value associated with a Widget can change over time to reflect the Widget's new location in the tree.

You may have already encountered the warning, that tries to prevent you from accessing the context after an an asynchronous operation. The only way to check if a context is still associated with a widget (i.e. the widget is still mounted in the tree) is to check the mounted property value.

RenderObject : the unsung heroes.

We have stated recently that Element(s) were responsible for rendering Widgets. We omitted to specify that this task is delegated to RenderObject(s). The name of the Component speaks for itself.

To complete this task, the RenderObject component implements layout and painting protocols. RenderObject associated with the Widget is created when it's been inserted in the tree (the createRenderObject method is called to achieve this).
After the object is created, and attached to a slot in the tree, it calls successively three methods :

The performLayout method helps compute the layout of the widget using constraints information provided by the parent widget.
The paint method provides a visual appearance to the widget given a PaintContext (a place to perform draw operations) and an Offset.
The describeSemanticsConfiguration method helps report semantics associated with this object. It’s generally used for accessibility purposes.

After this operation, the Widget appears on the screen. Another method can be called later: updateRenderObject. He is responsible for updating the render object when the associated widget description changes. This method will eventually call the three precited methods, depending on what values that changed.

So many trees

So as we stated, there are three trees in every Flutter application :

The Widget Tree: Contains configurations and descriptions of Elements. In fact, for us as developers, it helps us describe how our application interface, must be rendered.
The Element Tree: Handles lifecycles and arranges widgets into a hierarchy. It’s responsible for placing our widget into a location in the Widget tree. It also associates a rendering object with each Widget that needs it.
The RenderObject Tree: Contains information about widget layouts, and sizing and is responsible for painting.

What if I told you, there are more than three trees? Let's see that next time.

In the next blog post, we will dive into Element and explore its lifecycle.

Sources.

Arrête d’être un·e junior·e

Kokou AGBAVON — Mon, 24 Jul 2023 02:06:57 +0000

Cet article est une traduction d’un article originellement publié sous le nom de Stop being a junior par Kent C. Odds.

Es tu un·e développeur·se junior·e ? Si ta réponse est oui, comment tu sais ? Es ce que parce ton titre dans ton travail actuel c’est : Développeur·se Junior·e ? Ou bien est ce parce que tes collègues font le travail le plus intéressant et tu es souvent cantonné·e aux tâches les plus répétitives ou à résoudre les bugs les plus simples ? Ou simplement tu estimes que tu n’as pas encore assez rouler ta bosse pour pouvoir te débarrasser définitivement de l’appellation Junior·e ?

Peu importe ton positionnement actuel, j’aimerais te dire d’arrêter d’être un·e junior·e. Arrête maintenant. J’ai discuté avec beaucoup de personnes qui commence leur conversation avec moi en disant “Je viens juste de commencer…” ou “Je suis juste un·e junior·e_, …”; ce à quoi je réponds _“C’est génial. Bienvenue dans le monde du développement logiciel.”, pour après découvrir qu’elles travaillent comme développeur·se·s d’applications depuis plus d’un an et demi. C’est quelque chose qui me surprend. Et cela arrive si souvent que j’ai décidé d’écrire un article de blog sur comment se sortir de cet éternelle posture de junior·e et commencer par agir positivement pour sa carrière.

La tech évolue à une grande vitesse

C’est très important de prime abord de dire ceci :

Il n’y a aucune durée minimum que vous devez passer à être un·e développeur·se junior·e avant de pouvoir prétendre à passer ce cap.

Si vous avez déjà entendu ou lu un nombre d’années, sachez que c’est faux.

Une des choses que j’aime le plus dans notre industrie, c’est qu’elle évolue rapidement. Avec à chaque instant une émergence de nouvelles technologies et une amélioration constante de l’existant, cela ne prend pas beaucoup de temps à un·e développeur·se qui se maintient informé·e des avancements dans son domaine, d’atteindre un niveau de connaissance qui rivalise avec ses pair·e·s qui ont plusieurs décennies d’expérience.

Imaginez que le développement logiciel ce soit une montée d'une colline avec un pourcentage de pente constant. Monter la colline depuis la base c'est avoir de l'expérience. Mais les nouveaux développeur·se·s ne commencent pas l'ascension par la base ; ils rejoignent les développeur·se·s expérimenté·e·s là où il·elle·s se trouvent actuellement. Ainsi il ne leur faut pas longtemps pour être dans le rythme ; peu importe depuis combien de temps les autres ont commencé la montée. Oui vous manquerez un peu d'expérience ; vous trébucherez un peu plus. Mais la nouvelle expérience vous l'acquérez ensemble. Mon analaogie n'est pas parfaite, mais je pense qu'elle est instructive.

Bien entendu, il faut reconnaître que les personnes avec des décennies d'expérience possèdent une longueur d'avance sur les autres ; il n'y a pas que des avantages, mais il y en a. Les personnes expérimentées apprennent mieux et plus rapidement les nouveaux outils, bien souvent parce que souvent c'est des anciennes choses que les nouvelles sont tirées (c'est au bout de l'ancienne corde qu'on tisse la nouvelle) ; bien que pas toujours, et être capable de désapprendre est également une aptitude à cultiver. Les développeur·se·s avec du vécu, repèrent plus facilement les problèmes potentiels dans le code, avant qu'ils ne soient critiques parce qu'il·elle·s compris au fil du temps comment les choses marchent dans cet écosystème, et qu'il·elle·s comprennent mieux les contraintes.

Cela dit, les développeur·se·s avec de l'expérience sont également plus réticent·e·s à essayer les nouveaux outils ou technologies, et à l'inverser être plus accroché·e·s à leur manière de faire les choses. La routine ou l'habitude de faire les choses d'une certaine manière peut les amener à faire l'impasse sur de nouvelles fonctionnalités dans les langages et outils. Cela peut leur faire rater la migration vers des changements majeurs dans l'écosystème.

Ce que j'essaie de dire ici c'est que le rythme effréné auquel les changements interviennent dans l'industrie du développement logiciel :

Donne à tout un chacun l'opportunité de devenir un·e expert·e dans certaines technologies assez rapidement.

Et si cette personne est capable de tempérer raisonnablement son enthousiasme avec une compréhension pragmatique des avantages de son manque d'expérience, elle peut avoir un puissant impact dans son travail.

Mon expérience personnelle

Pendant mes études à l’université je faisais des stages en entreprise. Cela m’a permis d’appréhender le domaine dans lequel j’allais évoluer avant même d’être en capacité d’y travailler à plein temps. Donc lorsque j’ai obtenu mes diplômes, j’avais déjà pendant plus d’une année et demi, travaillé comme développeur d’applications à mi temps.

Après l’obtention de mon diplôme, j’ai été embauché en tant qu'ingénieur logiciel en plein temps. Dans mon entreprise, j’avais du mal à me départir de mon statut de junior. Malgré que le fait que toute mon expérience se résumait à ces 18 mois, où je travaillais à mi temps tout en continuant mes études, j’avais l’impression de connaître aussi bien notre architecture logicielle que mes collègues, et cela me semblait injuste d’être cantonné à faire les tâches les moins prioritaires.

Je voyais les tâches avec un challenge architecturelle élevée confié aux développeur·se·s expérimenté·e·s et je voulais également pouvoir être en charge de quelques unes. Toutefois, vu que j’étais encore en période de transition d’étudiant stagiaire à employé à plein temps, j’avais le sentiment que tout le monde me considérait dans l’entreprise d’une certaine façon un peu comme le stagiaire.

Peut être que j’aurais dû énoncé un peu plus clairement mes objectifs et ambitions, mais à ce moment j’ai décidé que la seule voix pour avoir plus de responsabilités était de changer de compagnie ; une compagnie où les gens ne me verraient pas comme le stagiaire, mais juste comme un collègue.

Et c’est ce que j’ai fait. 4 mois après être passé en plein temps, j’ai été recruté par une autre compagnie qui m’offrait une revalorisation salariale (plus de 50%) et 20% de mon temps, je travaillais sur l’architecture de notre code source. C’était indescriptible. Personne ne me voyait plus comme un stagiaire. Dans les faits, j’étais à un cheveu de devenir architecte logiciel dans une entreprise valorisée à plus de 250 millions de dollars, et cela seulement 4 mois après mon diplôme universitaire.

Cela a été un pari gagnant pour eux également. Quand j’ai rejoint la société, elle était engagée dans une migration majeure de leur outil de développement pour le frontend. J’ai joué un rôle clé dans cette migration et c’était à la fin un succès retentissant.

Comment arrêter d’être un·e junior·e ?

Au lieu de réfléchir à comment arrêter d’être quelque chose, pense plutôt à comment faire pour commencer à être quelque chose d’autre.

Que font les développeurs seniors dans ton entreprise ? Fais ça au lieu de faire ce que les développeurs juniors font. Et voilà.

Il est évident que ton entreprise fais plus confiance aux seniors et tu n’as pas envie d’outrepasser tes prérogatives ; mais sois volontaire pour prendre part dans la résolution des tâches plus complexes. Ne serait qu’en demandant à prendre part aux réunions. Prends des notes des zones d’incompréhensions, et pose des questions plus tard. Dans les prochaines réunions, tu pourras contribuer plus activement, et apporter des suggestions. Continues de travailler sur les sujets évoqués dans les réunions à la fin de celles ci.

Évite d’être autoritaire ou impétueux. Vous pouvez acquérir beaucoup de connaissances rapidement, mais soyez conscient qu'acquérir de l’expérience limite l’utilité de ces connaissances. Donc sois respectueux de tes collègues. Trouves les personnes qui accepteront de prendre le temps de répondre à tes questions, et qui te permettront de combler le gap de ton inexpérience à mesure que tu gagnes en compétence.

Utilise à ton avantage le rythme effréné de renouvellement de l’écosystème de la tech et fais toi le porte voix des nouvelles fonctionnalités dans les langages et outils de développement lors des échanges entre toi et tes collègues, quand le cadre s’y prête. Si aucun cadre n’est prévu pour échanger autour de la tech avec tes collègues, sois en l’initiateur.

Sois volontaire pour animer des sessions de Talk lors des rencontres organisées dans les communautés locales de développeurs. Propose toi pour parler des sujets qui te passionnent lors des conférences.

Parle de tes accomplissements, des tâches auxquelles tu as participé et décris quelle était ta contribution ; cela prouvera que tu contribues au delà de ta sphère de simple junior·e. Fais leur penser : “Ce dev est seulement un·e junior·e_, et il_·elle fait ça ? C’est peut-être pas un·e junior·e après tout.”

Fais comprendre à ton manager tes ambitions, tes objectifs et tes attentes en tant que développeur·se. Tu dois exposer clairement et assez tôt à ton·ta responsable, tes objectifs et ton souhait de monter en grade. Il·elle pourra à son tour exprimer les attentes qu’il·elle a envers toi, afin d’être en mesure de te promouvoir à ce rôle.

Continue, jusqu’à atteindre ton objectif

Je n’aime pas la phrase “Fais semblant, jusqu’à ce que cela ne devienne réel.”, mais le résultat recherché y es. L’idée est d’agir au niveau où vous souhaitez être considéré·e, et éventuellement cela deviendra évident que vous êtes réellement à ce niveau.

J’ai senti que je devais quitter l’entreprise avec laquelle j’étais pour atteindre le niveau auquel j’aspirais. J’aurais probablement pu y arriver avec l’entreprise dans laquelle j’étais déjà, si j’avais été plus patient. L’expérience y aurait été différente sûrement si je n’avais pas d’abord été recruté comme étudiant stagiaire. Ceci dit, parfois, si vous ne pouvez tout simplement pas enlever le costume de junior·e là où vous êtes actuellement, vous devez envisager de chercher une autre opportunité.

Conclusion

J’espère que cet article ne dénigre pas la quantité de travail que cela demande de gagner de l’expérience et d’avoir de l’impact dans cet industrie. Pour autant, mon objectif principal est d’inspirer mes compaires à élever leurs ambitions et leurs exigences. Vous êtes capable de plus que vous ne pensez. Je vous le promet.

Vous n’avez plus besoin d’être un·e junior·e. C’est le moment de monter en grade.

Bonne chance.

Will ChatGPT replace StackOverflow?

Kokou AGBAVON — Mon, 05 Dec 2022 07:30:00 +0000

If you are a developer, you already know StackOverflow.

StackOverflow

The site that lets you find best practices for implementing certain features, or the solution to that obscure bug that only happens at 4 am on full moon days. Its takeover by Prosus for 1.8 billion dollars had made people cringe, but it is clear that so far no functionality or change that would degrade the user experience. has not been added.

OpenAI & GPT-3

But, you may be less familiar with OpenAI and GPT-3. OpenAI is an AI research lab, which created GPT, an autoregressive language model that uses deep learning to produce human-like text. GPT-3 (the third iteration of GPT) can absorb billions of references, articles, images and data on different topics and then re-serve them in a form very close to human language.

Several services like Dall-E (a generator of images from text in English) have already been unveiled, the result each time being quite impressive.

GPT-Chat

The latest service launched by OpenAI is GPT-Chat: accessible free of charge, it provides an answer to any type of question, in any field. The answers are each time precise and very detailed, as would be those of an expert in the field.

So when you ask GPT-Chat, how to browse an array of keys & values in JavaScript, here is its answer:

With a supporting example and explanation, the AI tells you the best solution to this common problem in JavaScript. The icing on the cake completes with a second solution.

Comparison GPT-Chat & StackOverflow

So why not systematically use it because unlike StackOverFlow, where you can sometimes be overwhelmed by the number of responses and differing opinions, GPT-Chat offers a complete, detailed solution, with more time running between the answer and the question. After entering your question, a few seconds are enough for the AI to offer you an answer; no need to navigate between several pages, and you have the possibility of directly copying the codes offered.

At the moment I see 3 main downsides to wider adoption:

1. Greater rigor in typed text.

With GPT-Chat, you have to be precise. Because with one word, the answer changes completely. Let's ask the same question as before, but omitting a pronoun.

To find you:

First question: How to iterate over a keys and values array in Javascript?
Second question: How to iterate over keys and values array in Javascript?

The proposed solution is valid only for simple arrays, consisting of a uniform list of elements, and with a little analysis, one can find inconsistency in it, even if the proposition is valid and will not throw exceptions.

Thanks to search engines, this situation is less frequent, because very often they redirect us to the right solution even in the event of a typo, or convoluted sentences.

2 - A less human explanation.

Consider the question with the most votes on StackOverflow.

Why are operations on a sorted array faster than those on an unsorted array?

Here is the answer from GPTChat.

This answer is correct, but nothing more. If we understand the answer, it means that we didn't need to ask the question.

Comparing with the answer on StackOverflow.

Supporting image, the interlocutor first takes the time to pose the general context, with non-technical terms, before gradually bringing the subject back to the initial and final question to deepen the reflection.

Not all answers on StackOverFlow are (and do not need) to be so qualitative and well-detailed. But this example illustrates the interpretation of the question and can modify the way of answering.

The biggest difference is that the AI is not able to determine the level of understanding of the interlocutor to adapt its response. It will probably explain in the same way and with the same terms, the theory of relativity; it does not matter if the interlocutor is a professor/researcher in physics, a student in physics, or a college student who wishes to document himself.

3 - Community, debate & contradictions.

Like it or not, StackOverFlow's greatest strength is its community. The platform is created and operates in such a way as to encourage and encourage the contribution of the greatest number.

On particular themes, the solution depends on many parameters. And this is where the multiple answers, the different opinions and the confrontation are useful because they allow the visitor to situate himself and choose by taking into account all the advantages and constraints of each solution.

The other strong point of StackOverFlow is peer validation. A solution proven and tested by thousands of other developers offers a greater guarantee.

Different use cases.

StackOverFlow will never be dethroned.

Like Copilot, Intellisense, and advanced IDEs, GPTChat (even if it is not limited only to code) is only one more tool, in the increasingly rich palette of tools of the developer. Like any self-learning model, it will learn and self-correct and improve over time.

StackOverFlow, or the GitHub Issues, will always be the best place for the trickier questions that require a less impersonal explanation, or more community endorsement.

But next time, instead of waiting for the magic answer on StackOverFlow for an hour, or days for relatively simple questions (How do I trigger HookConsumerWidget rebuild in Flutter?), ask to GPT-Chat.

Jekyll Blog to Flutter News Application : Part 2 - Data modeling.

Kokou AGBAVON — Mon, 28 Mar 2022 16:30:13 +0000

This is the second article of our series : Blog Website to Flutter News Application.

In the last article we have configured our jekyll blog website to serve all contents throw a single API endpoint.

As said already, at this stage we will assume that you have a fully hosted and functional jekyll project. Otherwise, you can clone this preconfigured repo. If you want to run it on your computer, you need to complete Jekyll installation.

Data modeling.

a. Create your flutter application.

So, obviousely, we need to create a new flutter application. Just run the

flutter create [project]

script (be sure to use a recent version of the flutter sdk).

b. Create & Generate Models for Jekyll Posts API.

There are many ways to communicate with a Restful API in Flutter.

First we need to create the models classes representation of our json objects. In order to speed up this part, we will use the json_to_model package which allows to generate model classes from JSON files. So all we need is to follow the installation instructions and create a jsons directory at the Flutter project root.

This directory will contain 5 files:

📃 blog.json :

{
    "homepage": "",
    "version": "",
    "name": "",
    "description": "",
    "logo": "",
    "last_update": "@datetime",
    "expired": false,
    "favicon": "",
    "url": "",
    "disqus": "",
    "email": "",
    "paginate": "",
    "posts": "$[]article"
}

📃 article.json :

{
    "id": "",
    "slug": "",
    "url": "",
    "title": "",
    "date": "",
    "image": "",
    "featured": false,
    "premium": false,
    "sticky": false,
    "author": "$author",
    "read_time": "",
    "date_iso": "@datetime",
    "date_fr": "$date_article",
    "date_en": "$date_article",
    "category_main": "",
    "categories": [""],
    "tags": [""],
    "next": "$article_related",
    "previous": "$article_related",
    "comments": "",
    "summary": "",
    "content": ""
}

📃 article-related.json :

{
    "id": "",
    "slug": "",
    "url": "",
    "title": "",
    "image": "",
    "author": "$author",
    "read_time": "",
    "date_fr": "",
    "date_en": "",
    "category_main": "",
    "tags": [""],
    "type": "@enum:post"
}

📃 author.json :

{
    "name": "",
    "avatar": "",
    "display_name": "",
    "gravatar": "",
    "email": "",
    "site": "",
    "twitter": "",
    "social": "",
    "instagram": "",
    "bio": ""
}

📃 date-article.json :

{
    "day": "",
    "month": "",
    "year": "",
    "complete": ""
}

After this, execute the command flutter pub run json_to_model. A directory named models with all models classes will be created. The most useful part of each classes, is the fromJson method generated which we will use to convert JSON to model object.

This is an example of the method body for the article model :

factory Article.fromJson(Map<String,dynamic> json) => Article(
    id: json['id'].toString(),
    slug: json['slug'].toString(),
    url: json['url'].toString(),
    title: json['title'].toString(),
    date: json['date'].toString(),
    image: json['image'].toString(),
    featured: json['featured'] as bool,
    premium: json['premium'] as bool,
    sticky: json['sticky'] as bool,
    author: Author.fromJson(json['author'] as Map<String, dynamic>),
    readTime: json['read_time'].toString(),
    dateIso: DateTime.parse(json['date_iso'] as String),
    dateFr: DateArticle.fromJson(json['date_fr'] as Map<String, dynamic>),
    dateEn: DateArticle.fromJson(json['date_en'] as Map<String, dynamic>),
    categoryMain: json['category_main'].toString(),
    categories: (json['categories'] as List? ?? []).map((e) => e as String).toList(),
    tags: (json['tags'] as List? ?? []).map((e) => e as String).toList(),
    next: ArticleRelated.fromJson(json['next'] as Map<String, dynamic>),
    previous: ArticleRelated.fromJson(json['previous'] as Map<String, dynamic>),
    comments: json['comments'].toString(),
    summary: json['summary'].toString(),
    content: json['content'].toString()
  );

c. Setup basic UI layout.

At this stage, we only created some interfaces and used fake data to make them look attractive :

Splash screen : first application page which appears until application loaded successfully.
Home page : Divided into two parts (featured posts and others posts sorted by most recent).
All articles subdivided by category.
Favorited, To Read Later articles and Settings pages.
Article Page.
Search Page.

No fear, I will provide my code implementation of these different pages and features at the end of the article. You will be free to modify and adapt it according to your needs.

Our app UI layout is ready. So let's rock it ! We need to make it communicate with our Jekyll Posts API endpoint.

d. Add Jekyll JSON API integration.

We have our models; so let's them operate with the API.

Let's explain how our application works. After launching the app, we send a GET request to our blog posts API endpoint. Next, we parse our response body to a blog object that contains all of our posts. Then we display the content to the user. This is simple.

In Flutter we need the http package to perform this operation.

 var request = await http.get(
    Uri.parse("https://myawesomejekyllblog.com/api"),
    headers: {"Accept": "Application/json"},
 );

 Blog blog = Blog.fromJson(jsonDecode(request.body));

 List<Article> myPosts = blog.posts;

It was simple wasn't it? With these three lines, and no network or data parsing error, we have all the contents of our blog.

Now that we have our data, we need a bridge that allows us to pass this data to our widgets. It must also, depending on the states of the data (the image of the article is loaded, this article is in the favourites, etc.) or the events (click on an article, the user is no longer connected to a network , ...) perform specific actions (consult the content of an article, reload the rest of the articles in the list, ...).

This in Flutter is called state management. The next chapter in our series will try to cover this great area (with a specific plugin, Riverpod).

In the meantime, you can clone the Jekyll blog, and the Flutter project if you want to dig into the code a bit.

So, what's your thoughts at this step ?

Jekyll Blog to Flutter News Application : Part 1 - Introduction.

Kokou AGBAVON — Tue, 15 Mar 2022 06:07:37 +0000

Introduction

Like the title indicates, in this series of articles, we will reach into the steps for convert an existing Jekyll Blog Website to a fully functional Flutter Mobile app. I will do my best to be as clear as possible, but some passages may be blurry because I am at the same time improving my English.

So let's began.

The content of these articles will be divide into three main parts.

Jekyll blogging website and GitHub pages.
Communication between the application and the website via Jekyll JSON Posts API.
User interface and features of the Flutter mobile app.

I will not dwell on some topics, such as setting up Github Pages or customizing a Jekyll blog, because that is not the purpose of this article.

Part 1.

1. Jekyll Blogging and GitHub Pages.

Jekyll + GitHub Pages is one of the best couples to quickly set up a blog without significant financial investment. I started blogging with Jekyll without knowing a single Ruby syntax. I cloned a repository and started customizations.

For those who use other blogging / CMS platforms, I will soon write other articles covering the same path, but starting from Wordpress, GetPublii...
In the rest of the article we will assume that you already have a Jekyll blog hosted online or locally.

If you don't have a Jekyll blog, but you want to follow the tutorial till the end, just clone a free template from Bootstrap Starter. You will customize it later. I particularly like Mediumish.

At this step, i assume that you have a forked a Jekyll blog on GitHub. To host your pages with GitHub just go to your repo settings, section GitHub pages. You can activate hosting there and even setup custom domain name. By default GitHub associate your blog page to your github account ([username].github.io).

You are not limited to GitHub ; if you prefere GitLab, you can use instead GitLab Pages.

2. Communication between the application and the website via Jekyll JSON Posts API.

The best way to make a mobile app communicate with a web service is to create a RESTful API. As with the Jekyll blog, the content is generated once when changes are detected, we do not need to configure a web service. All we need is a JSON endpoint which at all times contains all the blog information such as all the articles and other useful data.

To achieve this, we need to have a little knowledge of how the Jekyll template works and the layout architecture. We also need to deepen our knowledge of Liquid filters.

For this tutorial we will use this model :

---
layout: null
permalink: /api/
#So your API will be accessible at <mydomain>/api
# newline_to_br - replace each newline (\n) with html break
# replace - replace each occurrence e.g. {{ 'foofoo' | replace:'foo','bar' }} #=> 'barbar'
# prepend - prepend a string e.g. {{ 'bar' | prepend:'foo' }} #=> 'foobar'
# append - append a string e.g. {{ 'foo' | append:'bar' }} #=> 'foobar'

---


{
    "homepage" : "{{ site.baseurl }}",
    "version"  : "1",
    "last_update" : "{{ site.time | date_to_xmlschema }}",
    "name": {{ site.name | smartify | jsonify}},
    "description": "{{ site.description }}",
    "logo": "{{ site.logo }}",
    "expired": false,
    "favicon": "{{ site.favicon }}",
    "url": "{{ site.baseurl }}",
    "disqus": "{{ site.disqus }}",
    "email": "{{ site.email }}",
    "paginate": "{{ site.paginate }}",
    "authors": {{ site.authors | jsonify}},
    "posts" : [{% for post in site.posts %}
        {
        "id":"{{post.id | slugify: "latin"}}",
        "slug":"{{post.title | slugify}}",
        "url":"{{site.baseurl}}{{post.url}}",
        "media":"MEDIA_NAME",
        "title":"{{post.title}}",
        "featured":{%if post.featured == nil || post.featured == '' %}false{% else %}{{post.featured}}{% endif %},
        "premium":{%if post.premium == nil || post.premium == '' %}false{% else %}{{post.premium}}{% endif %},
        "date":"{{post.date}}",
        "image":"{{ site.baseurl }}/{{post.image}}",
        "author":{{site.authors[post.author] | jsonify}},
        "read_time":"{{post.content | number_of_words | divided_by:180 }}",
        "date_iso":"{{ post.date | date_to_xmlschema }}",
        "date_en"     : {
            "day"   : "{{ post.date | date: "%d" }}",
            "month" : "{{ post.date | date: "%B" }}",
            "year"  : "{{ post.date | date: "%Y" }}",
            "complete"  : "{{ post.date | date: "%B, %d %Y" }}"
         },
         "date_fr"     : {
            "day"   : "{{ post.date | date: "%d" }}",
            "month" : {% assign m = post.date | date: "%-m" %}{% case m %}{% when '1' %}"Janvier"{% when '2' %}"Février"{% when '3' %}"Mars"{% when '4' %}"Avril"{% when '5' %}"Mai"{% when '6' %}"Juin"{% when '7' %}"Juillet"{% when '8' %}"Août"{% when '9' %}"Septembre"{% when '10' %}"Octobre"{% when '11' %}"Novembre"{% when '12' %}"Décembre"{% endcase %},
            "year"  : "{{ post.date | date: "%Y" }}",
            "complete"  : "{{ post.date | date: "%d" }} {% assign m = post.date | date: "%-m" %}{% case m %}{% when '1' %}Janvier{% when '2' %}Février{% when '3' %}Mars{% when '4' %}Avril{% when '5' %}Mai{% when '6' %}Juin{% when '7' %}Juillet{% when '8' %}Août{% when '9' %}Septembre{% when '10' %}Octobre{% when '11' %}Novembre{% when '12' %}Décembre{% endcase %} {{ post.date | date: "%Y" }}"
         },
        "category_main" : "{{post.categories | first }}",
        "categories" : {{post.categories | jsonify }},
        "tags" : {{post.tags | jsonify }},
        {%if post.next == nil %}"next" : {}, {% else %}"next" : {
            "id":"{{post.next.id | slugify: "latin"}}",
            "slug":"{{post.next.title | slugify}}",
            "url":"{{site.url}}{{post.next.url}}",
            "title":"{{post.next.title}}",
            "image":"{{site.baseurl}}/{{post.next.image}}",
            "author":{{site.authors[post.next.author] | jsonify}},
            "read_time":"{{post.next.content | number_of_words | divided_by:180 }}",
           "date_iso":"{{ post.next.date | date_to_xmlschema }}",
            "date_fr"     : "{{ post.next.date | date: "%B, %d %Y" }}",
             "date_en"     : "{{ post.next.date | date: "%d" }} {% assign m = post.next.date | date: "%-m" %}{% case m %}{% when '1' %}Janvier{% when '2' %}Février{% when '3' %}Mars{% when '4' %}Avril{% when '5' %}Mai{% when '6' %}Juin{% when '7' %}Juillet{% when '8' %}Août{% when '9' %}Septembre{% when '10' %}Octobre{% when '11' %}Novembre{% when '12' %}Décembre{% endcase %} {{ post.next.date | date: "%Y" }}",
            "category_main" : "{{post.next.categories | first }}",
            "type":"{{post.next.layout}}",
            "tags" : {{post.next.tags | jsonify }}
        }, {% endif %}
        {%if post.previous == nil %}"previous" : {}, {% else %}"previous" : {
            "id":"{{post.previous.id | slugify: "latin"}}",
            "slug":"{{post.previous.title | slugify}}",
            "url":"{{site.url}}{{post.previous.url}}",
            "title":"{{post.previous.title}}",
            "image":"{{site.baseurl}}/{{post.previous.image}}",
            "author":{{site.authors[post.previous.author] | jsonify}},
            "read_time":"{{post.previous.content | number_of_words | divided_by:180 }}",
           "date_iso":"{{ post.previous.date | date_to_xmlschema }}",
            "date_fr"     : "{{ post.previous.date | date: "%B, %d %Y" }}",
             "date_en"     : "{{ post.previous.date | date: "%d" }} {% assign m = post.previous.date | date: "%-m" %}{% case m %}{% when '1' %}Janvier{% when '2' %}Février{% when '3' %}Mars{% when '4' %}Avril{% when '5' %}Mai{% when '6' %}Juin{% when '7' %}Juillet{% when '8' %}Août{% when '9' %}Septembre{% when '10' %}Octobre{% when '11' %}Novembre{% when '12' %}Décembre{% endcase %} {{ post.previous.date | date: "%Y" }}",
            "category_main" : "{{post.previous.categories | first }}",
            "type":"{{post.previous.layout}}",
            "tags" : {{post.previous.tags | jsonify }}
        }, {% endif %}
        "comments"   : "",
        "summary":{{post.excerpt | smartify | jsonify }},    
        "content":{{post.content | jsonify }}
    } {% unless forloop.last %},{% endunless %}
    {% endfor %}
    ]
}

So basically, this API returns blog information (logo, homepage, email, pagination, authors ...), saved in the Jekyll configuration file (_config.yml).
Some information may seem unnecessary or redundant, such as the link to the homepage or the name of the blog. But they can be useful when you want to convert multiple blogs into one app.

The most important thing then is to get all the articles. This is done with this syntax {% for post in site.posts %}, which goes through all the articles.
Apart from the basic information like the title, the URL, the date of the article, the image, the category, the tags, the summary and the content, we also collect some information which will be useful later:

premium field will be used to Configure Google Ads service.
*The previous * and * next * fields contain information on other articles related to this article.
disqus field will helps us setup comments section with Disqus platform.
Fields formatted like date_lang are useful for internalization in a simplier way. You can also do it, in Flutter with date_iso field and throw package like intl.

⚠️ You can name this file as you see fit, but it must obligatorily end with the .json extension to force Jekyll engine to render it as a JSON file and not as a HTML one. I named mine simply as posts_api.json. This is how it looks when the API is implemented.

3. User interface and features of the Flutter mobile app.

So based solely on the number of stars on GitHub, Flutter is one of the most popular mobile app development platforms in recent years.

Flutter 2 was announced recently and offers some very interesting features, so we will be using this version. To follow and understand the features that will be used in this part, you don't need to be a Flutter expert. One year ago, I had never written Dart code.

So, here are the features we will develop:

Jekyll JSON API Modeling & Integration.
Link the app to a specific domain name (this is for those who have setup a custom domain for their blog).
Limit app data usage (with caching & image backup).
Offline mode.
Integration of Google Ads & Facebook Network Audience.
State management with Riverpod.
Night Mode.
Comments section with Disqus.
Internationalization.
Push Notifications.

A single article cannot cover all of these features and implementations. This tutorial will therefore be divided into several parts with the complete implementation of at least one feature per part.

So see you in the next chapter of this series to learn how to :

Create our flutter application.
Setup models according to our Jekyll Blog Posts API.
Connect our models with the hosted API.
Dynamize our interfaces by connecting it with the data received from the API.
Manage our application states with Riverpod.

As already said, this is my first technical write. So feel free to reach me if something is not clear and to give advice so that future articles will be even more useful and understandable.