This post is a continuation of Flet mobile strategy published a few months ago.

Our original approach to Flet running on a mobile device was Server-Driven UI. Though SDUI has its own benefits (like bypassing App Store for app updates) it doesn't work in all cases, requires web server to host Python part of the app and, as a result, adds latency which is not great for user actions requiring nearly instance UI response, like drawing apps.

I've been thinking on how to make Python runtime embedded into Flutter iOS or Android app to run user Python program. No doubt, it's technically possible as Kivy and BeeWare projects do that already.

Current Flet architecture​

The current architecture of Flet desktop app is shown on the diagram below:

Running Flet program on a desktop involves three applications (processes) working together:

• Python runtime (python3) - Python interpreter running your Python script. This is what you are starting from a command line. Python starts Fletd server and connects to it via WebSockets.
• Fletd server (fletd)- Flet web server written in Go, listening on a TCP port. Fletd holds the state of all user sessions (for desktop app there is only one session) and dispatches page updates and user generated events between Python program and Flet client.
• Flet client (flet) - desktop app written in Flutter and displaying UI in a native OS window. Flet client connects to Fletd server via WebSockets.

The architecture above works well for Flet web apps where web server is essential part, but for desktop it seems redundant:

• If all three processes run on the same computer WebSockets could be replaced with sockets or named pipes with less overhead.
• Fletd server has no much sense as there is only one user session and UI state is persistently stored in Flet desktop client which is never "reloaded".

Flet new desktop architecture​

Flet desktop app architecture can be simplified by replacing Fletd with a "stub" written in Python and communicating with Flet desktop client via sockets (Windows) and named pipes (macOS and Linux):

Flet mobile architecture​

Mobile applications are running in a very strict context with a number of limitations. For example, on iOS the app cannot spawn a new processes. Other words, Flet Flutter app cannot just start "python.exe" and pass your script as an argument.

Luckily for us, Python can be embedded into another app as a C library and Dart (the language in which Flutter apps are written) allows calling C libraries via FFI (Foreign Function Interface).

Additionally, while Android allows loading of dynamically linked libraries iOS requires all libraries statically linked into app executable. This article covers Dart FFI in more details, if you are curious.

Flet mobile architecture could look like this:

Python runtime will be statically or dynamically linked with Flutter client app and called via FFI and/or named pipes.

Running Python on mobile will have some limitations though. Most notable one is the requirement to use "pure" Python modules or modules with native code compiled specifically for mobile ARM64 architecture.

Asyncio support​

Asyncio is part of Python 3 and we start seeing more and more libraries catching up with async/await programming model which is more effective for I/O-bound and UI logic.

Currently, Flet is spawning all UI event handlers in new threads and it's also a pain to see threading.sleep() calls hogging threads here and there just to do some UI animation. All that looks expensive.

Using of async libraries from a sync code is possible, but looks hacky and inefficient as it keeps CPU busy just to wait async method to finish. So, we want a first-class support of async code in Flet app.

Async/await model is a state machine switching between tasks in a single thread. By going async Flet will able to utilize streams for socket server and use async WebSockets library library. It will be possible to use both sync and async event handlers in a single Flet app without any compromises or hacks.

Even more exciting, async Flet will be able to run entirely in the browser within Pyodide - Python distribution based on WebAssembly (WASM). WebAssembly doesn't have multi-threading support yet, so running in a single thread is a must. Just imagine, Flet web app with a truly offline Flet PWA that does not require a web server to run a Python code!

Development plan​

We are going to crunch the scope above in a few iterations:

1. Async API support with async WebSockets library. Works with the same Fletd in Go.
2. Fletd server ("stub") in Python to use with a desktop.
3. Embedding Python with Fletd "stub" and user program into iOS.
4. Embedding Python into Android.
5. Packaging mobile apps for iOS and Android.

Hop to Discord to discuss the plan, offer help, ask questions!

Flet is a fast-evolving framework with a new functionality and bug fixes being committed every other day.

The development model with one pull request per release didn't work well for the project as users waited for weeks to get hands on a new release and, honestly, from development perspective producing large "heroic" releases takes a lot of energy 🫠.

From now on we'll be breaking releases into multiple pull requests with one feature/bugfix per PR.

Every PR merged into main branch will be publishing pre-release (developmental release) package to pypi.org having version format of X.Y.Z.devN.

Installing pre-releases​

To install Flet pre-release package use the following command:

pip install flet --pre

Flet versioning​

Flet is switching to Semanting Versioning with a version number MAJOR.MINOR.PATCH:

1. MAJOR will be incremented when there are "incompatible API changes". Right now it's 0 and we expect to make it 1 when we feel that Flet API is stable enough.
2. MINOR will be incremented when a new functionality added in a backwards compatible manner.
3. PATCH will be incremented when we make backward compatible bug fixes.

According to that rule, upcoming Flet release will have version 0.2.0. Bug fixes for that release will be labeled as 0.2.1, 0.2.2, etc. The release after that release will be 0.3.0 and so on.

Flet pre-releases will have a format of MAJOR.{LAST_MINOR + 1}.0.dev{BUILD} where LAST_MINOR is MINOR version of the last release and {BUILD} is a build number set by CI. For example, if the last published release is 0.1.65 pre-releases will have versions 0.2.0.dev{BUILD}. Pre-releases after 0.2.0 release will be labeled as 0.3.0.dev{BUILD}.

We just released Flet 0.1.65 which is adding a bunch of mobile-optimized controls, fixing some bugs and introducing a new layout control - ResponsiveRow.

ResponsiveRow control​

ResponsiveRow borrows the idea of grid layout from Bootstrap web framework.

ResponsiveRow allows aligning child controls to virtual columns. By default, a virtual grid has 12 columns, but that can be customized with ResponsiveRow.columns property.

Similar to expand property every control now has col property which allows specifying how many columns a control should span. For example, to make a layout consisting of two columns spanning 6 virtual columns each:

import flet as ft

ft.ResponsiveRow([
    ft.Column(col=6, controls=ft.Text("Column 1")),
    ft.Column(col=6, controls=ft.Text("Column 2"))
])

ResponsiveRow is "responsive" because it can adapt the size of its children to a changing screen (page, window) size. col property in the example above is a constant number which means the child will span 6 columns for any screen size.

If ResponsiveRow's child doesn't have col property specified it spans the maximum number of columns.

col can be configured to have a different value for specific "breakpoints". Breakpoints are named dimension ranges:

For example, the following example collapses content into a single column on a mobile device and takes two columns on larger screens:

import flet as ft

ft.ResponsiveRow([
    ft.Column(col={"sm": 6}, controls=ft.Text("Column 1")),
    ft.Column(col={"sm": 6}, controls=ft.Text("Column 2"))
])

Here is more elaborate example of responsive layout:

import flet as ft

def main(page: ft.Page):
    def page_resize(e):
        pw.value = f"{page.width} px"
        pw.update()

    page.on_resize = page_resize

    pw = ft.Text(bottom=50, right=50, style="displaySmall")
    page.overlay.append(pw)
    page.add(
        ft.ResponsiveRow(
            [
                ft.Container(
                    ft.Text("Column 1"),
                    padding=5,
                    bgcolor=ft.colors.YELLOW,
                    col={"sm": 6, "md": 4, "xl": 2},
                ),
                ft.Container(
                    ft.Text("Column 2"),
                    padding=5,
                    bgcolor=ft.colors.GREEN,
                    col={"sm": 6, "md": 4, "xl": 2},
                ),
                ft.Container(
                    ft.Text("Column 3"),
                    padding=5,
                    bgcolor=ft.colors.BLUE,
                    col={"sm": 6, "md": 4, "xl": 2},
                ),
                ft.Container(
                    ft.Text("Column 4"),
                    padding=5,
                    bgcolor=ft.colors.PINK_300,
                    col={"sm": 6, "md": 4, "xl": 2},
                ),
            ],
        ),
        ft.ResponsiveRow(
            [
                ft.TextField(label="TextField 1", col={"md": 4}),
                ft.TextField(label="TextField 2", col={"md": 4}),
                ft.TextField(label="TextField 3", col={"md": 4}),
            ],
            run_spacing={"xs": 10},
        ),
    )
    page_resize(None)

ft.app(target=main)

ResponsiveRow docs, example.

Other new controls​

This release adds new visual and non-visual controls requested by Flet community and also required to build UI of the upcoming Flet Studio.

BottomSheet​

Shows a modal Material Design bottom sheet:

BottomSheet docs, example.

NavigationBar​

Bottom Navigation bar which offers a persistent and convenient way to switch between primary destinations in an app:

NavigationBar docs, example.

Tooltip​

A tooltip control:

Tooltip docs, example.

HapticFeedback​

Allows access to the haptic feedback (clicks and vibrates) interface on the device.

HapticFeedback docs.

ShakeDetector​

A control to detect phone shakes. Based on shake widget.

ShakeDetector docs.

Other improvements​

Markdown code syntax highlight​

Sample code.

Variable fonts support​

Flutter has finally supported variable fonts and we bring that into Flet too!

Sample code.

Upgrade Flet module to the latest version (pip install flet --upgrade) and let us know what you think!

Enjoy!

We are thrilled to introduce Matplotlib and Plotly charting controls in Flet 0.1.63!

Matplotlib and Plotly are the most recognized Python charting libraries with a ton of features. They are greatly compatible with other scientific Python libraries such as Numpy or Pandas.

No doubt, it would be nearly impossible to replicate their functionality as pure Flutter widgets. Fortunately, both Matplotlib and Plotly can export charts into various formats, such as SVG. On the other hand Flet can display SVG images and that gives a perfect combination - Flet charting controls for Matplotlib and Plotly!

The resulting solution works so great that it's possible to display almost any example from Matplotlib and Plotly galleries - your imagination is the only limit!

Plot a simple bar chart:

a nice scatter with legend:

or some multi-chart contour plot:

Check the docs for Matplotlib and Plotly charting controls:

• MatplotlibChart
• PlotlyChart

Explore Flet chart examples.

Learn Python libraries by examples:

• Matplotlib gallery
• Plotly gallery

In the future releases, we may add an interactive "toolbar" for Matplotlib charts by implementing a custom backend. Or maybe it's a great exercise for Flet users? 😉

Also, when it's time for Flet to support other languages we would need to re-visit charting to make it language-agnostic as the current charting implementation relies on Python libraries.

Upgrade Flet module to the latest version (pip install flet --upgrade), integrate auth in your app and let us know what you think!

Enjoy!

We've just released Flet 0.1.62 with support of gestures processing!

There is a new control - GestureDetector which allows handling all sorts of gestures: single and double taps with a left (primary) and right (secondary) mouse (pointer) buttons, vertical, horizontal and bi-directional drags, zoom (pinch-in and pinch-out) gestures as well as hover events. Now, by wrapping it into GestureDetector, you can make any Flet control "clickable" and "draggable"!

Here is a simple example of an app which allows you to drag containers inside a Stack:

import flet as ft

def main(page: ft.Page):
    def on_pan_update(e: ft.DragUpdateEvent):
        e.control.top = max(0, e.control.top + e.delta_y)
        e.control.left = max(0, e.control.left + e.delta_x)
        e.control.update()

    gd = ft.GestureDetector(
        mouse_cursor=ft.MouseCursor.MOVE,
        on_vertical_drag_update=on_pan_update,
        left=100,
        top=100,
        content=ft.Container(bgcolor=ft.colors.BLUE, width=50, height=50, border_radius=5),
    )

    page.add( ft.Stack([gd], expand=True))

ft.app(target=main)

Gesture detector is yet another great addition to a collection of Flet primitives that allows you to build apps limited only by your imagination. 2D drawing coming later this month is going to complete that ensemble!

That release wasn't about only gestures though - that was a "stabilization" release too. We fixed a number of bugs and added a bunch of other small features which you can see here.

Upgrade Flet module to the latest version (pip install flet --upgrade), integrate auth in your app and let us know what you think!

Enjoy!