Introduction

Getting a Context inside a RecyclerView.Adapter is a common Android task because adapters often need access to resources, layout inflation, or click handling that starts another screen. The key is not only how to get a context, but also how to do it without creating memory leaks or overly coupling the adapter to an activity.

The Simplest Option: Pass Context In

The most direct pattern is to pass a Context into the adapter constructor.

1class UserAdapter(
2    private val context: Context,
3    private val users: List<String>
4) : RecyclerView.Adapter<UserAdapter.UserViewHolder>() {
5
6    class UserViewHolder(view: View) : RecyclerView.ViewHolder(view) {
7        val title: TextView = view.findViewById(R.id.title)
8    }
9
10    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): UserViewHolder {
11        val view = LayoutInflater.from(context).inflate(R.layout.row_user, parent, false)
12        return UserViewHolder(view)
13    }
14
15    override fun onBindViewHolder(holder: UserViewHolder, position: Int) {
16        holder.title.text = users[position]
17    }
18
19    override fun getItemCount(): Int = users.size
20}

This works well when the adapter genuinely needs a context for inflation or resource lookup.

Often You Already Have a Better Context

Inside adapter methods, you can frequently use the parent or item view instead of storing a separate field.

1override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): UserViewHolder {
2    val inflater = LayoutInflater.from(parent.context)
3    val view = inflater.inflate(R.layout.row_user, parent, false)
4    return UserViewHolder(view)
5}

This is often preferable because parent.context is available exactly where you need it. It also reduces the chance of holding an unnecessary reference.

Likewise, from a view holder or click listener:

1holder.itemView.setOnClickListener {
2    val itemContext = holder.itemView.context
3    val intent = Intent(itemContext, DetailActivity::class.java)
4    itemContext.startActivity(intent)
5}

For many use cases, itemView.context is enough.

Pick the Right Kind of Context

Android has multiple context flavors:

• Activity context
• Application context
• Context obtained from a view

If you are inflating themed layouts or launching an activity, an activity-related context is usually the right choice. If you only need something application-wide, such as a simple system service, the application context may be safer.

For example:

val appContext = context.applicationContext
Toast.makeText(appContext, "Saved", Toast.LENGTH_SHORT).show()

Be careful, though. Starting UI flows and applying theme-dependent resources with the wrong context can behave incorrectly.

Avoid Making the Adapter Too Powerful

Adapters are easier to maintain when they focus on binding data rather than owning navigation logic. Instead of letting the adapter directly start activities everywhere, consider passing a click callback from the fragment or activity.

1class UserAdapter(
2    private val users: List<String>,
3    private val onUserClick: (String) -> Unit
4) : RecyclerView.Adapter<UserAdapter.UserViewHolder>() {
5
6    class UserViewHolder(view: View) : RecyclerView.ViewHolder(view) {
7        val title: TextView = view.findViewById(R.id.title)
8    }
9
10    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): UserViewHolder {
11        val view = LayoutInflater.from(parent.context).inflate(R.layout.row_user, parent, false)
12        return UserViewHolder(view)
13    }
14
15    override fun onBindViewHolder(holder: UserViewHolder, position: Int) {
16        val user = users[position]
17        holder.title.text = user
18        holder.itemView.setOnClickListener { onUserClick(user) }
19    }
20
21    override fun getItemCount(): Int = users.size
22}

Then the fragment handles the navigation:

1val adapter = UserAdapter(users) { user ->
2    val intent = Intent(requireContext(), DetailActivity::class.java)
3    intent.putExtra("user_name", user)
4    startActivity(intent)
5}

This pattern keeps the adapter simpler and avoids overusing Context.

Common Pitfalls

One common mistake is storing an activity context in a long-lived adapter or singleton. If the activity is destroyed, that reference can leak memory.

Another mistake is passing applicationContext everywhere. It works for some operations, but not all UI actions. Layout theming and activity launches can require an activity context.

A third mistake is forgetting that parent.context and itemView.context already exist. Many adapters do not need a dedicated context field at all.

Summary

• You can get a context in a RecyclerView.Adapter by constructor injection, parent.context, or itemView.context.
• 'parent.context is usually the cleanest option for inflating views.'
• Use an activity-related context for UI work and application context only when appropriate.
• Prefer click callbacks to keep navigation logic outside the adapter when possible.
• Be careful not to leak an activity by storing a context longer than necessary.