Sander Goossens

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

Thibault Maekelbergh

Easy versioning for all files related to a versioned React Native app, via Fastlane

Single point versioning with Fastlane for React Native

Robrecht Meersman

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.

From Figma to React Native using Specify

Elias Lecomte

<h2>Version number and code?</h2>
While building Android apps, there are 2 very important characteristics; the version number and version code.
You define them in your <code>app/build.gradle</code>:
<pre class="language-groovy"><code class="language-groovy">android { defaultConfig { versionName 1.2.3 versionCode 123</code></pre>
We typically want to change this version code so that it's clear that it's built by CI and by which pipeline.
Also, the version code has to be higher then the previous release when uploading an app to the Play Store.
<h3>Via gradle.properties</h3>
We've been making Android apps for many years now, and typically defined the version code and name in the <code>gradle.properties</code>.
This makes it easy to find and update manually or with a script.
<pre class="language-groovy"><code class="language-groovy">projectVersionName=1.2.3 projectVersionCode=1230</code></pre>
In your <code>app/build.gradle</code> you can then use these properties:
<pre class="language-groovy"><code class="language-groovy">android { defaultConfig { versionName projectVersionName versionCode projectVersionCode</code></pre>
<h3>Gradle property</h3>
The next iteration, fueled by Fastlane documentation was to pass a gradle property when building your app.
So you build your app with:
<pre class="language-shell"><code class="language-shell">./gradlew assembleRelease -PciVersionCode=1004 -PciVersionName="1.0.0.4"</code></pre>
Or if you use Fastlane:
<pre class="language-groovy"><code class="language-groovy">gradle( task: "assemble", build_type: "release", properties: { "ciVersionCode" => 1001, "ciVersionName" => "1.0.0.4", }</code></pre>
In your <code>app/build.gradle</code> you then need to add some code to check if the property is present or not and use them accordingly:
<pre class="language-groovy"><code class="language-groovy">def newVersionName if (project.hasProperty('ciVersionName') &amp;&amp; project.ciVersionName) { newVersionName = project.ciVersionName } else { newVersionName = projectVersion } def actualVersionCode android { defaultConfig { versionName newVersionName versionCode newVersionCode</code></pre>
<h3>With a fastlane plugin</h3>
There is also a Fastlane plugin <a href="https://github.com/beplus/fastlane-plugin-versioning_android">fastlane-plugin-versioning-android</a> that actually rewrites your <code>app/build.gradle</code> file.
I do think this is a cool approach, but I'm always careful not to use yet another dependency that isn't activily maintained.
<h2>Or, you can change it without writing code in your app/build.gradle!</h2>
While all of these previous solutions are nice, they require you to add code. And while I was reading through the Fastlane documentation I actually discovered that there is a baked-in gradle metbod that isn't very known at all.
After reading the <a href="https://docs.fastlane.tools/actions/gradle/">fastlane gradle documentation</a>, going through this never resolved <a href="https://github.com/fastlane/fastlane/issues/15633">issue</a>, I then discovered this <a href="https://stackoverflow.com/questions/36213977/is-it-possible-to-set-android-version-code-and-name-via-a-gradle-task/36221899#">this stackoverflow thread</a>.
Somewhere at the bottom of it there is a small reply that you can actually use <code>android.injected.version.code</code> and <code>android.injected.version.name</code> to edit this without further configuration!
All the constants that you can use this way look to be listed in <a href="https://www.javadoc.io/static/com.android.tools.build/builder-model/2.5.0-alpha-preview-02/constant-values.html">this javadoc</a>. Not the best reference, but after some testing I can conclude that this works wonderfully!
To summarize, if you want to change your android version code and name, you can now simply use these gradle properties and no longer have to write code in your <code>app/build.gradle</code>!
I've also made a PR on the Fastlane documentation to make this clearer in their docs: https://github.com/fastlane/fastlane/pull/19370#issuecomment-923986665 (which has been merged :sparkles:).
<h3>Gradle property</h3>
<pre class="language-shell"><code class="language-shell">./gradlew assembleRelease -Pandroid.injected.version.code=123145 -Pandroid.injected.version.name="1.2.3.145"</code></pre>
<h3>Fastlane</h3>
<pre class="language-groovy"><code class="language-groovy">gradle( task: "assemble", build_type: "release", properties: { "android.injected.version.code" => "1.2.3.145", "android.injected.version.name"=> 123456, } )</code></pre>

Changing Android version number and code while building on CI

Wesley Van De Voorde

<h2>The problem</h2>
When we initially start a React project we define a fixed set of colors in a <code>colors.ts</code> file. These color constants could then be used throughout the app and changing their values when a design is updated goes pretty easy. But then we need to change.
In the meanwhile, the app kept growing and we started working on a 'mini-app' within the main app, which had to use a whole new and different set of colors. Instead of dynamically changing colors in the components we already built we decided to go for something flexible: the theming solution.
<h2>The fix</h2>
Thibault found a small library we could use that allows us to create a custom UI theme, much like React-Native's Stylesheet API and hooks: <a href="https://github.com/wvteijlingen/react-native-themed-styles">react-native-themed-styles</a>. Since it's so small we decided to copy this code and created a custom <code>useTheme</code> hook instead of using the library itself (reduces dependencies and fixed a typing issue the original repo had). If you're familiar with styled-components this approach will look normal to you, since the way of interpolating dynamic properties in the theme is roughly the same!
First of all we defined our themes that will be used and the default theme:
<pre class="language-tsx"><code class="language-tsx">const mainTheme = { colors: { colorPrimary400: 'rgba(4,15,18,1)', }, }; const miniApp = { colors: { colorPrimary400: 'rgba(5,200,199,1)', }, }; const ThemedStyle = registerThemes({ mainTheme, miniApp }, () => 'mainTheme');</code></pre>
Once defined, in our components we could replace the original <code>StyleSheet</code> styles with our <code>ThemedStyle</code>:
<pre class="language-ts"><code class="language-ts">const styles = StyleSheet.create({ container: { color: Colors.colorPrimary400, }, });</code></pre>
became:
<pre class="language-ts"><code class="language-ts">const styles = ThemedStyle((theme) => ({ container: { color: theme.color.colorPrimary400, }, }));</code></pre>
Notice that the color no longer comes from our colors constants file, but is injected from the theme that is used within the screen/navigation.
Now in our component itself we initialize the <code>useTheme</code> hook and inject the custom styles.
<pre class="language-tsx"><code class="language-tsx">const [styles, theme] = useTheme(styles, 'miniApp');</code></pre>
We now can use our custom styles and can even access other theme specific properties from the theme object itself.
As a second parameter in our hook, we added <code>miniApp</code> which tells the hook to initialize the other theme. If not set our default theme will be used.
<h2>Summary</h2>
We spent some time researching the best way to:
<ul>
<li>set up multiple themes</li>
<li>stay close to RN's <code>StyleSheet</code> API</li>
<li>allow for easy usage in our components</li>
</ul>
Ran into some merge conflicts updating all already styled components to use these new theme colors, but now we now fully functionable and themeable components throughout the app.
What's very interesting in the approach here is that it could work great with a dark/light theme to improve accessibility in your app, and is the least intrusive in an existing codebase/design system/component library.

Create a way to use multiple themes in your react-native app

Themed styles in React application

<h1>Fix bugs in React Native packages and their Android code</h1>
In this blog post we'll address how to fix bugs in packages &amp; native code with as little effort possible.
<h2>How do packages work?</h2>
Packages installed with npm i package_name are downloaded to the folder node_modules/package_name. A React Native package contains folders like android, ios, src, ... just like any React Native app.
With some React Native magic, the Android code is added to your app project and actually viewable in Android Studio. After the initial wait till it's loaded, you can actually edit this code as well! Just mind that, when you <code>npm i</code> again, all your alterations to packages are gone. But it's an easy way to change code &amp; test in your app.
<h2>Apply the fix</h2>
So go ahead and fix your native code!
Take in mind when testing native changes, that a simple <code>npx react-native run-android</code> doesn't pick up java changes from packages.
It's best to run gradlew clean to make sure it compiles all java code:
<pre class="language-shell"><code class="language-shell">cd android ./gradlew clean cd ..</code></pre>
<h2>Patch Package</h2>
The package <a href="https://github.com/ds300/patch-package">Patch Package</a> reallly is an enormous time saver. What it basically does is generate a git patch that will be applied on the package in node_modules/package after installing. The patch is a simple git change file.
So when you've tested your changes, it's time to generate your patch. Check instructions on <a href="https://github.com/ds300/patch-package">Patch Package</a>. Usually it is something like:
<pre class="language-shell"><code class="language-shell">npx patch-package some-package</code></pre>
This will generate a file: patches/some-package+1.2.3.patch containing all changes that you've done to the package.
Android Studio probably generated a few files and changes that you don't need to add. Remove them from the patch and you are ready to commit your code and get it in review 🤩.
<h2>Improve the open source package</h2>
Now that you saved the day for your app project, it's time to also improve the open source package and save the world 😉.
<ol>
<li>Fork the repo to your own account</li>
<li>Clone the code</li>
<li>Apply your change</li>
<li>Testing is often harder, as most React Native packages don't have example apps that use the local code immediately</li>
<li>Commit your code under a feature/branch</li>
<li>Open a PR accross forks to the original repo</li>
</ol>
Once the fix is approved and released, you can update your dependency and get rid of your patch 🎉.
<h3>But I really want to test this</h3>
Once your code is commit'd &amp; pushed, you can actually add this as a dependency in a project:
<pre class="language-json"><code class="language-json">"dependencies": { "example-package": "git+https://github.com/eliaslecomte/example-package.git#c2f4b5d6d01ba761f309a84bff4320d717902af2" }</code></pre>
Just replace the version with an url like above and the commit hash of your fix. Install &amp; test!

In this blog post we&#39;ll address how to fix bugs in packages &amp; native code with as little effort possible.

Fixing Bugs in React Native Packages

<h2>The problem</h2>
During our continuous accessibility (mainly screen reader) effort in React Native, 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 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.
<h2>The &quot;fix&quot;</h2>
To fix it, we created the <a href="https://git.inthepocket.org/thibault.maekelbergh/web-a11y/-/blob/master/react-native/hooks/useAccessibilityFocus.ts"><code>useAccessibilityFocus</code> hook</a>! 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:
<pre class="language-ts"><code class="language-ts">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&lt;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]; }</code></pre>
Now we can call it in a <code>useEffect</code> or react-navigation's <code>useFocusEffect</code> to focus on the element when the screen appears:
<pre class="language-tsx"><code class="language-tsx">const DetailScreen = ({ navigation }) => { const [focusRef, setFocus] = useAccessibilityFocus(); useFocusEffect(setFocus); return ( &lt;View> &lt;TitleInput /> &lt;View ref={focusRef}> &lt;Text>Content I want the focus on&lt;/Text> &lt;/View> &lt;View> ) }</code></pre>
Another way would be to hook into a listener on your stack's screens:
<pre class="language-tsx"><code class="language-tsx">const RootNav = () => { const [focusRef, setFocus] = useAccessibilityFocus(); return ( &lt;Stack.Navigator> &lt;Stack.Screen component={OverviewScreen} /> &lt;Stack.Screen component={DetailScreen} options= listeners= /> &lt;/Stack.Navigator> ); };</code></pre>
Worth noting that now, we have the added benefit that we can use the 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 <code>Platform.OS</code> check in the hook in that case.
<h2>The solution</h2>
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 href="https://github.com/react-navigation/react-navigation/issues/7056">A PR discussion about this is open</a>, you can even see yours truly in the discussion, but sadly no development towards fixing this has been done I guess.

Hacking/fixing screen reader focus for iOS when using react-navigation

React Navigation &amp; iOS screen reader focus

Remain up to date in the continuously evolving technology landscape. The ITP Tech Radar reflects our current view on software engineering technologies.

React Native

Why do we adopt this technology?

Related technologies

Flutter

Related Cases

Multipharma

Articles