Alex-min's tech blog

Releasing LiveView native with Flutter preview

Sat, 07 Oct 2023 00:00:00 +0000

I’ve mentioned in my previous post working on a Live View Flutter Client, here is now the open source release!

What is LiveView native?

LiveView native is a new way to build mobile apps with Phoenix LiveView in Elixir. There’s two native clients being built at the moment, one with Swift for the Apple platform (which is basically almost complete) and one in Kotlin mainly targetting Android (which is currently being built).

I wanted a client using Flutter and since nobody made any, I’m building it!

What does it look like?

Here is a sneak peek on my computer of a LiveView with three devices, an Android target, a Linux target and a web target:

Video demo of the live view flutter client

Everything communicates together an all three targets are sharing the same counter !

Where is the code?

The source code is here, happy hacking!

What’s missing?

Pretty much everything is missing at the moment, I need more styling, forms, live interop, hook, themes… The road ahead is pretty long. I have a lot of experience with flutter since I built a full mobile app with it (~30k lines of code) so I know where I’m going. g This is the priorities I’m working on right now:

Implement all LiveView events
All the Flutter components (only a subset are implemented in this demo)
Routing
Making the full Flutter styling API accessible
LiveView hooks with an embed js engine
Themes
…

Stay tuned!

LiveView native with Flutter preview

Mon, 02 Oct 2023 00:00:00 +0000

What is LiveView native?

I wanted a client using Flutter and since nobody made any, I’m building it!

What does it look like?

Here is a sneak peek on my computer of a LiveView flutter client with a simple view:

Video demo of the live view flutter client

It almost look like it’s running with a web browser!

Where is the code?

The full source code will be released as soon as it’s ready, it’s too much of an alpha state now to use it in a production environment.

If you want more news about this upcoming release, please subscribe to the newsletter just below! I will update you regularly.

What’s missing?

This is the priorities I’m working on right now:

Implement all LiveView events
All the Flutter components (only a subset are implemented in this demo)
Routing
Making the full Flutter styling API accessible
LiveView hooks with an embed js engine
Themes
…

Stay tuned!

Improving Flutter latency through sksl automation

Sat, 29 Jan 2022 00:00:00 +0000

Improving Flutter latency through sksl automation

Here’s a demo of the end result, automating the navigation through the whole app:

Video demo of the sksl generation where the app is playing itself

The core issue

Flutter performance is very critical when using production apps. There’s a built-in way to improve performance & reduce jank called sksl shader caching.

Animations can appear laggy the first time you are going through the app. Once the shader cache kicks-in, it becomes faster again, we call this laggy effect rendering jank. This is especially bad on iOS since iOS has a different rendering model which makes the app extra laggy on the shader generation.

Flutter has a built-in command to generate a cached shader file

flutter run --profile --cache-sksl

However, this is very tedious since it requires you to go through the whole app page by page manually and click on the most common screens where you think there’s going to be some animation. The cached file is also built against a specific skia & Flutter version so every time you upgrade Flutter you have to regenerate it by hand. The Flutter team also advises to build two different cache file for iOS and Android, that doubles the amount of manual work on each release.

Let’s automate that boring job with Flutter driver!

Flutter driver is a way to automate taps & navigation through your app by using code. With a single command, the file can generate the shader cache file:

flutter drive --profile --cache-sksl --write-sksl-on-exit android-shaders.sksl.json -t test_driver/sksl_generator.dart

20 seconds later and Flutter going through every page of the app at light speed and the new shader cache is generated! This is then used in the production build.

Improving the reliability of the shader generation

Pages can take a variable amount of time to generate, buttons can be visible only after some animation has completed, slowdowns can happen…

The safest way to improve reliability of the shader generation is to wait for an element to be present first and then tapping on it. This ensures that any animation has finished completion.

Here is a small extension on the Flutter driver which does exactly that and an example code on how I tap on the custom currency input keyboard:

extension WaitForTap on FlutterDriver {
  waitForAndTap(SerializableFinder finder) async {
    await waitFor(finder);
    await tap(finder);
  }
}

// Moving through the calculator

Future<void> useCurrencyInput(FlutterDriver driver) async {
  await driver.waitForAndTap(find.byType('CurrencyInput'));

  for (var i = 0; i < 10; i++) {
    await driver.waitForAndTap(find.byValueKey('keyboard_delete'));
  }
  await driver.waitForAndTap(find.byValueKey('keyboard_2'));
  await driver.waitForAndTap(find.byValueKey('keyboard_1'));
  await driver.waitForAndTap(find.byValueKey('keyboard_hide'));
}

Now I can start this driver every time I want to deploy a production build, this driver also work for creating iOS shaders!

Participating to the Flying High with Flutter podcast

Fri, 04 Jun 2021 00:00:00 +0000

I’ve participated to the Flying High with Flutter podcast with Allen Wyma. We’ve been discussing about my personal finance Flutter app and all the challenges I encounter building it, Please find a link to the podcast here:

Have a look to the Flying High with Flutter Podcast!

I hope you find it interesting, there are many challenges to build this app and let me know if you have any questions!

Open-sourcing my battery-included Phoenix boilerplate!

Sun, 30 May 2021 00:00:00 +0000

Checkout the ExPlatform boilerplate on GitHub

During the past year working on my saas budget app, I’ve accumulated some amount of boilerplate to create my project. I’ve chosen to open-source it all, say hello to ExPlatform! Here’s what’s included out of the box:

TailwindCSS with Tailwind jit
Phoenix auth integrated with nice Tailwind pages and transformed to support i18n
i18n everywhere (PRs are welcomed to add more languages)
Notifications with a nice animation and auto-clear
Auth emails are using Bamboo and proper HTML template
Javascripts tests with Jest (and I’ve included some built-in tests)
Pre-commit checks for styling & dialyzer (this boilerplate is ready for team work)
Github actions checking the pre-commits and the tests for each commit
Dependabot
Asdf integration, just use the .tools-versions for all your versions! It’s also what’s used in the Github actions.
Eslint

A few screenshots:

The signup page

The user settings page

Thinking Elixir podcast: Using LiveView and Hooks!

Thu, 25 Feb 2021 00:00:00 +0000

I’ve participated to the Thinking Elixir podcast with Mark Ericksen, David Bernheise and Cade Ward. We’ve been discussing about my Elixir project and the Elixir news in general, Please find a link to the podcast here:

Listen to the Thinking Elixir Podcast!

This podcast is great for getting in touch with what’s happening in the community, they have a good variety of guests and I highly recommend listening to it if you want to discover more about Elixir and its community.

Managing browser timezones to display dates with Phoenix Live View

Sun, 07 Feb 2021 00:00:00 +0000

Checkout the demo project on GitHub

I’m currently building a web version of my personal finance application, for that, I’ve chosen to use Phoenix Live View, it’s the perfect tech for my use case.

In this finance web application, you do have a lot of dates to display such as when you actually spent the money. Users (including myself) can also travel so the dates needs to be displayed according to the current browser timezone.

There’s a simple way to get the timezone in the browser:

new Date().getTimezoneOffset(); // returns the timezone offset in minutes

So here are the main things we need to do:

Send the browser timezone to the Live View
Store the timezone in the session. This is needed for the server side rendering since we also want to display the right date even on the server side before the live view mounts. If we don’t do this, the user is going to see the wrong date first and then the view will be re-rendered properly once the socket connects, this isn’t a great UX and will look janky.
Retreive the timezone either from the Live socket parameters or the session depending if we’re on the server side rendering.

Sending the timezone

Luckily for us, there’s a simple way to send parameters on the initialisation of the Live Socket:

let liveSocket = new LiveSocket("/live", Socket, {
    params: {
        timezone: - (new Date().getTimezoneOffset() / 60)
    }
})

That’s as simple as that! This enables us to receive the timezone when the live view is connected, Phoenix.LiveView.get_connect_params/1 can then be used to retreive that data if the socket is connected.

The first part being completed, we need to create a small controller which stores the timezone into the session:

defmodule MavioWeb.SessionSetTimezoneController do
  use MavioWeb, :controller

  def set(conn, %{"timezone" => timezone}) when is_number(timezone) do
    conn |> put_session(:timezone, timezone) |> json(%{})
  end
end

On the first page load, we need to call this controller to store the timezone in the session, for that a small bit of Javascript is needed:

export default function sendTimezoneToServer() {
    const timezone = - (new Date().getTimezoneOffset() / 60);
    let csrfToken = document.querySelector("meta[name='csrf-token']").getAttribute("content")


    if (typeof window.localStorage != 'undefined') {
        try {
            // if we sent the timezone already or the timezone changed since last time we sent
            if (!localStorage["timezone"] || localStorage["timezone"].toString() != timezone.toString()) {
                var xhr = new XMLHttpRequest();
                xhr.open("POST", '/api/session/set-timezone', true);
                xhr.setRequestHeader("Content-Type", "application/json");
                xhr.setRequestHeader("x-csrf-token", csrfToken);
                xhr.onreadystatechange = function () {
                    if (this.readyState === XMLHttpRequest.DONE && this.status === 200) {
                        localStorage['timezone'] = timezone.toString();
                    }
                };
                xhr.send(`{"timezone": ${timezone}}`);
            }
        } catch (e) { }
    }
}

I’m using XMLHttpRequest since I also need to support older browsers but you might want to use window.fetch or Axios which have much nicer apis.

On the Live View

On the Live View we just retreive the timezone, either from the session or from the socket parameters depending of what we have available:

  def get_timezone(socket, session) do
    if Phoenix.LiveView.connected?(socket) do
      case Phoenix.LiveView.get_connect_params(socket) do
        %{"timezone" => timezone} -> timezone
        _ -> session["timezone"] || 0
      end
    else
      session["timezone"] || 0
    end
  end

At this point you are probably thinking why I’m bothering with the session if we can send this data every time the socket is initialized? There’s a very simple reason for that, Live views are rendered server side before the socket is actually connected, if we did not do that session step, the dates would simply be rendered with the wrong timezone the first time and then “corrected” once the socket is actually connected, that would be a poor user experience.

I’ve then created a simple Live view helper to display the date according to the timezone and the local:

  def to_datestring(date, _locale, _timezone) when date == nil or date == "" do
    ""
  end

  def to_datestring(date, locale, timezone) when is_binary(date) do
    {:ok, parsed_date, _} = DateTime.from_iso8601(date)

    {:ok, str} =
      Mavio.Cldr.DateTime.to_string(parsed_date |> Timex.shift(hours: timezone), locale: locale)

    str
  end

  @spec to_datestring(DateTime.t() | String.t(), String.t(), integer()) :: String.t()
  def to_datestring(date, locale, timezone) do
    {:ok, str} =
      Mavio.Cldr.DateTime.to_string(date |> Timex.shift(hours: timezone), locale: locale)

    str
  end

This helper supports using strings or actual DateTime objects, I’m using the excellent Timex library to shift the timezone offset and Cldr for internationalization.

And here we go, our objective is completed! Dates can now be displayed in multiple languages and multiple timezones!

A hook for handling very large lists with Phoenix Live View

Fri, 01 Jan 2021 00:00:00 +0000

Checkout the demo project on GitHub

I’m currently building a web version of my personal finance application, for that, I’ve chosen to use Phoenix Live View, it’s the perfect tech for my use case.

In this finance web application, you have a lot of very large lists to display like the list of transactions for example. Each wallet can have between 2k and 20k transactions and it’s unreasonable to load everything at once. Loading everything slows down the initial page load with those large queries and then it also slows down the browser.

The solution is to build a list of transactions which is streamed as you go like on Fastmail or Gmail. The user has the impression that they can scroll down and that the full list is already there but in reality, everything is being streamed in chunks and loads as they scroll.

I’ve use Fattable.js for that purpose, it’s a small library which is making handling those large tables easier.

First, here is a preview of the end result:

Video preview of the infinite scrolling where I scroll anywhere and you can see the list loading as I scroll dynamically

Now let’s dive into the code!

The Live View

Here is first what the live view looks like, it’s pretty straightforward and does not change much from a normal list.

@records here only contains the first page of records (so a maximum of 40 records in my case), this is used to display data when loading the page so that the user can interact directly with the list without waiting for the first page to load.

<div class="bg-white flex-1 h-100 lg:block x-space-y-2 overflow-auto relative h-full"
         id="scroll-<%= @wallet.id %>"
         phx-hook="InfiniteScroll"
         data-count="<%= @records_count %>"
         data-page-size="<%= @records_per_page %>"
         data-row-height="<%= @row_height %>"
         data-loading-block-id="loading-block">
        <%= for record <- @records do %>
          <%= render(MavioWeb.LayoutView, "record.html",
               conn: @socket,
               record: record,
               locale: @locale,
               timezone: @timezone,
               wallet: @wallet,
               row_height: @row_height
             ) %>
        <% end %>
    </div>

    <!-- 
        here is the loading block, this is the block which is used when the data is still loading.
        This is the "pulse" animation you can see on the video when scrolling.
     -->
    <div id="loading-block" class="hidden" aria-hidden="true">
      <div class="animate-pulse rounded p-5 bg-white" style="height: <%= @row_height %>px">
           <div class="flex space-x-3">

              <img src="/images/loading-icon.svg">
              <div class="flex flex-col w-56">
                <div class="h-4 bg-blue-100 rounded mb-1"></div>
                <div class="h-4 bg-blue-100 rounded w-5/6"></div>
              </div>
          </div>
       </div>
      </div>
    </div>

As you can see, I’ve kept the live view as simple as possible, I’ve created a bunch of additional attributes that are used in the javascript:

data-count contains the total number of items, this is helpfull for fattable.js to calculate the total height of the div.
data-page-size is the chunk size which we’re loading the items with, I’m setting it to 40 for my use case but it depends of what you are building, you might want a lower page size if retreiving the data is very expensive.
data-row-height is the row height in pixels. Unlike a traditional list, with this method, we need to have every row at the exact same height.
data-loading-block-id is an id linking to the HTML which is used when loading the data, it’s what’s using the “pulse” animation in the video.

The Infinite Scroll Hook

The main chunk of the code is in the new InfiniteScroll Hook, it handles the link between the fattable.js library and the Live View. I’ve commented every part to make it easier to follow:

require('fattable/fattable.js');


/* 
 * This variable is used to keep the scroll position when the live view navigation changes.
 * This is useful for modals.
*/
let keepScroll = {};

export default {
    mounted() {
        /*
         * Here we're loading the first page which is already rendered in the HTML 
         */
        var firstBlock = [];
        for (let i = 0; i < this.el.children.length; i++) {
            firstBlock.push(this.el.children[i].outerHTML);
        }

        /* 
         *  All the attributes are mapped from what we sent in the live view 
         */
        const numberOfRows = parseInt(this.el.getAttribute('data-count'));
        const pageSize = parseInt(this.el.getAttribute('data-page-size'));
        const rowHeight = parseInt(this.el.getAttribute('data-row-height'));
        const loadingBlock = document.getElementById(this.el.getAttribute('data-loading-block-id')).innerHTML;

        let painter = new fattable.Painter();

        painter.fillCell = (cellDiv, data) => cellDiv.innerHTML = data.content;   // filling the data when it's received
        painter.fillCellPending = (cellDiv) => cellDiv.innerHTML = loadingBlock;  // the loading block when there's no data

        let tableModel = new fattable.PagedAsyncTableModel();

        tableModel.cellPageName = (i) => (i / pageSize) | 0;
        tableModel.hasColumn = () => true;
        tableModel.columnHeaders = ["Transaction"]; 
        tableModel.getHeader = (i, cb) => cb(tableModel.columnHeaders[i]);


        /*
         * This is where we fetch the current page to render the header
         * We're using Live View events instead of HTTP requests since the socket is already opened
         * If it's the first page, we render the elements we gathered already from the server side rendering, no need to fetch them again
         */
        tableModel.fetchCellPage = (offset, cb) => {
            if (offset == 0) {
                cb(function (i) {
                    return {
                        rowId: i,
                        content: firstBlock[i]
                    }
                });
            } else {
                this.pushEventTo(`#${this.el.id}`, "load-table", { offset: offset });
                this.handleEvent(`${this.el.id}-receive-table-${offset}`, payload => {
                    cb(function (i) {
                        return {
                            rowId: i,
                            content: payload.html[i - payload.offset * pageSize]
                        }
                    });
                });
            }
        }

        /* 
         * This is used to resize the list if the window size changes 
         */
        let getColumnWidth = () => {
            return [this.el.getClientRects()[0].width];
        }

        this.table = fattable({
            container: `#${this.el.id}`,
            model: tableModel,
            nbRows: numberOfRows,
            rowHeight,
            headerHeight: 0,
            painter,
            columnWidths: getColumnWidth()
        });

        window.addEventListener('resize', () => {
            this.table.columnWidths = getColumnWidth()
        });

        /*
         * We set the scroll to where it was before, this object isn't stored in the localStorage,
         * this is by design, we want the list to be scrolled top when the user actually reloads the page, same as an actual list.
         */
        if (keepScroll[this.el.id]) {
            this.table.scroll.setScrollXY(0, keepScroll[this.el.id]);
        }
    },

    /*
     * This will be called before the table is destroyed to save the scroll position, this is very useful for modals.
     */
    beforeDestroy() {
        keepScroll[this.el.id] = this.table.scroll.scrollTop;
    }
}

And we load the hook in the LiveSocket, like any other Live View hook:

import { LiveSocket } from "phoenix_live_view";
import InfiniteScroll from './hooks/InfiniteScroll';

/* ... */

let csrfToken = document.querySelector("meta[name='csrf-token']").getAttribute("content")
let liveSocket = new LiveSocket("/live", Socket, {
    hooks: {
        InfiniteScroll
    },
    params: {
        _csrf_token: csrfToken,
    }
});

The Elixir side of things

Most of the code being on the hook, the Elixir side is very simple, we just listen to the hook event asking for data and we reply with what is needed.

  def handle_event(
        "load-table",
        %{"offset" => offset},
        %{assigns: %{user: user, wallet: wallet, locale: locale, timezone: timezone}} = socket
      ) do
    {:noreply,
     socket
     |> push_event(
       "scroll-#{wallet.id}-receive-table-#{offset}",
       %{
         offset: offset,
         html:
           list_records_from_wallet(
             user: user,
             wallet_id: wallet.id,
             page: offset + 1,
             per_page: @records_per_page
           )
           |> Enum.map(fn record ->
             render_to_string(MavioWeb.LayoutView, "record.html",
               conn: socket,
               record: record,
               locale: locale,
               timezone: timezone,
               wallet: wallet,
               row_height: @row_height
             )
           end)
       }
     )}
  end

Some additional explanation:

list_records_from_wallet is simply a function which does a sql query to fetch data with a page offset
We return a list of each record rendered into HTML, the hook is then using that to replace the loading blocks.

And here you go! We can create a list of 20k records without slowing down the browser and the pageload!

Solving 'cannot redirect socket on update/2' with Phoenix Live view components

Wed, 23 Dec 2020 00:00:00 +0000

Maybe you’ve encountered this cannot redirect socket on update/2 error while using a live_component and a put_redirect on Phoenix live view:

[error] GenServer #PID<0.1068.0> terminating
** (RuntimeError) cannot redirect socket on update/2
    (phoenix_live_view 0.15.0) lib/phoenix_live_view/utils.ex:413: Phoenix.LiveView.Utils.maybe_call_update!/3
    (phoenix_live_view 0.15.0) lib/phoenix_live_view/diff.ex:324: Phoenix.LiveView.Diff.component_to_rendered/4
    (phoenix_live_view 0.15.0) lib/phoenix_live_view/diff.ex:366: Phoenix.LiveView.Diff.traverse/6
    (phoenix_live_view 0.15.0) lib/phoenix_live_view/diff.ex:427: anonymous fn/4 in Phoenix.LiveView.Diff.traverse_dynamic/6
    (elixir 1.11.2) lib/enum.ex:2181: Enum."-reduce/3-lists^foldl/2-0-"/3
    (phoenix_live_view 0.15.0) lib/phoenix_live_view/diff.ex:339: Phoenix.LiveView.Diff.traverse/6
    (phoenix_live_view 0.15.0) lib/phoenix_live_view/diff.ex:580: Phoenix.LiveView.Diff.render_component/9
    (phoenix_live_view 0.15.0) lib/phoenix_live_view/diff.ex:194: Phoenix.LiveView.Diff.write_component/5
    (phoenix_live_view 0.15.0) lib/phoenix_live_view/channel.ex:463: Phoenix.LiveView.Channel.component_handle_event/6
    (stdlib 3.13.2) gen_server.erl:680: :gen_server.try_dispatch/4
    (stdlib 3.13.2) gen_server.erl:756: :gen_server.handle_msg/6
    (stdlib 3.13.2) proc_lib.erl:226: :proc_lib.init_p_do_apply/3

This is actually easy to solve, your component just needs to have an id:

<%= live_component @socket, MyApp.MyComponent, id: "something" %>

The reason being that stateful components needs to have an id for the lifecycle function to do its job properly. Now you are done!

Automating Play Store screenshots in Flutter

Fri, 31 Jul 2020 00:00:00 +0000

After adding support for seven languages to my personal finance app, I very quickly discovered that making Play Store screenshots manually was just unworkable anymore. Every locale needs five or six screenshots and each screenshot needs to be in the right language. Additionally, I would have to do all of this tedious work again whenever I change anything significant to one of the views, some automated solution was necessary.

Automating screenshots

I used the Flutter “screenshots” package. To generate better screenshots, I used a demo SQLite database full of random transactions and I also fixed the clock time for the financial statistics pages to look similar months after months.

Config.clock = Clock.fixed(DateTime.parse('2019-06-07T04:34:10.958Z'));
Config.dbFilename = "https://.../demo.db"; // remotely fetching a demo database

The database is then downloaded at boot, copied into the application folder, this configuration clock is used everywhere time is gathered on the app.

static const supportedLanguages = ["en", "fr", "ru", "vi", "de", "es", "pt"];

The screenshot script then boots the application, loops into each supported language and supported currency per language, goes into each screen and creates a screenshot. The whole operation takes about 5 min for the 70 screenshots to generate.

All the raw captures are now generated.

Making those screenshots look better

I’ve created a second script which then takes the raw screenshots and transforms them into something nicer. Using a headless browser was a quick and easy option.

It was very easy to generate the kind of appearance I wanted by changing a few lines of css and the dynamic items (like the i18n text and the capture) could be replaced at runtime.

const browser = await puppeteer.launch({ headless: true });
const page = await browser.newPage();
const screenshotDirectory = path.resolve(`${__dirname}/../../android/fastlane/metadata/android/en-US/images/phoneScreenshots/`);
var files = fs.readdirSync(screenshotDirectory);

// ...
await page.goto(`file://${__dirname}/featuredView.html`);
// ...

for (var i = 0; i < files.length; i++) {
  const file = files[i];
  // ...
  await page.evaluate((screenshotDirectory, file, title, content) => {
      document.getElementById('screen_title').innerHTML = title;
      document.getElementById('screen_content').innerHTML = content;
      document.getElementById('main-image').style.background =
          `url(file://${screenshotDirectory}/${file})`;
  }, screenshotDirectory, file, i18nTitle, i18nDescription);
  await element.screenshot({ path: `generated/${file}` });
}

I’ve removed a few boring parts of loading the locale JSON files and plumbing logic which isn’t really that interesting but you get the idea.

And now the result we were waiting for…

Looks nicer isn't it?

Also works for any supported language!

Sending all those screenshots to the Google Play Store

Uploading those screenshots to the Play Store is also a tedious task by itself, you need to go to each locale and add the screenshots one by one, I was sure we could do better.

Google provides an access to the Google Play Store api, although it’s much more limited than the actual Play Store in the browser, it’s good enough for my needs.

import { google } from 'googleapis';

const packageName = "fr.mavio";
const androidpublisher = google.androidpublisher("v3");

const auth = new google.auth.GoogleAuth({ scopes: ['https://www.googleapis.com/auth/androidpublisher'], });
const authClient = await auth.getClient();
google.options({ auth: authClient });

const { id: editId } = (await androidpublisher.edits.insert({ packageName })).data;

Now we’ve connected to the Google API and created a draft version (called “edit”) of our data. This API works in two steps, you make all the changes you want to the edit and then you commit the new data, similar to source control.

It’s now time to actually send the screenshots.

import * as fs from 'fs';

const googleLanguageToMavioMapping = {
    'en-US': 'en',
    'fr-FR': 'fr',
    'ru-RU': 'ru',
    'pt-PT': 'pt',
    'es-ES': 'es',
    'de-DE': 'de',
    'vi': 'vi',
};
const screenPath = `${__dirname}/../store-screenshots/generated/pixel3-root-`;
for (let language in googleLanguageToMavioMapping) {
    let file: fs.ReadStream;
    const mavioLanguage = googleLanguageToMavioMapping[language];
    var screens = ['accounts', 'stats', 'transaction', 'home', 'statspage'];
    for (var i = 0; i < screens.length; i++) {
        let type = screens[i];
        console.log(`uploading ${type} image screenshot for ${language}`);

        let currency = defaultCurrencyForLocale[language] || 'EUR';
        file = fs.createReadStream(`${screenPath}${type}-${mavioLanguage}|${currency}.png`);
        await androidpublisher.edits.images.upload({
            editId,
            packageName,
            language,
            imageType: 'phoneScreenshots',
            media: {
                mimeType: "image/png",
                body: file
            }
        });
    }
}

A few minutes of file upload later…

The end result as seen on the Play Store

Here you go! All the captures for all the locales are now on the Google Play Store.

Conclusion

Automating screenshots generation for my app was a fun project. Doing everything manually becomes impossible when you support a few languages. Another benefit of the automation is that I can keep the Play Store up to date with any change I’m making in the app.

That happened to me once already, I’ve redesigned one of the statistics pages. Instead of spending a few hours to make the screenshots again for this page for each locale and currency, I’ve just ran the tools and everything was up to date once again!

Alex-min's tech blog

Releasing LiveView native with Flutter preview

What is LiveView native?

What does it look like?

Where is the code?

What’s missing?

LiveView native with Flutter preview

What is LiveView native?

What does it look like?

Where is the code?

S'abonner

What’s missing?

Improving Flutter latency through sksl automation

Improving Flutter latency through sksl automation

The core issue

Let’s automate that boring job with Flutter driver!

Improving the reliability of the shader generation

Participating to the Flying High with Flutter podcast

Open-sourcing my battery-included Phoenix boilerplate!

Thinking Elixir podcast: Using LiveView and Hooks!

Managing browser timezones to display dates with Phoenix Live View

Sending the timezone

On the Live View

A hook for handling very large lists with Phoenix Live View

The Live View

The Infinite Scroll Hook

The Elixir side of things

Solving 'cannot redirect socket on update/2' with Phoenix Live view components

Automating Play Store screenshots in Flutter

Automating screenshots

Making those screenshots look better

Sending all those screenshots to the Google Play Store

Conclusion