Day 6: Compose won't compose

Writing an Android app in Kotlin: while learning and playing around with AI was fun so far, LLM was stuck at trying to implement the FlowRow feature of the Compose library. I had no idea how Gradle dependencies are managed; and Android has two of them with a lot of magic lines that weave things. When the AI agents failed, they looked into logs, tried to fix, failed again, and I was exhausted watching this little Tom and Jerry show.

It was giving confident feedback:

Looks like the experimental feature is not supported by animated view, let’s get rid of animated view. Now it compiles and the box will now expand properly.

The box didn’t expand. It went on and on and on and on. Sigh!

Skill Issue

When AI works, it works; but when it fails, it fails staggeringly. It shows a clear skill issue. And, if the operator, in this case me, has the skill issue as well… the problem becomes real. Now, you need to look in the thousands of lines of code that LLM has vomited which was working a minute ago. Now you need to look into the possible damages it has done when it went berserk trying to fix the code by changing unrelated code. While I am hopeful that these agents will continue to be smarter, right now you need to know two things:

1. Keep yourself acquainted with the code that it writes. And, it's an extreme mental load. Unlike human coders, the amount of code AI spits in a day is massive. You need to give yourself a fair amount of time and familiarize with what it’s doing. It will pay off when your coding companion goes postal.

2. You can’t “vibe” code and be insincere. You need to be skilled to be able to roll your sleeve and get some elbow grease on. I have been suggested to use multiple agents, which I haven’t tried. It may solve the issue, I don’t know. It feels very helpless asking the AIs, watching them fail, and then asking another and praying. But it maybe how future of coding look like.

The NeoVim Config Drama

While talking about skill issue, I remembered another incident from a few days ago when I decided to switch to NeoVim from VS Code. VS Code was giving up on my moribund computer, so NeoVim made sense.

I am super comfortable with Vim editor, so getting initial setup done wasn't big deal. It's only when I decide to use LazyVim and plugins when I thought let's have AI assist me.

Bad idea. Because it confidentially lies. Just as I was setting up the config and plugins to upgrade the barebones NeoVim, a couple of plugins won’t work as expected. I see the error messages every time I launch NeoVim. The LLMs kept telling me about various fixes: more and more complicated but completely wrong solutions and eventually (after a good 30 minutes of head banging) it said this:

If it still fails, honestly—just use the simpler config without Treesitter for now. Treesitter is nice to have, but not essential. You can code perfectly fine without it. Telescope is more important for your workflow anyway.

While it’s not incorrect; but there exists a better solution than giving up. Looking into docs and forums, I found out a version mismatch between two plugins was causing this. So, here's what happened.

1. LLM, as a copy-and-paste tech, pasted codes from someone’s repo who used explicit version numbers. It didn’t do it for all the plugins. Some were @latest and others were on some specific versions.

2. When fixed the versioning, the LLM didn't fix configs accordingly until I looked up the documentation, and told LLM what to do.

Here is the thing, and it's a repeat theme: if you have skill issue, AI will take you for a ride. As of early 2026, you can reach 90% success without ever looking at the code and just prompting the GPTs; and for a vast majority of businesses that's good enough.

Day 6: Custom Cloud, Deployment and Automation

A client once asked me to migrate his services from expensive AWS to the cheapest cloud service provider. Back then, I was sworn by the big three because of reliability, documentation, and the plethora of available tooling. With my newly found superpower with LLM, this time, I called him up and signed a two day contract; that much confidence. (Of course, I knew the worst case I’d be writing a couple of Dockerfiles, shell scripts, and cron jobs)

Since, I had written the whole code base of the internal web application, I knew every detail: node version, Vite build script, file permissions, and post deployment test scripts; so I wrote a meticulous 2000 words long prompt with exactly what it should do. It whirred and buzzed for a solid 10 minutes and spat two docker-compose files (two hosts), .env files, modified 4 Dockerfiles, added health checks to the backend, and as specified added Traefik for routing and Let’s Encrypt SSL. Perfect. Copied the Docker-compose files to prod VMs. Two minutes later. All services were up on the new domain.

The rest of the afternoon was spent reading the generated code; found that the code generated is using the old versions of some dependencies, docker-compose was emitting half a dozen warnings about deprecation. Fixed them. Migrated the data over. Created and secured the VM images. Happily called the client to say that work is done and I still need 2 days of payment.

Cheap cloud, no documentation, no support: LLM Shines

CloudPe is probably the cheapest cloud service provider that I could find. It provides you VM, Volume, Network, and Object Store; but that’s it. Barely, any documentation, and support people are clueless, screaming on social media tagging them returns no response. I didn’t know I would suffer this because they had a documentation selection on their website which, on close inspection, looks like someone did a poor job at it.

The client asked me to shutdown the servers at 11 PM and launch it again in the morning at 7 AM. Spoilt by big clouds, I thought I’d just import their SDK in a Python script and write a cron job to shelf and unshelf the VMs. I'd trigger this script from one of the client’s office machines. It wasn’t a critical requirement, so if it didn’t work on some days, it would be acceptable.

I was surprised that the API documentation was thin and had no SDK. A glimpse of hope came when I saw OpenStack somewhere in their sparse documents and started “hacking”. lol. Auth won’t work, tried a couple of iterations and then gave the LLM one task:

The VM provider is very likely using OpenStack. I don’t know which version. I want to manage the VM using OpenStack Python SDK, but it’s failing when I tried authenticating using: username and password and username and secret key. You have access to the shell command to run the Python script, edit it, and keep iterating till the problem is solved.

A few seconds of cling-clangs and bangs later, it came with a functioning YAML format that does authentication. If it wasn't the AI agent, I would have given up. This task was not in the scope. But hey, now the client saves 8 hours of billing, thanks to AI.

Reality Check

At this point, it's repetitive to say that web development has fundamentally changed. I am confident this will sharply cut the number of developers needed to do a job. However, skill is still somewhat important, occasionally when AI is stuck solving something the way it's intended and needed a nudge in the right direction.

The cover image is generated by ChatGPT 5.2 using prompt: "Generate an image of a dejected tin man with rest of the friends of Wizard of Oz. The friends are in the background, and distracted, and on the soil land lies a broken laptop. The environment is farmland, and these folks are on a thin dirt road, the sky had clouds. Make this image like line art in the children books from the '50s. No coloring, and it should look like drawn on a distressed paper that has yellowed due to aging."

Day 4: Reanimating a 2016 WebApp in 2026

Back in 2016, MERN stack was very different from today. React wasn’t yet function oriented, no hooks, Redux was marred with complicated “stitching” to get it working, and Babel was a complicated mess. Node wasn’t nice as well. Typescript wasn’t fully baked and EcmaScript didn’t have a lot of syntax niceties, promises were still requiring Bluebird (or Q). MongoDB ORMs, like Mongoose, weren't supporting (schema) types properly either. But the was a fully functional solid functioning software, serving a decade in production.

The software is still running in production thanks to containerization to provide infrastructure for 2016 stack. The client who I did project for, approached me multiple times in the last couple of years to add new features, and I said no; dreading entangling my foot in a mess that I no longer feel familiar or comfortable working with.

What was nagging me so far in my experiments with AI assisted coding, was the fact that all these projects I did so for were, what commonly known as, green field projects. No real figuring out, no existing coding pattern to learn, no deprecated library to replace without rewriting the entire codebase. I had almost entirely forgotten how things were done a decade ago. And, if I had to try, I would rather request a rewrite of the whole codebase. Well, this time, I was over enthusiastic about AI, and unsurprisingly it did poorly.

Attempt 1: Robot, modernize this code!

I woke up from my daydream of AI freeing us developers from the nagging nitty-gritty of coding and focusing on architecture when I tried this. I allowed the LLM to read and understand the code and then provided the latest stack, asked it to update the codebase to use React 19, keep Booostrap CSS (yeah!) styles untouched, update Redux to its modern form, bake Typescript in backend and front-end code. The prompt was more fine-grained, more explicit, I provided guardrails, and tests that it must pass. And click “Go!”.

It whirred and grunted, and whistled, and stumbled, and recovered, and it went on like this a good 21 minutes. Exhausted more than 90% of daily token quota and presented me with a non building, non functional hot garbage. In desperate attempts to fix it, I finished all the daily tokens.

"Well, maybe this brand’s LLM isn’t so great at learning, editing, and fixing the code.", I thought. Subsequently, I bought two more LLM subscriptions -- top three LLMs for coding all resulting in the similar fate, a non-functioning Frankenstein’s monster. Time to call it a day.

Attempt 2: Rewrite the app learning from the codebase

The next day, I was still reluctant to put in more effort in refactoring, so I asked the LLMs to learn the code and create a replica app (in UI and functionality) using the modern stack. Before lunch, I had a web app that was nothing like the original. It did have similar texts and some (MongoDB) collections were similar but LLM got the app completely wrong.

Attempt 3: Guide LLM like you’re buddy coding with a junior developer

I realized the LLMs were not there, yet. They were very close, and very soon they are likely to be able to do the messy job. So, if I wanted to refactor this, I would have to do a little more legwork than I expected.

Since I developed the whole system, I knew if I had to refactor this code, where would I start, what and which files to touch first and what changes need to be done in what order. I didn’t want to switch to another state management library because this was a proof of concept whether LLMs can help in real life messy scenarios like this. So, I started giving AI piecemeal tasks in the order I would do it.

I started with updating dependencies, Node versions, removing old Babel config, and adding prettier and modern tooling. I realized back in 2016, I didn’t care to segregate data logic from UI logic. I carefully went file by file refactoring the whole UI. It was broken all the time; and there were more than desirable times when I had to fix the code by hand because LLM wouldn’t just do the job. Once I was done, the UI was working and the back-end was still old.

It was getting evening, and I was frustrated. A quick look at the back-end code, I realized I could keep the existing code as-is and update the Node.js library. So, instead of changing every function, I decided to use a completely different ORM and added new code in Typescript and kept the old code.

Bottom line: it was frustrating, but AI was a massive help. I could finish the job in a day that would have taken me something like 30 days. If it was manual effort by me, I would rather have it rewritten faster.

Day 5: Deep Diving Android Development

The last time I touched Android development was way back in 2014. It was frustrating. The IDE was clunky, the emulator was slow, the horrible XML layout sent chills to my spine, and I didn't even dive deep, I was just building an application that makes API calls and renders screens. Since then, React Native has been my favorite way to develop applications for mobile.

For the last few years, I had an annoying problem with my Android 12 phone: I had to play music to change the audio destination from bluetooth to phone or to another bluetooth headset. All I wanted was to open the audio output selector. How hard would it be? “Pretty easy!” (All hard projects start like this.)

Learning Kotlin

I’ve used Kotlin for server apps, but I can’t describe myself as an expert Kotlin developer. I can read and write code, but I still roll my eyes on syntactic sugar the language adds. It’s nice. A million times better than Java.

Since I’ve never used all the bells and whistles that come with Kotlin, vibe coding with an assistance that explains what and why something is done, and gives me links for further reading, seemed like a good idea. I can comfortably say that the amount of learning I had in 8 hours that day, is more than what I could have learnt in a week.

Early Failure

As it turned out, there was no way to switch audio in Android 12 and below, it’s a platform level restriction. The only way is to play music, and have the user choose the audio device from the pull down menu of the card that shows media playing.

This is amazing, the amount of hoops I’ve jumped through to find a way to get it working for Android 12, and finally coming to this conclusion is mind boggling. In an unassisted, pre-AI, post Google world, these experiments and attempts would have easily eaten up a couple of days.

1. AI initially pretended it's possible to programmatically select an audio device on Android 12 without having to have an audio streaming.

2. When that failed during the tests, and I proposed playing a silent audio if no audio was playing for a moment, just to enable the audio switcher to work. AI spewed out some non-working code.

3. After some Google searches, and reading old forums, I realized it can't force show the audio output device selector for Android 12. (As we will see, I later learnt that It's an restriction at the SDK level.) The AI agent concurred.

4. I was hard pressing against AI because I had an old phone with Android 12 and wanted it to work. So, I wanted it to look up the internet and give me when and what exactly changed that allowed this to work in Android 13. AI took its sweet time and gave me the exact location in the Android's source code where and when it was allowed for code to show the audio change menu, and it was not for Android 12, the codebase belonged to Android 13+.

Although, I found out this is a fundamentally impossible to do it in Android 12, I’ve failed with a satisfying “why” answer in 3 hours. Figuring things out in almost unfamiliar coding / SDK territory could easily have taken up a day, at least, and likely, I wouldn't have had a good answer to defend. So, I had a bittersweet feeling at this moment.

Getting a functioning app and knowing Android APIs

It always bothered me that all my projects so far were web services: content delivery, feed management, or business application. It bothered me why people don’t use PWAs instead of building the apps. The app gives them no extra benefit except being able to download from the app / Play stores. (But, that's another topic for another day).

This time I wanted to play with Android's APIs, doing native things: things like writing an app that has a Quick Tile (the Android’s pull down menu where you have Wi-Fi tile, and Airport Mode tile etc), intercepting media playback requests, making Android API calls to show the switch audio device drawer.

With a newly found excitement of ability to do it while learning made me understand and build and app that has:

1. A quick tile to change audio output device (for Android 13 and above)

2. A fancy UI written using Jetpack Compose, which feels oddly similar to React (or other modern web dev tooling)

3. Build a rule engine and an observer to prompt to switch to a preferred audio output device if the user set it so. (Of course, the ideal case would have been to automatically switching to the desired output device, but it seems like Android doesn't like third party apps doing that)

I will update this post once the app is approved on Android 13. I am still testing it on a borrowed phone.

The End of the Honeymoon Period

What seemed like an unstoppable force screaming through social media, crushing software jobs by causing relentless firing, and the one which The Big Players claim it (the AI) to be our gods, it's not there yet.

Don't get me wrong, it's powerful: powerful than Google search, which was powerful than community forums, which was powerful than reading Complete References. It's just the jump in efficiency like it always has been, but this time the jump is really high.

Coming down from early exhilarating experience of AI crest into the trough of messy interactions with LLMs, the AI agents seem less god like and more like excellent pattern matchers. Sometimes it feels smart, and most of the times it does a good job even with poorly specified specs. It's an important tool in my developer's pocket: the most powerful one for sure!

The cover image was generated by ChatGPT 5.2 with prompt "an image of a coder in wild west style with a smoking gun and a broken Thinkpad... the opponent has knives. Kinda like the coder brought a gun to sword fight."

This is a fairly simple app. A week of coding to build a functioning app, nothing polished. 10 days to polish things up. 15 to build a release candidate. About a two week of work for me. Then I thought, well, let’s check how good AI coding agents have become. So, I swiped my card for a month-long subscription of an AI service and fired-up my IDE. What I am going to tell here is how things snowballed from casually building an app in a set-up (React, React Native, Typescript, Sqlite, and plotting libraries) for which I can churn code in my dream to diving deep into interacting with Android’s MediaRouter2 and looking into Android’s codebase to understand why I am targeting a certain minimum SDK version while progressively building deliverables at a mind boggling speed without much fear of not knowing what AI is doing.

Since it’s a long article, I am going to split it into multiple smaller posts.

Day 1: Pain Recorder App

Tuesday morning, sitting next to my mom in a hospital after her successful surgery of a life threatening condition, I started to feel my DISH (Diffuse Idiopathic Skeletal Hyperostosis) bothering me. As I popped Gabapentin, I realized I am delaying my visit to the doctor to figure out what’s going on. I always fumble when doctors ask what hurts, how much, when it hurts the most, and so on. It’s usually the recollection of the last couple of days; and if it happened to be good days, it goes like, “there wasn’t much pain in the last couple of days, but it was hurting before… I can’t clearly recall” I feel like doctors get insincere once they hear this. So, sitting there, I decided to write an app. Glued to an uncomfortable chair with my 9 year old MacBook Pro with its infamous broken keyboard -- I wished I had a junior engineer to write the code while I oversee, because the stack (React Native) was so familiar to me, there wasn't a new learning with this project.

I decided to give an AI agent a chance. I prepared a very clear phase wise development plan, created a palette that’s colorblind friendly, wrote down unit tests that it must generate and pass, and got my Balsamiq mockups to provide me the UI sketches as PNGs. Initialized a new Expo project, and started feeding the AI. Lo and behold, 4 hours of careful instructions and validating every phase I had a production ready app. It blew my mind.

(I will paste the URL here once the Play Store approves my app, it seems you can’t publish a health related app as an individual.)

Day 2: A website of my choice

In the evening, I decided, I would like to publish it on the Play Store. Which demanded a location to read privacy policy and terms and conditions. I got workslocally.com registered and decided to use Github pages to publish a simple Markdown driven site. It looked ugly. Signed off for the day.

The newly found confidence in AI’s capability, told me to make a better website, still simple but not unoriginal. I have been wanting to use Jekyll for quite some time now, and this is the time. Ruby on my geriatric computer full of Ruby tombstones wouldn’t work and my love for Ruby isn’t that great. I found Eleventy -- similar in concept and a quick 30 minutes of reading got me what it does and it’s pretty slick. Again, I can build a website in 4 hours with good CSS and mobile support, but why not make AI worth my dollars.

Within 30 minutes, I had a functioning framework for a website with placeholder text, and got my Github actions written to generate the page and deploy to Github pages every time a commit is made in the main branch.

I filled up the content, merged into main and you can now see https://workslocally.com

Day 2 and 3: An Invoice Reader Image Processing

I’ve been bugged by an auditor to automate the invoice reading that his team does. His team takes hundreds to thousands of invoice pictures, and PDFs of printed, or handwritten invoices and extracts various pieces of information from it to create a unified excel sheet. I, while impressed by the capabilities of modern LLMs, it was the fact that it's indeterministic, made me uneasy. Reading invoices that were handwritten, possibly in Hindi made me even less confident. But, I was on a rampage. Bring it on.

I decided to use FastAPI, Gemini, and React+Vite. FastAPI and Vite weren’t really the things I used in professional development. A few toy projects here and there. I drew a back of a napkin UI diagram, got it approved by the client; and instead of providing exact mockups to the coding agent, I gave it vague ideas and let it do design for me. AI spat the code, and I (git) committed when a UI or UI component turned out to be of my liking and modify or undo when I didn’t like the result, and tweaked the prompt.

A six hours of effort and an MVP is ready. After a half an hour of discussion with a demo later, I spent a couple of hours building a production ready webapp using ReactJS, FastAPI (Python), and Postgres. The client, a medium sized auditing firm, wasn't really keen on SRE and uptime and had an on premise Ubuntu server. I got it deployed using Docker Compose and gave a primer to their admin person. (As of now) They have been trying this software for six weeks now, and liking it. There might be more feature requests.

So far, so good

These are low hanging fruits for LLMs in early 2026. I knew a greenfield run of the mill project isn't going to be a toughie for LLM. Although, it did hallucinate a little here and there, but still better than a junior engineer. I wanted to drag LLM to some real messes, and we will see in the next posts, it's not there yet but the gap is closing real fast.

The cover image was generated by ChatGPT 5.2 using the following prompt: "a tron like bike with a programmer like guy on it zooming fast on a road made of colorful coding view of dark UI of an editor and it's a curve. The shot is a low shot taken from the road level... the scene is like '80s sci-fi movies, and so are the colors."

This post was originally published on Medium by me on Oct 15, 2021

It started with me forgetting to edit android/app/build.gradle file to increment the version number before uploading to Google Play Store on a Friday evening when I had popcorn getting ready in the oven and friends already started streaming Squid Game in the hall. Play Store console didn’t let me publish the app with the old conflicting version (of course!), and I had to redo the slow build. I needed a way to automate this!

A couple of PSAs first:

1. This article is only about Android releases. It does not go into iOS or React Native Web/Desktop releases.
2. If you have FastLane automation, you may want to use their versioning plugin
3. If you are using Expo, look into their Release Channels
4. If you are using Microsoft AppCenter Codepush, look into versioning mechanism in CodePush

With that out of the way, let’s get going.

The demand started when the client wanted to see the version of the binary on the React Native screen. It looks something like this (it used to be a manual update to package.json).

☝️ The binary version number should be shown on the React Native screen

In React Native, I found no easy way to fetch the version number of the binary without having to install a massive library like react-native-device-info, which sounded like an overkill to me. We know that we can fetch the version from package.json, what if there was a way to keep version numbers in package.json and build.gradle in sync? Auto-may-shun!!!

☝️ Automation!!! Courtesy https://workchronicles.com/automation/

STEP 1: Add these two utility functions to android/app/build.gradle

☝️ The Utility Functions That Fetch The Version Name and Code From package.json during the build

The idea is stolen from this StackOverflow post

STEP 2: Edit the lines in the block below to utilize our newly minted utility functions at the top of the file.

defaultConfig {  
  applicationId YOUR_APPLICATION_ID  
  minSdkVersion rootProject.ext.minSdkVersion  
  targetSdkVersion rootProject.ext.targetSdkVersion  

  // Edit these two lines  
  versionCode 110  
  versionName 0.1.10  
}

And the block above should look like this:

☝️ Changes in android/app/build.gradle to use the utility methods

At this step, if you go ahead, and run ./gradlew bundleRelease, you will see it picks up version value from package.json. If you are OK with manually updating version in package.json and running gradle build, you are done here. But, AUTOMATION?!!

STEP 3: yarn and npm both provide a mechanism to update the version of the project (and also automatically tag it for you). See more details here: https://classic.yarnpkg.com/en/docs/cli/version

Along with updating the version, it also calls a version lifecycle method postversion (also a preversion before the versioning starts). So, if we call our Gradle build as part of the post version step, the following things will happen:

1. Yarn will set the new release version (this process is interactive!) in package.json, and create a tag.
2. Yarn will kickoff gradle build which will use the new version in package.json

A win-win!

Let’s add a postversion script that performs the Gradle build in package.json

☝️ Add a new npm script

And, we are done! Open up your cli and fire the command yarn version and observe the smoothness. Ah-tow-mation, finally!

☝️ Watch the version code and version name derived from version in package.json

By the way, this is how you fetch the version from package.json on the React Native side:

☝️ Fetching version from package.json in a React Native Component

That’s all, folks!

This post was originally published on Medium by me on Dec 6, 2020

When a user taps on a push notification, they expect to land on the screen the notification is about. When I started to implement this feature, I found no easy way to do it. Although, I had deep linking figured out, still there was no definitive approach to pass a deep link in push notification and let the link do the magic of taking the user to the intended screen.

We know where to go, but not how to

React Native Firebase project suggests a simple case of setting initialRouteName in the Navigator tag after extracting the route name from the notification’s data object. Refer: https://rnfirebase.io/messaging/notifications#handling-interaction

☝️ Firebase Cloud Messaging suggest this mechanism to handle Push Notification for redirection

This has some obvious drawbacks:

1. It seems to be convoluted to handle a situation where screens are scattered in nested Navigator tags across various files.
2. It is not obvious how to deal with parameters that may be required to pass to the screen to render it
3. We have a perfectly working deep linking mechanism to open the app and auto-navigate with parameters, why can’t we reuse it instead of reinventing the wheel?
4. If you try use a solution that lets you redirect to any screen from anywhere without props (https://reactnavigation.org/docs/navigating-without-navigation-prop/), you will end up requiring to wait for the navigator to render to have this working. (this was my first solution, but I always ended up triggering the redirection/navigation as soon as the app starts before the Navigator is rendered, causing crash)

Lucky for us, not long ago, a PR (https://github.com/react-navigation/react-navigation/pull/8987) sorted this out for us. This article is about how to implement it.

I assume you have push notification functional. If not, head here to get that working first: https://rnfirebase.io/messaging/usage. I also assume that you have React Navigation configured, and you are on a version 5.8.10 or above. I am using "@react-navigation/native": "^5.8.10" in this article.

Before the linking is configured our app looks something like this:

☝️ Simplest App with React Navigation

How to configure deep linking

Deep linking using React Navigation is well explained here: https://reactnavigation.org/docs/deep-linking However, it took me some time to figure out how to support deep links that have myapp:// as well as https://app.myapp.com/ on Android phones. Trick is to add two different intent filters one for each like this:

☝️ Configure URL Scheme in Android in a way that handles custom as well as HTTPS prefixed URLs

Now we gotta tell the NavigationContainer that we are reacting to these schemes, so my App.tsx becomes:

☝️ Deep Linking Done!

At this point, you rebuild your app (commonly, using npx react-native run-android), and you should be able to do the following from your CLI:

☝️ Test if your deep links work

Now that the deep linking is sorted, we can now freely share the deep link with https scheme in emails and websites and when people click this deep link on their desktops or phones that does not have your app installed, it will take them to your website where they can see the web version or you ask them to install the app nicely. If they have the app, they would find it delightful.

Reusing Deep Links in Push Notification

Push Notification payload contains a data attribute. You can send any key-value pair as data. If we just pass the deep link as a part of data object and somehow we tell our navigation mechanism to open the link as the first screen instead of the home screen of the app, our work is done.

React Navigation provides a neat little function in the linking attribute of the NavigationContainer tag. NavigationContainer commonly contains all the application (and definitely all the routes). This function is named getInitialUrl and it is called every time the application launches from the quit state. It is where you will land when the app is opened from a push notification. So, we need to put the logic here to redirect to the appropriate screen. Since we cleverly pass the deep link as a part of push notification, we can let React Navigation deal with it.

Here is how our linking attribute looks like once we add getInitialUrl function to it (refer: https://reactnavigation.org/docs/navigation-container#linkinggetinitialurl):

☝️ Handle the case when Push Notification arrives and the app is closed

But what about the case when we receive the push notification when our app is in the background? You need to add a listener in that case. It looks like this (refer: https://reactnavigation.org/docs/navigation-container/#linkingsubscribe):

☝️ Handle the case when Push Notification arrives and the app is running in background

We are done now. When a push notification is tapped either getInitialUrl is called or onNotificationOpenedApp invokes our listener passed in subscribe method. In both cases, React Navigation handles the incoming URL and redirects to the right screen.

To test this, go to Firebase console, to the project that’s linked to this app (URL looks something like this: https://console.firebase.google.com/u/0/project/YOUR-PROJECT-NAME-HERE/notification/compose), fill out fields. In the Custom Data field, add a link key, with value to one of the valid deep links.

☝️ At the bottom of the screen there is a way to push key-value payload

Assuming you have your device’s FCM token handy, send a test notification.

☝️ Keep your FCM token handy to test your code

Recline your chair, raise your arms, take a sip of hot tea while you wait for the notification to appear (should not take more than a moment), tap the notification and watch yourself chauffeured to the screen mentioned in the link. You are done for the day.

This post was originally published on Medium by me on Aug 5, 2020

This is the second and the final part of the two part series. Read the first part here.

As happy and dandy as we feel after setting up a pipeline that makes majority of app release bypass the app stores, but the happiness does not last long when you want to do a pre-release testing (Alpha Track in app store) or a beta testing with beta participants, or A/B Testing over 20% of all the users. Only if CodePush could do these for us. Well, you are in luck, CodePush can do all this and more. Let’s explore?

An App with Multiple Deployment Keys

Let’s try and get our app to do the following:

1. Do not pull the updates automatically
2. Pull the updates when the programmer or the user wants
3. When the updates are pulled programmatically, do not apply the updates immediately (Because that may stun the user. Imagine you are filling up a long from, and just before the submit button was clicked, the app reboots. Not nice.)
4. When user switches the deployment key (as in, they switch from Stable version to Beta version or vice versa), load the changes immediately
5. Provide an “Open Sesame” to the users to switch between beta and stable versions.

MANUAL UPDATES

Remember the AppWrappedInCodePush.tsx file from Part 1? It looked laughingly small. We are going to make it the center of our deployment logic. Here is the full version of it:

☝️ AppWrappedInCodePush.tsx

☝️ constants.ts

Let’s read it through:

#35: We are now passing a parameter that tells the CodePush client to not pull the code automatically at the start up.

As soon as the main application is mounted, the lines #14–28 does a couple of things:

1. Checks if AsyncStore has a value for the key IS_BETA_USER
2. If that key is set to true, sync the codebase with beta stream (because we are using the Staging Key)
3. Otherwise, sync the codebase with the stable stream as we pass the Production Key in this case
4. Noteworthy, we are setting the installMode to codePush.InstallMode.ON_NEXT_RESTART. Because, from the point of view of the user, this update is happening automatically, and in the background. If you install the code immediately, causing a reboot of the app, the user may not like it. So, we download and wait for the next time the user opens the app to show them the shiny new app.

As of now, we have not set IS_BETA_USER to anything, so the behavior stays unchanged compared to what we had at the end of Part 1 of this article. But, we can see if somehow we set the IS_BETA_USER value to true in our AsyncStorage, we will start seeing the beta version of the app.

SWITCHING BETWEEN STABLE AND BETA VERSIONS

I like Easter Eggs in software. What we want to do here is to create a component that looks like plain text information of the software’s version. When a user taps it 8 times, we show them the option to switch between stable and beta versions with a fair warning.

Here is that component’s code look like:

☝️ VersionInfo.tsx

Line number #58 — #78 is the core of it. The rest is just the display logic.

The toggleBetaUser does the following:

1. Sets the IS_BETA_USER value as true or false and stores it in AsyncStore for persistence
2. Calls CodePush’s sync method with appropriate key with installMode as IMMEDIATE. This will cause the code to be downloaded from an appropriate release stream and apply it immediately after the download. This will cause the app to reboot and show the downloaded version.

Now that we have a mechanism to toggle and save the user preference to AsyncStore, our code in the first part of this article would work. If use has set beta mode on, it will sync with the Staging stream, otherwise CodePush will sync with the Production stream.

☝️ From left to right, top to bottom: 1. Stable version V5, 2. After the user tapped the version text 8 times, 3. The user opted-in for beta and assets are downloading, 4. User is now on beta version

FUN THINGS TO DO WHILE SYNCING

MetaData: codePush.metadata() returns null or a LocalPackage object. Among other things, it has a couple of cool attributes. LocalPackage.appVersion gives you the version of the binary installed on the device. You can see 0.0.4 in the screenshot above. LocalPackage.label gives the CodePush’s resource version installed. It is indicated by v5 in production deployment, and v3 in staging deployment. You can also ask deploymentKey from LocalPackage.

Check for Updates: codePush.checkForUpdate() — This method returns a Promise<null|RemotePackage>. If null, there is nothing to do; all up to date. If it returns a package object, then you can either show to the user that a new update is available or pull the latest.

Synchronize at Will: codePush.sync() — This method kicks off synchronization. This packs a couple goodies. Here is the method signature:

/* 1.*/ codePush.sync(  
/* 2.*/ options: Object,  
/* 3.*/ syncStatusChangeCallback: (syncStatus: Number) => void,  
/* 4.*/ downloadProgressCallback: (progress: DownloadProgress) => void,  
/* 5.*/ handleBinaryVersionMismatchCallback: (update: RemotePackage) => void
/* 6.*/ ): Promise<Number>;

options is a JSON object. The most notable attributes are deploymentKey and installMode. The former is the deployment you want the app to sync with, and the latter is how you want the install to happen: immediately, after restart, when the app goes to background or any other way. There are other attributes that can be found in the documentation.

syncStatusChangeCallback is a function with its signature as (syncStatus: Number) => void, where syncStatus can be any of the values as shown in the enum below. This is what I am using in my code to display the spinner until the syncStatus reaches the UPDATE_INSTALLED state

downloadProgressCallback is a function with its signature as (progress: DownloadProgress) => void. You can get really fancy with this. You can use DownloadProgress.totalBytes and DownloadProgress.receivedBytes to show progress bar animation or something.

handleBinaryVersionMismatchCallback can be used to handle situations where you are trying to sync with a deployment whose binary version has diverged from the one on the local machine. This is your opportunity to remind the user to download the latest version from the app store.

ENFORCE CERTAIN USERS TO HAVE CERTAIN DEPLOYMENT

I hope you do not discriminate against your users on the basis of gender, race, region, belief or anything that they do not have their control over. That’s just not the nicest thing to do. But, it may make sense in certain cases to differentiate the users. What if you want to enable the beta version for all the users whose UserProfile object has isBetaUser = true in the database. Or, maybe, you wanted to roll out the beta version first in certain countries and based on their feedback, you want to decide whether to promote beta version globally.

In all such cases, wherever you fetching user profile just set AsyncStore.setItem(‘IS_BETA_USER’, `${userProfile.isBetaUser}`)

Ta-da!

Why stop here?

The binary is already embedded with the production key. So, everyone will get the production version to start with. If nothing is altered, they will continue to have production updates. Why can’t we, instead of having a binary value — IS_BETA_USER and hardcoded Deployment Key, dynamically set Deployment Key in AsyncStore and use that key to sync?

☝️ Different UIs based on your thumb size?

That means, we can set different Deployment Keys for different users and make releases specific to them. For example, if your sync logic looks like this:

// undefined userProfile.deploymentKey would use   
// the key stored in the binary  
codePush.sync({  
 deploymentKey: userProfile.deploymentKey,  
 installMode: codePush.InstallMode.ON_NEXT_RESTART,  
});

A hypothetical ticket to make a completely new release only to a specific group of users and its workflow would look like this:

TICKET #666: Make a deployment specific to Indian and Australian users.
DevOps: Well, since deployment keys are just a name and an identifier, let’s create one for this ticket

# Create a new deployment key  
# appcenter codepush deployment add <KEY_NAME> --app <USER>/<APP_NAME>
appcenter codepush deployment add colonial_cousins --app nishant/blog-app

Deployment colonial_cousins has been created for nishant/blog-app with key nkaKawu1CtuHuzzahGIJWq_LOTVcAHEcyLEWt

DBA: Let’s set users in India and Australia with deployment_key as nkaKawu1CtuHuzzahGIJWq_LOTVcAHEcyLEWt, others may be null or whatever value they are set to.

UPDATE user_profiles   
SET deployment_key = ‘nkaKawu1CtuHuzzahGIJWq_LOTVcAHEcyLEWt’   
WHERE country IN (‘AU’, ‘IN’)

Release Engineer: Well, let’s push this release to Indians and Aussies, and close the ticket.

# Release to specific deployment  
# appcenter codepush release-react -a <USER>/<APP_NAME> -d <KEY_NAME>

appcenter codepush release-react -a nishant/blog-app -d colonial_cousins

There we go. We did not touch client code, we did not ask the user to do something special, and still, we have managed to distribute a targeted software update. Isn’t it smooth?

A/B TESTING

Dark Mode vs Light Mode?
Tabs vs drawer?
Automated grouping or ungrouped messages?
How much time spent on the app on an average?

Sometimes, you want to be cautious, and release an upgrade to a percentage of users first and then, based on analytical data, you want to decide whether to go ahead with the upgrade or rollback. CodePush makes it as simple as specifying a parameter in the release command. You can specify what percentage of the users get this release. Here is an example

# appcenter codepush release-react -a <USER>/<APP_NAME> -d <KEY_NAME> -r <PERCENTAGE_ROLLOUT>

# The following will roll out the blog app to 20% of the users who are having Production deployment

appcenter codepush release-react -a nishant/blog-app -d Production -r 20%

PROMOTING STAGING RELEASE TO PRODUCTION

A common scenario is where once you have tested the app in staging, you want everyone else to have that version. It is a good practice, because it gives you confidence that the tested bundle is going to the production users, not a single bit different.

You can do it by running the promote command

#appcenter codepush promote -s <SOURCE_DEPLOYMENT_NAME> -d <DESTINATION_DEPLOYMENT_NAME> -a <USER>/<APP_NAME>

appcenter codepush promote -s Staging -d Production -a nishant/blog-app

Want to be super cautious and promote only to partial users? Just use the -r argument along with the other options above.

As always, Deployments are just names and identifiers, you can promote any deployment to any deployment.

BINARY TARGETED RELEASE

Imagine you have two binaries in app stores, one versioned 42.69.8 and another 43.0.0. The older version has some bugs which are fixed in the newer version, but the code in the newer version is incompatible to the code in the older version (maybe because you changed REST response, or added a new node module that’s not there in the older version).

You want to make a targeted release to the 42.69.8 binary release version.

# Release to specific deployment

# appcenter codepush release-react -a <USER>/<APP_NAME> -d <KEY_NAME> -t <VERSION>

appcenter codepush release-react -a nishant/blog-app -d Production -t 42.69.8

FANCIER THINGS

It should be clear to you by now that a deployment is just a name and an identifier associated with it. So, can we use it in our JavaScript as a name and an identifier attached to it? Of course!

You can use the identifier as the environment name. You can have things like this:

// I am assuming you have method somewhere to get currently  
// used deployment key and a constants object that holds  
// the deployment keys

const isStaging =  
  getDeploymentKey() === constants.STAGING_DEPLOYMENT_KEY;

export const API_ROOT_URL = isStaging  
  ? 'https://test.tehbesttodo.dev/api'
  : 'https://production.tehbesttodo.app/api';

I think I will close at this. There are many other helpful commands and tricks to use with CodePush, you just need to peek out of the box a little and read the documentation: https://docs.microsoft.com/en-us/appcenter/distribution/codepush/. Definitely, the latter.

If you liked the article please do not hesitate to slap the clap button for 50 times. Yes, you can. It is not tiring at all! And share it may be?

This post was originally published on Medium by me on Aug 4, 2020

The initial days of a new mobile app development is a melting pot of frequently added features and improvement, broken-for-certain-devices releases, bugs slipped from the tired eyes, and an out-of-patience-midnight-oil-burning-DevOps with a dark sense of humor. The only thing you do not want at this point is a third party authority with their impractical review policies guarding the doors of the mobile phones where your broken code is pushing the users to the brink of uninstalling the app and writing a scathing review on the store about how poorly developed the app is, ignoring all the hard work done by a team of three night owls surviving on Ramen noodle providing the app for free by paying the bills using AWS free credits (https://aws.amazon.com/activate/) and digging into their parents savings. No, we do not want this.

WE WANT SEAMLESS UPDATES, AND WE WANT IT NOW!

Enter CodePush

CodePush is a nifty little utility for React Native and Cordova developers to update JavaScript code and bundle assets on client devices on the fly, in minutes after the release. Remember, Not the full app, just the JavaScript and bundle assets. Let me explain this quickly.

☝️ CodePush: push your code

React Native application is made of JavaScript code, image assets, and platform specific binaries bundled by the bundler. CodePush takes responsibility of keeping the JavaScript code and the asset part of the bundle in sync with the latest code that you have uploaded to the CodePush server. When the user installs your app, they get the version of JavaScript and assets that came with the binary that you uploaded to the AppStore or PlayStore. As soon as the user launches the app, the CodePush client that’s installed as a part of your app, checks the latest version of JavaScript bundle on CodePush server and downloads it. Then on, every time you update the bundle on CodePush server, the app syncs itself with it. Doesn’t it sound too similar to how web pages work?

☝️ CodePush code synchronization in short

Let’s clear up our expectations here. This is what we want:

1. Set up an AppCenter account and configure our app with the CodePush library
2. Release the binary (.aab, .apk, .ipa) to the stores of your choice (or just distribute them over FTP, I don’t care)
3. Change some JavaScript, and release it via CodePush
4. Restart the app (this time new bundle should be downloaded and installed), and restart again (this time the new bundle should be applied) you should see the new changes
5. Allow the users to choose whether they want to become beta user
6. Use CodePush deployments to serve bleeding edge updates to beta users while others still have the stable version
7. Use CodePush to promote the beta version to production

Setting Up CodePush

First, we need to create a Microsoft AppCenter account and set up a new project. It is easier than setting up your social media account. It is free, so, if you haven’t yet, go ahead and create an account here: https://appcenter.ms/ . I will be waiting for you. Once in, go to Add New > Add New App. Give a recognizable App Name, select OS either Android or iOS, select React Native as Platform and click Add New App button.

Select the App, from the left menu under Distribute, click CodePush. From the center, click "Create Standard Deployments"

☝️ CodePush is hidden under Distribute menu

Now, you should see a “Everything is Ready” message with info on how to integrate CodePush with your app and how to release it. On the top right corner, you should be seeing a spanner🔧wrench icon. Click it. You should be seeing two identifiers: one titled “Staging” and another named “Production”. Two channels essentially. Two streams if you will. The Names do not matter. You can use any of these for production release. But, no one likes to watch the world burning. So, let’s assume, we will use the Production key for production deployments and Staging for staging release (or beta testers).

☝️ What’s in a name: deployment names and corresponding keys

For the remaining of the article, whenever we are talking about Deployment Keys, Keys, Production Deployment Key, Staging Deployment Key, or Beta Deployment key, we are talking about one or both of these values. (Over the course of the article, I created two different projects in CodePush, so, the values in the text below may not match the values in the image above)

Integrate CodePush with the App

With our CodePush server configuration done, we are ready to do what we love the most. Code. (Really?) CodePush comes under Microsoft’s AppCenter service which provides much wider services than just managing release synchronizations.

Install AppCenter CLI

Just follow the command and replace appropriate values wherever it makes sense.

# Get the CLI  
npm install -g appcenter-cli

# Login  
appcenter login

# View your apps, we will use these names later  
appcenter apps list

# View the environments and corresponding deployment keys  
# appcenter codepush deployment list -k --app <USERNAME>/<APPNAME>  
appcenter codepush deployment list -k --app nishant/blog-app

┌────────────┬───────────────────────────────────────┐  
│ Name       │ Key                                   │  
├────────────┼───────────────────────────────────────┤  
│ Production │ Jbach1Qk_achQarrrhNOA9zwVlJnruLsa9jsr │  
├────────────┼───────────────────────────────────────┤  
│ Staging    │ jhai-muzz27Nt7Y11KLp-cBsNA22EGjGHEYfr │  
└────────────┴───────────────────────────────────────┘

Code Changes

Install the appropriate version of react-native-code-push as mentioned here: https://github.com/microsoft/react-native-code-push

As of now here is the versions of react-native-code-push and corresponding react-native versions:

WRAP THE APP

Wrap the main app component with CodePush’s higher order component. You can do it the way it is explained here in their official documentation: https://github.com/microsoft/react-native-code-push#plugin-usage

I personally do not like too many things in my App.tsx or App.jsx file. In a realistic case, you must already be wrapping the main App component with various Context providers like Theme, Redux, GraphQL client, Authorization provider et-cetera. Adding more noise to this is just… well, not so pretty. But prettiness apart, CodePush has a separate concern altogether. CodePush is a continuous delivery solution provider, and the rest of the code is either to rendering the UI or to perform the business logic.

So, I created a separate class component that wraps the App component with CodePush component. And, edited index.js to use this new class component. Here is what they look like

☝️ AppWrappedInCodePush.tsx

💡 No CodePush in local env?!

If you don’t wanna activate CodePush while you are in the debugging mode. You can conditionally apply CodePush wrapper like this:

export default __DEV__ ? App : codePush(AppWrappedInCodePush);

☝️ Changes to be made in index.js

Now, we need to do OS specific changes. Please note that OS specific instructions below are for React Native 0.60.0 and onwards. For older versions, refer the official documentation.

Android

For the Android side of the code, here are diffs and list of files to be changed.

☝️ android/app/build.gradle

☝️ MainApplication.java

☝️ strings.xml contains the Production CodePush Deployment Key, use your own key!

☝️ settings.gradle

🐞 POSSIBLE BUG!
Got a message in late 2021, someone saying CodePush sync wasn’t working on Android. Back then, I tested on a new project, it worked. Recently (early 2022), a freelance project I was working on I saw the issue. A little bit of searching around led me to this GitHub post: CodePushUnknownException. In case you are facing this, please make the following change to your android/app/build.gradle file, add the following lines under android.defaultConfig block:

// The code below is one single line!  
resValue 'string', "CODE_PUSH_APK_BUILD_TIME", String.format("\\"%d\\"", System.currentTimeMillis())

iOS

iOS side requires fewer changes, here they are:

☝️ AppDelegate.m

You need to add the CodePushDeploymentKey in your Info.plist and set its value to the Production key from the CodePush console.

You can use XCode to add this, as show below:

☝️ Add CodePush Production Deployment Key as a new attribute to Plist, use your own

Or you can edit the Info.plist directly, it looks like this:

☝️ Editing Info.plist in a text editor? Here are the changes. Make sure the Production Deployment Key is right.

Phew!!! A lot of changes, feeling anxious? I think that’s the right response. Now, you need to build the production release binary and distribute it to the users (via AppStore, PlayStore, and/or by just sharing the APK or IPA file).

Cool. The users have the app up and running. Now, make a change (or many changes) to JavaScript files. Perform a CodePush release, here how you do it:

# Make your changes and then  
# appcenter codepush release-react -a <USERNAME>/<APPNAME>  -d Production  
appcenter codepush release-react -a nishant/blog-app -d Production

Detecting android app version:  
Using the target binary version value "0.0.4" from "android/app/build.gradle".

Running "react-native bundle" command:  
[-- snip --]  
index.js --platform android  
Welcome to React Native!  
Learn once, write anywhere  
[-- snip --]

Releasing update contents to CodePush:  
Successfully released an update containing the "/var/folders/89/s5j46yyd7xn1s9ctl\_5td2d80000gn/T/code-push202072-97439-5f5fka.gokh2/CodePush" directory to the "Production" deployment of the "blog-app" app.

Give it a few moments, and then open the app (maybe keep it up for a minute or two so that the sync completes), close the app, and open the app again. You should be seeing the new changes.

Congratulate yourself. 🎉

At this point, we have the pipeline set. Since the majority of the code movement in React Native applications happen in JavaScript, whenever we want to release the updated code to our users, we’d just push the code through CodePush and have it reflected immediately on the users devices without waiting for AppStore or PlayStore to approve it.

A lot of us would be happy with just this. However, wouldn’t it be better if we could have two release streams — one for a smaller audience, the beta testers who would get the preview version and another the stable release for everyone else? When we are happy with the beta version, we’d promote it to stable release for everyone else to see it.

Shouldn’t we have more control over the updates? Is there a way to manually kick off the update? Should we ask the user whether they want the update? Can we show update progress? Can we rollback a bad release? Since you mentioned preview and stable versions, can we use this for A/B testing? Can we have more than two deployment keys? Can we remotely control the user’s version (deployment key) by setting key specific to them on their user profile when they log in? Can we use these keys to switch the environment as in, one key point to test environment APIs and other to production APIs? Also, when is CodePush not enough and we require a binary release to the stores?

We will discuss all these fun things in the next part.

Fresh from the oven, here is the second part

This post was originally published on Medium by me on July 22, 2020

In this final chapter of the three part tutorial, we will discuss some of the advanced features offered by i18next, these topics will include rendering dynamic strings using features such as interpolation, formatting, setting timezone locale, pluralization, nesting, context, and JSON objects and arrays.

If you want to learn about configuring localization and internationalization with i18next, jump to part 1 of this series.

If you want to learn about organizing translations for a medium to large application and providing language change control to the users, hop on to part 2 of the series.

If you want to view code for this part, please clone the repo at: https://github.com/naishe/rn_multilanguage and checkout part_3 branch.

With all the formality done, let’s earn some elbow grease, shall we?

INTERPOLATION

The most frequently used utility is interpolation. Interpolation allows you to provide a templated string like { howdy: “Hey {{ username }}, how are you doing today?”} and render it with the dynamic value you pass from the rendering code.

t("howdy", { username: "Nishant"});
// returns: Hey Nishant, how are you doing?

But, life isn’t easy. Most of the time you have things like user object and userBill object and you need to print something like Hey <username>, your account has been suspended until your last bill Rs <bill amount> is cleared. Here is the trick:

// String template  
accountSuspended: "Hey {{ user.username }}, your account has been suspended until your last bill Rs {{ userBill.total }} is cleared."

// Rendering  
const user = {  
 username: "Nishant",  
 intelligenceLevel: 7  
};

const userBill = {  
 total: 420.69,  
 paymentDueDate: "May the fourth"  
};

t("accountSuspended", { user, userBill })  
// returns: Hey Nishant, your account has been suspended until your last bill Rs 420.69 is cleared.

FORMATTING

You can create your custom formatting function and pass its name along with the string to be formatted to i18next.t and it will do it for you. You need to register your formation functions in init configuration under the interpolation attribute as format key.

For example, if you want to write a formatting function that takes a number and prints the Indian flag that many times if language code is hi, Hindi, else prints world emoji those many times. If it is not a number it returns whatever is passed. The code looks like as below:

I haven’t found a great use case where I would use formatting. One of the most useful things we can do is we can instruct Moment.js (https://momentjs.com/) to use locale whenever the language preference changes.

You just need to add a listener after initializing i18next, like this:

// i18next configuration file

//Make sure you import the locales  
import 'moment/min/locales';  
import moment from 'moment';

// — removed for brevity — 

i18n.on('languageChanged', (lng: string) => moment.locale(locale));

A caveats here. Moment does not load all the locales so you need to import the locales.

Let’s have a look how formatting code looks like:

<Text>{t('flagsCount', {count: 3})}</Text>

<Text>  
  Moment.js Locale 42 minutes ago:  
  {moment().subtract(42, 'minutes').fromNow()}  
</Text>

And it renders:

☝️ Format in action, also automatically switches locale for Moment.JS

PLURALIZATION

Different languages handle pluralization differently. It is not uncommon to come across uses where you need to display difference strings depending on the quantity of subject matter. Here is an example in English:

Singular: 1 knife found during the autopsy
Plural: 3 knives found during the autopsy

To display different content based on the number passed to i18next.t function, you need to define two keys, one regular key to be used for singular cases and another key suffixed with _plural for plural usage.

{  
  autopsy: “{{count}} knife was found during the autopsy”,  
  autopsy\_plural: “{{count}} knives were found during the autopsy”,  
}

// returns:  
// t(‘autopsy’, {count: 1}) = 1 knife was found during the autopsy  
// t(‘autopsy’, {count: 7}) = 7 knives are found during the autopsy

However, this way of writing sentences does not have human touch to it, it is still too beep-boop-1-krrr-knife-was-found-isque. We would probably want something like this:

No knife was found on the dead body.
A knife was found during the autopsy.
7 knives were found during the autopsy. Looks like a work of a deranged maniac.

To that end, let’s try specifying what number triggers which translation. So, for example, a set of keys like this should serve our purpose:

{  
 autopsy_0: "No knife was found on the dead body.",  
 autopsy: "A knife was found during the autopsy.",  
 autopsy_plural: "{{ count }} knives were found during the autopsy. Looks like a work of a deranged maniac.",  
}

// returns:  
// t(‘autopsy’, {count: 0}) = 0 knives were found during the autopsy. Looks like a work of a deranged maniac.

// t(‘autopsy’, {count: 1}) = A knife was found during the autopsy.

// t(‘autopsy’, {count: 7}) = 7 knives were found during the autopsy. Looks like a work of a deranged maniac.

Hmmm, it did not work that way expected. I was disappointed to learn this.

Limitations of Plural: The variable has to be named count. I would have liked a case where you can tell which field in a JSON object controls the pluralization. But, this is just a minor inconvenience.

You need to know which locale supports what kind of pluralization, so you cannot arbitrarily create keys key_0, key_1, key_2, and so on and expect it to work. You can use this lookup utility to see what suffixes work for your locale https://jsfiddle.net/sm9wgLze

Also, have a look at this issue: https://github.com/i18next/i18next/issues/1220

Let me explain what I just said, for example:

hi supports key (for count = 1) and key_plural (for count other than 1, even zero and negative counts)

en supports key (for count =1) and key_plural (for all other values of count)

ar — Arabic — supports key_0 (for count=0), key_1 (for count=1), key_2 (for count=2), key_3 (for count=3 to 10), key_4 (for count=11 to 99), key_5 (for count=100 and above)

So, pluralization does not look much fun anymore. If you still want to use count based translation, the good people from i18next have provided a post processor https://github.com/i18next/i18next-intervalplural-postprocessor You can learn about it on their GitHub repo.

CONTEXT

Context can be thought of as “which variation of a key can be used in a given context”. Case in point, ThatMate (https://thatmate.com) is a sexual and mental health awareness platform for teenagers. We have been planning to use binary and gender neutral pronouns in English locales. Here is quick glance on what it looks like

☝️ Learn more about gender spectrum

{  
  loveThyself_she: "She is in love with herself",

  loveThyself_he: "He is in love with himself",

  loveThyself_they: "They is in love with themself",   
  //yes, "is" is the right helping verb for they here

  loveThyself_ze: "Ze is in love with hirself",

  loveThyself_ey: "Ey is in love with eirself",  
}

We want the appropriate translation to appear on screen based on what the user has chosen as their preferred pronoun. So, if a user’s profile says their preferred pronoun is “ey”, we want then to see the last variations of “loveThyself”. My context here is “ey”

Context is a really powerful tool. For example, Hindi, ‘hi’ does not have equivalent five pronouns. It has just three pronouns, for male, for female, and a gender neutral. We need to fallback on gender neutral pronouns in Hindi for ‘ze’ and ‘ey’ pronouns. But that does not mean we will have to create five keys the same as the case above and have ‘ze’, ‘ey’ and ‘they’ have the same content. We can just define, three and non matching will fallback to suffix-less translation. So, the Hindi keys look like this:

{  
  loveThyself_she: 'वह अपने से प्रेम करती है।,  
  loveThyself_he: 'वह अपने से प्रेम करता है।',  
  loveThyself: 'वो अपने से प्रेम करते हैं।',  
}

And to access these contexts you need to call `i18next.t` with key and context as options. So, for a code that look like this:

const genderPronouns = \['she', 'he', 'they', 'ze', 'ey'\];

// — code removed for brevity

{   
  genderPronouns.map((context) =>   
    (<Text key={context}>{t('loveThyself', {context})}</Text>)  
  )  
}

The outcome in en language code is as follows:

☝️ All five genders have their appropriate pronouns

And, the same code render the following in hi language:

☝️Hindi has just three forms of the pronouns

If you look closely, even though you do not get the script, the last three fallback to the translation that does not have any context (no suffix).

— — — — — — —

There are only a few good things in the world. You can count them if you think hard and long lying on your back well fed and healthy in a serene environment. Context is one of those. Remember how disappointing it was that pluralization could not help us with cases where we specified translations for count = 0, 1, and for all other values of count. Context with help of interpolation can do that. The following code gives the desired result:

<Text>{t(‘autopsy’, {count: 0, context: ‘0’})}</Text>  
<Text>{t(‘autopsy’, {count: 1, context: ‘1’})}</Text>  
<Text>{t(‘autopsy’, {count: 7, context: ‘7’})}</Text>

The result:

☝️ Pluralization combined with context can do what Pluralization should have done

OBJECTS AND ARRAYS

Language resources are just a big JSON object with string keys and values that could string, JSON objects or arrays. Sometimes you may want i18next to return you the object or array instead of string. One such case appeared when we wanted to display a random funny loading message from a list of loading messages. If we get a list of strings, we could just do list[ Math.floor( Math.random() * list.length ) ]. Luckily for us, we can retrieve a key as a JSON object or array, just by instructing i18next so.

{  
  funnyLoadingMessages: [  
    "Maybe the server gnomes are sleeping",  
    "What is taking so long?",  
    "Damn! I can believe I paid for this app.",  
    "One mississippi, two mississippi, …",  
  ]  
}

And the following code returns the array

t("funnyLoadingMessages", { returnObjects: true });

You can apply interpolation and pluralization on the return as well.

REFERENCING OTHER KEYS
You can reference one key into another key’s translations. For example, something like this:

{  
  salutation: "howdy!",  
  goodnight: "$t( salutation ) What are you doing so late up? I am signing off. Good night, m8!"  
}

t("goodnight");  
// returns: howdy! What are you doing so late up? I am signing off. Good night, m8!

And as always, interpolation, context, etc works as expected.

This concludes the third and the final chapter of this tutorial. But, by no means it is a substitute of the documentation offered by i18next (https://www.i18next.com/) and react-i18next (https://react.i18next.com/), so if you want to dive deeper please look into those resources.

Here is how the final app looks like

☝️ Left is Hindi locale, and right is English

☝️ Of course, you’d give the repo a try, but just in case, you wanted to see

Please press the clap button 50 times (yes, you can) if you liked the article. I wrote this article while looking for a complete How-To for multiple language support on React Native in the middle of a break neck ongoing sprint, so there is a good chance that I have made buckets of spelling and grammatical mistakes. Please be kind and let me know if you come across mistakes of any kind. I hope my tardy sense of humor did not bore you to death.

Read Part 1

Read Part 2

This post was originally published on Medium by me on July 22, 2020

This article runs in three parts.

Read Part 1

Read Part 3

If you are looking for the code for part 2, checkout part_2 branch of the GitHub repo at https://github.com/naishe/rn_multilanguage

In the last part, we have got the basics of multiple language support done. We could set up a project, guess the best possible language, store and retrieve language preference and display content in the language. It sounds like we are done, but for any serious medium to large project, there are a bunch of things you want to do to avoid pulling your hair over the course of app development. In this article, we will do some advanced things. Here is the list of things we will do:

1. Splitting the translations into manageable files and move the JSON away from the config file
2. Allow users to change the language and apply it across the app
3. [Let’s leave it for part 3] Rendering dynamic strings using features such as interpolation, formatting, setting timezone locale, pluralization, nesting, context, and JSON objects and arrays

Organizing translations: Namespaces and Deep Objects

What to want when it comes to organizing translations? We want each language to have its own directory, and we want translations to split in multiple files. Maybe, I want to have a “common” file that has translation for commonly used texts like OK, Cancel, Back, and so on. I also want one file for each screen, so I want translations for Home screen in home file, and Settings screen in settings file. So, this is what I want as far as folder structure is concerned

☝️ Folder Structure of Translation Files

Where my common.ts, homePage.ts, and index.ts looks as follows:

☝️ common.ts, homePage.ts and index.ts for English (en)

So, essentially, when we import en from './en', we get a JSON that looks like:

{  
 common: {  
  ok: "OK",  
  cancel: "Cancel"
 },

 homePage: {  
  welcome: "Welcome to i18Next!"  
 }  
}

In i18n lingo, common and homePage are called namespaces. And, we can refer to the contents of a namespace by referring to the key with the namespace as prefix with colon as separator. So, to access ok key from common namespace, we need to do the following, t('common:ok') and it will render the value of ok from the selected language’s common file.

What if we want another layer of grouping? What if we want to group translation of a dialogue box component within the home page. Like this:

{  
 homePage: {  
  welcome: "Welcome to i18Next!",  
  title: "An unnecessarily lengthy tutorial",

  dialogue: {  
   title: "An unnecessary dialogue box",  
   close: "Go back to home page"
  }  
 }  
}

We can use dot notation to traverse through the nested JSON object. Here, t("homePage:title") will return "An unnecessarily lengthy tutorial" and t("homePage:dialogue.title") will return "An unnecessary dialogue box".

Now that the file organization and nested translation is sorted out, we are mostly OK with it. But, wouldn’t it be good if we do not have to type namespace for the most commonly used namespace? It would be so nice, if we could, just do t(“cancel”) and we get the value from the common namespace. Well, we are in luck. We can specify default namespace in configuration and for all the cases where a namespace is not mentioned it will look into default namespace.

At this point, out i18next configuration looks like this:

And, a code looks like this,

<Text>homePage NS: {t('homePage:welcome')}</Text>
<Text>Deafult NS: {t('ok')}</Text>

☝️ Yeah, I see the typo! 😅

Allow Users to Switch Language

It will be a powerful display of your confidence if you choose a user’s preferred language for them and not let them choose the language they want your app to be. But, we do not live in that kind of world where installing an app is a long term commitment. So, we need to provide a way to let user change the language and it is as easy as calling i18n.changeLanguage(“YOUR_LANGUAGE_CODE”)

When you call changeLanguage it changes language for the whole application at the same time, the cacheUserLanguage is also called with the language code of the newly selected language. If you remember from the last part, this is where our logic to store the language code also exists. So, as soon as we change language, the new change gets applied and the preference is stored. Neat!

A small React Native utility component that does the whole heavy lifting for you would look like this:

And the outcome looks like this:

☝️ The default View (language is picked from user preference)

As you click English, the whole app changes to English and it is stored to AsyncStore for future.

☝️ Everything is in English

Well, at this point, the majority of us are done, except for the annoying ones with their “what ifs”. A bunch of advanced features will be discussed in part 3. Hope to see you there.

Read Part 1

Read Part 3

This post was originally published on Medium by me on July 21, 2020

This article runs in three parts. If you are looking for code, please use part_1 branch of this repo: https://github.com/naishe/rn_multilanguage

The second part can be accessed at https://medium.com/cybermonkey/mastering-multiple-language-support-in-react-native-part-2-d33262acc21d

Part 3 is here: https://medium.com/cybermonkey/mastering-multiple-language-support-in-react-native-part-3-d8091339c767

If you are serving a multilingual audience through your app, it becomes quickly obvious that supporting the languages of the demography will give you an edge over the singular language app. Working on ThatMate’s mobile app that serves sexual and mental health education to children and young adults in India, we came to realize that we will have to support multiple Indian languages along with English sooner than later. Luckily, for us, the React Native ecosystem makes it really simple. This article will explain how we did it.

Please be aware that fully localization is much more than just multiple language support, it includes currency conversion, date and time format, RTL (right to left) language and UI direction support, calendar type, timezone, whether they use metric system, and temperature unit among other things. This article is about supporting multiple languages, however, it can easily be extended to provide full localization support.

NOTE: This tutorial assumes that your project is created using React Native CLI (as in npx react-native init AwesomeProject ). If you are using Expo, there is an excellent guide on Expo website https://docs.expo.io/versions/v38.0.0/sdk/localization). The Expo guide uses the i18n-js library for internationalization. If you want to use i18next, you will have to use expo-localization instead of react-native-localization as the dependency.

If you are trying this on a fresh project, create a new React Native project:

# Initialize a new React Native project
npx react-native init rn_multilanguage --template react-native-template-typescript
# Go to the directory generated
cd rn_multilanguage
#Install dependencies
npm install --save i18next react-i18next react-native-localize @react-native-community/async-storage

Where the installed libraries are:

react-native-localize: The library that provides helper functions to figure out the device’s localized preferences like languages, timezone etc. Read more here: https://github.com/react-native-community/react-native-localize

i18next: Our internationalization library. Read more about this here: https://www.i18next.com/

react-i18next: This library provides nice binding with React and React Native projects using hooks, higher order components and also providers Trans — translator component. Read more about it here: https://react.i18next.com/

@react-native-community/async-storage: Local storage library, we will use this library to persist the language preference over app restarts

Now that we have our workspace set up, let’s start coding. In general, this is what we want:

1. Initialize internationalization at the beginning of the app
2. Check user’s stored language preference, and show the content in that language
3. If this is the first time user launching our app or there is no language preference saved, find the best suited language for the user by providing all supported languages and looking into device’s language preference
4. If no matching language is found in step fallback to default language

Initialize i18next for React

Let’s break this code down:

Line #46 to #68 is where the initialization is happening. We are passing a custom language detector to be used. Also, passing initReactI18next from react-i18next to enable React and i18next integration. Then we pass the initialization settings.

Initialization has three parts:

Resources: A JSON object that contains the supported language codes and for each language code, we have a key and the equivalent translation in that language. In the code snippet, we have two language codes: en for English and hi for Hindi. We have added the same keys to both the languages and the associated values are the representation of that key in the respective languages. So, if you do t("Welcome to React") the users with Hindi preference would see “रियेक्ट तथा रियेक्ट-आई १८ एन में आपका स्वागत है” and the users with English as their preference would see “Welcome to React and react-i18next”.

You might be thinking that this way of setting translation will quickly become unwieldy. And, perhaps what if you want to organize the translations in a more nested way, or maybe how gender or pluralization could be handled? Worry not. Let’s get through the basics, then we will see how we can make our life much easier by keeping translations in separate files and how to use nesting.

React: React specific settings go here. I have disabled suspense here. Otherwise, you will get a warning in the lines of

Exception has occurred: Error  
Error: I18nextWithTranslation suspended while rendering, but no fallback UI was specified.  

Add a <Suspense fallback=...> component higher in the tree to provide a loading indicator or placeholder to display.

You will either have to wrap your components in <Suspense> tag like it is suggested here: https://react.i18next.com/latest/using-with-hooks#translate-your-content or you can disable Suspense like I did.

Interpolation: i18next provides you to use template strings and interpolate them at the render time. For example the following translation can be evaluated dynamically

{  
 "sayMyName": "My name is {{ name }}"  
}

When you do the following:

i18next.t("sayMyName", "<Nishant>")  
// returns: My name is &lt;Nishant&gt;

This is to avoid XSS attacks. Read more here: https://www.i18next.com/translation-function/interpolation#unescape

However, in React Native we do not have this issue. We want strings to be rendered as is. So, we want the last interpolation to return us “My name is ” and for that, we want to turn off the escapeValue.

Now that we know how to initialize i18next. Let’s check out how to detect the user language. And, that is the fun part.

I18next follows a middleware plugin sort of architecture. If you have used Express.js, you might be familiar with the concept. In essence, the library exposes a specification, inputs to the plugin and expected outputs from the plugin. In our case, our plugin code spans from line #10 to line #44.

We specify that it is a languageDetector plugin (#11), the detection happens asynchronously (#14). At #15, it provides you with various objects that might be required for your plugin to initialize. I left it empty because I did not need it, but I mentioned it here in case you wanted to do something. Then comes the meat of the code, the detect function. Detect function is provided with a callback function that takes the detected language. Note that the callback function is passed when we mention async is true. If your detection is synchronous, then you can set async:false and return the language code from the detect function. Let’s dig into this detect function, shall we?

At line #23, we look into the AsyncStorage for previously stored language code. I know that I have stored it with the key APP_LANG (I will tell you later where I store the user preference, for now assume that language code is stored in APP_LANG and APP_LANG is a name I provided. You can use your own key if you did not like it). If fetching the language code errors out or returns a falsy value, we will try guessing the user’s preference.

Guessing User’s Language Preference: It only makes sense to suggest a language if we somehow get a list of user’s acceptable languages prioritized by users preference for those languages and compare that list with the languages that we provide for the app and then find which language fits the best. Luckily for us, React-Native-Localize has a tool that does exactly that.

At line #33,

const bestLng = RNLocalize.findBestAvailableLanguage(\['en', 'hi'\]);

We ask react-native-localize to find the best suitable language among the provided language codes by comparing it with the user’s system language preference. In the case shown in the screenshot below, the function will return “hi”, Hindi, as the best language.

☝️ User’s Language Preference: Tamil first, Hindi second, and English third

In case there is no common language between the list of languages you support and the list of languages in the user’s language preference, RNLocalize.findBestAvailableLanguage returns undefined and that is our clue to return the fallback language. In our case, we are returning en, English, as our fallback language at line #35.

Lastly, if it is a sunny day, the stored language will be fetched from local store and we will return this as I did at line #38.

Storing User Language Preference: My favorite part of the plugin is the cacheUserLanguage method, because it centralizes the logic to store user selection. This method is called every time after detect is called and, as we will see later in this post series, when the user opts to change the language.

Step 2: Integration with the App

At this point, we have configured i18next to work with React to guess the best language and to store the selected language permanently. What’s the wait? Let’s integrate with our React Native code. It’s as simple as importing this file in the application main entry file, which is, for most of us mortals, either App.tsx or App.jsx.

At this point our app looks like this:

☝️ Automatically selected Hindi and served the content

Are we done yet? Well, almost. We haven’t given a way to change the language. Neither have we looked at how to split translations in different files. How to interpolate, and how to return an object or array of strings. We do not know how to handle gender specific sentences or plural and singular sentences. Let’s take a break. And continue this in the next article.

Part 2: https://medium.com/cybermonkey/mastering-multiple-language-support-in-react-native-part-2-d33262acc21d
Part 3: https://medium.com/cybermonkey/mastering-multiple-language-support-in-react-native-part-3-d8091339c767

#React #ReactNative #Internationalization #i18n