AG is a mini-series on the quirks and idiosyncrasies of Android app development. Check out Part 1 here.

Toggling Visibility

I’ve always had to deal with layouts that are GONE by default and are made VISIBLE based on certain conditions.

In most cases this isn’t a simple View , but a complex ViewGroup . This could be something like a fancy progress indicator or details that show on click of a button.

The views participate in the layout inflation even if they are GONE by default. If you have many views like these in a complex layout, it might slow down rendering and increase memory usage.

Rescue time

Lazy load resources at runtime only when they are needed by:

1. Creating a ViewStub

A ViewStub is an invisible, zero-sized, no dimension View that doesn’t draw anything or participate in the layout.

2. Loading the ViewStub

When a ViewStub is made visible , or when inflate() is invoked, the layout resource is inflated. The ViewStub then replaces itself in its parent with the inflated layout. The ID of the inflated layout is the one specified by the android:inflatedId attribute of the ViewStub .

“It’s cheap to inflate and cheap to leave in a view hierarchy.”

Boom 💥

Click here for Part 3

If you liked this post, hit 👏 . Stay tuned for the next one!

Read other stuff I’ve written here. Share some quirks with me on Twitter!