Flutter Vikings - Day 2

After a great first day of Flutter Vikings conference in Oslo, let's dive into the second day with the conferences I have seen !

The cookbook of Flutter testing

Teresa Wu started this talk by stating that the might important thing about test might not be a very high code coverage (or at least that aiming for it was not absolutely necessary) but that instead we should aim at doing proper testing.

She then described the different kinds of tests that we can think about in an app :

• Behaviour Driven Testing (BDD) with TDD
• Unit tests (for data and domain)
• Acceptance testing (for domain)
• End-to-end and snapshot testing

She particularly insisted on BDD testing in this talk as it might be the less well-known and yet a very important one. Different steps are BDD were described as follows :

1. Discovery story
2. Backlog / User acceptance
3. Example mapping (small meetings to ask all the questions, trying to think about the edge cases, particular scenarios such as failing cases, ...)
4. Gherkin scenario, using a gherkin package in Flutter to actually write the tests in a spoken language

Here is a small example of example mapping :

To end this talk Teresa talked about widget testing, integration testing and also contract testing to make sure APIs clients behave as expected.

Parallel Beauty with Isolates into the Mandelbrot set

Despite a lot of technical difficulties during the talk, Thomas Burkhart still did a great presentation. He first introduced how Dart is multi-threaded even though we tend to think of Dart as a single-threaded language because we usually only use the main thread in an app.
He also explained the differences between single-threading, multi-threading and parallel processing.

After this useful introduction it was time to dive in the code to learn more about Dart Isolates. Although compute() is great to create small isolates, Thomas showed us in great details how you can manually handle isolates : message streams with send and receive ports, how global variables, static variables and parameters are always passed as copies, how to handle a pool of isolates... Very technical and very instructive too, we definitely learnt a lot!

Writing Flutter apps in Lego style

This title was definitely catchy, I had to see what it was really about!

In this recording talk by Anna and Oleksander Leushchenko (unfortunaly Oleksander could not join in person because of the situation going on in Ukraine 🇺🇦 😢), they started by explaining how Lego is so powerful and why you can still today arrange 1970 bricks with 2022 bricks : extreme modularity.

Although code might not be able to reach such a level of modularity, modular programming exists and we might try to use it.

Basically modularity in Dart resides in making modules (duh! ) aka packages (at least to keep things simple), and all the code needs to rely on interfaces.

Anna and Oleksander then started to explain how we can use (de)composition to achieve greater modularity in our code. The first step is to separate our code in three main parts :

• App
• Features
• Core

Each feature will basically be in its own package, core will be for common things such as design system and app will be here to connect all the features together, handle external navigation and such.

They then had a dive at the feature part which is probably where most of the code will be written. Features can be further decomposed into:

• Domain, with models and services
• Dependency Injection
• Configuration, with either local feature flags, remote feature flags or flavors
• Localization, that can either be set through common i18n or through feature-local i18n
• UI and state management for only feature-specific parts. As stated previously shared widgets and design will come from the core package
• Navigation, for the feature-internal part. External navigation will be handled later by the app package
• Tests. As features are very isolated from each other, they are easy to test and should probably tested with BDD (using Gherkin), testing only the entrypoint of the feature as the rest will be called by the feature and is implementation details. Also greater isolation allows for easier testing because the feature can be tested almost without mocks, just adding HTTP interceptors to mock API / backend.

Finally Anna and Oleksander presented various tools to help handling the number of packages, such as Mason to write templates for easier feature package generation and Melos for the "orchestration" part (compiling in a certain order and such).

Building better Bingo backends

In this very fun talk, Frank Van Puffelen and Eric Windmill from the Firebase team took Bingo as an example app for setting a Firestore database (and only that) to create a multi-player app with both clients and host.

They went through the basics of Firestore : how it is document-structured, how it is real-time and you can get snapshots updates as soon as there are changes in the database, how you can use security rules to secure database access (because obvisouly you don't want your clients to be able to touch to the host part) and more features.

Very fun talk while instructive on Firestore basics!

Game Development in Flutter

The last talk I saw on Day 2 was from Filip Hracek where he gave a very honest feedback on Game development when you try to make your own as a personal project (i.e. not working for a big game studio).

In the first part he asked why we, as developers, initially want to develop a game. He took an interesting parallel with movies using a Scorsese quote. Basically, we want to create game because we can do what we want with it, potentially passing a message to players, by taking much more risks than a big studio.

He then explained the various reasons why games fail, often because life happens, or it's just too much work and we lack discipline, or we were stuck on a specific aspect of game design, architectural issue or perf issues. The answer to this was basically to know from the beginning that developing a game is work, it's not just fun all the way.

In the final part he gave some advices to avoid problems stated before. It's okay if it's not beautiful from the very beginning, it's okay if it feels hacky (after all the players don't care!), you can start small and don't need everything done at first. Also, don't reinvent the wheel and finally : try to be your own Product Manager, you have to set boundaries to yourself!

After Filip talk we were close to the end of the Day, but there was a great Q&A session with Dart, Flutter and Firebase teams that answers attendees questions. A great way to get honest answers for the future of Flutter, Dart and Fireb

I must say that it was a great way to end this awesome Flutter Vikings conference.

The end.

...until next year ? 🤞