Sign in

This article is about something I’ve been regularly seeking but as of the date of its publication, I cannot yet find a working solution. If I happen to find a good alternative, I’m going to post an update later.

Image by Pexels from Pixabay

Motivation

Unless you’re publishing an iOS-only application and abandoning the other 70% of your potential customers in the mobile market (I can see you, Clubhouse), you’re going to have multiple shared (as in duplicated) messages between iOS, Android, and possibly, Web clients.

As a matter of fact, programmers hate duplicating stuff. It violates our precious Don’t Repeat Yourself principle, and duplication always


Android provides a simple (and unprotected) key=value storage that can be used to persist user preferences and other non-critical data.

All the data stored in SharedPreferences should be considered PUBLIC even if they are accessed using the mode Context.MODE_PRIVATE, and by no means they should EVER be used to store password hashes (even salted), tokens or credit card information. Some people even argue that one should not use Android Shared Preferences AT ALL.

Nonetheless, you might decide (at your own risk 😛) to use this kind of store to keep some non-sensible data as language or filter preferences.

It’s easy…


Photo by Pixabay from Pexels

Managing several libraries in a multi-module project might get a bit complicated over time. Hopefully, there’s Gradle Kotlin DSL for the rescue.

In your app/build.gradle for an Android module, you might have:

dependencies {
//...
implementation ("androidx.appcompat:appcompat:1.0.2")
//...
}

After a few months, you decide to create a new library module and move some nice library you’ve been writing in your main module to a separate one. Then you create your new module using the assistant in Android Studio, and it creates a new mylib/build.gradle file that's going to include:

dependencies {
//...
implementation ("androidx.appcompat:appcompat:1.2.0")
//...
}

You end up…


Photo by Brett Jordan from Pexels

Sometimes a backend provides you with a partial or unstyled html code, usually provenient from a Rich Text editor in a Web App. Therefore, you need to complete this html code and display it in a WebView. If you’re using a custom font, you might have noticed there’s no straightforward way to modify the default WebView font family, as there is for other views. Here’s an easy way to do it via CSS.

Let’s just assume you have a .ttf or an .otf file under your res/font directory. You can use the following code…

Tiago Reul

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store