Introduction

View.GONE removes a view from layout, but it does not animate anything by itself. If you call setVisibility(View.GONE) immediately, the view disappears before the user sees a transition, so the usual pattern is to animate properties such as alpha or translationY first and set GONE only when the animation ends.

Why GONE Feels Abrupt

Android layout visibility has three common states:

• 'VISIBLE: draw the view and keep its layout space'
• 'INVISIBLE: hide the view but keep its layout space'
• 'GONE: hide the view and remove its layout space'

That last behavior is why GONE is useful for collapsing panels, banners, and optional form sections. It is also why a direct visibility change can feel harsh. The layout updates immediately and neighboring views reflow with no visual bridge.

The fix is not to animate GONE itself. The fix is to animate the properties that the user can see, then switch visibility at the end.

A Practical Pattern with ViewPropertyAnimator

For simple show and hide transitions, ViewPropertyAnimator is usually enough. It is lightweight, readable, and built for common UI property changes.

1import android.os.Bundle
2import android.view.View
3import androidx.appcompat.app.AppCompatActivity
4
5class MainActivity : AppCompatActivity() {
6    override fun onCreate(savedInstanceState: Bundle?) {
7        super.onCreate(savedInstanceState)
8        setContentView(R.layout.activity_main)
9
10        val panel = findViewById<View>(R.id.detailsPanel)
11        val toggle = findViewById<View>(R.id.toggleButton)
12
13        toggle.setOnClickListener {
14            if (panel.visibility == View.VISIBLE) {
15                panel.animate()
16                    .alpha(0f)
17                    .translationY(-20f)
18                    .setDuration(200)
19                    .withEndAction {
20                        panel.visibility = View.GONE
21                        panel.alpha = 1f
22                        panel.translationY = 0f
23                    }
24            } else {
25                panel.alpha = 0f
26                panel.translationY = -20f
27                panel.visibility = View.VISIBLE
28                panel.animate()
29                    .alpha(1f)
30                    .translationY(0f)
31                    .setDuration(200)
32            }
33        }
34    }
35}

This pattern handles both directions correctly:

• when hiding, animate first and apply GONE in withEndAction
• when showing, set initial visual state, switch to VISIBLE, then animate into place

That is the core rule. If you set GONE before the animation, there is nothing left to animate.

When Parent Layout Animation Helps

If the main goal is to animate the layout reflow when children appear or disappear, it may be better to animate the container instead of each child manually. A LayoutTransition on a ViewGroup can animate changes when children are added, removed, or have visibility changes.

Manual animation is usually better when you want precise control over one panel. Container layout animation is better when multiple child views shift around and you want the movement of neighboring views to feel smoother.

Choosing the Right Effect

For a simple hide action, the safest choices are:

• 'alpha for fade-out'
• 'translationY or translationX for a small slide'
• a combination of both for a more polished effect

Avoid large motion for basic toggles. These interactions happen often, so the animation should communicate state change without making the interface feel heavy.

A short duration such as 150 to 250 milliseconds is usually enough. Longer durations may look decorative but can make the app feel slow.

XML Animation Versus Property Animation

Older Android code often uses view animations loaded from res/anim. Those can still work for basic effects, but property animation is generally easier for visibility toggles because it lets you update alpha, translation, and end actions in one place.

The distinction matters because older view animation APIs can change how something looks without actually updating the underlying property values. For visibility transitions tied to layout state, ViewPropertyAnimator is usually the cleaner choice.

Common Pitfalls

The most common mistake is setting View.GONE before the hide animation starts. That removes the view from layout immediately, so the user never sees the effect.

Another mistake is forgetting to reset alpha or translation after hiding. Then the next time the view becomes visible, it may stay transparent or offset.

A third issue is trying to use the same logic for INVISIBLE and GONE without considering layout. GONE changes layout flow; INVISIBLE does not. Choose the one that matches the behavior you want.

Summary

• 'View.GONE does not animate on its own.'
• Animate visible properties first, then set GONE in the animation end callback.
• Use ViewPropertyAnimator for simple fade and slide transitions.
• Reset alpha and translation when bringing the view back.
• Use parent layout animation only when the main concern is child reflow, not just one view fading out.