👨‍💻

Recently I've found myself spending a lot of time trying to make sure things look nice on both LTR as well as RTL locales, so that folks with UIs in Arabic, Hebrew, Persian, or Urdu can also have an A+ experience on Android. I ran into an annoying problem where international phone numbers, such as +9708675309 would show up in the app as 9708675309+. The issue was that in RTL languages, numbers should be LTR, so the phone number portion was displayed correctly, but unfortunately the + was displayed on the right side of the phone number. After a good amount of Googling, the fix is actually really simple. Just place the Left-to-Right Isolate Unicode mark on the left of the text you want to be LTR, and then place the Pop Directional Isolate Unicode mark on the right of the text, so that it doesn't make the entire rest of the text LTR. It looked sort of like this in Kotlin: "\u2066+9708675309\u2069" and it worked like a charm!

Over the past year I've learned a bunch of useful tricks for RxJava, and I'm gonna post them here as I remember them or use them. Hopefully this'll grow to a large list/cheatsheet! Here is a way to take the first element multiple flowables that may emit the same data (but loaded from disk or memory or network) and then emit the first one that returns. Concat checks flowable1 first, and then flowable2. I got this from this blog post from Dan Lew . Flowable .concat(flowable1, flowable2) .firstElement() Dan uses it for loading data first from memory, then from disk, and finally from network, so there's a lot of other stuff you can add to it too. He demonstrates how you can use a side effect to create a flowable that saves to network requests to disk and memory whenever you load it from remote: val cache: Flowable<Data> = ... val network: Flowable<Data> = ... val networkWithCaching: Flowable<Data> = network .doOnNext { data -> add...

The other day, I was browsing through the Android blog world (make sure to check out https://blog.danlew.net/ ), and found this really awesome blog post from the developers over at Square about reliably displaying the Android keyboard, which is controlled by a rather difficult API. After trying out their code, however, I realized that it did not work for my purpose which was to focus a SearchView after clicking a button. The bug was really strange, because while we had called requestFocus() on the SearchView , when we queried it for isFocused , it would return false ! Turns out, after a lot of struggling, I found that requestFocus() actually may give focus to one of the descendants of the View instead. SearchView is actually a ViewGroup , so focus was actually given to a TextView that was a child of the SearchView . After learning about this, the fix was easy: Instead of only directly checking the SearchView for isFocused , do a recursive check on the focusedChild of the Searc...