Categories
Programming

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.

Categories
Programming

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.

Categories
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.

Categories
Programming

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.

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.

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>.

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.

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.


Categories
Programming

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.
Categories
Programming

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.

Categories
Programming

#f2d2d2

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.

Categories
Programming

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)?

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

Categories
Programming

CSS: Adding Dark Mode to Posts on Certain Category on WordPress.com

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 WordPress.com, 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 WordPress.com 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,
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. WordPress.com’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.

Categories
Programming

Digging into Coroutines

With Kotlin comes one of its most famous features: coroutines.

Javanese is my first language. No, not the Java programming language. Javanese. So whenever I hear a foreign word like coroutines, nothing shows up in my mind. It has no meaning. This post is an attempt to dig into the word to give my brain some understanding of it.

Coroutines, Threads, Processes

First, here’s what the official documentation says about it (emphasis mine):

One can think of a coroutine as a light-weight thread. Like threads, coroutines can run in parallel, wait for each other and communicate. The biggest difference is that coroutines are very cheap, almost free: we can create thousands of them, and pay very little in terms of performance. True threads, on the other hand, are expensive to start and keep around. A thousand threads can be a serious challenge for a modern machine.

“Your first coroutine with Kotlin”

I know that coroutines is a way to do asynchronous programming, and from the information above, it seems to have these three major points:

  1. Analogous to a light-weight thread,
  2. Multiple coroutines can run together at the same time, they can wait for each other, and also communicate to each other,
  3. Having a lot of them does not hurt performance.

I’m currently using Kotlin for programming Android apps, so the next step seems to be to figure out what exactly a thread is in this context. Here’s what the documentation says (emphasis mine):

When an application component starts and the application does not have any other components running, the Android system starts a new Linux process for the application with a single thread of execution. By default, all components of the same application run in the same process and thread (called the “main” thread). If an application component starts and there already exists a process for that application (because another component from the application exists), then the component is started within that process and uses the same thread of execution.

Android Developers — Processes and Threads

So from here, it seems like within Linux there is a concept of “process”, and also “thread of execution”. According to Wikipedia:

In computing, a process is the instance of a computer program that is being executed by one or many threads. It contains the program code and its activity. Depending on the operating system (OS), a process may be made up of multiple threads of execution that execute instructions concurrently

Wikipedia — Process (computing)

This helps understanding what a “process” is. One of the definition from Merriam-Webster is: “something going on”. So in this context, a process is the idea of an app that’s currently running within Android. That’s simple enough.

Also, it just blew my mind right now that this is why a processor is called that —again, English is not my first language—it’s basically the thing that runs the apps.

Let’s have a few seconds of visual break:

Photo by Tran Mau Tri Tam on Unsplash

Wikipedia has this to say about thread of executions:

In computer science, a thread of execution is the smallest sequence of programmed instructions that can be managed independently by a scheduler, which is typically a part of the operating system.[1] The implementation of threads and processes differs between operating systems, but in most cases a thread is a component of a process. Multiple threads can exist within one process, executing concurrently and sharing resources such as memory, while different processes do not share these resources.

Wikipedia — Thread (computing)

Thread, according to Merriam-Webster:

3 : something continuous or drawn out: such as

a : a line of reasoning or train of thought that connects the parts in a sequence (as of ideas or events)

So from the two explanations above, a process seems to be the whole existence of a running app, while a thread is the smaller element within the process.

For example in Instagram, a thread might be the start from finish when someone uploads a new picture (tap plus icon, find the image, add filter, add description, click upload, wait for it to be sent, have the image displayed). I don’t know if that’s technically accurate, but probably a good approximation.

The Wikipedia about thread also has this useful section about the difference between processes and threads:

Threads differ from traditional multitasking operating-system processes in several ways:

  • processes are typically independent, while threads exist as subsets of a process
  • processes carry considerably more state information than threads, whereas multiple threads within a process share process state as well as memory and other resources
  • processes have separate address spaces, whereas threads share their address space
  • processes interact only through system-provided inter-process communication mechanisms
  • context switching between threads in the same process typically occurs faster than context switching between processes

It also has this useful image:

A process with two threads of execution, running on one processor

So far we’ve learned about what a process and a thread is. And, specifically within Android, we have learned that a running app is given one process and one main thread.

So a coroutine is like a thread, and has similar behaviors, except that it’s light-weight and can perform better.

That’s a good start. Now let’s see if we can figure out what it means with multiple coroutines running in parallel, communicating and coordinating with each other.

Photo by Gaelle Marcel on Unsplash

Here is another explanation of what coroutine is:

coroutine A program component that allows structuring of a program in an unusual way. A coroutine resembles a subroutine, with one important difference. A subroutine has a subordinate position relative to the main routine: it is called and then returns. Coroutines, however, have a symmetric relation: each can call the other. Thus a coroutine is resumed at a point immediately following its call of another coroutine; it never returns, but terminates its operation by calling (resuming) another coroutine.

Encyclopedia.com — coroutine

What even is a subroutine?

In computer programming, a subroutine is a sequence of program instructions that performs a specific task, packaged as a unit. This unit can then be used in programs wherever that particular task should be performed.

Subroutines may be defined within programs, or separately in libraries that can be used by many programs. In different programming languages, a subroutine may be called a procedure, a function, a routine, a method, or a subprogram. The generic term callable unit is sometimes used.

Wikipedia — Subroutine
Photo by Mousssss Liu on Unsplash

So subroutine is basically a function. I know functions! I don’t think it’s practically possible to learn programming without learning about functions anyway.

Co+routine


“co-” prefix, from Wiktionary:

  1. together; mutually; jointly
  2. partner or subordinate in an activity
  3. to the same degree

So linguistically, perhaps coroutines mean functions that can run and work together as an equal.

I’m happy with that conclusion. It’s something I can picture in my mind. It does not seem to explain technically all coroutines can do in the context of Kotlin programming, in fact it sounds a little too bland to me. However, it is concise and memorable. And that perhaps is all a good name needs to do.