Android Development
LayoutInflater
Non-Activity Context
UI Design
Android Programming

Call getLayoutInflater in places not in activity

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

getLayoutInflater() is an Activity convenience method, not a general Android API you can call from anywhere. Outside an activity, the real solution is to obtain a LayoutInflater from a Context, use the inflater already passed into a callback, or rely on fragment-specific lifecycle methods that expose one for you.

Use LayoutInflater.from(context)

If you are in a class that has access to a valid Context, use LayoutInflater.from(context):

kotlin
val inflater = LayoutInflater.from(context)
val view = inflater.inflate(R.layout.list_item_user, parent, false)

This is the standard replacement for getLayoutInflater() outside an activity.

Common places where this works:

  • custom views
  • adapters
  • helper classes that receive an activity or themed context
  • dialog builders

The important part is the quality of the Context. A theme-aware UI context is usually better than the application context when inflating visual layouts.

In Fragments, Use the Inflater You Already Get

Fragments do not need getLayoutInflater() from an activity most of the time, because onCreateView() already receives a LayoutInflater:

kotlin
1class UserFragment : Fragment() {
2    override fun onCreateView(
3        inflater: LayoutInflater,
4        container: ViewGroup?,
5        savedInstanceState: Bundle?
6    ): View {
7        return inflater.inflate(R.layout.fragment_user, container, false)
8    }
9}

That is the cleanest option because it uses the inflater provided for the fragment lifecycle. If you later need an inflater elsewhere inside the fragment, LayoutInflater.from(requireContext()) is also valid.

In Adapters, Inflate from the Parent Context

RecyclerView and ListView adapters are another common place where developers try to call getLayoutInflater(). Use the parent view group instead:

kotlin
1class UserAdapter : RecyclerView.Adapter<UserAdapter.UserViewHolder>() {
2
3    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): UserViewHolder {
4        val view = LayoutInflater.from(parent.context)
5            .inflate(R.layout.list_item_user, parent, false)
6        return UserViewHolder(view)
7    }
8
9    override fun getItemCount(): Int = 0
10
11    override fun onBindViewHolder(holder: UserViewHolder, position: Int) {}
12
13    class UserViewHolder(itemView: View) : RecyclerView.ViewHolder(itemView)
14}

Using parent.context is usually better than holding a separate inflater field because it preserves the correct themed context for that part of the hierarchy.

Dialogs and Other Non-Activity Classes

When you need to inflate a custom dialog view, the same principle applies:

kotlin
1val dialogView = LayoutInflater.from(requireContext())
2    .inflate(R.layout.dialog_confirm_delete, null, false)
3
4AlertDialog.Builder(requireContext())
5    .setView(dialogView)
6    .setPositiveButton("Delete", null)
7    .setNegativeButton("Cancel", null)
8    .show()

You do not need direct access to Activity.getLayoutInflater() to build the UI. You only need the right context and the correct parent or attachment behavior.

In helper classes, it is usually cleaner to pass the needed Context from the caller and create the inflater at the point of use. That avoids storing stale inflater references and keeps layout creation aligned with the current themed environment.

Common Pitfalls

The biggest mistake is using the application context for inflating themed UI. The view may inflate, but it can miss activity-level theme attributes, leading to incorrect colors, text appearances, or material components behavior.

Another common issue is inflating with the wrong parent arguments. Passing null everywhere works in some cases, but layout parameters from the intended parent can be lost. In adapters, inflate(layout, parent, false) is usually the correct form.

Developers also often ask for getLayoutInflater() in services. Most service code should not inflate interactive UI at all. If you truly need a view, make sure the surrounding component and windowing model support it.

Finally, do not treat getLayoutInflater() as special magic. It is mainly a convenience wrapper around the same inflater mechanism available through LayoutInflater.from(context).

Summary

  • 'getLayoutInflater() is an activity convenience, not the only way to inflate layouts.'
  • Outside activities, use LayoutInflater.from(context).
  • In fragments, use the inflater passed to onCreateView() when possible.
  • In adapters, prefer LayoutInflater.from(parent.context).
  • Use a theme-aware context and the correct parent arguments to avoid broken UI styling or layout params.

Course illustration
Course illustration

All Rights Reserved.