Internationalization (i18n), the process of adapting your app to support multiple languages and regions, can be a really time-consuming process involving many different people (engineers, copywriters, translators, etc.). At Zenly, we’ve developed a number of workflows to enable us to support 30+ languages for our users all over the world. This blog post sets out the issues we faced as Zenly grew, and the tools and processes we developed along the way to help us scale our internationalization process.
If the project you’re working on grows and attracts users across many different languages, chances are you will face some of the following…
Sometimes you know a given operation is going to take a while, it can be a network call (especially on mobile, with bad network conditions), heavy image processing, or even when getting the user’s location with Core Location.
In that case, most of the time, a loader needs to be displayed somewhere on the screen.
It’s easy to design how we would displaying the loader in an imperative programming world:
However, things might be different if we try to stick with the philosophy of reactive programming:
How would you create an
Observable<Bool> that emits
true when the network request is in progress, and
false when it finishes, just using the
getMe() function? …
It’s been almost a year since we started using RxSwift along the Model-View-ViewModel (MVVM) architecture at BlaBlaCar. We’re thrilled with the results. The code we’re writing with this approach is much easier to understand, maintain, test and scale. However, the first weeks were not a piece of cake: we had to iterate on some aspects of our MVVM+RxSwift architecture to get things right. One of them is the way Inputs are provided to ViewModels.
Let’s go through two different approaches to providing inputs (Rx Events) to ViewModels.
But first, let’s quickly talk about ViewModels.
The public contract of a ViewModel is very important. You have to get it right (for more than one…