DEV Community: In The Pocket

React Native is here to stay

Robrecht Meersman — Tue, 09 Apr 2024 09:42:48 +0000

This post originally appeared on our ITP website

React Native is one of many cross-platform frameworks aiming to bridge the gap between iOS and Android app development. However, React Native is not like any other cross-platform framework. With a growing number of top-ranking apps built using React Native and the backing of major companies, it's clear that this framework is not just a passing trend but a significant player in the mobile development landscape.

If you’re not already sold, this article should convince you to embrace React Native and show you how we utilise it at In The Pocket to create top-notch mobile experiences.

(For clarity: this article is NOT sponsored by React Native 🥲)

Built on solid ecosystems

React Native builds upon solid foundations: JavaScript and React. Foundations many developers are skilled in and that have big and active communities. The "Learn once, write anywhere" slogan of React Native really holds true, empowering developers to utilise their existing coding skills to write code for both iOS and Android platforms with minimal learning curve.

Apart from leveraging these foundations, React Native still retains the ability to fully access and utilise the native capabilities of the underlying iOS and Android platforms. This means that developers can tap into the performance and accessibility functionalities of the devices seamlessly, without compromise, even though they're primarily working with JavaScript and React.

Backed by big companies

The open source landscape can be the Wild West, often relying on the goodwill of solo developers who can pull the plug at anytime. React Native distinguishes itself with backing from major players like Meta, Microsoft, and Shopify. Their active involvement ensures the continuous growth and improvement of React Native. Moreover, companies such as Software Mansion and Callstack contribute valuable libraries and host yearly conferences, enlarging the community.

Another big asset is Expo, a major player in simplifying React Native development with a suite of tools and services. By getting rid of native complexities, Expo allows developers to focus on building features rather than dealing with technical cross-platform intricacies. Through open-source libraries and tools, Expo streamlines development.

Next to that, Expo Application Services (EAS) is a cloud-based solution for building, signing, distributing, and updating apps, reducing setup time and continuous integration workflows. And Expo Updates, a feature of EAS, enables over-the-air updates, ensuring users have access to the latest features and bug fixes, facilitating rapid app iteration and improvement.

Bright future ahead

The future of React Native looks promising, as the React Native team plans a significant overhaul of its core internals, called the New Architecture, aimed at improving its performance and scalability. Additionally, Expo continues to evolve, enhancing developer experience with new features and keeping an exciting roadmap.

Expo promises to release an update to their SDK each quarter, so apps will always be able to target the latest iOS and Android versions. These advancements make it easier than ever to build, deploy, and manage React Native applications, ensuring the framework remains at the forefront of mobile development.

React Native in practice

Izimi mobile app

At In The Pocket, React Native has enabled us to create robust and future-proof applications like the Izimi mobile app: a sturdy and future-proof digital vault, also available as a web portal. Harnessing React Native's native capabilities and seamlessly integrating Itsme e-ID authentication, Izimi ensures a secure and user-friendly authentication experience. By sharing JavaScript code between web and app, we've accelerated our development process while minimising code duplication.

Multipharma app

For Multipharma, React Native facilitated the rapid development of a new mobile app in just five months. The same developers could work on the mobile app and web portal, keeping feature parity high. Because React Native is just native, we could leverage on-device security measures like biometrics and encryption, ensuring end-to-end application security.

Colruyt Xtra app

These security features also play a role in the Xtra app we help develop for Colruyt Group. Native integrations allow the user to use biometrics to securely pay your groceries right from the app. Thanks to the large open source community, these native integrations often already exist, helping us gain speed by not reinventing the wheel. The modularity of React allows us to collaborate with multiple feature teams in parallel while maintaining a consistent look and feel through the use of a centralised design system. The design system used in Xtra enforces accessibility by default, and using TypeScript strengthens the ability to ensure accessibility in the application.

React Native at In The Pocket

At In The Pocket we’ve had React Native on our tech radar since its early stages and we have seen it grow and mature. We have seen that React Native can create just as high-quality, performant, innovative apps as native ones. At In The Pocket, we fully embrace React Native and we are actively contributing to its open source landscape. We adopt Expo's ecosystem to accelerate our development even further.

We're excited to see how React Native continues to evolve and how it will shape the future of mobile development. As we continue to build and innovate, one thing remains clear—React Native is not just here to stay but to lead the way in mobile development.

Building accessible forms

Klukies — Tue, 29 Mar 2022 08:29:45 +0000

On September 14th, In The Pocket signed the Digital Inclusion Charter to underline our commitment in fighting digital exclusion. In this post I'll explain how this can be applied to handling form submissions.

In the example, which can be found on GitHub, a user is able to fill in their name and email address, which will be validated in remix when submitting the form. There's two states of the form. The first one will occur if there are any validation errors and the second is a toast message which will appear and dissapear when the user has successfully submitted the form.

First up, want to see a demo?
Just head over to this StackBlitz app, click the "Open in New Window" in the header and enable VoiceOver.

Native browser behaviour

Before I started coding specifically towards React/Remix, I first had a look at how native browser validation behaves. If we take a look at the screenshot above, we'll notice that browsers validate input fields one by one. Meaning that, if we have an error in a certain input field, that input field will be focused and an unstyled (and rather ugly) browser popover will be displayed with an error message.

This is important because when we want to create anything custom, we should take the native browser behaviour as a base for our validition. Users expect certain UI to be consistent, as it makes it easier for them to navigate a page.

Custom validation

Because we're always striving towards spectacular UI and UX, we decided to implement the following improvements towards this form:

Validate the entire form when submitting the form.
Show all validation errors in a styled error message underneath the input.
When there are no validation errors, display a success message.

Validating the entire form is easily done thanks to Remix's action function and yup. All I had to do was create a function that validates our form data based on the validation schema and return each error. The specific code isn't present here because it would bloat the post, so again another incentive to have a look at the GitHub repo 😊.

To show the validation errors in a styled error message, we created a span element for each input element and bound our error messages. This leaves us with this beautiful validated form.

Accessibility

Now that we have a beautiful UI, thanks to custom validation, let's improve the UX by implementing the best features of native browser behaviour and make it accessible thanks to the use of some aria attributes.

After reading the Web Accessible Initiative tutorial regarding forms we are able to make our forms accessible by using the
following code:

const Index = () => {
  const { toastRef, showToast } = useToast();
  const actionData = useActionData();
  const { formRef } = useAccessibleForm({
    hasErrors: actionData?.hasErrors,
    errors: actionData?.errors,
    showToast,
  });

  return (
    <main>
      <Toast role="alert" aria-live="polite" />
      <Form method="post" aria-label="Personal information form" noValidate>
        <div className="form-group">
          <label htmlFor="first-name">First name</label>
          <input
            type="text"
            id="first-name"
            name="firstName"
            aria-required
            aria-describedby="first-name-error"
          />
          <span id="first-name-error" aria-hidden>
            {actionData?.errors?.firstName}
          </span>
        </div>
      </Form>
    </main>
  );
};

There are three things which help to make this form accessible.

First up, a toast component which has an alert role and and aria-live attribute. The alert role is used to communicate an important and usually time-sensitive message to the user. Seeing as form validation is quite important, this attribute fits perfectly! However, as the docs state, the alert role also causes aria-live to be set with the value "assertive", meaning it will interrupt the user's screenreader. In order to prevent this we set the aria-live attribute to "polite".

Second, when the form contains errors, the useAccessibleForm() hook will:

generate all errors,
create a human readable error message,
call the showToast() function with this error message.

Because the error messages are shown underneath the input fields, we don't have to show the toast. Thanks to the aria-live attribute however, the screenreader will still read this out.

Last, to bring everything together we're hiding the error message for the screenreader space. In order to add the relationship between the input field and the error message we can use the aria-describedby attribute, which will ensure the error message will be read out after the user navigates to the
input field.

As you can see: with little effort we were able to make the web a better place for people using a screenreader. There's plenty of other things we can do to improve accessibility and usually it comes down to our mindset. I hope this was useful and you'll probably see some more in the future!

Original blogpost
GitHub repo

From Figma to React Native using Specify

Robrecht Meersman — Fri, 11 Mar 2022 14:20:19 +0000

This post originally appeared on our ITP Dev blog

We all know the benefit of design systems. As a designer we want to have a consistent UI over web, mobile and any other platform the brand is present. As a developer we do not want to spend time exporting assets and colors from Figma, importing them into the code and repeating this process every time something changes.

Luckily there exists a tool to automate this process. Specify is a cloud platform which stores a single source of truth for your design tokens (text styles, colors, icons, imagery, etc.) and distributes them to the different platforms. Specify allows you to import your tokens from a source like Figma (and soon other sources like Google Drive or Dropbox) and keep them in sync while you make changes to the source. You can view the tokens in the web app and export them to GitHub or to your project using the CLI.

In this blogpost we will focus on syncing the design tokens from Figma to React Native.

Figma to Specify

Syncing design tokens from Figma to Specify is just a matter of clicking a few buttons. The Specify team has written a clear guide on how to set it up, and Specify will automatically sync any new changes made to the Figma file.
I recommend taking a look at the example Figma file to see how each design token should be delivered.

Specify to React Native

To pull design tokens into a project, Specify offers a CLI with a pull and sync command. The pull command will import all design tokens, where the sync command will only update the ones that are already present.
The CLI uses a .specifyrc config file (JS or JSON) in which you can write rules, which are different jobs to run in parallel.

// .specifyrc.js
module.exports = {
  repository: '@my_organization/my-repository',
  personalAccessToken: 'my_personal_access_token',
  rules: [
    // different jobs in parallel
  ],
};

For each rule we can use a different filter, such that the rule only applies to certain types of design tokens. Next to filters, we can also use parsers, which will manipulate the raw design tokens (which are in JSON format) and output a format that suits the programming language and platform more. Parsers behave like a pipeline, where each parser receives the input of the previous one. There are a lot of parsers to choose from, some perform very low level transformations such as round-number and camelcasify, but also full-blown parsers to a single technology such as to-tailwind and to-react-native.

Downloading fonts & assets

If we filter on assets ('vector', 'bitmap' and 'font'), Specify will download the assets themselves instead of the JSON describing them. They will be placed under the given folder (here src/common/assets).

For SVG's, we can use the svgo parser, which optimizes the SVG code and outputs a minified result. The default svgo settings are pretty good, but we add removeDimensions to make them responsive and replace the hard coded colors with "currentColor" such that we can color them with React Native styles.

// .specifyrc.js
  ...
  rules: [
    {
      name: "🖊 Download Vector Assets",
      path: "src/common/assets/vector",
      filter: {
        types: ["vector"],
      },
      parsers: [
        { name: "camelcasify" },
        {
          name: "svgo",
          options: {
            svgo: {
              plugins: [
                { removeDimensions: true },
                { convertColors: { currentColor: true } },
              ],
            },
          },
        },
      ],
    },
    {
      name: "🏞 Download Bitmap Assets",
      path: "src/common/assets/bitmap",
      filter: { types: ["bitmap"] },
      parsers: [
        { name: 'camelcasify' },
        {
          // This parser will give @2x and @3x variants their correct file name
          name: 'name-assets-files-by-pattern',
          options: {
            pattern: '{{name}}{{#dimension}}@{{dimension}}x{{/dimension}}.{{format}}',
          },
        },
      ],
    },
    {
      name: "🔡 Download Fonts",
      path: "src/common/assets/fonts",
      filter: { types: ["font"] },
    },
  ],
  ...

Syncing desing tokens

Now that assets and fonts are downloaded, we are ready to import the rest of the design system. For this we will use the to-react-native parser. It will generate a JavaScript (or TypeScript) theme object with all the design tokens in the correct format for React Native to understand.

// .specifyrc.js
...
{
  name: '⚛️ Import tokens',
  path: 'src/common/theme/theme.js',
  parsers: [
    {
      name: 'to-react-native',
      options: {
        assetsFolderPath: {
          bitmap: 'src/common/assets/bitmap',
          vector: 'src/common/assets/vector',
        },
      },
    },
  ],
},
...

If you have questions or notice any issues with the to-react-native parser, feel free to contribute or talk to me about it 🙏

An example of a full .specifyrc.js file can be found here. The output file will look something like this:

// src/common/theme/theme.js
import assetChevronRight from '../assets/vector/chevronRight.svg';
import assetLogo from '../assets/bitmap/logo.png';

const theme = {
  bitmap: {
    logo: assetLogo,
  },
  vector: {
    chevronRight: assetChevronRight,
  },
  textStyle: {
    body: {
      fontWeight: '500',
      fontSize: 16,
      lineHeight: 24,
      fontFamily: 'Montserrat-Medium',
      color: 'rgb(0, 0, 0)',
    },
  },
  measurement: {
    grid: 8,
  },
  color: {
    primary500: 'rgb(0, 0, 153)',
  },
  gradient: {
    sunset: [
      {
        angle: 90,
        colors: ['rgb(245, 72, 63)', 'rgb(255, 142, 5)'],
        locations: [0, 1],
      },
    ],
  },
  opacity: {
    dimmed: 0.6,
  },
  font: {
    montserratMedium: 'Montserrat-Medium',
  },
};

export default theme;

As a final step we will add an npm script in our package.json:

// package.json
  "scripts": {
    ...
    "specify:pull": "specify pull -C .specifyrc.js",
  },

Now we have our Figma project synced with React Native 🎉. Every time the designer changes a color or adds an icon, we can run npm run specify:pull and see the changes in our app!

Using the theme object

Making use of the design tokens is fairly straighforward for most types.

Bitmaps

Simple as that!

import { Image } from 'react-native';
import theme from 'common/theme';

const App = () => <Image source={theme.bitmap.logo} />;

Vectors

All vector assets in theme.js are imported directly. If you are not using Expo, you will need to install and configure react-native-svg-transformer to resolve the import statements.

Unlike bitmaps, the imported assets are React elements. We create a Vector component to make the usage look more like regular images:

const Vector = ({ source: SVGElement, ...props }) => <SVGElement {...props} />;

const App = () => (
  <>
    {/* a bit weird */}
    <theme.vector.chevronRight />
    {/* much better! */}
    <Vector source={theme.vector.chevronRight} />
  </>
);

Fonts

This part is specific to non-Expo projects. For Expo apps, it could be different.

In the "Download Fonts" rule above, the downloaded .ttf files will be under src/common/assets/fonts/, but they should also be imported in the native projects as well. This can be done by creating a react-native.config.js

// react-native.config.js
module.exports = {
  project: {
    ios: {},
    android: {},
  },
  assets: ['src/common/assets/fonts/'],
  dependencies: {
    // Optionally.
    // Prevent `react-native-vector-icons`
    // from linking all fonts
    'react-native-vector-icons': {
      assets: [],
    },
  },
};

Running react-native link will link all fonts under that path automatically to the Android and iOS project! We can run it after every specify pull job:

// package.json
  "scripts": {
    ...
-    "specify:pull": "specify pull -C .specifyrc.js",
+    "specify:pull": "specify pull -C .specifyrc.js && react-native link",
  },

Gradients

The to-react-native parser transforms gradients into a format which is easy to use with react-native-linear-gradient.
Example usage:

const App = () => (
  <LinearGradient
    colors={theme.gradients.myGradient.colors}
    locations={theme.gradients.myGradient.locations}
    useAngle
    angle={theme.gradients.myGradient.angle}
  />
);

Conclusion

Specify is a young but promising tool to sync Figma files to all you different platforms. If you feel like there is a parser missing or want to add some options, feel free to contribute to the project. The Specify team is very responsive and is open to suggestions.

Dynamic Open Graph images with Next.js

Robrecht Meersman — Thu, 10 Mar 2022 13:10:07 +0000

Update 2022-10: Vercel release a new OG Image Generation library, which does the same thing except 5x faster and at the edge!

This post originally appeared on our ITP Dev blog

Introduction

Let me start of with a question: which link are you more likely to click on, the left or the right?

Obviously, adding a social media preview image is an great way to improve the professional look of your website and increase your click through rate (though I have no data on this). These social media images are specified using the Open Graph Protocol, which is a spec introduced by Facebook and now supported by any software that previews URLs for you. The OG image is specified in the document's head:

<head>
  <meta property="og:image" content="https://url-to-your-image.png" />
</head>

This can be hooked up to a CMS so editors can choose a picture which suits their landing page, blog post, news article… the most. It is important that the preview gives the user a clear idea of what to expect on the webpage, similar to a thumbnail on a YouTube video.

But what if the content of the page is not visual at all, and no photo really suits the contents of the page? And what if we have a lot of these pages, with dynamically generated content? Luckily we are not limited to photography, we can use text! The prime example of this is how GitHub generates previews for issue URLs: they generate an image containing enough info such that users know what they will click on. These images are generated on-demand, as storing an image for every GitHub pull request or issue would be unfeasable. Another example is Vercel, which even open sourced their Open Graph Image as a Service that they occasionally use on blog posts or announcements.

In this article we will find out how we can create these dynamic Open Graph images in Next.js. We will use our In The Pocket Tech Radar as an example. Our Tech Radar reflects our current view on software engineering technologies. It includes the technology choices we’ve made and motivates why we’ve made them. It also shows which technologies are “on our radar”, and why we consider adopting them.

Each technology has its own webpage, and we have more than 100 technologies on our radar. Manually creating an OG image for each technology would be a boring, repeating task.

TL;DR

Don't care about the details? Here's a small tutorial on how to add an API route to your Next.js app that generates the images on demand.

First, install next-api-og-image.

yarn add next-api-og-image

Then configure an API route

// pages/api/og-image.ts
import { withOGImage } from 'next-api-og-image';

interface QueryParams {
  stage: string;
  name: string;
}

export default withOGImage<'query', QueryParams>({
  template: {
                                // include HTML template here
    html: ({ name, stage }) =>  `<h1>${name} - ${stage}</h1>`,
  },
  cacheControl: 'public, max-age=604800, immutable',
  dev: {
    inspectHtml: false,
  },
});

And call the route from the web page:

// pages/technology/[slug].ts
<Head>
  <title>Next.js | Tech Radar</title>
  <meta 
    property="og:image" 
    content="https://inthepocket.tech/api/og-image?name=Next.js&stage=adopt" 
  />
</Head>

and done!

Behind the scenes

As you see in the code above, we are using the next-api-og-image library with almost no configuration required to generate the images. Super easy! The interesting part however is what the library does under the hood.

The withOGImage method exposes a GET /api/og-image?name=Next.js&stage=adopt API route with some query parameters we can define ourselves. In the case of our Tech Radar, we use the name and stage parameters. The API route returns an image containing the name and stage we provided:

When requesting the API route, the Next.js serverless function will actually spin up a web browser on the server (a headless instance of Chromium, using chrome-aws-lambda). Next, a webpage will be generated with HTML we can define ourselves. This HTML will be used to construct the image. That means that as a developer we can generate images using HTML and CSS, technologies we are already familiar with!

  template: {
    html: ({ name, stage }) =>  `<h1>${name} - ${stage}</h1>`,
  },

Of course we are not limited to a simple h1 tag, this can be a full HTML document with styles, images and custom fonts.

Finally, a screenshot of the webpage is taken using puppeteer and sent to the client-side.

We add some aggressive caching (public, max-age=604800, immutable) to prevent generating the same image too many times, because the image generation is quite slow and computationally intensive. The way we set up caching is also the reason we pass the query parameters and not just the technology's ID. You might think it is cleaner to fetch the technology's stage and name from the CMS inside the API route, but this makes caching more tricky. By adding all variable elements as query parameters, one URL will always return the same image and we can use the immutable setting on the caching. If the stage or the name of a technology would change on the Tech Radar, we will update the URL, and not update the image behind the URL.

Conclusion

Adding dynamic Open Graph images in Next.js is very low effort, but makes your site feel 10x more professional!

Creating an end-to-end encrypted chat with GetStream.io and seald.io

Sander Goossens — Wed, 23 Feb 2022 07:32:57 +0000

This post originally appeared on our ITP Dev blog

Recently, a client came to us asking for a chat solution with encryption support. After some research, we quickly came to a combined solution
of GetStream.io and Seald.io.

GetStream.io offers real-time chat messaging with a reliable chat infrastructure and feature-rich SDKs. One of the main selling points of GetStream.io is the
availability of UI components out of the box. With support for React Native, React, Android, Flutter, iOS/Swift,... you can quickly create a chat application without
the hassle of creating every UI interaction yourself.

Seald.io offers end-to-end encryption in Europe. The solution benefits from a security visa (CSPN) issued by the ANSSI, which ensures you a robust security model.
CSPN is the certification of Seald's level of robustness, based on compliance analysis and advanced penetration testing.
End-to-end encryption is the most secure technology available, but it is also the most complex and time-consuming to implement (key management, user account recovery, etc.).
To simplify its adoption, Seald has developed an SDK associated with an API, which allows you to add end-to-end encryption to your applications in a few lines of code, without any prior knowledge of cryptography.

Because of the APIs and components SDKs made available by Stream, we can hook the end-to-end encryption of Seald into it.

Enough introduction, let's see what we are going to build and how we approached this!

Goals

Chat messages should only be readable by the members of a conversation
Chat messages should not be readable in the Stream admin dashboard

Services

Messaging API custom nodeJS backend to handle all GetStream and Seald server side functionality. Has a postgreSQL database where we store seald users.
Users API custom nodeJS backend to handle everything conserning users.

Now to the actual implementation

Let's start our application with a registration screen where the user can enter their details. When a user successfully registers, we can authenticate him/her with our authentication provider.

The authentication providers returns with a JWT code that can be used across our full application.

{
  "accessToken":  "eyJ2ZXIiOiIxLjAiLCJraWQiOiIzYWMxMTjYwZi0yMzhm..."
}

We would like to connect the user to the GetStream servers, thus we need to fetch a JWT token from GetStream. An endpoint in our Messaging API will handle this.
Use the user ID from your authentication provider to create a token at GetStream.

import { StreamChat } from 'stream-chat';
const serverClient = StreamChat.getInstance(STREAM_KEY, STREAM_SECRET);

export async function getMessagingToken(id: string) {
  return serverClient.createToken(id);
}

We will store this messaging token inside our react-native application. We are using Zustand ❤️ for this.
Using this token, we are now able to connect a user to our GetStream client.

 const client = StreamChat.getInstance(config.stream.apiKey);

 const init = useCallback(async () => {
   try {
      // First disconnect any user that was still connected.
      await client.disconnectUser();
      await client.connectUser(
        {
          id: connectedUserId,
        },
        // Use the JWT token received from our messaging API endpoint.
        messagingToken.accessToken,
      );
    } catch (error) {
      logException(error);
    }
  }, [messagingToken, connectedUserId, client]);

We call this init function inside our ChatProvider that's wrapping our screens.

Let's continue to the next step in our onboarding process. We now need to initialise our 2FA with seald.
We created a screen where the user can enter his/her phone number.

When a user enters their phone number, we need to send a challenge that the user can enter on the following screen.
We created a custom hook useTwoFactorAuth to handle the setup of 2FA.

For doing actual API calls, we use react-query. I will not deep dive into every custom hook, the 3 hooks below are fetching some data with react-query
from our API endpoints.

  const { signup, isLoading } = useSignupSeald();
  const { fetchMe, isLoading: isLoadingFetchMe } = useMeSeald();
  const { sendChallenge, isLoading: isLoadingSendChallenge } = useSendChallenge();

When a user does not yet exist, we call the signup endpoint. This endpoint will make sure that the user is saved in our postgreSQL database and that a twoManRuleKey is created and stored in our database. To know more about the protection with the 2-man-rule, you can check the docs.

  const setup2FA = async (phoneNumber: string) => {
    let user: OnboardedUser;

    try {
      // The messaging API will be called to fetch an existing seald user, this is needed because the login will also execute this setup2FA hook.
      user = await fetchMe();
      // It's possible that the user early killed the application while the signup was still busy. If we were not able to
      // store an activation key, we need to signup the user again to receive one needed for the initiation of the identity.
      if (!user.activationKey) {
        user = await signup();
      }
      // eslint-disable-next-line @typescript-eslint/no-explicit-any
    } catch (error: any) {
      // User does not exist
      if (error?.error?.type === MessagingApiErrorType.USER_NOT_FOUND) {
        user = await signup();
      }
    }
  };

For seald to be able to work properly, we need to generate a user licence token in our backend. See docs for more information on how to do this. Whenever the endpoint to fetch the user or to signup the user is called, a licence token will be generated
and returned by our API.

When an existing user returns, the fetchMe endpoint will return the following response:

{
   "id":"0015r00000OxGgIAAV",
   "isEnrolled":true,
   "sealdId":"TESTING_0015r00000OxGgIAAV",
   "twoManRuleKey":"VCl2Z0U+LYZ6Fq2rjm40PFrYWlrLDIsSRgGufKo9wJGlxDAU+5mUwji21g2G86GzN3dLKsrdWmYbPZn0QTGa9g=="
}

When a new user is created during signup, the response from the signup endpoint will be:

{
   "activationKey":"dbbb72c5-b2c5-47db-ad4c-5dfec91918df:5b1f82d5f3cb073c0103a4aa55bdd900777a4b3b4b89b99d906af533f3358a6e:7f24176eff547227984710ac5b2d858b3a78af509225f5b6cdc41197254dd81a02b16d893b176ffd70c952b87c4ba95a1f98b9f0bc3d0926f117e832fa45a9f3",
   "id":"0015r00000Q0DQcAAN",
   "isEnrolled":false,
   "sealdId":"TESTING_0015r00000Q0DQcAAN",
   "twoManRuleKey":"miSTd8ad7FrtvNSMee+uLDLgj+tYCPf9iENm3CzsytILSw5YuMI1TEOtEF7sU46f4qa6KVF+wb3tU1cdbLzTBA=="
}

Now that our user is created, we can send the challenge to the user and initiate the seald identity with the activation key.

    if (user) {
      // The activation key is the user licence token from seald.
      const { sealdId, activationKey } = user;

      // Create session in seald, send challenge to user.
      await sendChallenge({ phoneNumber });

      if (sealdId && activationKey) {
        await seald.initiateIdentity(sealdId, activationKey);
      }
    }

The sendChallenge will call our Messaging API endpoint that implements the sending of a challenge according to the specifications.
Seald will create a "session" and this session will be required in the save or retrieve of our seald identity.

{
   "mustAuthenticate": true,
   "twoManRuleKey":"miSTd8ad7FrtvNSMee+uLDLgj+tYCPf9iENm3CzsytILSw5YuMI1TEOtEF7sU46f4qa6KVF+wb3tU1cdbLzTBA==",
   "twoManRuleSessionId":"c1c2b55f-f119-4a88-8a0d-e95512e3c667"
}

We can now continue to our last screen for entering the challenge.

A custom hook will be called when the challenge was entered:


export const useSaveOrRetrieveSealdIdentity = () => {
  const { updateUser } = useUpdateUser();
  const { enroll } = useEnroll();

  const sealdId = useStore(state => state.sealdId);
  const twoManRuleSessionId = useStore(state => state.twoManRuleSessionId);
  const twoManRuleKey = useStore(state => state.twoManRuleKey);
  const mustAuthenticate = useStore(state => state.mustAuthenticate);
  const userEnrolled = useStore(state => state.isEnrolled);

  return {
    saveOrRetrieveIdentity: async (phoneNumber: string, challenge: string) => {
      // Store phone number for later login purposes.
      await updateUser({ c_recoveryPhoneNumber: phoneNumber });

      // If user was already enrolled, the identity already exists so we need to retrieve it.
      // SSKS will be called, and the identity will be retrieved.
      if (userEnrolled) {
        await seald.retrieveIdentity(
          sealdId,
          twoManRuleSessionId,
          twoManRuleKey,
          challenge,
          phoneNumber,
        );
      } else {
        await seald.saveIdentity(
          phoneNumber,
          twoManRuleKey,
          sealdId,
          twoManRuleSessionId,
          mustAuthenticate,
          challenge,
        );

        if (!userEnrolled) {
          enroll();
        }
      }
    },
  };
};

We now have established a secure identity and can use this identity to create secure sessions between two users 🙌

Creating a secure chat

GetStream.io offers us very fine UI components that easily integrate in our react-native application. We have modified some components of GetStream, but in this example
I will only show the necessary things.

When creating a screen for the chat, you can start with a basis implementation like this:

  import { Channel, Chat } from 'stream-chat-react-native';

  const client = StreamChat.getInstance(config.stream.apiKey);
  const channel = client.channel("messaging", id, ["member1", "member2"]);

  return (
    <Chat client={client}>
        <Channel channel={channel} /> // Channel you created between two members.
    </Chat>
  );

Without encrypting/decrypting any messages, the chat will look like this:

But we want to be able to send messages encrypted. Therefore, we need to override the doSendMessageRequest method.
As you can see, we encrypt our message using an encryption session. This encryption session needs to be created when creating your channel.

When an encryption session between two users is created, we store the session ID on our channel metadata in getstream, so it can be reused to fetch an encryption session.

  const channel = client.channel("messaging", id, ["member1", "member2"]);
  await channel.watch();

  let session: EncryptionSession;

  if (channel.data?.session_id) {
    session = await seald.retrieveEncryptionSession(channel.data.session_id);
  } else {
    session = await seald.createEncryptionSession(members.map(member => member.sealdId));
    await channel.updatePartial({ set: { session_id: session.sessionId } });
  }

  const sendMessage = async (_channelId: string, message: Message) => {
    const encryptedText = await encryptionSession.encryptMessage(message.text || '');
    return channel.sendMessage({ ...message, text: encryptedText });
  };

  return (
    <Chat client={client}>
        <Channel
          channel={channel}
          doSendMessageRequest={sendMessage}
        />
    </Chat>
  );

If we send another message now, you can see that the message text is now encrypted and unreadable.

We need to override the MessageText component to show an unencrypted message.

  return (
    <Chat client={client}>
        <Channel
          channel={channel}
          doSendMessageRequest={sendMessage}
          MessageText={(props: MessageTextProps) => (
            <DecryptedMessageText
              {...props}
              channel={channel}
              session={encryptionSession}
              onError={handleDecryptionError}
              onFinished={handleDecryptionEnd}
            />
          )}
        />
    </Chat>
  );

Our DecryptedMessageText component will use our encryption session to decrypt the message.

import { useEffect, useRef, useState } from 'react';
import { useTranslation } from 'react-i18next';
import type { EncryptionSession } from '@seald-io/sdk/lib/main';
import type { MessageTextProps, MessageType as Message } from 'stream-chat-react-native';

import type { LocalChannel } from 'core/chat/types';

interface Props extends MessageTextProps {
  channel: LocalChannel;
  session: EncryptionSession;
}

const decryptMessage = async (text: string, session: EncryptionSession) => {
  try {
    // If we have  JSON, it can be decrypted.
    JSON.parse(text);
    try {
      if (!session) {
        throw new Error('EncryptionSession is undefined');
      }
      return await session.decryptMessage(text);
    } catch (err) {
      logException(err);
      return false;
    }
  } catch (err) {
    // Otherwise it's just plain text
    return text;
  }
};

const DecryptedMessageText = ({
  channel,
  session,
  message,
  renderText,
  theme,
  ...rest
}: Props) => {
  const { t } = useTranslation();
  const decryptedMessage = useRef<Message>(message);

  useEffect(() => {
    const decrypt = async () => {
      if (message.text) {
        const text = await decryptMessage(message.text, session);
        if (text === false) {
          // Handle errors
          return;
        }

        decryptedMessage.current = {
          ...message,
          text,
        };
      }
    };

    decrypt();
    // eslint-disable-next-line react-hooks/exhaustive-deps
  }, [message, session]);

  return renderText({
    ...rest,
    message: decryptedMessage.current,
  });
};

export default DecryptedMessageText;

Our message is now decrypted, and again visible for the members of the conversation.

When we take a look at the GetStream.io dashboard, we can also see that our messages are not readable, and so are securely encrypted 💪

![Dashboard getstream](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ddbpu7nfohvkqs06wfma.png)

Conclusion

Single point versioning with Fastlane for React Native

Thibault Maekelbergh — Mon, 31 Jan 2022 08:39:40 +0000

This post originally appeared on our ITP Dev blog

The issue

When upgrading (or "bumping") a React native app you often need to touch multiple files. You need to change the version in the node package manifests, update that same version and the build id in every Xcode scheme you use, and on Android either set the version via gradle.properties or via CLI flags when executing Gradle.

Previously at ITP we tackled this with a conceptually simple bash script. You supplied it the current version and desired version and it did basic find and replace with sed:

#!/usr/bin/env bash
set -e

function _replace_in_file() {
  if command -v sed > /dev/null; then
    sed -i -e "s/$1/$2/g" "$3"
  else
    echo "You don't have sed and this script relies on it."
    echo "Please install sed via apt or brew"
    exit 1
  fi
}

function bump_android() {
  echo "Updating gradle.properties"

  _replace_in_file "$1" "$2" ./android/gradle.properties
  # shellcheck disable=SC2001
  _replace_in_file "$(echo "$1" | sed -e 's/\.//g')0" "$(echo "$2" | sed -e 's/\.//g')\0" ./android/gradle.properties
}

function bump_ios() {
  local schemes=("appstore" "client" "dev" "release")
  for scheme in "${schemes[@]}"; do
    echo "Updating Xcode scheme: $scheme"
    _replace_in_file "$1" "$2" "./ios/RNApp/Info-$scheme.plist"
  done
}

function bump_node() {
  echo "Updating package.json, package-lock.json"

  _replace_in_file "\"version\": \"$1\"" "\"version\": \"$2\"" package.json

  # Regenerate package-lock
  npm i --ignore-scripts
}

function main() {
  if [[ -z "$1" || -z "$2" ]]; then
    echo "Commands supplied were not valid."
    echo "This script expects the following form:"
    echo "  $ ./bump-version.sh <old_version> <new_version>"
    exit 1
  fi

  echo "Performing version bump from $1 👉 $2..."

  bump_node "$@"
  bump_android "$@"
  bump_ios "$@"

  # sed outputs some clutter files suffixed with -e, we delete them with xargs
  if [ "$(uname)" == "Linux" ]; then
    find . -type f -name \*-e -print0 | xargs --null /bin/rm -rf
  else
    find . -type f -name \*-e -print0 | /usr/bin/xargs -0 /bin/rm -rf
  fi
}

main "$@"

However, for people not familiar with Bash this script is some advanced dark magic. It was also reliant on which sed you have available on the system, GNU or BSD (see the check at the end of the script). The files changed were standards for iOS & node, but for Android we used an older way of putting the version in a variable inside of gradle.properties and then read that variable during the gradle assemble task.

Why automate

Why automate something you could just change in VS Code or Xcode in the relative files? Well, version upgrades might not happen that often and then you need to either take your chances or ask around with coworkers if they remember the files that need to be changed. It's also super fast for newcomers in the team or to native development to just run the script (however they won't know the deeper details of what's happening).

You could, if desired, also just run this in a CI pipeline and have CI take care of automating version upgrades instead of making it a semi-automatic process via script.

This worked great for a few years, but when I came to think about it this way is still a bit to over engineered. We already use the great Fastlane tool in all our projects for building iOS & Android so surely there must be a way to make it easier and integrated with Fastlane.

Single point versioning via Fastlane

The solution to this in Fastlane is really easy:

Use Fastlane's load_json plugin and read node's package.json
Get the semver version e.g 1.0.0 from the version property
Append a unique build identifier. We use the job ID from our CI/CD pipeline
Join version and build id to a string
Set that as the version in Fastlane gradle & gym tasks.

This gives us a single point to manage the version: package.json. Updating the version there makes Fastlane read that and supply it to gym/gradle relative commands.
We abstracted this to a utils.rb ruby module since we use different schemes and build configurations, but if you have a simpler app it could just as well be written inline or at the top of your Fastfile

utils.rb

def load_build_metadata(opts)
  package = load_json(json_path: './package.json')
  build_id = ENV['AZURE_UNIQUE_BUILD_ID']

  if build_id.nil? || build_id.empty?
    puts "Required environment variable 'AZURE_UNIQUE_BUILD_ID' not found. Got: #{build_id}"
    exit(1)
  end

  app_version = package['version']
  build_number = build_id.gsub('.', '') # We expect a date format like 20211122.6 here and trim the dot

  # Return a hashmap with all version metadata we could be interested in
  Hash[
    'build_number' => build_number,
    'app_version' => app_version,
    'full_version' => "#{app_version}#{opts[:suffix] || ''}.#{build_number}"
  ]
end

Fastfile

platform :ios do
  desc '📱🥉 Build iOS Client'
  lane :build_client do
    add_app_icon_badge(label: 'client')
+   build_metadata = load_build_metadata(suffix: opts[:suffix])

    update_settings_bundle(
      xcodeproj: "ios/RNApp.xcodeproj",
      configuration: 'Client',
      target: 'RNApp-iOS',
      key: 'version_preference',
+     value: build_metadata['full_version']
    )

    set_info_plist_value(
      path: "ios/RNApp-iOS/Info-Client.plist",
      key: 'CFBundleShortVersionString',
+     value: build_metadata['app_version']
    )

    set_info_plist_value(
      path: "ios/RNApp-iOS/Info-Client.plist",
      key: 'CFBundleVersion',
+     value: build_metadata['full_version']
    )

    gym(...)
  end
end

platform :android do
  desc '🤖🥉 Build Android Client'
  lane :build_client do
    add_app_icon_badge(label: 'client')
+   build_metadata = load_build_metadata(suffix: opts[:suffix])

    gradle(project_dir: 'android', task: 'clean')

    gradle(
      project_dir: 'android',
      task: 'assemble',
      build_type: 'Clientrelease',
      properties: {
+       "android.injected.version.name": build_metadata['full_version'],
+       "android.injected.version.code": build_metadata['build_number']
      }
    )
  end
end

Conclusion

We now just need to do npm version minor and commit that the branch so the CI pipeline can pick it up 👷🏻‍♂️

And then to summarise, this way of versioning multiple configurations/schemes is better for us because:

We stopped using gradle.properties to version Android and inject it into Gradle by reading from the properties file! Instead we now use CLI flags passed to Gradle under the hood to configure versions at build time rather than in code.
Creating a new version is actually handled by the one tool in control: Fastlane. The need to manually bump the correct files is gone. We narrowed it down to one: package.json
This works regardless of which OS you are running on or which version/flavour of bash and subtools you use (e.g sed, xargs)
It's more declarative than the bash script which required some knowledge of bash. That's not a common thing.
The file typically doesn't change a lot, and if it does, anyone can easily solve/adapt it.

"Fixing" React Navigation & iOS screen reader focus

Thibault Maekelbergh — Thu, 08 Apr 2021 09:14:41 +0000

The problem

During some extensive accessibility (mainly screen reader) testing on a React Native app we're currently developing, we bumped into an issue where focus would be lost for the screen reader when navigating to a new view in a stack using React Navigation.

You would transition from the overview to a detail page, but instead of respecting the navigation tree for that page, React Navigation would focus the screen reader on the position where your focus was in the previous screen. This would pose a big problem of course: Imagine scrolling through a long list (FlatList), then navigating to the detail for the item you tapped, and having the screen reader focus somewhere on the middle of the screen.

This issue was however only happening on iOS. My guess was that React Navigation in some way does not respect the iOS native navigation elements and does some JS things inbetween, which makes iOS act up in this case.

The "fix"

To fix it, we created the useAccessibilityFocus hook! It’s very simple and will just return a ref to bind to your element, and a function to trigger focus to the element carrying the ref:

import type { MutableRefObject } from 'react';
import { useCallback, useRef } from 'react';
import { AccessibilityInfo, findNodeHandle, Platform } from 'react-native';

/**
 * Returns a ref object which when bound to an element, will focus that
 * element in VoiceOver/TalkBack on its appearance
 */
export default function useAccessibilityFocus(): [MutableRefObject<any>, Void] {
  const ref = useRef(null);

  const setFocus = useCallback(() => {
    if (Platform.OS === 'ios') {
      if (ref.current) {
        const focusPoint = findNodeHandle(ref.current);
        if (focusPoint) {
          AccessibilityInfo.setAccessibilityFocus(focusPoint);
        }
      }
    }
  }, [ref]);

  return [ref, setFocus];
}

Now we can call it in a useEffect or even better, React Navigation's useFocusEffect to focus on the element when the screen appears:

const DetailScreen = ({ navigation }) => {
  const [focusRef, setFocus] = useAccessibilityFocus();

  useFocusEffect(setFocus);

  return (
    <View>
      <TitleInput />
      <View ref={focusRef}>
        <Text>Content I want the focus on</Text>
      </View>
    <View>
  )
}

Another way would be to hook into a listener on your stack’s screens:

const RootNav = () => {
  const [focusRef, setFocus] = useAccessibilityFocus();

  return (
    <Stack.Navigator>
      <Stack.Screen component={OverviewScreen} />
      <Stack.Screen
        component={DetailScreen}
        options={{
          header: () => (
            <NavHeader ref={focusRef} title="Detail" />
          ),
        }}
        listeners={{
          transitionEnd: () => setFocus()
        }}
      />
    </Stack.Navigator>
  )
}

Worth noting that now, we have the added benefit that we can use this hook in other situations! Rather than moving to another view in the stack, we can now use this to trigger screen reader focus to modals, notifications, alerts, errors etc. Just be sure to remove the Platform.OS check in the hook in that case

The solution

The real fix however, is that React Navigation fixes this issue in their core implementation so that focus is carried along when navigating to another screen. A PR discussion about this is open, you can even see yours truly in the discussion, but sadly no development towards fixing this has been done I guess.

Flutter Europe 2020: My First Developer Conference

Bram De Coninck — Sat, 08 Feb 2020 21:22:01 +0000

This year the first Flutter Europe conference took place in Warsaw (Poland) on January 23 and January 24. It was packed with interesting talks and it was awesome to meet other members of the Flutter community. I've learned a lot about animations, performance, augmented reality, building games, domain-driven-design, convincing companies and clients of Flutter's awesomeness, ... In this article I'll share some insights on what was undoubtedly one of the most amazing experiences of my life.

The talks

There were 26 talks in total but 2 were always given at the same time, so you could only attend 13 talks in total. Sometimes it was very difficult to device which talk would be more interesting or fun. Luckily, all talks will soon be published on the Flutter Europe YouTube channel.

I've learned something useful from every talk I attended and I enjoyed all of them, but if I had to pick my 5 favourite talks it would be these:

Performance: Optimizing your Flutter app
Augmented Reality in Flutter
Animations in Flutter Done Right
Building games using Flame
How to convince business to Flutter? Real-life cases

Unfortunately I missed out on some interesting talks. Apparently 'Implementing complex UI with Flutter' was an amazing talk. From what I've heard, Marcin Szałek really had the audience in the palm of his hand. He was able to explain this topic so well that creating complex UI didn't look so difficult or intimidating anymore. This is definitely the first talk I'm going to watch as soon as they're available online.

The Flutter community

If you're anything like me you read Flutter articles, watch Flutter videos, listen to Flutter podcasts, ... on (almost) a daily basis. A lot of the more famous Flutter community members who create this content attended Flutter Europe. I'm really glad I was able to meet so many of my personal heroes and heroines, like Emily Fortuna, Filip Hráček, Matt Rešetár, Simon Lightfoot, Rémi Rousselet, Felix Angelov, Jorge Coca, Hillel Coren, the Codemagic team, ...

They say you should never meet your heroes, but that's not true if your heroes/heroines are members of the Flutter community.

It was also amazing to meet a lot of other members of the Flutter community. On my plane to Warsaw the two people sitting next were also attending Flutter Europe, and I met a lot of others there in between the talks, during lunch or at the two parties.

I was travelling by myself, but there was never a moment where I was alone. I'm usually an introvert but it was so easy to connect with other Flutter developers. I heard a lot of amazing stories about other people's experiences with Flutter and I'm glad I was also able to share my own.

The loot

As I've already mentioned in the title, this was my first developer conference. I've only attended gaming conferences like Gamescom so far. When I go to one of those I know I'll bring home a backpack full of loot, a.k.a. gadgets, toys and merchandise. I didn't expect this to happen at Flutter Europe. I wanted to attend this conference for the knowledge and the networking opportunity, but secretly I hoped I' go home with one of those Dash plushies you see everywhere on social media...

You should be going to a conference for the knowledge instead of the loot, but I can't be the only Flutter developer who wanted to get his hands on a Dash bird plushie, right?

Ever since I learned of their existence I knew I wanted one. I'm really glad attendees were able to earn one by completing a programming challenge. The challenge itself wasn't very hard, the most difficult part was typing on a German keyboard (the semicolon was very well hidden).

Everyone who attended received a Flutter t-shirt and a goodiebag with a hat, a water bottle and some other things. If you visited the booths of GDG, Codemagic, LeanCode and the others, you were also able to get some other t-shirts, all kinds of stickers, ...

My personal highlights

Because I wanted the complete Flutter Europe experience I decided to go to the first party, the one before the conference started. This party took place in a stupendous building called the 'Warsaw Spire'. When I was standing in line to get my badge, someone who seemed quite familiar came to stand next to me. It was Matt Rešetár, a.k.a. Resocoder. In my opinion, his Flutter videos are the best you can find on YouTube and it was an honour to meet him.

At this party I was also finally able to meet Marie Jaksman in real life. You might know her if you're a member of the Codemagic community. She introduced me to Łukasz Kosman, one of the organisers of Flutter Europe and also the co-founder of LeanCode. He gave the 'How to convince business to Flutter? Real-life cases' talk on the second day. Marie told him I was the person who wrote the article about Flutter vs. other mobile development frameworks. His reaction was amazing, but also very unexpected.

He said that he had a slide in his presentation about an experiment I conducted for my article. I was flabbergasted (or should I say fluttergasted?).

This was the first article I've ever written, but apparently it was quite popular. To my surprise, some of the people I met at Flutter Europe had read it. The fact that it was also a part of a presentation at Flutter Europe was definitely a highlight for me.

There's another person worth mentioning who definitely made the whole Flutter Europe experience even better. His name is Dylan Beattie. The first time we saw him was at the party after the first day of the conference where he gave a performance. He turned Billy Joel's 'Piano Man' into 'Bug in the Javascript', Bon Jovi's 'You give love a bad name' into 'You give REST a bad name', ... If you're a programmer who's into the rock classics, you should definitely visit his YouTube channel.

Dylan also gave the last talk of the conference named 'The Art of Code'. He gave some amazing examples of why programming could/should be considered a form of art and at the end of the presentation he talked about a special project of his. Dylan is the creator of 'Rockstar', a programming language designed for creating computer programs that are also song lyrics. It's difficult to explain how amazing his talk was, but you can watch it here and see for yourself. I can guarantee you that you'll enjoy it!

Conclusion

In my opinion, and I'm convinced a lot of other attendees agree with me, Flutter Europe 2020 was an amazing experience. This was only the first edition, but the organisers already got so many things right. Hopefully Flutter Europe 2021 will be even bigger and better. I'm happy I was able to attend and I can't wait for next year's edition!

Localising Flutter applications and automating the localisation process

Bram De Coninck — Thu, 30 Jan 2020 19:16:40 +0000

Developing a small application or PoC in one language is acceptable, but as soon as you release an app to the public you might want to consider localising it first. I live in Belgium, a country best known for its chocolate, waffles, fries and beer. We have three official languages: Dutch, French and German. We also have English as an unofficial language. If I want to publish an app and I want as many Belgians as possible to be able to use it, it'll definitely need to support these languages.

The more languages and locales your application supports, the bigger your target audience will be.

In this article I will guide you through localising your Flutter application using .arb (Application Resource Bundle) files and the Intl package. I will also show you how you can automatically provide your app with the latest translations using the Loco tool. I've written a shell script that can be run locally or used by a CI/CD tool of choice. I'll be using Codemagic because it's easy to set up and visualise.

Adding the dependencies to the project

Before you can localise your Flutter app, you'll first need to add some dependencies to the pubspec.yaml file of your project.

dependencies:
  flutter:
    sdk: flutter

  flutter_localizations:
    sdk: flutter

dev_dependencies:
  flutter_test:
    sdk: flutter

  intl_translation: ^0.17.7

Localisation in the MaterialApp

Most of the setup for the localisation happens in the MaterialApp, which is the heart of your Flutter app. It doesn't necessarily have to be a MaterialApp though, it can also be a CupertinoApp or a WidgetsApp. This is the place where the supported locales are defined and is decided which locale is going to be used in the app. It's also where we'll add our own localisations delegate, which is where the rest of the magic happens.

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Localisation Demo';
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: HelloWorld(),
      // List of all supported locales (language code followed by country code).
      // For this example, I'll be using Belgian English, Belgian Dutch and Belgian French.
      // The order of the supported locales is very important because a fallback mechanism is used.
      supportedLocales: const [
        Locale('en', 'BE'),
        Locale('nl', 'BE'),
        Locale('fr', 'BE'),
      ],
      // These delegates are responsible for loading the translations of the selected locale.
      localizationsDelegates: [
        // This is where all translations are defined, will be added later.
        const AppLocalizationsDelegate(),
        // Built-in delegate for the localisation of the Material widgets (e.g. tooltips).
        GlobalMaterialLocalizations.delegate,
        // Built-in localisation for text direction (left-to-right or right-to-left).
        GlobalWidgetsLocalizations.delegate
      ],
      // This is where it's decided which locale should be used.
      localeResolutionCallback: (Locale locale, Iterable<Locale> supportedLocales) {
        for (final supportedLocale in supportedLocales) {
          // The language of the device of the user is compared to every supported language.
          // If the language codes match, the supported locale with that language code is chosen.
          // This allows users using American English or British English as locales
          // to be able to use the Belgian English localisation.
          if (locale.languageCode == supportedLocale.languageCode) {
            return supportedLocale;
          }
        }

        // If the language of the user isn't supported, the default locale should be used.
        return supportedLocales.first;
      },
    );
  }
}

Creating the AppLocalizations class and the AppLocalizationsDelegate

The AppLocalizations class contains the logic to load the messages (= translations) of a given locale. It's also where you'll define all Intl messages that will be used in the app. All messages should be in the same language, the language of the 'source locale' of your project. In this case it's Belgian English.

I've created two Intl messages: one for the app title and one for a 'hello world' message that we'll use later in the UI.

class AppLocalizations {
  static Future<AppLocalizations> load(Locale locale) {
    final String name = locale.countryCode == null || locale.countryCode.isEmpty
      ? locale.languageCode
      : locale.toString();
    final String localeName = Intl.canonicalizedLocale(name);

    return initializeMessages(localeName).then((_) {
      Intl.defaultLocale = localeName;
      return AppLocalizations();
    });
  }

  // Localizations are usually accessed using the InheritedWidget "of" syntax.
  static AppLocalizations of(BuildContext context) {
    return Localizations.of<AppLocalizations>(context, AppLocalizations);
  }

  // Messages which contain a string in the default language of your app and a name as identifier.
  // CamelCasing is required for the name of the Intl message.
  String get appTitle => Intl.message('Localisation Demo', name: 'appTitle');
  String get helloWorld => Intl.message('Hello world!', name: 'helloWorld');
}

The AppLocalizationsDelegate is the glue between the AppLocalizations class and the MaterialApp. The load function returns an AppLocalizations object as it contains all localised messages. The isSupported function can be used to check if a certain locale (or in this case language code) is supported.

class AppLocalizationsDelegate extends LocalizationsDelegate<AppLocalizations> {
  // As the instance of this delegate will never change, it can have a const constructor.
  const AppLocalizationsDelegate();

  // Checks whether or not a certain locale (or language code in this cast) is supported.
  // The order of the locales doesn't matter in this case.
  @override
  bool isSupported(Locale locale) => ['en', 'nl', 'fr'].contains(locale.languageCode);

  // Load the translations of a certain locale.
  @override
  Future<AppLocalizations> load(Locale locale) => AppLocalizations.load(locale);

  // Defines whether or not all the app’s widgets should be reloaded when the load method is completed.
  @override
  bool shouldReload(LocalizationsDelegate<AppLocalizations> old) => false;
}

If you copy/paste this code you'll get an error on the initializeMessages method, as it's not defined yet. This method will be generated later by the Intl package. Before you can start providing translations to your Flutter app, you first need to create a Loco project.

Creating the Loco project

Head over to Loco and create an account if you don't already have one. Loco has a generous free plan which allows you to create two projects. Create a new Loco project and make sure to select the same source locale you've used for your Intl messages.

Next, head over to 'Developer Tools' and click on 'API Keys'. This will open up a dialog in which you can create a 'Full access key' for your project. Make sure to save this key somewhere, as it's impossible to retrieve it later. In case you lose this key, you'll have to generate a new one.

How Flutter works together with Loco

Your Flutter app will interact with Loco in two ways. The Intl messages you created in the AppLocalizations class will be imported into Loco. Everytime you add or update these translations your Loco project will get an update as well. New assets will be created in your source locale or existing assets will get a new value. The second way you use Loco is by downloading all translations for all locales in .arb format and then turning these files into .dart files.

It doesn't have to be the job of the developer to provide the translations for the app, it can also be done by a product owner or a client for example.

In your Loco project you can choose additional locales you want to support, in my case Belgian Dutch and Belgian French. Translating messages for a new locale from your source locale can be done by a very user-friendly GUI. You don't need to be a technical person to add or edit translations.

Automating the localisation process

Importing messages into Loco and exporting translations from Loco can be done manually, but it's a tedious process. These are the steps that need to be taken for the entire localisation process:

Generate .arb files from the Intl messages defined in the AppLocalizations class.
Import those .arb files into the Loco project to add/update the translations for the source locale.
Fetch the latest translations for all locales in .arb format from the Loco project.
Generate .dart files from these translations.

It's possible to automate this process with a simple shell script I've provided below. The only thing you need to do is provide a value for all variables: your Loco API key, the path of the AppLocalizations class and the desired output path for the translations.

#!/usr/bin/env sh

set -e # Exit on first failed command

# Variables
LOCO_API_KEY="LOCO_API_KEY"
APP_LOCALIZATIONS_PATH="lib/app_localizations.dart"
OUTPUT_PATH="lib/l10n"

# Get packages
flutter packages get

# Generate .arb files
mkdir l10n-input
flutter pub pub run intl_translation:extract_to_arb --output-dir=l10n-input $APP_LOCALIZATIONS_PATH

# Import translations into Loco
curl -f -s --data-binary "@l10n-input/intl_messages.arb" "https://localise.biz/api/import/arb?async=true&index=id&locale=en&key=$LOCO_API_KEY"

# Export translations from Loco
curl -s -o "translated.zip" "https://localise.biz/api/export/archive/arb.zip?key=$LOCO_API_KEY"
unzip -qq "translated.zip" -d "l10n-translated"

# Create directory for output if it doesn't exist yet
if [ ! -d $OUTPUT_PATH ]
then
    mkdir $OUTPUT_PATH
fi

# Generate Dart files with translations
flutter pub pub run intl_translation:generate_from_arb --output-dir=$OUTPUT_PATH --no-use-deferred-loading $APP_LOCALIZATIONS_PATH l10n-translated/*/l10n/intl_messages_*.arb

# Cleanup
rm translated.zip
rm -rf l10n-translated
rm -rf l10n-input

It's possible to run this script locally but you can also integrate it into your CI/CD tool of choice. I've chosen to use Codemagic because it's easy to set up and use. Codemagic allows you to execute shell scripts before and after every phase of a build. It's important to execute this script before the build phase though. I've decide to run the script before the test phase.

Using a CI/CD tool to fetch translations automatically will make sure users always have the most recent translations.

The reason it's so useful to integrate this script into a CI/CD tool is that with every build of the application the latest translations will be fetched automatically. A developer might forget to fetch the latest translations before releasing a new version of the Flutter app to the stores and it's possible that another person has added or updated translations on Loco.

Using localised messages in the UI

In the example below you can see how to get a localised message from the AppLocalizations class and use it in a Text widget. Try changing the language of your device without closing the app. When you open the app again, the widget will be rerendered automatically and display the message in the language you've selected (as long as it's supported, obviously).

class HelloWorld extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: Text(AppLocalizations.of(context).helloWorld),
      ),
    );
  }
}

Using localised messages without context

Using localised messages without context is possible but it's a bit hacky in my opinion. There's currently no other way to do it though.

It can sometimes be useful to get a localised message without using context, in a BLoC or a ViewModel for example.

class AppLocalizations {
  static AppLocalizations current;

  AppLocalizations._(Locale locale) {
    current = this;
  }

  static Future<AppLocalizations> load(Locale locale) {
    final String name = locale.countryCode == null || locale.countryCode.isEmpty
      ? locale.languageCode
      : locale.toString();
    final String localeName = Intl.canonicalizedLocale(name);

    return initializeMessages(localeName).then((_) {
      Intl.defaultLocale = localeName;
      return AppLocalizations._(locale);
    });
  }

  // Localizations are usually accessed using the InheritedWidget "of" syntax
  static AppLocalizations of(BuildContext context) {
    return Localizations.of<AppLocalizations>(context, AppLocalizations);
  }

I've added a static AppLocalizations object in the AppLocalizations class. It gets its value from the private constructor, which is used in the load method. As you can see in the example below, it's now possible to use localised messages without context.

class HelloWorld extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: Text(AppLocalizations.current.helloWorld),
      ),
    );
  }
}

Localising the app title

It's also possible to localise the name of your application by using the onGenerateTitle callback of the MaterialApp at the root of your project. Make sure you're not using the 'title' property of the MaterialApp.

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: HelloWorld(),
      // Make sure you're not using the title property!
      onGenerateTitle: (BuildContext context) => AppLocalizations.of(context).appTitle,
      ...
    );
  }
}

Conclusion

This approach makes localising your Flutter apps a lot easier. Developers create or adjust Intl messages in the source locale in the AppLocalizations class. Anyone can provide translations for those messages on Loco, it doesn't have to be the developer. Using the provided script and a CI/CD tool of choice will make sure the Flutter app and the Loco project are always synchronised. This allows the users of the Flutter app to always have the most recent translations.

Flutter Versus Other Mobile Development Frameworks: A UI And Performance Experiment

Bram De Coninck — Mon, 13 Jan 2020 22:21:15 +0000

I’ve already read a lot of articles about how Flutter compares to other mobile development frameworks, but most of them were written from a theoretical point of view. It’s already been well established that Flutter is a solid choice for creating mobile applications and that it’s a worthy opponent to frameworks like React Native and Xamarin Forms.

Everyone agrees that Flutter looks good on paper, but how can companies who still doubt Flutter be convinced that they should at least consider using it? Theories and opinions are one thing, but what we really need more of is proof of Flutter’s capabilities and performance.

This year I graduated in Applied Computer Science at University College Ghent in Belgium. During my last year I was given the opportunity to write a thesis around a topic of my choice. I decided to write my thesis around Flutter because I hoped it would be one of the first of its kind. In the first section I discussed how Flutter works, what Dart is and why it’s ideal for Flutter and I also discussed a couple of state management techniques. In the second section I performed two experiments.

During the first experiment I created the same app five times, each time with a different framework. The frameworks I used were native Android, native iOS, Flutter, Xamarin Forms and React Native. During the second experiment I measured the CPU usage of the apps I created in the first experiment. In this article I will share the results of these experiments.

Creating the same application five times

I’m going to be honest with you, this first experiment wasn’t really fair. I don’t have the same amount of experience with every framework I used. If I were to make a ranking of the amount of experience I had with each framework from highest to lowest, it would probably look like this:

Android
Flutter
Xamarin Forms
iOS
React Native

I do however want to point out that I had already created mock-ups of the application so I wouldn’t have to mess around with thinking about the UI during the development of the first app. I also knew enough about every framework to create the application without Googling a lot, so there wasn’t much of a learning curve.

The name of the application I created is Cocktailr. As the name indicates, this app is for cocktail lovers who want to discover new cocktails and also search for cocktails they can make with ingredients they have or want to use.The application exists out of four screens: a cocktail list screen, a cocktail detail screen, an ingredient list screen and a cocktail creation screen. The images underneath are the mock-ups I created before developing the applications. I don’t think I have to show you the screens of the five apps I created because, spoiler alert, they all look nearly identical to the mock-ups (apart from some minor inconsistencies which I’ll discuss later). Instead, I’m going to discuss what it was like to develop the app with each framework and also point out some of the difficulties I encountered. I’m also going to compare the amount of time it took to create the apps per framework.

Creating the native Android application

To create the native Android application I used Android Studio as IDE and Kotlin as programming language. The 3rd party packages I relied on were Glide for fetching network images, Retrofit for consuming HTTP requests and GSON to convert JSON objects into POJOs (Plain Old Java Objects). I also used something called the Navigation Component, which is a part of Android Jetpack, a suite of libraries, tools, and guidance to help developers write high-quality apps easier. It was still in alpha at the time, but I loved it and I felt comfortable using it.

To create layouts on Android you can either use a visual layout builder or you can create it in XML. Usually you’ll work with both to get the best of both worlds.

The main problem I had (and still have) with Android development is that there are too many ways to accomplish a certain task. If you were to Google how to make network requests on Android you would discover all kinds of different packages and documentation. That’s why the Android developers at Google are currently working on Android Jetpack, the set of tools I mentioned earlier. This will make finding the right tools to solve your problems more straightforward. Since both Java and Kotlin are supported for Android development, you’re sometimes going to find code samples or tutorials written in the language you’re not using. Android Studio does have support for turning Java code into Kotlin code but the ‘translation’ isn’t always 100% accurate.

Another difficult problem is that it can be quite hard to add elements to your layout dynamically (Jetpack Compose, which allows you to create layouts declaratively like with Dart, wasn’t around when I created this project). On the cocktail detail screen I wanted to add a table with the names of the ingredients of the cocktail and also a measurement per ingredient. I found it quite difficult to add rows to a table programmatically. There isn’t a lot of information about it in the official Android documentation, so when you have a problem like this you’re probably going to have to look for a solution on websites like StackOverflow. I was eventually able to add the rows programmatically but the solution was, in my opinion, quite cumbersome. The Kotlin code underneath is the function I wrote to create table rows programmatically.

private fun createTableRows() {
    tl_cocktail_detail_ingredients.removeAllViews()

    val params = TableRow.LayoutParams(0, TableRow.LayoutParams.WRAP_CONTENT, 1f)

    val tv1 = TextView(this.context)
    tv1.text = "INGREDIENT"
    tv1.background = ContextCompat.getDrawable(context!!, R.drawable.grid_border)
    tv1.setPadding(6, 6, 6, 6)
    tv1.layoutParams = params
    tv1.gravity = Gravity.CENTER
    tv1.setTextColor(ContextCompat.getColor(this.context!!, R.color.black))
    tv1.typeface = Typeface.DEFAULT_BOLD

    val tv2 = TextView(this.context)
    tv2.text = "AMOUNT"
    tv2.setPadding(6, 6, 6, 6)
    tv2.layoutParams = params
    tv2.gravity = Gravity.CENTER
    tv2.setTextColor(ContextCompat.getColor(this.context!!, R.color.black))
    tv2.typeface = Typeface.DEFAULT_BOLD

    val tr = TableRow(this.context)
    tr.background = ContextCompat.getDrawable(context!!, R.drawable.grid_border)

    tr.addView(tv1)
    tr.addView(tv2)

    tl_cocktail_detail_ingredients.addView(tr)

    if (!cocktail?.ingredients.isNullOrEmpty() && !cocktail?.measurements.isNullOrEmpty()) {
        cocktail!!.ingredients.forEachIndexed { index, ingredient ->
            val tv1 = TextView(this.context)
            tv1.text = ingredient
            tv1.background = ContextCompat.getDrawable(context!!, R.drawable.grid_border)
            tv1.setPadding(32, 6, 6, 6)
            tv1.layoutParams = params

            val tv2 = TextView(this.context)
            if (index >= cocktail!!.measurements.count()) {
                tv2.text = ""
            } else {
                tv2.text = cocktail!!.measurements[index]
            }
            tv2.setPadding(32, 6, 6, 6)
            tv2.layoutParams = params

            val tr = TableRow(this.context)
            tr.background = ContextCompat.getDrawable(context!!, R.drawable.grid_border)

            tr.addView(tv1)
            tr.addView(tv2)

            tl_cocktail_detail_ingredients.addView(tr)
        }
    }
}

Something that isn’t really an issue but I also find quite cumbersome is how certain styling has to be done. Let’s say you want to create a text field with a border around it. To accomplish this, you’ll have to add the text field to the layout of your screen but you’ll also have to create a separate XML file to define the border. Then, you need to set that separate file as the background of the text field. It isn’t difficult at all, it just feels like a lot of work for such a simple task. The XML code underneath is set as background of the textfield to create a border around it.

<?xml version="1.0" encoding="utf-8"?>
<shape xmlns:android="http://schemas.android.com/apk/res/android" android:shape= "rectangle">
    <solid android:color="#ffffff"/>
    <corners android:radius="5dp" />
    <stroke android:width="1dp" android:color="#000000"/>
</shape>

Creating the native iOS application

To create the native iOS application I used Xcode as IDE and Swift as programming language. No 3rd party packages were used. I based my way of working on the book “App Development with Swift”, which is an official book by Apple.

Even though I’m an Android developer at heart, I must say it’s a lot easier to find the best way to tackle a certain problem. There are for example less ways to add functionality like consuming HTTP requests, which makes it easier to find the solution that fits best for the needs of your project.

Something that I had to figure out that wasn’t described in the book was how to subscribe to changes happening in the cocktail repository, the class were all cocktail objects are stored. I didn’t want to refetch all cocktails every time the cocktail list screen was opened. To solve this problem I used something called the NotificationCenter.

Thanks to the book I mentioned earlier I hardly had to google anything. In fact, the article I found on NotificationCenter was the only source of information I used apart from the book. I was lucky that the article had an example on how to use it in Swift, but during the development of other applications I encountered the same issue I had on Android. Older articles or StackOverflow answers might have solutions provided in Objective-C, the language used for iOS development before Swift was introduced. Even though I didn’t have this issue during the development of the native iOS application for Cocktailr, I thought it was worth mentioning that it exists.

My main issue with iOS development is that a Storyboard, the visual layout builder for iOS apps, can be more complex than necessary. For example, finding a setting to add a border around a text field can be very difficult. Luckily, it’s a lot easier to do this programmatically than it is in Android. SwiftUI, a way to create layouts declaratively with Swift, wasn’t around when I created this app by the way. It’s also possible to make changes to your layout in the XML file of a Storyboard, but unlike Android, the XML is a mess. The XML code underneath is the cocktail list screen, which actually only contains a list when you think about it.

<scene sceneID="aud-0C-1Pk">
    <objects>
        <tableViewController id="3Sf-E8-Zfo" customClass="CocktailTableViewController" customModule="Cocktailr_iOS" customModuleProvider="target" sceneMemberID="viewController">
            <tableView key="view" clipsSubviews="YES" contentMode="scaleToFill" alwaysBounceVertical="YES" dataMode="prototypes" style="plain" separatorStyle="default" rowHeight="-1" estimatedRowHeight="-1" sectionHeaderHeight="28" sectionFooterHeight="28" id="9Np-nI-tQC">
                <rect key="frame" x="0.0" y="0.0" width="414" height="896"/>
                <autoresizingMask key="autoresizingMask" widthSizable="YES" heightSizable="YES"/>
                <color key="backgroundColor" white="1" alpha="1" colorSpace="custom" customColorSpace="genericGamma22GrayColorSpace"/>
                <prototypes>
                    <tableViewCell clipsSubviews="YES" contentMode="scaleToFill" preservesSuperviewLayoutMargins="YES" selectionStyle="default" indentationWidth="10" reuseIdentifier="CocktailCell" id="qUV-tm-57K" customClass="CocktailTableViewCell" customModule="Cocktailr_iOS" customModuleProvider="target">
                        <rect key="frame" x="0.0" y="28" width="414" height="44"/>
                        <autoresizingMask key="autoresizingMask"/>
                        <tableViewCellContentView key="contentView" opaque="NO" clipsSubviews="YES" multipleTouchEnabled="YES" contentMode="center" preservesSuperviewLayoutMargins="YES" insetsLayoutMarginsFromSafeArea="NO" tableViewCell="qUV-tm-57K" id="4Hj-H9-rtF">
                            <rect key="frame" x="0.0" y="0.0" width="414" height="43.5"/>
                            <autoresizingMask key="autoresizingMask"/>
                        </tableViewCellContentView>
                        <connections>
                            <segue destination="IYp-bk-shv" kind="show" identifier="CocktailDetailSegue" id="bjc-Sd-8ni"/>
                        </connections>
                    </tableViewCell>
                </prototypes>
                <connections>
                    <outlet property="dataSource" destination="3Sf-E8-Zfo" id="Arh-Wp-anV"/>
                    <outlet property="delegate" destination="3Sf-E8-Zfo" id="qJE-tE-xa7"/>
                </connections>
            </tableView>
            <navigationItem key="navigationItem" title="Cocktailr" id="0Li-fu-c3B">
                <barButtonItem key="backBarButtonItem" title=" " id="4vq-K8-peJ"/>
                <barButtonItem key="rightBarButtonItem" title="Search" image="Search Icon" id="fCh-D0-Tws">
                    <connections>
                        <action selector="searchBarButtonClick:" destination="3Sf-E8-Zfo" id="0Pk-I0-Hsb"/>
                    </connections>
                </barButtonItem>
            </navigationItem>
            <connections>
                <segue destination="UPM-k4-dYF" kind="show" identifier="SearchTableViewSegue" id="e9G-mk-bUI"/>
            </connections>
        </tableViewController>
        <placeholder placeholderIdentifier="IBFirstResponder" id="dkZ-bW-bEE" userLabel="First Responder" sceneMemberID="firstResponder"/>
    </objects>
    <point key="canvasLocation" x="886" y="-457"/>
</scene>

I encountered a problem during the creation of the cocktail list page. The list, or TableView as it’s called on iOS, exists out of custom cells. Each cell contains the information of one cocktail: an image, its name and its ID. When you scroll through the list of cocktails you’ll see that all of a sudden the cocktail names don’t match with the images anymore. This happens because the cells of the list are reused when you scroll through the list and it takes a bit longer to load an image than it does to load text. Some iOS developers have told me this is an issue all junior iOS developers encounter and that it’s quite easy to fix. I thought it was still worth mentioning, as I didn’t have a similar problem with any of the other frameworks.

I also had to use a TableView to create the table on the cocktail detail page, as there isn’t an iOS component to create tables. The name ‘TableView’ can be quite misleading.

Creating the Flutter application

To create the Flutter application I used Visual Studio Code as IDE and Dart as programming language. The 3rd party packages I relied on were Image_picker for taking photos, Http for consuming HTTP requests and RxDart to use Observables for data streams. I used the BLoC state management technique for this application, but I didn’t use the 3rd party package. I found all of the information I needed to create this application in the official Flutter docs and in articles about BLoC written by Didier Boelens.

Flutter doesn’t have a visual layout builder. You also don’t need an additional language like XML to create your layout. You use Dart to create widgets which together will form your layouts, and you build these layouts declaratively.

The biggest problem I faced during the development of this application was state management. I didn’t have a lot of experience with BLoC at the time and the Provider package wasn’t around when I created this application. BLoC is, in my opinion and as regularly stated by Google, the superior state management technique. It has a huge learning curve to it though. I didn’t have any experience with Redux or Scoped_Model either, and only using setState() wasn’t going to suffice, so I had to resort to BLoC.

Flutter provides its own widgets, and it has a lot of them! One of them is a Table widget, which made it really easy to create the table on the cocktail detail page. I had problems creating this table with both Android and iOS, so this was a nice change of pace. The code underneath is the function to create all the table rows.

List<TableRow> _createTable(Cocktail cocktail) {
  List<TableRow> tableList = [];
  tableList.add(
    TableRow(
      children: [
        Padding(
          child: Text(
            "INGREDIENT",
            textAlign: TextAlign.center,
            style: TextStyle(fontWeight: FontWeight.bold),
          ),
          padding: EdgeInsets.all(4),
        ),
        Padding(
          child: Text(
            "MEASUREMENT",
            textAlign: TextAlign.center,
            style: TextStyle(fontWeight: FontWeight.bold),
          ),
          padding: EdgeInsets.all(4),
        )
      ],
    ),
  );
  for (int i = 0; i < cocktail.ingredients.length; i++) {
    tableList.add(
      TableRow(
        children: [
          Padding(
            child: Text(cocktail.ingredients[i]),
            padding: EdgeInsets.all(4),
          ),
          Padding(
            child: Text(i < cocktail.measurements.length
                ? cocktail.measurements[i]
                : ''),
            padding: EdgeInsets.all(4),
          )
        ],
      ),
    );
  }
  return tableList;
}

The only other ‘issue’ I encountered is that the iOS app doesn’t have a native look-and-feel. I used the Material widgets to create the application. Native Android apps implement Material design, but native iOS apps implement Cupertino design instead. A lot of widgets do look native on both platforms though, like the List widget for example. Other widgets like the AppBar widget don’t. Some widgets like the Switch widget have an adaptive constructor, which allows you to create a switch that look native on both platforms. It’s possible to create separate widgets for Android and iOS for widgets without an adaptive constructor, but unfortunately that costs more time.

Creating the React Native application

To create the React Native application I used Visual Studio Code as IDE and TypeScript as programming language. I relied on a lot of 3rd party packages to create this application:

Expo to make the development of the application easier and because it has picture taking support built-in.
React-native-easy-toasts for showing a toast on the cocktail creation screen.
React-native-elements because it has a lot of beautiful UI components.
React-native-svg-transformer to be able to use SVG icons.
React-navigation for the navigation of the app.
Styled-components to make it easier to style components.

React Native doesn’t have a visual layout builder. You use a language called JSX to create your layouts declaratively.

Managing state was one of the biggest challenges I encountered during the creation of this application. I didn’t know Redux, and learning it would have been a big time investment. This was not the fault of React Native, it was my own fault.

The only styling issue I encountered was during the creation of the cards used in the list of the cocktail list screen. To create shadows on this card for Android I had to use the ‘elevation’ property. To have the same effect on iOS I had to use the ’shadow-color’, ’shadow-radius’, ’shadow-opacity’ and ’shadow-offset’ properties. Having to do styling in two different ways to have the same result on both Android and iOS isn’t really great when your goal is to make a cross-platform app. The code underneath shows the style I created for iOS and the elevation property I used for Android. It also shows the CocktailCard as a whole, written in JSX.

const styles = StyleSheet.create({
    cardWrapper: {
        shadowColor: '#000000',
        shadowOffset: {
            width: 0,
            height: 3,
        },
        shadowRadius: 2,
        shadowOpacity: 0.3,
    },
})

export default class CocktailCard extends React.PureComponent {
    render() {
        const { id, image, name, onPress } = this.props

        return (
            <CocktailCardWrapper elevation={5} style={styles.cardWrapper} onPress={onPress}>
                <CocktailImage source={{ uri: image }} />
                <CocktailText>
                    <CocktailName>{name}</CocktailName>
                    <CocktailId>{`ID: ${id}`}</CocktailId>
                </CocktailText>
            </CocktailCardWrapper>
        )
    }
}

The Android and iOS app created with React Native did have a native look-and-feel. That’s because React Native uses widgets of the platform it’s running on instead of providing its own widgets like Flutter does.

Both Flutter and React Native support Stateful Hot Reload, but I have to say that it’s faster on Flutter than on React Native. On React Native it took longer to reload the app and sometimes it wouldn’t even work at all. The fact that it took longer might have something to do with the use of Expo.

Creating the Xamarin Forms application

To create the Xamarin Forms application I used Visual Studio for Mac as IDE and C# as programming language. The only 3rd party packages I relied on was Xam.Plugin.Media for taking pictures.
Xamarin Forms has a visual layout builder, but it isn’t as good as the ones you use for native Android and native iOS development. You’ll do most of the layout building with the XAML language, which is very similar to XML.

When I created this application, Xamarin Forms didn’t support Hot Reload. At the time of writing this article it’s either in beta or already supported. I don’t know how well it performs in comparison to the Hot Reload of Flutter and React Native though.

Xamarin Forms is a cross-platform framework but when it comes to styling it doesn’t seem to be as straightforward as Flutter or React Native. I wanted to change the colour of the app bar to red. Apparently this isn’t a change you can make in the shared codebase, you need to change the colour of the app bar on Android and iOS separately. This is also the case for the colour of the selected item in the bottom navigation bar. Because you have to do the same styling twice, you might end up with inconsistencies between your Android and iOS applications if you’re not careful.

Now that we’re on the topic of colours, I was unable to change the colour of the search icon in the app bar on the cocktail list screen and the camera icon of the cocktail detail screen. There is probably a way to change these colours, but it’s not straightforward at all. The images underneath illustrate the colour inconsistencies between Android and iOS.

The biggest issue I encountered was, again, the table on the cocktail detail screen. The styling of the table wasn’t the issue though. I have to iterate over the list of ingredients and the list of measurements, but iterating over two lists isn’t possible to create your layout. I had to create a new model which contains the ingredient and its measurement. Then I was able to iterate over a list of those objects. This is the only framework where I had to change the models in such a way and it’s very cumbersome.

Conclusion of the first experiment

The table below shows how much time it took to create every screen per framework. As you can see, I was able to build the Flutter application and the React Native application faster than either one of the native applications. You also have to keep in mind that because these are both cross-platform frameworks I was able to make an Android and iOS application in less time than one native application.

Creating the Flutter application only took approximately ⅓ of the time it took to create both native applications combined. This proves how much time you save by using cross-platform frameworks. Their Hot Reload functionality also sped up the development cycle a lot.
Both the Flutter and the React Native applications look nearly identical to the mock-ups. The Xamarin Forms application has some minor yet visible differences.

I was able to create the Flutter app faster than the React Native app, but that’s because I had more experience with Flutter than with React Native. I also didn’t know how to manage state properly in the React Native. That’s why declare both Flutter and React Native the winners of this experiment.

Measuring the performance of the Android applications

This experiment will determine the performance of the Android applications created during the first experiment. To conduct this experiment, I used the Android Profiler, a tool built into Android Studio. This tool allows you to collect data about CPU-usage, network activity and memory/battery consumption. I chose to focus on the CPU-usage as performance indicator for this experiment.

It’s best to use a physical device for this experiment. I used the smartphone the smartphone I owned at the time, a OnePlus 6T with the following specifications:

Operating System: Android 9.0 (Pie); OxygenOS 9.0.13
Chipset: Qualcomm SDM845 Snapdragon 845 (10nm)
CPU: Octa-core (4x2.8 GHz Kryo 385 Gold & 4x1.7 GHz Kryo 385 Silver)
GPU: Adreno 630
Memory: 8 GB RAM
Storage: 128 GB ROM

How the experiment was conducted

When conducting this experiment, a certain route was followed in every application and in the meantime the Android Profiler kept track of the CPU-usage. This tool then generated graphs to visualise the data it gathered. These steps were followed in every application:

Open the app and wait until the cocktails are loaded in
Start measuring the CPU-usage
Scroll down to the bottom of the list of cocktails
Scroll back up to the first cocktail in the list
Click the first cocktail in the list
Return to the list of cocktails
Open the list of ingredients
Scroll down to the bottom of the list of ingredients
Enter ‘Gin’ into the search field
Click on the ‘Gin’ ingredient. (This brings you back to the cocktail list screen.)
Scroll down to the bottom of the list of cocktails again
Scroll back up to the first cocktail in the list again
Click the first cocktail in the list
Return to the list of cocktails
Click on the ‘suggestion’ button in the bottom navigation bar
Write the word ‘description’ as description
Click on the camera button, grant permissions and take a picture
Tap the ‘Make suggestion’ button

Preparations for the experiment

I was able to install the native Android application correctly on my device using Android Studio, which was very easy. Correctly installing the other applications wasn’t as straightforward. To install the Flutter application for example, I had to use the command flutter run — profile. I wasn’t able to use a debug build because the Flutter application would have been compiled JIT (Just In Time, used for debugging) instead of AOT (Ahead Of Time, used for release and profile builds). This would have tempered the performance of the application.

In the Xamarin Forms project I enabled ‘Enable developer instrumentation (debugging and profiling)’ before installing the application. To install the React Native application I first had to start Expo and then enable profiling and install the application.

Results of the experiment

The graphs underneath were generated by the Android Profiler. The green waves represent the CPU-usage of the application. The dark blue waves represent the CPU-usage of other processes. The vertical lines represent the moments in time where started and stopped measuring the CPU-usage.

Take a moment to look back at the steps I followed in every application to notice that certain actions were more CPU-intensive than others. The spike you see near the beginning of every graph is when I started scrolling in the list of cocktails. The spike near the middle of the graph is when I started scrolling in the list of cocktails again, but this time all cocktails with gin as ingredient were shown. That list has more cocktails in it than the original one.

CPU-usage of the native Android application:

CPU-usage of the Flutter application:

CPU-usage of the React Native application:

CPU-usage of the Xamarin Forms application:

Conclusion of the second experiment

The table below contains statistics based on the data off the graphs that were generated by the Android Profiler. The first thing that stood out to me is that every application has a minimum CPU-usage of 0%. This happened when I opened the cocktail creation screen. At that time, the application is in a static state, causing the CPU temporarily unused.

The second thing that stood out to me is that the 4 apps can be split into 2 groups. The CPU-usage of the Flutter application peers with the CPU-usage of the native Android application, while the CPU-usage of the React Native application matches the CPU-usage of the Xamarin Forms application.

Before conducting this experiment, I had anticipated that the native Android application would have been the most performant one and the apps of the cross-platform frameworks would follow. For the most part this is true, but the Flutter application is an exception to this. The Flutter application was even slightly more economical on the CPU.

When I was conducting the experiment it was already noticeable to me that the Xamarin Forms and the React Native application struggled when I scrolled through the list of cocktails. I think this is because of all of the cocktail images that needed to be downloaded. The Xamarin Forms application also struggled a bit when I was scrolling down the list of ingredients, which only had text and no images.

It’s obvious that the CPU-usage of the Flutter application is smaller than that of the React Native and Xamarin Forms applications, and that’s why I declare Flutter the winner of this experiment.

Is Flutter more performant than React Native and Xamarin Forms?

In the second experiment it was concluded that the Flutter application was less taxing on the CPU than the React Native and Xamarin Forms applications. This doesn’t automatically prove that Flutter is more performant than React Native or Xamarin Forms.

There are a lot of features that the Cocktailr app doesn’t have, like caching for example. That would reduce the amount of network requests that need to be made and would make the app more performant, meaning that it could lead to different results. I also only used CPU-usage as a performance indicator. I don’t have any data on the memory or battery consumption for example. These are also an important performance indicators.

I didn’t know beforehand what the results of this experiment were going to be. All I hoped to prove is that Flutter can stands its ground against other cross-platform frameworks, and I think I achieved that goal.

Introducing the Hubble ecosystem: an automated design and documentation system

Kevin Meyvaert — Thu, 02 May 2019 10:45:58 +0000

This post originally appeared on the In The Pocket blog.

At In The Pocket, we've been theorycrafting about design systems for quite some time now. In our Shift article on the future of design systems, which we published at the end of 2018, we addressed the challenges of working towards a full fledged future-proof automated design system. Today we are glad to announce that we have moved past theory and that we are launching the first version of Hubble, our automated design and documentation system.

The Hubble origin story: peeking into deep space

We have been around for quite some time now and have grown as a team and as a company. As our clients and projects got bigger over the years, we have been forced to adapt, optimize our workflows and improve our tooling to meet client needs and increase our own productivity.

At first, we used a screen-based design approach; we had to update hundreds of screens, update a multitude of prototypes and review each one of them every step of the process. Friction between design and engineering was huge and maintenance was hard.

When we started the first React projects at In The Pocket, we embraced atomic design as a new way to increase productivity and agility. We created a library with the best possible atoms for design and engineering. We became increasingly more consistent and created the routine of documenting everything along the way.

Progress was being made. However, we were still defining our design in two completely separate locations. In our case, for design, this was being done in Zeplin. Developers had to copy the styles from Zeplin into the codebase, which was a process very prone to inconsistencies and errors. At this point, friction between design and engineering was still big, but we worked more smoothly than before. We had a solid component library, however, this was no automated design system - yet.

Over the last couple of months, a lot of small automation initiatives were taken by different teams, across different competences. These initiatives were focussed on trying to create an impact on our current way of working. We researched Sketch-to-code tools and design tokens, created a common component library, assembling our own create-react-app wrapper, generating automated documentation etc.

We decided to bundle those efforts and create a cross-competence design system team consisting of like-minded developers and designers. Project Hubble was born.

Shifting focus: scalable design automation

The goal of Hubble is to build the bridge between design and engineering by reducing the cost of having to do things over and over again, thus increasing productivity, and offering a single source of design truth which results in shipping faster, better and more consistent products.

To make sure we didn't lose focus when starting development on Hubble, we created a backlog of cool things we wanted in the system and split those functionalities in different tracks - epics if you will. This way, we could differentiate which features could mean quick wins for our organization and which features could bring long term value to the teams.

On one side we have the “design to development” track, which consists of everything related to “design to code” automation. The second track is the “document style guide” track that focuses on creating automated documentation which updates whenever a designer makes adjustments to the design files. Finally, we have the ”component” track, where we focus on creating an extensive library of fully accessible and reusable components for all our different technologies. This track was initiated from our React Web team, but React Native, iOS, Android and Xamarin are following.

This approach paid off, we are now in the process of rolling out Hubble in our first client projects and have a clear roadmap of features to make Hubble even better.

A team without vision is hard to keep alive

connecting design files with engineering projects. This consistency allows you to ship faster and build products with higher quality that need less effort to develop them. As Mary Poppins would say: it’s practically perfect in every way.

Yes, it’s open source

We use open source tools on a daily basis for a multitude of projects, that is why we decided to open source all the core tools that make Hubble great. On our Github page, you can find The Hubble Plugin, this plugin sends all the design data from the design tool to the Hubble App. The Hubble App is responsible for integrating the JSON tokens to your projects. Our Hubble Scripts are responsible for converting the design elements from design tools to JSON tokens. It can convert tokens to another format and keeps track of history. Other design elements that can't be converted to JSON - like images and fonts - can be uploaded through the app.

Get your hands-on experience with Hubble today and feel free to contribute to the future of design systems via our In The Pocket Github page.

A single source of truth: the future of design systems

Kevin Meyvaert — Tue, 27 Nov 2018 12:08:42 +0000

Last year at Shift we talked about getting started with design systems: living style guides that are collaborative and code-connected. This concept is gradually finding its way into our workflows and great examples are already out there. At In The Pocket, we are continuously improving our efforts to implement design systems in existing and new projects for our partners, but while doing so, new challenges arise. Usually design systems are initiated and owned by the designer or design team. During the implementation of the designed screens, discrepancies with the original design will start to occur sooner or later.

The approach of making an interaction and visual design for every screen has long been the standard for mobile app design. This approach is clear for clients as well as developers and suits the needs of small products with a short lifespan. Nowadays we build products that are long-lasting, require more maintainability, need scalability and are consistent across a variety of platforms and other products in an organization. These products demand a different and more efficient approach to design and tooling.

The main challenge we are facing now is the fact that tools don’t communicate with each other in a desirable fashion. Details fall through the cracks, and important nuances get lost. There is a huge gap between design and engineering; to make sure we stay on top of the constant changes, a lot of time-consuming manual work still has to be done. When a new designer or developer joins the team, there is a need for a swift onboarding process and good conclusive documentation to get started on the project. Designers should be able to move quickly from ideation to production, and developers should be enabled to dive straight into the code.

The way we work today can broaden the gap between engineering and design, and the many layers between designing and building are a burden. We can do better. We can work better. - Alex Schleifer, Airbnb

When we look at what is happening in the industry, we see other companies facing these challenges as well. Companies like Airbnb have invested a lot of resources in developing specific tools to maintain a design language while enabling them to close the gap between design and development - a gap that has only gotten bigger in the last couple of years. Software development has become a lot more collaborative due to the availability of a plethora of tools, making engineering increasingly productive. In comparison, design tooling has been lagging behind.

When talking about design systems, the main issue these companies are facing is that they often focus on one workflow, one technology, which makes it very hard for that system to match or integrate into other systems. Ideally, they want their system to be entirely decoupled from one specific technology and toolkit, making it ‘plug-and-play’ for any given environment. In the long term, this could be achieved by creating a generic file format from which any design tool or new technology can import, and export to one source of truth.

To support this idea of what is basically one source of truth for design and development, we started building our own system with a cross-competence team. Using our atomic design approach, we analysed which components and patterns we currently have and created new ones to fulfil the need to build a complete product.

This is an excerpt from an article I wrote for Shift, our annual report on the next big trends in digital. It is read by more than 1,000 experts worldwide. Join the conversation and get your free copy today! The article on design systems continues on page 89.

Download your copy of Shift here!

This article was authored by @behangmotief and @maartenderoeck for @itpocket.