The Context-in-ViewModel debate has been echoing through Android circles for years — a quiet civil war between practicality and purity.

The confusion stems from how Android’s lifecycle works — not all contexts are created equal, and misusing one can quietly wreak havoc.

Here are 4 Commandments of Context in Android ViewModels - guiding principles to help you write clean, leak-free, and lifecycle-safe code.

Thou shalt not store Context in a ViewModel property.

Never do this:

class MyViewModel(val context: Context) : ViewModel() // 🚫 BAD

This pins your Activity to memory and prevents proper Garbage Collection after configuration changes. If you must access context frequently, use:

class MyViewModel(application: Application) : AndroidViewModel(application)

Then retrieve context via:

val appContext = getApplication<Application>().applicationContext

This returns the Application context, not the UI one.

You can also inject the context in a ViewModel:

@HiltViewModel
class MyViewModel @Inject constructor(
    @ApplicationContext private val context: Context
) : ViewModel() {

If you must inject Context into a ViewModel using Hilt, always qualify it with @ApplicationContext — anything else risks tethering your ViewModel to a destroyed Activity.

Thou shalt only use Context for short-lived operations

While the general rule is to avoid using Context in a regular ViewModel, there are valid cases for short-lived Ops where you temporarily need it.

Accessing a String Resource - useful for localized messages or logging:

fun getWelcomeMessage(context: Context): String {
    return context.getString(R.string.welcome_message)
}

Getting a System Service - like ClipboardManager, Vibrator etc.

fun copyTextToClipboard(context: Context, text: String) {
    val clipboard = context.getSystemService(Context.CLIPBOARD_SERVICE) as ClipboardManager
    clipboard.setPrimaryClip(ClipData.newPlainText("Copied", text))
}

This is transient usage — no storage, no reference kept, no leak risk.

Thou shalt not pass an Activity or a View Context

When you pass a Context tied to a Fragment or Activity, it references their UI lifecycles.

If your ViewModel holds it longer than the screen’s lifetime, the system can’t garbage-collect the destroyed Activity, resulting in a leak.

// 🚫 BAD: Activity context passed directly to the ViewModel
class MainActivity : ComponentActivity() {

    private val viewModel = MyViewModel(this) // ❌ leaks Activity after rotation

    override fun onCreate(savedInstanceState: Bundle?) {
        viewModel.startSomething()
    }
}

class MyViewModel(private val context: Context) : ViewModel() {

    fun startSomething() {
        // Holding Activity context inside ViewModel = potential memory leak
        val vibrator = context.getSystemService(Context.VIBRATOR_SERVICE) as Vibrator
        vibrator.vibrate(VibrationEffect.createOneShot(100, 255))
    }
}

Why this is bad:

• The context here references the Activity, not the application
• When the screen rotates, Activity dies, but ViewModel may live longer
• That lingering reference keeps the destroyed Activity in memory which is what we call a memory leak

Think of it like borrowing a USB stick but forgetting to give it back — now you’re holding onto the whole desktop!

However, in the Compose world, this pattern is safe because it is short-lived and you are not saving the context anywhere:

val context = LocalContext.current
viewModel.analyzeGalleryImage(context, imageUri)

If it smells like a UI operation, move it out of the ViewModel

If you ever find yourself doing something like this, inside the ViewModel — 🚨 that isi code a smell.

Toast.makeText(context, "Saved!", Toast.LENGTH_SHORT).show()

Instead, send UiAction event and let the Activity or Composable handle it.

Wrapping Up the Debate

Context is not forbidden inside ViewModels but it should be treated like radioactive material: useful in tiny, controlled doses.

You can safely use it for quick, one-off tasks like reading resources, grabbing a system service, or decoding a file — but never hold onto it.

When in doubt, prefer the Application context or push the call down into a repository or use case layer.

While Room simplifies many aspects of database handling, understanding foreign keys is crucial for creating relational databases with complex relationships between entities.

A foreign key is a referenced column or columns that can be found in a different table.

A foreign key establishes a link between two tables in a database to create a way of cross-referencing the two tables.

The Idea behind Foreign Key

The idea behind foreign keys is based on a parent-child relationship where we have a parent table and a child table.

The below diagram maps a HR system with 2 tables - the first table stores employees’ basic info while the other contains extra employees’ details.

The child table is linked to its parent table through a foreign column(key) which references the parent table.

In essence, foreign keys establish a connection between related tables facilitating the retrieval of interconnected data within the database.

A table can have multiple foreign keys that reference different tables.

What about Primary Key

A primary key is a unique identifier for each row in a database table.

It prevents duplicated rows by ensuring no records share the same key while also guaranteeing that primary column doesn’t contain null values.

Room database enables you to autogenerate Primary key by using an incrementing integer value, a UUID (Universally Unique Identifier), or a custom algorithm.

Primary Key vs Foreign Key

While a primary key uniquely identifies records within its own table, a foreign key acts as a bridge, connecting records across multiple tables.

The foreign key column (referenced column on child table) must contain only unique values and often it is the primary key of the parent table.

Anatomy of Foreign Key in Code

The code for the above parent table looks like this:

@Entity(tableName = "customers_table")
data class Customer(
    @PrimaryKey(autoGenerate = true)
    @ColumnInfo(name = "customer_id")
    val customerId: Long,
    @ColumnInfo(name = "name")
    val name: String,
    @ColumnInfo(name = "phone_number")
    val phoneNumber: String,
    @ColumnInfo(name = "address")
    val address: String
)

• @Entity marks the Customer class as an entity in the Room database
• @PrimaryKey annotation marks the customerId property as the primary key for the Customer entity.
• autoGenerate = true parameter specifies that Room should automatically generate unique values when inserting new records.
• @ColumnInfo annotation specifies column details and provides a flexibile way to customize the column name, data type etc

The code for the above child table looks like this:

@Entity(
        tableName = "orders_table",
        foreignKeys = [
            ForeignKey(
                    entity = Customer::class,
                    parentColumns = arrayOf("customer_id"),
                    childColumns = arrayOf("customer_id"),
                    onUpdate = ForeignKey.CASCADE,
                    onDelete = ForeignKey.CASCADE
            )]
)
data class Order(
    @PrimaryKey(autoGenerate = true)
    @ColumnInfo(name = "order_id")
    val orderId: Long,
    @ColumnInfo(name = "customer_id")
    val customerId: Long,
    @ColumnInfo(name = "item_id")
    val itemId: String,
    @ColumnInfo(name = "order_details")
    val orderDetails: String
)

• Order entity class is annotated with @Entity and includes the foreignKeys parameter
• Inside the foreign keys parameter we define an array of ForeignKey objects
• entity = Customer::classspecifies the entity (table) that the foreign key references, in this case it is the parent Customer entity
• parentColumns = arrayOf("customer_id") specifies the column in the referenced parent Customer entity that the foreign key corresponds to i.e. the customer_id column in the Customer entity.
• childColumns = arrayOf("customer_id") specifies the column in the Order child entity that the foreign key is defined on

Handling updates and deletions

We can optionally use onDelete and onUpdate attributes to define the behavior when a record on the parent is deleted or updated.

ForeignKey.CASCADE means when a row in the parent table is deleted, the child table also deletes associated rows on its table.

Relationships

Foreign keys create relationships between tables, defining how data in one table relates to data in another.

These relationships can be one-to-one, one-to-many, or many-to-many as detailed on this blog post.

Exploring One-to-One Relationship Models in Room Database

Conclusion

Together, primary and foreign keys form the foundation of relational databases, enabling developers to design robust and scalable data models.

Cheers guys!

Room Database is a persistence library provided by Google and acts as an abstraction layer over the underlying SQLite database.

This means Room simplifies database setup and configuration allowing your app to interact with the database through ordinary function calls.

One fundamental concept in database design that Room Database handles exceptionally well is the one-to-one relationship.

This relationship type defines a scenario where each row in one table is associated with exactly one row in another table.

On the above illustration, each row from table one is mapped to one row of table two. This concept can be visualized as a single table split halfway with a common property.

Classic Examples

Some examples of one-to-one relationship modeling include:

• Country and Capital: each country has a unique capital, and each capital is associated with exactly one country
• User and UserProfile: user’s username and password data can be stored in one table while additional profile information (like email, bio, etc.) could be stored in a separate table linked to the user table.
• Employee and EmployeeInfo: HR database system can have employee’s basic details like Id, name, etc in one table with a supplementary table holding additional info such as contact details, home address etc.
• Customer and CreditCard: In a banking system each customer might have one credit card associated with their account.

One-to-One Relationship Model in Code

This is how the above tables would look like in code.

@Entity(tableName = "countries_table")
data class Country(@PrimaryKey val id: Long, val name: String, val lang: String)

@Entity(
        tableName = "capitals_table",
        foreignKeys = [
            ForeignKey(
                    entity = Country::class,
                    parentColumns = arrayOf("id"),
                    childColumns = arrayOf("country_id"),
                    onDelete = ForeignKey.CASCADE
            )
        ]
)

data class Capital(
    @PrimaryKey(autoGenerate = true)
    @ColumnInfo("id")
    val id: Long,
    @ColumnInfo(name = "country_id")
    val countryId: Long,
    @ColumnInfo(name = "name")
    val name: String
)

You will notice that Capital entity specifies a foreign key to link it to the Country Entity.

The foreign key column will act as a common column and will be used on the POJO class to specify the relationship between Country and Capital.

You can find more info on foreign keys on this blog.

Connecting Room Tables Using Foreign Keys

Relation Wrapper for DAO

When querying the database the dao will return neither Country nor the Capital entities.

This is where an intermediary Plain Old Java Object (POJO) comes in. We need a POJO helper class which models one-to-one relationship between two entities.

data class CountryAndCapital(
    @Embedded val country: Country,
    @Relation(
            parentColumn = "id",
            entityColumn = "country_id"
    )
    val capital: Capital
)

This POJO tells Room how our entities relate and work together.

• The name of the POJO is CountryAndCapital which is a convention to combine first and second class names using With or And conjunctions
• In the POJO one entity must include a reference to the primary key of the other entity
• @Embedded annotation applied to the country property tells Room to include all properties of the Country class as columns in the CountryWithCapital table. This means that properties like id, name, and lang from the Country class will internally be treated as columns in the database table for CountryWithCapital
• @Relation is an annotation used in a POJO to specify the relationship between Country and Capital and automatically fetch relation entities
• parentColumn refers to the column in the parent entity - Country
• entityColumn refers to the column in the child entity - Capital

Querying a One-to-One Relationship Model

We can then query all users with their addresses like this:

@Dao
interface CountryCapitalDao {
    @Query("SELECT * FROM countries")
    fun getCountriesWithCapitals(): List<CountryWithCapital>?
}

This query will return a list of CountryAndCapital objects, each containing a Country object and a Capital object which you can then employ on your project’s logic.

Happy Coding

Jetpack Compose continues to revolutionize the way we create beautiful UI interfaces.

One of its intriguing features is the eye-catching Marquee effect achievable with just a few simple keystrokes using the standard compose modifier.

The basic marquee modifier allows you to animate text horizontally making it scroll continuously across the screen.

This can be useful when dealing with long chunks of text that do not fitting within the available space.

The scrolling effect not only ensures the visibility of the text but also adds a touch of flair to your app as seen on news tickers, breaking news alerts, social media feeds, testimonials, real-time currency and stocks updates.

The marque effect code is incredibly simple and beginner-friendly:

@OptIn(ExperimentalFoundationApi::class)
@Composable
fun MarqueeTextExample() {
    Text(
        text = "Breaking News: Jetpack Compose is Amazing!",
        modifier = Modifier
            .basicMarquee()
            .padding(20.dp)
    )
}

Marquee modifier is still marked as experimental in Jetpack Compose hence the @OptIn(ExperimentalFoundationApi::class) annotation.

We simply applybasicMarquee modifier to create the scrolling effect. The padding modifier adds some space around the scrolling text.

The modifier can even be customized further to control the speed, iterations, and delay, allowing you to tailor it to your specific design requirements.

For example, if you want the text to zip across the screen at speed of light, you simply need to increase its default velocity

The default speed is 30 dps per second but can this can be stepped up as needed.

@OptIn(ExperimentalFoundationApi::class)
@Composable
fun MarqueeTextExample() {
    Text(
            text = "Breaking News: Jetpack Compose is Amazing!",
            modifier = Modifier
                    .basicMarquee(
                            velocity = 500.dp,
                            initialDelayMillis = 2_000,
                            iterations = 5
                    )
                    .padding(8.dp)
    )
}

Marquee modifier can also be applied to a non-text composables as shown on this animation composed of a Row containing Cyan-colored Boxes

The boxes scroll horizontally courtesy ofbasicMarquee modifier applied on the Row.

@OptIn(ExperimentalFoundationApi::class)
@Composable
private fun MarqueeEffect() {

    Box(modifier = Modifier.padding(top = 80.dp)) {

        //Marquee modifier applied to the row
        Row(modifier = Modifier.basicMarquee()) {

            //Draw row content
            repeat(30) {
                Box(
                        modifier = Modifier
                                .size(40.dp)
                                .padding(4.dp)
                                .background(Color.Cyan)
                                .padding(4.dp)
                ) {

                    Canvas(
                            modifier = Modifier
                                    .size(20.dp)
                                    .align(Alignment.Center)
                    ) {
                        drawCircle(color = Color.Magenta)

                    }
                }

                Spacer(modifier = Modifier.width(8.dp))
            }
        }
    }
}

You can replace the boxes with any other composable to create a scrolling effect for different types of content. For instance, you could use images, icons or custom composables instead of the boxes.

It’s worth noting that scrolling occurs when the size of the content exceeds the available space. For example, when the device is rotated from portrait to landscape, the marquee effect doesn’t play.

Another hack is theanimationMode which determines if the marquee should start animating Immediately or only WhileFocused. However, for WhileFocused mode, the content must be made focusable.”

You can adjust the earlier code to request for focus:

@OptIn(ExperimentalFoundationApi::class)
@Composable
fun MarqueeTextExample() {

    val focusRequester = remember { FocusRequester() }
    Text(
            text = "Breaking News: Jetpack Compose is Amazing!",
            modifier = Modifier
                    .basicMarquee(animationMode = MarqueeAnimationMode.WhileFocused)
                    .focusRequester(focusRequester)
                    .focusable()
                    .clickable { focusRequester.requestFocus() }
                    .padding(40.dp)

    )
}

Rather than allowing the marquee to run endlessly which takes more battery life, a more effective approach is to display the marquee when the user clicks or focuses on the text intending to see more content.

It is a wrap guys, keep exploring!

In the world of programming, Boolean logic serves as the centerpiece in the decision-making processes.

Boolean is a data type that can hold either atrue or a false value.

One of Kotlin’s standout features is support for infix functions which becomes handy in the context of Boolean functions such as and, or, xor .

Infix functions remind me of the iconic Argentine Tango dance where 2 dancers tango to perform intricate and synched dance moves without stepping on each other’s toes.

Similarly, infix notation allows us to combine two code entities in a fluid manner without the need for dots or parentheses.

//Infix function demo
infix fun Int.add(other: Int): Int {
    return this + other
}

fun main() {
    val result = 5 add 3  // applying infix function
    println(result)      // prints: 8
}

We can leverage the power of infix functions in logic operations.

Tiny function 1 - and

Typically, we go for the double ampersand shorthand when both conditions need to be true.

fun main() {
   
    val isSunny = true
    val isWarm = true
    val isSunnyAndWarm = isSunny && isWarm // using ampersand
}

With a little help from infix notation, you can express the same using and .

fun main() {
    
    val isSunny = true
    val isWarm = true
    
    //using the and operator
    val isSunnyAndWarm = isSunny and isWarm // This will be true
}

Tiny function 2 - or

Tired of letting your finger traverse blindly on your keyboard looking for the below double pipe symbol?

fun main() {
    
    val isRaining = false
    val isSnowing = true
    val isRainyOrSnowy = isRaining || isSnowing // This will return true
}

Well, operator or guarantees zero strain as demonstrated on this snippet.

fun main() {

    val isRaining = false
    val isSnowing = true
    
    //using or operator
    val isRainyOrSnowy = isRaining or isSnowing // returns true
}

The or function returns true if at least one of the operands is true. It evaluates to false only if both operands are false.

Tiny Function 3 - xor

xor operator is an infix function that performs a logical XOR operation.

A logical XOR (exclusive OR) operation is a binary operation that takes two boolean operands - the result of the operation is true if exactly one of the operands is false.

If both operands are true or if both are false, then xor evaluates to false.

Imagine a situation where there are two security measures in place: a keycard scanner and a biometric fingerprint scanner. The restricted area can only be accessed if a person presents either a valid keycard or a verified fingerprint, but not both.

If someone tries to access the area with both a valid keycard and a verified fingerprint, they should be denied entry.

However, if they either present a card or a finger then access is granted.

If they don’t have the card or a fingerprint, then they are locked out.

Tiny Function 4 - not

Though not an infix function, the operator not is yet another out-of-box tiny function provided on the Boolean class for negating Boolean values.

Typically, you would perform the negation like this:

fun main() {

    val isSunny = true
    val isNotSunny = !isSunny // returns false

}

However, you can spice things up by using the .not operator.

fun main() {

    val isSunny = true

   // using not negation operator with if-else block
   if (isSunny.not()) {
        println("It's not sunny")
    } else {
        println("It's sunny")
    }

}

There you have it - embrace the power of Boolean logic in your Kotlin projects and elevate your coding experience to new heights!

Stackademic 🎓

Thank you for reading until the end. Before you go:

• Please consider clapping and following the writer! 👏
• Follow us X | LinkedIn | YouTube | Discord | Newsletter | Podcast
• Create a free AI-powered blog on Differ.
• More content at Stackademic.com

Power of Logic: Tiny Functions on Boolean Class was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.