One Idea That Changes Your Life

There’s a recent Ask Hacker News thread about one idea that changes someone’s life. Here are some parts that I find illuminating.

Interrogative-led questions:

Favor interrogative-led questions over leading questions.
A leading question attempts to get the listener to agree or disagree with a premise you feed to them.

An interrogative-led question often begins with the words: who; where; what; when; why.

Imagine the responses to these two questions:
– “Did you like the movie?” (Leading)
– “What did you think about the movie?” (Interrogative-led)
Asking good interrogative-led questions is essential for above-average results in many pursuits: science; engineering; interviewing; and negotiation; to name a few. It can also be an important way to de-escalate tense situations. I’ve found it especially useful when talking to subject matter experts when trying to learn something about areas I know little.


Assume Positive Intent:

This might be super basic, but… assume positive intent.

Your parent is not your enemy. Your teacher is not your enemy. Your boss is not your enemy. The other team at work is not your enemy. The corporation is not your enemy. The other political party is not your enemy. Or, more accurately, YOU are not THEIR enemy. At best, you’re an NPC in their game. Many of them probably even want to help you, because you are another person in the world, and that feels good.

I take back what I said about this being basic. The first steps (learning your parent, teacher, boss are on your side) is pretty basic. But applying this concept to more complex systems, like corporations and communities, can be pretty advanced. But at the end of the day, what it means is that, most of the time there isn’t a conspiracy against you, there are simply incentives that you don’t understand.


On Being Correct:

No matter how correct you are, you won’t get anywhere by making the other person feel stupid.


Putting Down Thoughts Into Words:

One thing that’s been super meaningful for me is the notion that if you don’t put something into words, either in speech or in your head or on paper, you don’t know anything about it, even if it’s a feeling or a belief or an intuition deep within you that you’ve held for as long as you can remember.

The act of simply putting a thought into words makes it immediately obvious to you if you really understand it or not, and if not, where your blind spots are.

If the thing you’re concerned with is an unresolved problem or a question, simply articulating the problem or the question can make the solution or the answer obvious. Just going through the process of putting it into words, one way or another, and being sure you’ve settled on the most concise and accurate description of it you can muster, will often make so many things that were hazy obvious, and can reveal to you areas of haziness in your own thinking that you may not have been aware of.


Setting Up Jetpack Navigation Component and Modal Navigation Drawer

On small screens like on mobile (setting aside how humongous smartphones tend to be nowadays), a very common pattern is to use a modal navigation drawer to allow users to navigate between one top-level destinations in the app. You’ve seen them: it’s usually the three horizontal lines on top left of an app, that can be tapped to show and hide a side drawer with a list of menu items inside of it.

Despite being a common design pattern, when I tried to learn how implement it in conjunction with the Jetpack Navigation Component, the available resources can be quite difficult to understand. They’re out there, but in my experience they’re a bit scattered and I had a hard time creating the right mental model in my mind on how to put things together.

This article is my attempt to sum things up. For things to make sense, you will need some familiarity with basic Android development and the Navigation Component itself.


General Mechanism for Scheduling Notification in Android

This article is more of a quick note about what’s involved when your Android app needs to create a notification and schedule it to appear at some time in the future. There’s a lot of articles out there that goes in details about the implementation. Think of this article as more of a summary.

Link Programming

Link: Adding Click Listener to RecyclerView using Kotlin

Recently I needed to figure out how to add click listeners to RecyclerView, in my app that’s using Kotlin as language. Kotlin supports higher-order functions, so the click listener solution can look more concise and elegant, avoiding the need to add interfaces like in Java. Andreas Jakl wrote a detailed tutorial about it here.


Kotlin: Using MediatorLiveData to Use Data from Two Tables at Once

With my current app, the main data is Subjects, where each Subject have multiple Reminders tied to it. For this purpose, I have a couple of tables in the database, which in its simplified form can be seen as below:

Subject table with:

  1. Subject ID
  2. Subject title

Reminder table with:

  1. Reminder ID
  2. Reminder timestamp
  3. Subject ID

I’m using Room for database and LiveData to pull data from the tables. The data then gets supplied to a RecyclerView, where each RecyclerView item will display a Subject with its Reminders.

RecyclerView where each row is a Subject and its four Reminder dates.

The tricky part is that, since there are two tables, I have two separate methods returning LiveData object from each table. Most tutorials out there assume the use of only one LiveData to be observed by the RecyclerView, so it can get confusing when there’s two LiveData at once.

I found a smart solution on Stack Overflow that makes use of MediatorLiveData and Kotlin’s Pair to make the whole thing work. This article is an attempt to expand on that solution by writing down my understanding of it.

This article assumes familiarity with Android concepts for RecyclerView, Room, ViewModel, and LiveData.

Create a “combination” MediatorLiveData class

The first thing to do is to create a class that extends MediatorLiveData. The interesting part is that we need to use Pair<List<Subject>, List<Reminder>> as MediatorLiveData’s type.

After that, we simply construct the class by sending it LiveData<List<Subject>> and LiveData<List<Reminder>> as constructor parameters, then put those two inside a Pair, and finally set the Pair as the MediatorLiveData object’s value.

import androidx.lifecycle.LiveData
import androidx.lifecycle.MediatorLiveData
// This class ia a MediatorLiveData created since I have two different sources of data:
// – subjects table
// – reminders table
// Since they then become two separate LiveData, and I need both to fill in the data
// on the main RecyclerView, then we're using a MediatorLiveData to grab both LiveData
// and add them as sources, so that we can notify observers when any of the data gets
// updated.
class CombinedSubjectReminders(
ldSubject: LiveData<List<Subject>>,
ldReminder: LiveData<List<Reminder>>
) : MediatorLiveData<Pair<List<Subject>, List<Reminder>>>() {
private var listSubject: List<Subject> = emptyList()
private var listReminder: List<Reminder> = emptyList()
init {
value = Pair(listSubject, listReminder)
addSource(ldSubject) {
if( it != null ) listSubject = it
value = Pair(listSubject, listReminder)
addSource(ldReminder) {
if( it != null ) listReminder = it
value = Pair(listSubject, listReminder)
Example of a MediatorLiveData class to handle two LiveDatas at once.

That is pretty much where the magic lies. The potentially tricky part is the addSource method and the value variable, both of which are built-in features of the MediatorLiveData.

Inside ViewModel

Inside the ViewModel, we call the repository’s methods for pulling LiveData from each table, then we return a “combination” object as we describe in the class above, and put in the LiveData as its parameters.

fun getSubjects(): LiveData<List<Subject>>? {
return sroRepository.getSubjects()
fun getReminders(): LiveData<List<Reminder>>? {
return sroRepository.getReminders()
fun getAllData(): CombinedSubjectReminders? {
var ldSubjects = getSubjects()
var ldReminders = getReminders()
if (ldSubjects != null && ldReminders != null) {
return CombinedSubjectReminders(ldSubjects, ldReminders)
return null
Methods inside ViewModel to grab two LiveData from repository and put them into one MediatorLiveData

Inside RecyclerViewAdapter

Inside the adapter, we modify its constructor to accept two Lists as parameters, the List<Subject> and the List<Reminder>.

class SubjectRecyclerViewAdapter(
val subjects: List<Subject>,
val reminders: List<Reminder>,
val listener: OnListFragmentInteractionListener?
) : RecyclerView.Adapter<RecyclerView.ViewHolder>() {
Put in the two List<> as constructor parameters in RecyclerViewAdapter

Observe the MediatorLiveData

Finally, inside the fragment or activity that has the RecyclerView, we observe the returned MediatorLiveData from the ViewModel. When there’s any change, the observer gives a Pair containing a List<Subject> and a List<Reminder>. We can then put those two as the parameter of the adapter.

mainViewModel = ViewModelProvider(activity!!).get(
// New observer
Observer { subjectsAndRemindersPair ->
view.sro_subject_list.adapter = SubjectRecyclerViewAdapter(
Observe the MediatorLiveData given by ViewModel, and update RecyclerViewAdapter accordingly.

Note how the Observer pattern uses a lambda with subjectsAndRemindersPair as the parameter. That is essentially the type of the MediatorLiveData in question, and by default Kotlin call that parameter it. I renamed it to subjectsAndRemindersPair to make it easier to understand.


Strategies for Creating A Single RecyclerView with Multiple ViewHolders

This article assumes familiarity with creating a RecyclerView using a single ViewHolder for each item, which is the most common use case.

Here are the possible cases where a RecyclerView might use an adapter with multiple ViewHolders instead:

A RecyclerView that uses two different layouts for each item based on odd/even position.

Case One

Have one RecyclerView to display different layouts for different items at the same time, based on certain conditions. Just as an example, here I have a RecyclerView that uses two different layouts for each item based on odd/even position.

A RecyclerView that uses identical layout for each item.

Case Two

Have one RecyclerView to display the same layout for each item. However, based on user action on certain conditions (such as during sorting or filtering action), the same RecyclerView will display the same data using a different layout. As an example, here’s a RecyclerView that uses just one layout for each item. Use your own imagination for an example where the RecyclerView at a different time uses a different layout instead.

Case 1

Here’s the general method. I’m only listing areas that differ from the usual case of RecyclerView with just one ViewHolder:

  1. We now have to create the multiple ViewHolder classes first. I prefer them to be inner classes of the custom RecyclerView.Adapter class. Pretty self-explanatory, the only possible gotcha/oddity here is that inside the class’s constructor, we create variables that directly access specific views inside a certain layout, without the class knowing about which layout it is related to.
  2. The RecyclerView adapter now must extend the more generic RecyclerView.Adapter<RecyclerView.ViewHolder>class instead of using the single custom ViewHolder class as the generic type.
  3. The RecyclerView now must override getItemViewType(), which is used to decide which ViewHolder class to be used on a certain item position in the RecyclerView.
  4. The method onCreateViewHolder() must now return the more generic RecyclerView.ViewHolder
  5. The method onBindViewHolder() must now use the more generic RecyclerView.ViewHolder object as its first parameter.

Case 2

  1. Have a variable to determine which ViewHolder should be used by the RecylerView. This will usually be inside the fragment or activity.
  2. Pass that variable as one of the parameters for constructing the RecyclerView’s adapter.
  3. Inside the adapter, create the multiple ViewHolder classes first. I prefer them to be inner classes of the custom RecyclerView.Adapter class. Pretty self-explanatory, the only possible gotcha/oddity here is that inside the class’s constructor, we create variables that directly access specific views inside a certain layout, without the class knowing about which layout it is related to.
  4. The RecyclerView adapter now must extend the more generic RecyclerView.Adapter<RecyclerView.ViewHolder>class instead of using the single custom ViewHolder class as the generic type.
  5. The RecyclerView adapter now must override getItemViewType(), and check the variable from step 2 to determine which ViewHolder to use.
  6. The method onCreateViewHolder() must now return the more generic RecyclerView.ViewHolder
  7. The method onBindViewHolder() must now use the more generic RecyclerView.ViewHolder object as its first parameter.

CSS History

Old CSS, new CSS is a great article recounting the history of CSS. With it, I can pinpoint exactly when I last regularly updated myself with its development (it was somewhere after browser prefixing hell, and before flexbox). Really useful for finding what I should catch up on, as well.



I was working with some CSS code when I accidentally typed the color code #f2d2d2, and found it to be such a pleasant color. I set it as the background color for this paragraph. Happy accident.


Data Binding with Kotlin; Why?

I came across the Data Binding resources page for Android, and reading through it got me questioning. Why is such setup necessary, when Kotlin extensions allows for super easy view binding already (example below)?

// Using R.layout.activity_main from the 'main' source set
class MyActivity : Activity() {
override fun onCreate(savedInstanceState: Bundle?) {
// Instead of findViewById<TextView>(
textView.setText("Hello, world!")
Example of view binding using Kotlin Extensions (source)

As it turns out, there’s quite a difference as explained on a Reddit comment that I pasted below:

Hey! Developer Advocate for Android at Google here!

I wanted to add a bit of background here. Kotlin Extensions with synthetic views was never intentionally “recommended” though that shouldn’t be taken as a recommendation to not use them. If they’re working for you please feel free to continue using them in your app!

We’ve been shifting away from them (e.g. we don’t teach them in the Udacity course) because they expose a global namespace of ids that’s unrelated to the layout that’s actually inflated with no checks against invalid lookups, are Kotlin only, and don’t expose nullability when views are only present in some configuration. All together, these issues cause the API to increase number of crashes for Android apps.

On the other hand, they do offer a lightweight API that can help simplify view lookups. In this space it’s also worth taking a look at Data Binding which also does automatic view lookups – as well as integrates with LiveData to automatically update your views as data changes.

Today, there’s a few options in this space that work:

  • Data Binding is the recommendation for view lookup as well as binding, but it does add a bit of overhead when compared to Android Kotlin Extensions. It’s worth taking a look to see if this is a good fit for your app. Data Binding also allows you to observe LiveData to bind views automatically when data changes. Compared to Kotlin Extensions, it adds compile time checking of view lookups and type safety.
  • Android Kotlin Extensions is not officially recommended (which is not the same as recommendation against). It does come with the issues mentioned above, so for our code we’re not using them.
  • Butter Knife is another solution that is extremely popular and works for both Kotlin and the Java Programming Language.

Reading through the comments here there’s a lot of developers that are having great luck with Kotlin Extensions. That’s great – and something we’ll keep in mind as we look at ways to continue improving our APIs. If you haven’t taken a look at Data Binding, definitely give it a shot.

As an aside, our internal code style guide is not intended to be directly applied outside of our codebase. For example, we use mPrefixVariables, but there’s no reason that every app should follow that style.

On ButterKnife

The quote mentions ButterKnife, so it’s probably worth mentioning also that the Github page for ButterKnife mentions that development for it is being winded down, and it recommends to use View Binding instead.

Data Binding vs View Binding

Now that these two concepts are being mentioned, what are the differences? From the View Binding documentation page:

View binding and the data binding library both generate binding classes that you can use to reference views directly. However, there are notable differences:

  • The data binding library processes only data binding layouts created using the <layout> tag.
  • View binding doesn’t support layout variables or layout expressions, so it can’t be used to bind layouts with data in XML.

Stack Overflow: Android : Difference between DataBinding and ViewBinding


CSS: Adding Dark Mode to Posts on Certain Category on

The other day I had an idea to make photography posts in my main blog to be displayed in a sort of dark mode design. This is something recently implemented in Instagram also, and I do feel that black background color and surroundings make pictures and colors pop more.

Making things dark is relatively simple with CSS, but then I found that the tricky part is targeting the right posts. My photography posts are already categorized properly, and usually with WordPress the way to target certain pages is to make use of the built-in body class feature, which adds certain classes to certain page’s <body> tag to make it selectable with CSS.

It looks like this for one of my photography posts, for example:

<body class="post-template-default single single-post postid-1005 single-format-standard logged-in admin-bar no-customize-support custom-background wp-embed-responsive customizer-styles-applied no-sidebar singular has-cta-button header-overlay-none featured-content-overlay-light tags-hidden author-hidden highlander-enabled highlander-light custom-colors">

It’s quite a lot, but the main thing there is that there is no class name that’s related to the post’s category there. WordPress by default doesn’t do that (perhaps because it might cause unpredictable issues since sometimes people would add a gazillion categories to a post, which would then create a gazillion body classes to be added).

There is a code snippet solution that can add category names to a single post’s body class, which can then be added thru a plugin. Technically my main blog is on the Business plan on, so it supports installing plugin. However, long time ago I decided not to have plugins on the site since I want to see how far I can modify a site without using plugins or code modifications in general.

So, the only solution then seems to be by using Custom CSS code, targetting each post individually. This can be done using the post ID, which fortunately is added in the class. Something like this:

/* Dark mode for photography posts */
body.postid-1005 .widget {
  background: #000;

This works, however the next problem is that it will get tedious to manually add CSS code for different post IDs, especially if there will be more posts in the future. This is until I discovered two things

  1.’s Custom CSS supports using the CSS extension SASS (and also LESS)
  2. Iteration is supported in SASS

So I messed around and came up with this solution:

$post-ids-dark-mode: 1005, 1337;
@each $id in $post-ids-dark-mode {
    body.postid-#{$id} {
        background: #000;
        .widget {
            background: #000;
        .site-title a, p, h1, .widget a {
            color: #fff;
        .comment a, .comment b {
            color: #d0d0d0;
            font-weight: bold;

The interesting parts are these:

$post-ids-dark-mode: 1005, 1337;

That’s a list that contains all post IDs to be affected. Yes, I will have to input each post ID individually there each time I have a new post, but at least I only need to add a single number and not write the rest of the CSS.

This then is where it loops:

@each $id in $post-ids-dark-mode {

It’s pretty self-explanatory what it’s doing, and the SASS code then gets automatically converted to CSS as follows:

body.postid-1005 {
    background: #000

body.postid-1005 .widget {
    background: #000

body.postid-1005 .site-title a,body.postid-1005 p,body.postid-1005 h1,body.postid-1005 .widget a {
    color: #fff

body.postid-1005 .comment a,body.postid-1005 .comment b {
    color: #d0d0d0;
    font-weight: 700

body.postid-1337 {
    background: #000

body.postid-1337 .widget {
    background: #000

body.postid-1337 .site-title a,body.postid-1337 p,body.postid-1337 h1,body.postid-1337 .widget a {
    color: #fff

body.postid-1337 .comment a,body.postid-1337 .comment b {
    color: #d0d0d0;
    font-weight: 700

The necessary CSS codes for all affected posts are automatically created. Pretty neat! Have a look at the result here.