Android Platform Components
The Jetpack building blocks an Android app is assembled from — Navigation with its back stack and deep links, Room over raw SQLite, Parcelable versus Serializable, and View Binding after the removal of Kotlin synthetics.
6 questions
MiddleTheoryVery commonWhat does View Binding replace, and why must a Fragment null its binding in onDestroyView?
What does View Binding replace, and why must a Fragment null its binding in onDestroyView?
It generates a typed binding class per layout, replacing findViewById and the removed synthetics. A back-stacked Fragment loses its view but survives, so a binding kept past onDestroyView pins the dead view tree — a leak. Null it there.
Common mistakes
- ✗Assuming a Fragment and its view are destroyed together, so the binding cannot leak
- ✗Treating the null-out as a lint convention rather than the fix for a real retained view tree
- ✗Thinking View Binding is a runtime cache instead of a generated typed class
Follow-up questions
- →Why does a Fragment on the back stack outlive its own view in the first place?
- →How does
viewLifecycleOwnerdiffer from the Fragment's own lifecycle owner?
MiddleTheoryCommonYour Room entity holds a nested object. Can you just store its Parcel bytes as a BLOB?
Your Room entity holds a nested object. Can you just store its Parcel bytes as a BLOB?
No. A Parcel is a live IPC buffer, not storage: its layout is an implementation detail and can change between releases, so persisted bytes may not read back. Room's tools are @Embedded, flattening the object into columns, and a TypeConverter.
Common mistakes
- ✗Treating
Parcelas a durable serialization format instead of a transient IPC buffer - ✗Reaching for
@Parcelizeon an entity instead of@Embeddedor aTypeConverter - ✗Believing Room cannot store a nested object without hand-written column mapping
Follow-up questions
- →When would you pick a
TypeConverterover@Embeddedfor the same nested type? - →What breaks on the next app update if the persisted encoding changes shape?
JuniorTheoryOccasionalWhy does Android pass objects as Parcelable rather than Java's Serializable?
Why does Android pass objects as Parcelable rather than Java's Serializable?
Serializable is a marker interface — the JVM walks the graph by reflection and allocates heavily, so it is slow. Parcelable writes the fields into a Parcel explicitly, with no reflection — much faster. @Parcelize generates that boilerplate.
Common mistakes
- ✗Thinking
Parcelableis also reflection-based and merely a different wire format - ✗Believing the speed difference comes from compression rather than from skipping reflection
- ✗Assuming the two are interchangeable and that either performs the same on Android
Follow-up questions
- →Which property types can
@Parcelizewrite into aParcelwithout extra help? - →Why should a
Parcelnever be written to disk or sent over a network?
JuniorTheoryOccasionalWhat does Room give you that the raw SQLiteOpenHelper API does not?
What does Room give you that the raw SQLiteOpenHelper API does not?
Room is a compile-time layer over the same SQLite. It verifies every @Query against the schema at build time, maps rows onto your entity classes so there are no Cursor loops, and generates the DAO. It also refuses to query the main thread.
Common mistakes
- ✗Thinking Room replaces SQLite instead of generating code over it
- ✗Believing
@Queryis validated at runtime rather than at compile time - ✗Assuming Room lets you keep querying from the main thread
Follow-up questions
- →How do you make a DAO method return results asynchronously?
- →What happens to the database when an entity gains a new column?
