7om Tech

Newton Evolution

Tue, 30 Dec 2025 08:00:00 +0000

Recently I received an email from a developer asking me if he could take over the maintenance of Newton Particles. On one side I was happy cause someone was interested enough to keep the flame of Newton, on the other hand, I was thinking “damn” I have so many features I still want to implement to make Newton a rockstar particle library. If you read my previous post I had quite hell for 2 years building a poker app for Betclic. Now I’m moving to another project, I wanted to enjoy the calm of the end of the year to get back to work on Newton.

Today I’m happy to announce Newton 0.3.0 is released.

Particles interaction with Widgets

Now particles can interact with your app widgets. For example, if you want your particles to bounce off your buttons, it’s doable and easy. Just use a NewtonCollider and wrap your widget with it and that’s all:

Newton(
  effectConfigurations: [RainPreset().toConfiguration()],
  child: Stack(
    children: [
      NewtonCollider(
        borderRadius: BorderRadius.circular(20),
        child: Container(
          width: 200,
          height: 100,
          decoration: BoxDecoration(
            borderRadius: BorderRadius.circular(20),
          ),
        ),
      ),
    ],
  ),
)

Your browser does not support the video tag.

Copy code from configurator

From the beginning you can directly test building an animation with the configurator. There are still some limitations, you cannot add a post effect animation but now you can directly copy the code when you are satisfied with an animation.

Introduction of Presets

To be honest my main concern when developing Newton was to have a highly configurable but also easy to use library. The first objective seems to be met but not the second one. You needed to tweak 30+ properties to get the perfect animation. Having presets allows you to have a good starting point to start an animation. If you have an idea for animations feel free to open a PR.

Newton(
  effectConfigurations: [
    RainPreset().toConfiguration(),
  ],
)

API coherence

The configuration API was a bit messy. You had properties scattered around and it wasn’t always clear where to find what you needed. I reorganized everything into logical groups like PhysicsProperties, VisualProperties, EmissionProperties, and so on. It makes the code more type-safe and easier to navigate.

I also renamed RelativisticEffect to PhysicsEffect because let’s be honest, the name was confusing.

Performance improvements

I pushed Box2D to reach the limits from 150 to nearly 300 particles with constant FPS. I won’t be able to go further with Box2D but to be honest I’m not satisfied…

But I did add viewport culling, which means particles outside the visible area are automatically removed from calculations. This helps a lot when you have particles flying off screen. I also optimized the rendering pipeline and improved how colliders report their positions to reduce unnecessary work.

There’s also a new particle pool system that reuses particles instead of constantly creating and destroying them. It’s more memory efficient and should help with performance on lower-end devices.

What’s next

To be honest when I started this library I wanted to be able to have 1000+ particles to be able to add really neat and unique animations to your app. Box2D seems to have reached a hard cap and I’m investigating other engines to reach this goal.

If you have ideas or want to help with this investigation, feel free to jump in. I’m also open to suggestions for new presets or features that would make Newton even better.

You can check out the full documentation at https://newton.7omtech.fr/ and the source code on GitHub. As always, feedback and contributions are welcome!

All-in on Flutter

Tue, 09 Dec 2025 01:00:00 +0000

One year ago, almost to the day, the new Betclic poker experience was released: the result of months of hard work, risk-taking, and a whole lot of Flutter magic.

And now, on this anniversary, it feels like the perfect moment to share my personal perspective on that journey. I even considered making a video, before remembering that I actually have a blog… one that’s been gathering dust for over a year. Time to bring it back to life.

So, I sat down, opened a blank page, and began retracing the journey.

Let me tell you the incredible story of Project Codename: Mowgli.

Preambule

Once upon a time, a young and adventurous Android developer living in Paris decided to go on a world tour with his girlfriend.

We took our first flight on June 2022, and flash forward nine months later, we were in Kuala Lumpur, Malaysia. That’s when my existential crisis started:

What do I want to do?
Where do I want to live?

The second question was easy, we really wanted to move to Bordeaux to escape the crazy life of Paris.
But the first one… that was tougher.

Did I want to become a doctor, raise sheep in the Pyrenees, or become a fucking awesome blacksmith forging magical swords and hunting deadly monsters?

None of those felt right. After 15 years of building Android apps, I came to a surprising realization: I had never released an app on the App Store.

I really, really (I’d add another really) didn’t want to learn Swift, and even less did I want to work with Xcode.
Then an idea popped up: Hey, it’s been a while since you checked out Flutter.

Within two weeks, I had built and released Factify on both the Play Store and the App Store, complete with ads and premium subscriptions. Honestly, it took more time to create my developer accounts and get the app validated than to actually build it.

That release gave me a sense of satisfaction I hadn’t felt in a long time.

Destiny is sometimes funny

A week after releasing my app, a friend of mine (an ex-colleague and biker), reached out to catch up. During our chat, he told me he was about to work on a Flutter app. The subject was confidential, but the real pain point was that the company wasn’t in Paris but in… (let me build some suspense)… Bordeaux!

So literally, a project was starting in September, on a technology I liked, in the exact city where I wanted to live.

My interview was scheduled for May, and I literally did it in a small hotel room in South Korea. The only info I could get was that the client, Betclic, wanted to build an “app-like game.”

A week later, I got the news: I’d be starting on the project in September.

In my spare time, after sightseeing during the day, I decided to dive deeper into Flutter. I started learning Flame and even created a particle animations library to better understand how things worked. That’s how Newton was born.

(And as of today, I still have a few features I’d love to add to this package.)

The beginning

On June 2023, it was time to go back home. I had mixed feelings, something was ending, but we were happy to see our family and start a new life.

After spending some time with our close ones, it was time to move to Bordeaux. We managed to find a flat quite quickly and, on September 4th, it was my first day. I signed the NDA and finally got to know a bit more about the project.

Betclic wanted to build a Poker app from the ground up in one year.
Yes, you read that correctly: one year to build an app (front and back) available on iOS, Android, macOS, and Windows.

In my head, I thought: Crazy… but ok, let’s fucking do it.

The project had already begun exploring what technologies we were going to use and what was doable with Flutter. But in September, we had the real kickstart. We were working in a separate building to preserve the NDA, and only a few people at Betclic even knew what was going on.

For the front-end team, two guys were already there: “Flute de Paon” (“Peacock Flute”) and “Pipo” (I’ll use Flute names to preserve the anonymity of my colleagues).

The First Steps

Our very first feature was… the login.
We could log into the app and land in the lobby, where, eventually, the poker offer would be developed.

Then we started implementing the game itself. We decided not to use Flame since it wasn’t really a video game, but instead went for a Flutter Casual Game Toolkit.

The communication with the game server relied on a websocket, so everything was bidirectional: we could receive events but also send commands to the server.

We started by implementing the first type of game, now called Spin & Rush.
It’s a short poker format where three players compete for the prize pool.

In the very first version, there was no prize pool, no lobby, the only action you could do was check.

Your browser does not support the video tag. Your browser does not support the video tag.

Then we added call, raise, resolution, and so on.

From app to Framework + Desktop

In October, while we were actively working on the core game, a big question came up:
How will the app be released on mobile?

At first, we thought it would be a standalone app.
But we quickly realized it could actually end up being a framework embedded in the iOS and Android native apps.

This had a huge impact. Some features, like login or account management, aren’t necessary on mobile since they’re already handled by the native apps, but they are still required on Desktop.

So, in a single day, we went from a single-app project to a multi-module project with two apps. The framework and the Desktop app, both packaging only the features they need.

We set up Melos and followed this architecture:

The goal was to limit interdependencies between modules and ensure we ended up with an acyclic graph of modules when packaging the apps.

Our main layers were structured as follows:

Utilities: All the non–Betclic-specific code. The rule of thumb was simple: if we could open-source it, it belonged here
Foundations: Core, non-UI components, mainly responsible for interacting with the Betclic platform
Features: As the name suggests, this layer contained the actual app features
DSM: The design system module, holding all the design tokens and assets shared across features. This is also where we defined reusable UI components
Composition: The layer where we started assembling pieces of the application, mainly handling routing and theming
Apps: The final layer, adding the last touches to routing and handling app-level configuration

After this decision we got back on track. In November Flutakouliss arrived. In December Santa Claus brought us the Y. The A-team was complete.

One table to rule them all

One of the main challenges when developing a mobile/desktop app is ensuring a single design works seamlessly across all devices. This was especially critical for our Poker Table experience.

To achieve this, we needed a reference screen. For us, it was the iPhone 14.
Our designer created the full table design, opponents, hero (your avatar and actions), board, etc. Once we had that, we turned it into a Table Specification, where every component was placed relative to the table itself.

When rendering the Poker Table on any mobile screen, we first compute the maximum available space (removing insets, navigation bar, etc.). From there, we calculate the largest box that preserves the table’s aspect ratio. Once that box is defined, it’s simply a matter of scaling.

At runtime, we determine the table size by multiplying the scale factor with the Specification, and we apply the same principle for relative positions.

In the end, we created three specifications:

Mobile Portrait
Mobile Landscape
Desktop

Each specification supports three layouts: 3-max, 6-max, and 9-max.

Adding other layouts is absolutely possible, we just need to extract the specifications from Figma, but these nine configurations have been enough for us.

As of today, we don’t have a way to fully automate this process, even though it’s technically doable.

iPhone 13 mini

iPhone 14

iPhone 16 Pro Max

Not ready

As the start-of-August deadline was approaching, reality hit us hard: we weren’t ready. End of story.

Fortunately, we got some extra time and the deadline was pushed to September. The final go/no-go decision, however, was set for December.

By then, the Poker Table had to be fully animated, and we also needed to support Omaha, a poker variant with four cards in hand and its own specific rules.

To be able to meet the deadline the A-Team was completed with “Picolo” in June and “Flutella” in October.

From FlutterAnimate to Rive

Animating widgets in Flutter is really easy, but it can also become really verbose.

Our first animations were done using flutter_animate. We even had a dedicated file storing all the animations for table elements (opponent cards, chips, etc.). That file was… well, let’s just say it was HUGE, thousands of lines, hard to maintain, and the animations didn’t really have that “wow” effect.

In September, we made a bold decision: migrate all our animations to Rive.
Cards, capsules, chips, most of our table elements became Rive components.

At the time, Rive was still really new (version 0.12), but it showed a lot of promise. With Rive, motion designers can create the animations they want and provide a state machine that developers can interact with.

For example, the capsule containing a player’s name has a state machine that lets us define its state: waiting, playing, or folded. All we need to do as developers is set the right state, and Rive takes care of the rest.

The magic is that we can update not just text at runtime, but also images. Even our cards became Rive objects, resulting in some really cool animations (see video below).

But great animations weren’t the only requirement: they also had to be controlled by the game server.
Since we’re building a real-time game, a user with a bad connection might otherwise end up with less time to play their animation.

We solved this with a simple approach: the game server tells us how much time we have to play an animation.

Take the reveal of the Flop as an example:

The reveal normally takes 500ms.
The game server sends us the end timestamp when the animation should finish (including extra latency buffer).
When the Flutter app receives the event, it computes how much time is left before the deadline.

If the time remaining is less than 50% (250ms), we skip directly to the end. Otherwise, we simply speed up the animation.

We ended up implementing a tailored animation system where a widget can receive animation events for a given target.

For example:

Our KoCenterWidget, which displays the big KO animation when eliminating a player in a PKO tournament, listens for animations on KoTarget.
When it receives an animation event, it computes a ratio that defines the animation speed.

The pseudo-code is as simple as:

@override
Widget build() {
  return Rive.widget(
    speed: speed,
  )
}

@override
Future<void> playAnimation(Animation<KoCenterAnimationType, KoCenterAnimationTarget> animation) async {
  setState(() {
    _viewModel // This a viewmodel from Rive using databinding
      ..colorLevel = animation.type.bountyLevel.toDouble()
      ..triggerStart();
  });
}

Our animation system is responsible to compute and fire animation events with the right speed. The speed is applied directly to the rive Animation. As you can see the result is really cool:

Your browser does not support the video tag. Your browser does not support the video tag.

Release Hell

The release date was finally set for December 9th, 2024, right in the middle of my holidays.
I promise, it wasn’t planned.

That morning, after a scheduled maintenance, we flipped the switch and Mowgli went live.

It didn’t take long before our servers went down.
After a few days of intense work, the platform was finally stable.

On the front-end side, we had some bugs, but nothing major. What we really wanted was feedback.

The poker community delivered, they were genuinely happy, loved the product, and were super excited, as you can see in this image:

Well… that was in my dreams and not worth to translate.

In reality, we got a lot of complaints.
No dark mode, no sounds, the app was crap. The poker community hit us hard.

It wasn’t the first time I’d released an app with major design and behavior changes. At Zenly, we did it twice. Both times people were disappointed and angry, but both times the number of users exploded right after.

When reading these kinds of comments, you shouldn’t take them personally. Instead, you need to understand what’s really causing the anger.

In our case, people weren’t happy about losing some features, but the feedback that came up over and over again was:

Dark theme
Sounds
Buggy animations
Ability to choose the deck color

In less than two weeks, all of these features/bugs were shipped.

That’s the power of mastering your code.

Finally some love

After a few weeks, we started to see more and more positive reviews popping up.
As expected, our user base grew, and grew a lot!

Month after month, we kept beating our own records:

number of users
number of games
and more.

We even started to take some market share from our main competitors, who had been in the poker field much longer than us.

At Betclic, we really care about what our users think of our products. We even set up a Discord with our most active players, where they can report bugs and share feedback.

As a developer, it’s always fascinating to see what users like, what they don’t, and what they’d love to have.

And now?

We keep adding really cool features that unfortunately I can’t talk about for now.
I have so many topics I could dive into, from our move from Rive to Rive Native, to multi-window support, performance tricks, weird crashes, or even how we managed near-monotonic time for animations. I may write dedicated articles on those subjects.

In the meantime, I wanted to share my feedback on working with Flutter.

First, I’d like to thank the Flutter community. It’s rare to find such a kind and motivated group of people. Everyone I interacted with was eager to help. The community is also incredibly active: whenever you think “I’d love to do this, maybe there’s a package for it”, there almost always is!

My team was also amazing, deeply dedicated to creating the best poker app and experience. Flutter itself delivered as well: we managed to maintain a single codebase for two apps and a framework. There’s still room for improvement, but honestly, as of today no other framework, not even KMP, delivers at Flutter’s level.

Big up to the Rive team. We had the chance to work closely with them, and their passion really shines through. Rive rocks, and I highly recommend giving it a try on your projects.

Of course, there are some frustrations too. The Flutter build system can be limiting, I miss Gradle from Android, especially for handling module variants. We worked around it with scripting (e.g. stripping out mobile-only assets when building desktop and vice-versa), but native support would be great.

Coming from the Android world, I was used to one big release a year. With Flutter, multiple releases per year are great, but the first release of a cycle often introduces new bugs. Usually, you need to wait for one or two patches for stability. Luckily, we never hit a dead end: rollback was always an option, and Flutter being open source makes a huge difference. You can even build your own version of Flutter if necessary, something I could never do with Android, where some bugs had no fix other than a painful workaround.

From our perspective, Windows support still lags behind macOS in quality. Considering Windows is (unfortunately) the most widespread OS, I’d love to see more effort from the Flutter team or Windows experts to improve this area.

All in all, after 15 years in tech, seeing the rise and fall of countless technologies, I can tell you this: there is no silver bullet. Every approach has its pros and cons, the key is making sure the upsides outweigh the downsides.

In our case, Flutter absolutely did.

I’ll dedicate more time to being involved in the Flutter community.

From the deep blue of my heart, I hope you enjoyed this article as much as I enjoyed writing it.

Flutterly yours,
Traversiere

The hiring bottleneck: why I built TestReviewer.ai

Sat, 06 Dec 2025 01:00:00 +0000

I did the math recently, and honestly, it was depressing.

If you are a Tech Lead, you know the struggle: your calendar looks like a game of Tetris where you are losing. Instead of building apps, I found myself constantly reviewing them.

The workflow is a killer. You stop your actual work, pull a repo, and pray that running the candidate’s code doesn’t hijack your local environment (a genuine security risk these days).

My colleagues and I tried using LLM prompts to speed things up, but that only solved the reading part, not the process. HR was still chasing us on Slack, the Tech team was swamped, and candidates were left in the dark.

I realized we didn’t just need a code analyzer; we needed a tool to bridge the gap between the Recruiter, the Candidate, and the Technical Evaluator.

Enter TestReviewer.ai

Today, I am launching TestReviewer.ai in Early Access.

The goal is simple: HR shouldn’t waste time chasing feedback, and Tech shouldn’t waste time on setup and basic code review.

I built a flow that respects everyone’s time.

Step 1: The Setup - The recruiter creates a test (e.g., “Senior Android Developer”), creates a candidate profile, and sends the test link. No friction.

Step 2: The Submission - The candidate opens the link, completes the task, and uploads a Zip file or a Git link.

But here is the “magical” part: We also allow candidates to upload a video walkthrough. If you’ve ever reviewed a UI/Frontend test, you know that code doesn’t tell the whole story. Seeing the dev explain their choices in a video? That’s a game changer.

Step 3: The Analysis - Before a human ever looks at the code, our tool analyzes the project for security concerns, anti-cheat, and project quality.

Step 4: The Feedback - The tech team receives a detailed report. They don’t need to run the code locally to know if it’s secure or functional. They get a deep analysis, add their final feedback, and the recruiter gets the green light to hire (or pass).

Why different?

The project is in the early stages, but the vision is to save you money and time immediately.

Most ATS platforms charge you a fortune in monthly subscriptions for seats you don’t use. I hate that model.

TestReviewer.ai is pay-per-completed-review. You don’t pay for idle seats; you only pay when you are actually interviewing.

I need your eyes on this

I’m launching this today, slightly under the radar, because I want honest feedback.

If you are a Recruiter tired of bottlenecks, or a Dev tired of reviewing messy code, give it a spin.

Check it out here: https://testreviewer.ai

If you find a bug, or if you think a feature is missing, join our Discord or shoot me a mail at hi@testreviewer.ai.

Happy reviewing,

CSS-like Gradient in Flutter

Sun, 21 Jul 2024 08:00:00 +0000

In one of my recent projects, we encountered the challenge of integrating gradients, but not the usual linear or radial types—this time, it was elliptical gradients. An elliptical gradient is essentially a radial gradient altered with a matrix transformation. However, accurately translating these from Figma into Flutter proved challenging; while the CSS code rendered perfectly, Flutter’s code generation didn’t quite hit the mark. Here’s a glimpse of what the CSS version looked like:

.radial-gradient {
    background: radial-gradient(60% 45% at 50% 50%, rgba(1, 246, 187, 0.80) 0%, rgba(1, 246, 187, 0.00) 100%);
    height: 400px;
    width: 200px;
}

It looks like this:

Given the complexities, we decided to develop an API that would allow us to easily implement the gradient using the same parameters.

To tackle this, we first dissected the CSS command:

radial-gradient(60% 45% at 50% 50%, rgba(1, 246, 187, 0.80) 0%, rgba(1, 246, 187, 0.00) 100%);

Breaking it down, it’s pretty straightforward:

60% 45% defines the ellipse dimensions relative to the container’s width and height.
50% 50% positions the center of the ellipse in the middle of the container.
The color stops transition from a semi-transparent green to fully transparent.

Now, let’s translate this into Flutter code:

EllipticalGradient(
  backgroundColor: Color(0xFFFFFFFF),
  ellipseRelativeCenter: const Offset(0.5, 0.5),
  ellipseScale: const Scale(widthFactor: 0.6, heightFactor: 0.45),
  colors: [
    Color(0xFF01F6BB).withOpacity(0.8),
    Color(0xFF01F6BB).withOpacity(0),
  ],
  stops: const [0.0, 1.0],
)

For the implementation, rather than creating a custom shader—which would be overkill—we utilized Flutter’s RadialGradient and applied a GradientTransform. This method modifies only the gradient’s appearance without altering the entire canvas.

Here’s the core of our EllipticalGradient class:

class EllipticalGradient extends Gradient {
  final Color backgroundColor;

  /// This offset is relative to top left of the widget, [0,0] means top left and [1,1] bottom right.
  ///
  /// The range is not limited to [0,1] for both x and y axis.
  final Offset ellipseRelativeCenter;
  final Scale ellipseScale;

  const EllipticalGradient({
    required super.colors,
    required this.backgroundColor,
    required this.ellipseRelativeCenter,
    required this.ellipseScale,
    super.stops,
  });

  @override
  Shader createShader(Rect rect, {TextDirection? textDirection}) {
    return RadialGradient(
      center: Alignment(
        ellipseRelativeCenter.dx * 2 - 1,
        ellipseRelativeCenter.dy * 2 - 1,
      ),
      colors: colors
          .map((color) => Color.alphaBlend(color, backgroundColor))
          .toList(),
      radius: 1,
      stops: stops,
      transform: _EllipseTransform(
        ellipseRelativeCenter: ellipseRelativeCenter,
        ellipseScale: ellipseScale,
      ),
    ).createShader(rect, textDirection: textDirection);
  }

  @override
  EllipticalGradient scale(double factor) {
    return EllipticalGradient(
      backgroundColor: backgroundColor,
      colors: colors
          .map<Color>((Color color) => Color.lerp(null, color, factor)!)
          .toList(),
      ellipseRelativeCenter: ellipseRelativeCenter,
      ellipseScale: ellipseScale * factor,
    );
  }
}

There are 3 important things to note in the previous code:

This operation ellipseRelativeCenter.dx * 2 - 1 is just to ensure our align value will be between -1 and 1. -1 meaning start and 1 end of the view.
The radius property is 1, this property is quite tricky cause the radius is percentage of the shortest side. Let’s imagine we have a box of width 300px and height 200px the size of the radial gradient will be 200px. (This behavior will have an impact on how we compute the width and height factor)
Last but not least we blend the background color with gradients color so the final result looks like there is a ColoredBox behind our gradient without the need of a Stack

Now comes the “Mathematical” part. The signature of the transform method is:

@override
Matrix4? transform(Rect bounds, {TextDirection? textDirection})

The initial step involves determining the correct dimensions for width and height, guided by the widthFactor and heightFactor. Given that the radius is set to 1, the radius of the radial gradient will equal the length of the shortest side of the container. Consequently, we must accurately adjust these size factors to maintain the desired proportions of the elliptical gradient:

final double widthFactor;
final double heightFactor;
if (bounds.width > bounds.height) {
  heightFactor = ellipseScale.heightFactor;
  widthFactor = ellipseScale.widthFactor * bounds.width / bounds.height;
} else {
  heightFactor = ellipseScale.heightFactor * bounds.height / bounds.width;
  widthFactor = ellipseScale.widthFactor;
}
final transformMatrix = Matrix4.identity()..scale(widthFactor, heightFactor);

Once the size factors and the transformation matrix are initialized, the next challenge is to accurately position the ellipse. This is the most intricate part of the process. Initially, we determine the ellipse’s position as though no transformation has been applied. Subsequently, we calculate the center’s position using the scaled matrix. The discrepancy between these values indicates the necessary translation of the matrix. It’s crucial to note, however, that this offset is influenced by scaling, so you must adjust the translation by dividing the scaled offset by the respective size factors. With these adjustments, the ellipse will be perfectly positioned.

final Offset originalCenterOffset = Offset(
  bounds.left + bounds.width * ellipseRelativeCenter.dx,
  bounds.top + bounds.height * ellipseRelativeCenter.dy,
);

final List<double> offsetLocation = transformMatrix.applyToVector3Array([originalCenterOffset.dx, originalCenterOffset.dy, 0.0]);
final dx = originalCenterOffset.dx - offsetLocation[0];
final dy = originalCenterOffset.dy - offsetLocation[1];
return transformMatrix..translate(dx / widthFactor, dy / heightFactor);

You can play with this dartpad to see how it behaves.

I won’t create a dart package just for this class, so if you feel it could fit your needs, feel free to copy/paste this code, but don’t forget to like the article if you do so ;).

Last but not least, while implementing this behavior I opened my first bug on Impeller, which was since fixed by the Flutter team. Thanks guys, keep the good work!

Cheers

Newton: Captivating Flutter Particle Effects

Sun, 06 Aug 2023 08:00:00 +0000

I was playing around with the Flutter casual game toolkit and the confetti animation caught my eye. Wouldn’t be cool to easily achieve this kind of effect in a flutter app? Today, i’m eager to introduce:

Newton is a highly configurable particle emitter package for Flutter that allows you to create captivating animations such as rain, smoke, explosions, and more. With Newton, you can easily add visually stunning effects to your Flutter applications.

Rain	Smoke	Pulse	Explode	Fountain

Installation

To use Newton, simply add it as a dependency in your pubspec.yaml file:

dependencies:
  newton_particles: use the latest version

Then, run flutter pub get to fetch the package.

Usage

Import the Newton package:

import 'package:newton_particles/newton_particles.dart';

Create a Newton widget and add it to your Flutter UI with the desired effects:

Newton(
    // Add any kind of effects to your UI
    // For example:
    activeEffects: [
        RainEffect(
            particleConfiguration: ParticleConfiguration(
            shape: CircleShape(),
            size: const Size(5, 5),
            color: const SingleParticleColor(color: Colors.black),
        ),
    )
],
)

Enjoy the doc

A complete documentation is available here, you’ll find out how to create custom effects and all the configuration properties.

What’s come next is even better!

Configure your effect

Newton provides an effect configurator to help you tweak the effects and achieved the desired result:

Feedback

The lib is still wip, don’t hesitate to give your feedback directly on github.

Really hope you’ll enjoy adding cool effects to your app. If you would like specific effects let me know!

Flutter: Translucent Navigation

Sun, 04 Jun 2023 15:04:23 +0000

While working on Factify Facts, I wanted to have a translucent navigation (status and navigation) for an immersive design in light and dark mode. Flutter provides everything you need to achieve this goal. However having a smooth experience on Android requires some adjustments. Let’s dive in!

Quick Takeout

If you are just interested by the solution, everything is available here. All commits are organized so you can understand the progression.

Setup the Sample

First we will need to define a simple light and dark theme:

import 'package:flutter/material.dart';

class AppTheme {
  ThemeData light() {
    var colorScheme = ColorScheme.fromSeed(
      seedColor: Colors.red,
      brightness: Brightness.light,
    );
    return ThemeData(
      brightness: Brightness.light,
      appBarTheme: AppBarTheme(
        backgroundColor: colorScheme.inversePrimary,
      ),
      colorScheme: colorScheme,
      useMaterial3: true,
    );
  }

  ThemeData dark() {
    var colorScheme = ColorScheme.fromSeed(
      seedColor: Colors.red,
      brightness: Brightness.dark,
    );
    return ThemeData(
      brightness: Brightness.dark,
      appBarTheme: AppBarTheme(
        backgroundColor: colorScheme.inversePrimary,
      ),
      colorScheme: colorScheme,
      useMaterial3: true,
    );
  }
}

As you can see nothing fancy, we will also need a theme provider to notify when the theme is switching from light to dark:

import 'package:flutter/widgets.dart';

class ThemeProvider extends ChangeNotifier {
  bool _darkMode = false;

  bool get darkMode => _darkMode;

  set darkMode(bool value) {
    if (_darkMode != value) {
      _darkMode = value;
      notifyListeners();
    }
  }

  void invertCurrentThemeMode() {
    darkMode = !darkMode;
  }
}

To finish, the app will just have an AppBar, a text with the current theme, and a floating action button to invert the theme:

@override
Widget build(BuildContext context) {
  return Consumer<ThemeProvider>(builder: (context, themeProvider, child) {
    SystemChrome.setEnabledSystemUIMode(SystemUiMode.edgeToEdge);
    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            const Text(
              "The current theme is :",
            ),
            Text(themeProvider.darkMode ? "Dark" : "Light"),
          ],
        ),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: () {
          themeProvider.invertCurrentThemeMode();
        },
        tooltip: 'Invert current theme mode',
        child: const Icon(Icons.change_circle),
      ),
    );
  });
}

The SystemChrome.setEnabledSystemUIMode(SystemUiMode.edgeToEdge) means that the navigation bar and status bar will be drawn on top of the application.

When playing on the emulator we could imagine that everything is working fine:

Gesture navigation

However some devices do not use the gesture navigation, and if you change the settings to display the navigation bar:

System navigation bar not translucent

The result is quite ok but not what we really expect.

Going Translucent

The easiest way we can find on Internet to go translucent is to call this method:

SystemChrome.setSystemUIOverlayStyle(const SystemUiOverlayStyle(
  systemNavigationBarContrastEnforced: false,
  systemNavigationBarDividerColor: Colors.transparent,
  systemNavigationBarIconBrightness: themeProvider.darkMode ? Brightness.light : Brightness.dark,
  systemNavigationBarColor: Colors.transparent,
));

We can see different parameters we need to adjust:

systemNavigationBarContrastEnforced -> this one means that the system “may” add a contrast color in order to ensure the navigation bar is visible. We want to be fully transparent so better to deactivate it.
systemNavigationBarDividerColor -> let define the color of the divider located a the top of the system navigation bar.
systemNavigationBarIconBrightness -> as you decided to override the contrast property, you need to apply the right brightness for the system bar navigation icons. Light brightness for dark mode and dark for light mode.
systemNavigationBarColor -> this one is pretty obvious.

Let’s go back to the emulator:

Navigation bar icons brightness issue

As you can see the system navigation bar is transparent BUT the icon brightness is not updating properly.

Introducing AnnotatedRegion

To solve this issue you need to use an AnnotatedRegion, this will ensure the layer tree will use the updated SystemUiOverlayStyle. I will write a dedicated post to explain in details why you need to do this.

@override
  Widget build(BuildContext context) {
    return Consumer<ThemeProvider>(builder: (context, themeProvider, child) {
      return AnnotatedRegion(
          value: SystemUiOverlayStyle(
            systemNavigationBarContrastEnforced: false,
            systemNavigationBarDividerColor: Colors.transparent,
            systemNavigationBarIconBrightness: themeProvider.darkMode ? Brightness.light : Brightness.dark,
            systemNavigationBarColor: Colors.transparent,
          ),
          child: Scaffold(...

System navigation bar is translucent on Android 29+

Job is done, I finished my day! Hold on, hold on, does it work for all API levels? Let’s test on api level 28.

System navigation bar not working on Android 28 and less

Hmm not working as expected. The reason behind this issue is quite simple and can be found in the documentation of SystemUiMode.edgeToEdge.

/**
 * Available starting at SDK 29 or Android 10. Earlier versions of Android 
 * will not be affected by this setting.
 */

This means that the app will not be drawn below the system navigation bar if API level < 29.

Faking Translucence

To be able to have a similar design for all API levels there is a simple trick. We are going to have the system navigation bar the same color as the background only for API levels < 29. As i don’t like to have reference to sdk levels in my code, i will have a DeviceFeature wrapper class that will let me know if the edgeToEdge feature is available.

For this i’ll need to use the device_info_plus plugin:

import 'dart:io';

import 'package:device_info_plus/device_info_plus.dart';

class DeviceFeature {

  DeviceFeature._internal();

  static final DeviceFeature _singleton = DeviceFeature._internal();

  factory DeviceFeature() {
    return _singleton;
  }

  final _deviceInfoPlugin = DeviceInfoPlugin();

  AndroidDeviceInfo? _androidDeviceInfo;

  Future<void> init() async {
    _androidDeviceInfo = await _deviceInfoPlugin.androidInfo;
  }

  bool isEdgeToEdgeAvailable() {
    return Platform.isAndroid && _androidDeviceInfo != null && _androidDeviceInfo!.version.sdkInt >= 29;
  }
}

The final code for our AnnotatedRegion becomes:

@override
Widget build(BuildContext context) {
  return Consumer<ThemeProvider>(builder: (context, themeProvider, child) {
    final edgeToEdgeAvailable = DeviceFeature().isEdgeToEdgeAvailable();
    final navigationBarColor = edgeToEdgeAvailable
        ? Colors.transparent
        : Theme.of(context).colorScheme.background;
    return AnnotatedRegion(
        value: SystemUiOverlayStyle(
          systemNavigationBarContrastEnforced: false,
          systemNavigationBarDividerColor: Colors.transparent,
          systemNavigationBarIconBrightness: themeProvider.darkMode ? Brightness.light : Brightness.dark,
          systemNavigationBarColor: navigationBarColor,
        ),
      ...

Tadaa everything works fine for all API levels!

System navigation bar working on Android 28 and less

Theme is Everything

Even if everything is working well, there is something i can’t get rid off my head. I don’t like to have theme attributes hard coded in my UI. Isn’t there a better way to handle this issue?

There is a systemOverlayStyle attribute in the AppBarTheme. We can leverage this and define everything at the theme level.

import 'package:flutter/material.dart';
import 'package:flutter/services.dart';

class AppTheme {
  ThemeData light(bool edgeToEdgeAvailable) {
    var colorScheme = ColorScheme.fromSeed(
      seedColor: Colors.red,
      brightness: Brightness.light,
    );
    return ThemeData(
      brightness: Brightness.light,
      appBarTheme: AppBarTheme(
        backgroundColor: colorScheme.inversePrimary,
        systemOverlayStyle: SystemUiOverlayStyle(
          statusBarIconBrightness: Brightness.dark,
          statusBarColor: Colors.transparent,
          systemStatusBarContrastEnforced: false,
          systemNavigationBarContrastEnforced: false,
          systemNavigationBarDividerColor: Colors.transparent,
          systemNavigationBarIconBrightness: Brightness.dark,
          systemNavigationBarColor:
              edgeToEdgeAvailable ? Colors.transparent : colorScheme.background,
        ),
      ),
      colorScheme: colorScheme,
      useMaterial3: true,
    );
  }

  ThemeData dark(bool edgeToEdgeAvailable) {
    var colorScheme = ColorScheme.fromSeed(
      seedColor: Colors.red,
      brightness: Brightness.dark,
    );
    return ThemeData(
      brightness: Brightness.dark,
      appBarTheme: AppBarTheme(
        backgroundColor: colorScheme.inversePrimary,
        systemOverlayStyle: SystemUiOverlayStyle(
          statusBarIconBrightness: Brightness.light,
          statusBarColor: Colors.transparent,
          systemStatusBarContrastEnforced: false,
          systemNavigationBarContrastEnforced: false,
          systemNavigationBarDividerColor: Colors.transparent,
          systemNavigationBarIconBrightness: Brightness.light,
          systemNavigationBarColor:
              edgeToEdgeAvailable ? Colors.transparent : colorScheme.background,
        ),
      ),
      colorScheme: colorScheme,
      useMaterial3: true,
    );
  }
}

As you can see we also have to define the status bar color and contrast enforcement to have a smooth integration for status and navigation bar. Now our main build is as simple as:

@override
Widget build(BuildContext context) {
  return Consumer<ThemeProvider>(builder: (context, themeProvider, child) {
    final edgeToEdgeAvailable = DeviceFeature().isEdgeToEdgeAvailable();
    final themeMode =
      themeProvider.darkMode ? ThemeMode.dark : ThemeMode.light;
    final appTheme = AppTheme();
    SystemChrome.setEnabledSystemUIMode(SystemUiMode.edgeToEdge);
    return MaterialApp(
      title: 'Translucent Navigation',
      themeMode: themeMode,
      theme: appTheme.light(edgeToEdgeAvailable),
      darkTheme: appTheme.dark(edgeToEdgeAvailable),
      home: const MyHomePage(title: 'Translucent Navigation'),
    );
  });
}

I hope you enjoyed this article. Don’t hesitate to leave a comment or ask questions!

If you could give your feedback about Factify Facts either on Product Hunt or by direct message it would be awesome!

May Flutter be with you!

Becoming Apple Developer: The Hard Way

Mon, 22 May 2023 15:04:23 +0000

I‘ve been an Android Developer for almost 10 years now, recently I was playing around with Flutter and was struck by a personal fact: “I’ve never published a personal mobile application on the stores”.

Well… in my previous jobs I was responsible for publishing releases, but I had never built and released a personal project on stores. This year, I decided things were going to change and built an app about fun/interesting facts. Factify Facts was born and it was time to release it on the stores (iOS and Android). I already own a PlayStore developer account but no Apple Developer Account. Spoiler alert: becoming an Apple Developer was not a ”Piece of Cake“.

Updating my Apple Id

I got the first macbook during my studies thanks to the Apple student program and it was looking like this:

At that time I used a hotmail.com mail address to register. For the youngest one it was the ancestor of outlook (damn I feel old). This hotmail mail address became by default my Apple Id. For my developer account, I wanted to update this Apple Id to use my gmail account instead. Once updated on appleid.apple.com, I logged in again on my mac and everything was working well.

So far so good, I downloaded the Developer app from AppStore to start enrollment. Upon logging in, the app was requested the password for my hotmail account and not my gmail account. Long story short I ended in state where I could enter my new Apple Id and password but a dialog was popping later requesting my password for my old account. None of the password was working, so I was totally stuck.

I reverted my change on appleid.apple.com back to my hotmail account and everything went back to normal.

Ok Apple, I will use my hotmail account!

Enrolling with Developer App on Mac

I started the enrollment within the Developer app. The first step was to take a picture of an Id card with the front camera of the mac. I used my driving licence, took a sharp picture and my first name ended up being Amomas and not Thomas. For some reason you can’t edit the fields to correct them and you can’t go back…

I contacted Apple Support, two days later the support had reset my personal information. In the mail, support confirmed that It was not possible to continue the enrollment in the Developer app. I had to finish it on the web.

Dead ending

I started over the enrollment on the web, completed all the step. On the last page, I was excited to click on the submit button and become an Apple Developer. The excitement became incomprehension as soon as I got this error message: Your enrollment in the Apple Developer Program could not be completed at this time. I love this kind of error message cause I have no idea at all what to do: should I try again? is it a temporary error? a server issue?

After having read some Apple community threads, I realized I was not the only one. I checked everything: my credit card, my birthdate, apple agreements, everything…

I ended sending an mail to Apple Support again and 2 days later I got the most epic mail:

Thank you for contacting Apple Developer Program Support.

My name is xxxxx and I am delighted to assist you today.

From your message, I understand that you are still unable to register for the Apple Developer program.

We cannot verify your identity through the Apple Developer app or provide additional support regarding this Apple ID for Apple developer programs.

You can still enjoy great content by using your Apple ID in Xcode to develop and test apps on your own device.

This was the most polite way I had ever seen to tell me: “Your Apple Id is fucked up, we can’t do anything but go play around”

“I WANT TO SUBMIT AN APP” I repeat “I WANT TO SUBMIT AN APP”.

New Apple Id

As I was not using iCloud services, I was ok to create a new Apple Id. Finally, I could use my gmail account! This time I took time to ensure that:

All my personal information was filled on Apple Id website with a valid birthdate (18+)
2FA was enabled and working properly
My credit card information was setup in Apple Id and AppStore app
iCloud services were enabled

Once everything was double (triple) checked, I started over on the web this time. I filled all the information paid 99$ and 2 hours later I got this mail:

Hello Thomas,
Thank you for joining the Apple Developer Program. We’re thrilled to support your work as you bring your ideas to life! As a developer program member, you have access to a comprehensive set of resources to build, test, and distribute innovative apps for Apple platforms.

You would think that the story is over, but noooo…

From Personal to Company Account

Few days later, I was finishing the in-app purchase implementation for my app when I started to wonder: “Wait a minute, how am I going to declare this revenue?” As I became a freelancer earlier this year, there is a rule in France that is: If you own a company in a specific field, you need to declare all revenue from that field

In fact, I must declare my revenue on my freelance company. I contacted Apple Support to request a migration to company account.

Few days later, I got the answer and had to provide following information:

Your organization’s legal entity name in Roman characters
Your organization’s D-U-N-S Number
A valid organization website is required

Thanks to Apple you can enjoy this new website cause at the time of the request it didn’t exist. Regarding DUNS Number, Apple provide a tool to search your company. Don’t pay for your DUNS number!

After everything was setup by mail, I got a call to ensure that I was actually me. Once confirmed that me was me, the migration process started. Two days later I finally got my company developer account.

Summary

As this article started to be a bit longish, I decided to elude the French specific part where I had to fill the W8ben then W8ben-e form for U.S. tax.

It took more time to have my developer account up and ready than developing Factify Facts. The main point to keep in mind when creating your developer account is to check that everything (birthdate, credit card, etc…) is correct. Don’t hesitate to contact support, they honestly did a good job and helped me a lot. Expect a 2 days delay for your answer though.

Finally, for anyone wishing to be an Apple Developer, I wish you good luck!