How to Implement TextSwitcher in Android (Deep, Practical Guide)

I still see Android screens where text updates snap from one value to another with no sense of flow. The human eye notices that abrupt jump even if your logic is perfectly correct. When you’re stepping through onboarding tips, cycling through quotes, or showing a live counter, a small animation makes the UI feel intentional rather than mechanical. TextSwitcher gives you that animation for free as long as you wire it correctly, and it’s been available since Android 1.6, so you don’t have to worry about compatibility.

In this guide, I’ll show you exactly how I implement TextSwitcher in a modern Android app. You’ll build a simple screen with a Next and Prev button, then add smooth in/out transitions. I’ll also show you how to integrate this into real screens like OTP flows and scoreboards, cover common mistakes I see in reviews, and discuss when TextSwitcher is the right choice and when it isn’t. Along the way, I’ll share practical Kotlin and Java implementations, along with the minimal XML layout and animation resources you need. You’ll leave with a ready-to-run setup and a clear mental model for why TextSwitcher behaves the way it does.

Why TextSwitcher Exists and When I Reach for It

TextSwitcher sits inside the same family as ViewSwitcher. The difference is simple: ViewSwitcher can swap any View, while TextSwitcher is specialized for TextView children. That specialization matters because TextSwitcher wraps a TextView factory and handles the animation between old and new text every time you call setText(CharSequence).

I reach for TextSwitcher when the text changes at a human-perceivable cadence: a quote carousel, a tip of the day, a “current step” marker, or a live counter that updates every few seconds. When text is changing rapidly (like 10+ times per second), you should avoid any animation; you’ll create visual noise and extra work for the UI thread.

A simple analogy I use: Think of TextSwitcher as a cue card display. You slide one card out and slide the next card in. The animation is the slide, while the cards are TextView instances created by a factory. If you skip the factory, you skip the cards—nothing will show.

When not to use it:

If you need multiple lines with rich formatting or inline images, I’d rather use a standard TextView with TextViewCompat.setAutoSizeTextTypeUniformWithConfiguration and animate the parent container.
If you need to transition between full layouts, use ViewFlipper, ViewSwitcher, or MotionLayout.
If the content is updated continuously (timer tick every 100ms), skip the animation altogether; it will feel jittery.

Project Setup and Layout: Minimal but Realistic

I like to keep the layout small and focused. The TextSwitcher sits near the center, and two buttons change the text. This is enough to prove the mechanism and can be copied into a larger screen later.

Here’s a clean activity_main.xml using ConstraintLayout. The background and button colors are placeholders—you can replace them with your own theme tokens.


<androidx.constraintlayout.widget.ConstraintLayout
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
android:layoutwidth="matchparent"
android:layoutheight="matchparent"
android:background="@android:color/white">
<TextSwitcher
android:id="@+id/textSwitcher"
android:layout_width="0dp"
android:layoutheight="wrapcontent"
android:layout_marginStart="24dp"
android:layout_marginEnd="24dp"
app:layoutconstraintToptoTopOf="parent"
app:layoutconstraintBottomtoTopOf="@+id/controls"
app:layoutconstraintStarttoStartOf="parent"
app:layoutconstraintEndtoEndOf="parent"
app:layoutconstraintVerticalbias="0.4" />
<LinearLayout
android:id="@+id/controls"
android:layoutwidth="wrapcontent"
android:layoutheight="wrapcontent"
android:orientation="horizontal"
app:layoutconstraintToptoBottomOf="@+id/textSwitcher"
app:layoutconstraintStarttoStartOf="parent"
app:layoutconstraintEndtoEndOf="parent">
<Button
android:id="@+id/prev"
android:layoutwidth="wrapcontent"
android:layoutheight="wrapcontent"
android:text="Prev" />
<Button
android:id="@+id/next"
android:layoutwidth="wrapcontent"
android:layoutheight="wrapcontent"
android:layout_marginStart="16dp"
android:text="Next" />

Why the width is 0dp on TextSwitcher: it allows ConstraintLayout to measure the view across the available width. TextSwitcher will match the available width and center the text inside its TextView child.

Animations: The Smallest Set That Feels Right

TextSwitcher only animates when you set its in/out animations. You can use stock animations from Android, but I prefer small custom ones so I can control direction and duration.

Create two files in res/anim/:

slideinbottom.xml


<translate xmlns:android="http://schemas.android.com/apk/res/android"
android:fromYDelta="30%"
android:toYDelta="0%"
android:duration="220" />

slideouttop.xml


<translate xmlns:android="http://schemas.android.com/apk/res/android"
android:fromYDelta="0%"
android:toYDelta="-30%"
android:duration="220" />

I keep the duration in the 180–260ms range. Shorter feels abrupt, longer feels sluggish. On mid-tier devices, this typically lands in the 10–15ms per frame range, which is a safe window for smoothness.

If you want a subtle fade, add an alpha tag inside each animation file. I keep it simple unless the design calls for it.

Kotlin Implementation: A Clean, Runnable Example

Here’s the full Kotlin Activity. It’s small, but it includes the pieces that matter: the factory, animations, index control, and safe bounds handling.

package com.example.textswitcher
import android.graphics.Color
import android.os.Bundle
import android.view.Gravity
import android.view.animation.AnimationUtils
import android.widget.Button
import android.widget.TextSwitcher
import android.widget.TextView
import androidx.appcompat.app.AppCompatActivity
class MainActivity : AppCompatActivity() {
private val items = arrayOf("1", "2", "3", "4", "5")
private var index = 0
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
val textSwitcher = findViewById(R.id.textSwitcher)
val prevBtn = findViewById

Key detail: setFactory must be called before setText. If you call setText without a factory, TextSwitcher has no child TextViews to swap and you’ll get an empty view.

Java Implementation: Same Behavior, Different Syntax

If you’re in a Java-heavy codebase, this is the equivalent Activity. I keep it parallel to the Kotlin version so you can compare line by line.

package com.example.textswitcher;
import android.graphics.Color;
import android.os.Bundle;
import android.view.Gravity;
import android.view.animation.AnimationUtils;
import android.widget.Button;
import android.widget.TextSwitcher;
import android.widget.TextView;
import androidx.appcompat.app.AppCompatActivity;
public class MainActivity extends AppCompatActivity {
private final String[] items = {"1", "2", "3", "4", "5"};
private int index = 0;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
TextSwitcher textSwitcher = findViewById(R.id.textSwitcher);
Button prevBtn = findViewById(R.id.prev);
Button nextBtn = findViewById(R.id.next);
textSwitcher.setFactory(() -> {
TextView tv = new TextView(this);
tv.setGravity(Gravity.CENTER);
tv.setTextSize(32f);
tv.setTextColor(Color.BLACK);
return tv;
});
textSwitcher.setInAnimation(AnimationUtils.loadAnimation(this, R.anim.slideinbottom));
textSwitcher.setOutAnimation(AnimationUtils.loadAnimation(this, R.anim.slideouttop));
textSwitcher.setText(items[index]);
prevBtn.setOnClickListener(v -> {
index = (index == 0) ? items.length - 1 : index - 1;
textSwitcher.setText(items[index]);
});
nextBtn.setOnClickListener(v -> {
index = (index == items.length - 1) ? 0 : index + 1;
textSwitcher.setText(items[index]);
});
}
}

Getting the TextSwitcher Factory Right

The factory is what actually creates the TextView instances that TextSwitcher swaps. Here’s how I think about it:

The factory is run twice the first time. That gives TextSwitcher two TextViews to swap between.
You should configure each TextView inside the factory so both instances look identical.
Avoid referencing view binding or layout inflation unless you need a custom TextView layout.

If you want a custom TextView layout (for example, a stylized text with a background chip), you can inflate it inside the factory:

textSwitcher.setFactory {
layoutInflater.inflate(R.layout.switchertextitem, null) as TextView
}

This is useful if you want a complex shape or apply a text appearance style. Just keep the layout minimal so it doesn’t measure too slowly.

Traditional vs Modern Approaches in 2026

I still see people using a plain TextView and manual animations. That works, but it’s easy to miss edge cases. Here’s how I compare the older approach with a modern TextSwitcher-based approach.

Approach

Traditional TextView + Animation

Modern TextSwitcher Setup —

—

— Setup

Manual create/remove or visibility toggles

Factory + setText triggers animation Code size

Medium to high

Compact Reliability

Easy to forget states

Built-in state swap Motion control

Custom but verbose

Simple and predictable Best for

Single transition, one-off

Repeated text changes

In 2026, I also use AI-assisted tooling to speed this up. For example, I let an LLM generate the first draft of the XML and animations, then I correct naming and constraints to fit our design system. I also run a quick UI test with screenshot tests if the product is visual-heavy. AI can’t validate motion quality, though, so I always preview it on a real device.

Common Mistakes I See in Code Reviews

These are the top problems I encounter, along with fixes:

1) Factory not set

If you never call setFactory, TextSwitcher won’t show text. Always set it before setText.

2) No animations

Without setInAnimation and setOutAnimation, the text changes with no visual transition. It still works, but it defeats the point.

3) Factory returns a view with match_parent height

This can cause odd layout jumps if the TextView expands beyond expected height. Keep it wrap_content or control it via layout params.

4) Changing text too frequently

If you set text in a tight loop or on every scroll, you’ll stutter. Rate-limit updates or disable animation for rapid updates.

5) Misaligned gravity

If your text appears off-center, check the TextView’s gravity instead of the TextSwitcher’s. The child TextView controls the text alignment.

Real-World Use Cases and Edge Cases

Here’s where TextSwitcher shines in my experience:

Step-based onboarding: Each step label animates in with a pleasant motion.
Score updates: When the score changes every few seconds, TextSwitcher gives a smooth update without a full UI refresh.
Live data summaries: For example, “Current route: 15 min” updates as the user moves.

Edge cases to consider:

Accessibility: Use content that still reads clearly without the animation. TalkBack will read the new text, but rapid updates can overwhelm users. If you update more than once every 2–3 seconds, consider disabling animation for accessibility.
State restoration: Save the index in onSaveInstanceState if the screen can rotate. Otherwise, it will reset to the first item.
Localization: Text length can change dramatically. Make sure the TextSwitcher has enough width and doesn’t clip on smaller devices.

A quick state-restore snippet in Kotlin:

override fun onSaveInstanceState(outState: Bundle) {
super.onSaveInstanceState(outState)
outState.putInt("index", index)
}
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
index = savedInstanceState?.getInt("index") ?: 0
// Continue with setup...
}

Performance Notes and UI Thread Behavior

TextSwitcher does its work on the UI thread. The actual cost is small, but if you trigger changes while your UI is already busy—like a list diff or heavy image decoding—you can see dropped frames. In normal apps, a single TextSwitcher update lands in a 10–15ms range for animation and draw. That’s fine as long as you’re not stacking it with heavy work in the same frame.

I recommend:

Don’t update more than every 300–500ms unless you disable animation.
Avoid setting a huge text size if you’re also doing multi-line layout; it can cause remeasure overhead.
Precompute the strings rather than building them on every click.

A More Useful Example: Cycling Status Messages

If you want something slightly more real than numbers, here’s a version that cycles through statuses. It also uses a List instead of a fixed array to make it easier to maintain.

private val statuses = listOf(
"Preparing order",
"Packing items",
"Waiting for courier",
"Out for delivery",
"Delivered"
)
private var index = 0
private fun showNext(textSwitcher: TextSwitcher) {
index = if (index == statuses.lastIndex) 0 else index + 1
textSwitcher.setText(statuses[index])
}
private fun showPrev(textSwitcher: TextSwitcher) {
index = if (index == 0) statuses.lastIndex else index - 1
textSwitcher.setText(statuses[index])
}

To make this production-ready, I often pair it with a handler that rotates messages every few seconds, and a stop/start tied to the lifecycle so it doesn’t animate when the screen is paused.

Understanding TextSwitcher Internals (So You Don’t Fight It)

TextSwitcher extends ViewSwitcher, which itself is a subclass of ViewAnimator. This matters because it tells you how switching works:

TextSwitcher holds exactly two child TextViews at any time.
setText updates the “next” child and then flips to it with the in/out animations you provide.
The outgoing view plays outAnimation. The incoming view plays inAnimation.
If you call setText repeatedly faster than the animation duration, the animations can overlap and look jittery.

This explains a lot of weird behavior. For example, if you want a distinct reverse animation when the user taps Prev, you can swap the in/out animations on the fly right before setText. That’s a powerful trick.

Here’s a short Kotlin example that flips direction depending on whether the user goes forward or backward:

private fun animateForward(textSwitcher: TextSwitcher) {
textSwitcher.inAnimation = AnimationUtils.loadAnimation(this, R.anim.slideinright)
textSwitcher.outAnimation = AnimationUtils.loadAnimation(this, R.anim.slideoutleft)
}
private fun animateBackward(textSwitcher: TextSwitcher) {
textSwitcher.inAnimation = AnimationUtils.loadAnimation(this, R.anim.slideinleft)
textSwitcher.outAnimation = AnimationUtils.loadAnimation(this, R.anim.slideoutright)
}

Then, in your button handlers:

prevBtn.setOnClickListener {
animateBackward(textSwitcher)
index = if (index == 0) items.lastIndex else index - 1
textSwitcher.setText(items[index])
}
nextBtn.setOnClickListener {
animateForward(textSwitcher)
index = if (index == items.lastIndex) 0 else index + 1
textSwitcher.setText(items[index])
}

This is the kind of nuance that makes TextSwitcher feel native and responsive.

Designing Animations That Match Your UI

I like to treat TextSwitcher animations as “motion typography.” It’s not just movement; it’s an extension of how the text feels. A few guidelines I follow:

If the text is instructional or calm (tips, quotes), use slow, gentle vertical movement.
If the text is transactional (scores, counters), use shorter, quicker movement.
If the text represents hierarchy (step numbers), use subtle scale with a small fade.

Here’s an example of a scale + fade in that feels modern but still subtle:

scalefadein.xml



<scale
android:fromXScale="0.96"
android:toXScale="1.0"
android:fromYScale="0.96"
android:toYScale="1.0"
android:pivotX="50%"
android:pivotY="50%"
android:duration="220" />
<alpha
android:fromAlpha="0.0"
android:toAlpha="1.0"
android:duration="220" />

scalefadeout.xml



<scale
android:fromXScale="1.0"
android:toXScale="0.98"
android:fromYScale="1.0"
android:toYScale="0.98"
android:pivotX="50%"
android:pivotY="50%"
android:duration="180" />
<alpha
android:fromAlpha="1.0"
android:toAlpha="0.0"
android:duration="180" />

This works well for compact text like numbers or short labels, but I avoid it for long paragraphs because scaling large text can be distracting.

TextSwitcher With View Binding and Fragments

Most apps now use ViewBinding or view lifecycle management in Fragments. Here’s the same idea implemented in a Fragment with ViewBinding, which is common in production projects.

class StatusFragment : Fragment(R.layout.fragment_status) {
private var _binding: FragmentStatusBinding? = null
private val binding get() = _binding!!
private val statuses = listOf("Preparing order", "Packing items", "Waiting for courier")
private var index = 0
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
_binding = FragmentStatusBinding.bind(view)
binding.textSwitcher.setFactory {
TextView(requireContext()).apply {
gravity = Gravity.CENTER
textSize = 20f
setTextColor(Color.BLACK)
}
}
binding.textSwitcher.inAnimation = AnimationUtils.loadAnimation(requireContext(), R.anim.slideinbottom)
binding.textSwitcher.outAnimation = AnimationUtils.loadAnimation(requireContext(), R.anim.slideouttop)
binding.textSwitcher.setText(statuses[index])
binding.next.setOnClickListener {
index = if (index == statuses.lastIndex) 0 else index + 1
binding.textSwitcher.setText(statuses[index])
}
}
override fun onDestroyView() {
_binding = null
super.onDestroyView()
}
}

The main thing to remember is that the factory uses requireContext and is tied to the view lifecycle. This avoids memory leaks and ensures you don’t hold references to a destroyed view.

TextSwitcher in RecyclerView Items (Yes, But Carefully)

Developers sometimes want TextSwitcher inside a list item (e.g., rotating price/discount text). It can work, but there are caveats:

RecyclerView reuses views. You need to reset the TextSwitcher factory and animations in your ViewHolder binding.
Avoid starting animations in onBindViewHolder unless the text actually changes; otherwise you’ll animate on scroll and it looks jittery.

Here’s a safe pattern:

class PriceViewHolder(itemView: View) : RecyclerView.ViewHolder(itemView) {
private val switcher: TextSwitcher = itemView.findViewById(R.id.priceSwitcher)
init {
switcher.setFactory {
TextView(itemView.context).apply {
gravity = Gravity.CENTER
textSize = 16f
setTextColor(Color.BLACK)
}
}
switcher.inAnimation = AnimationUtils.loadAnimation(itemView.context, R.anim.fade_in)
switcher.outAnimation = AnimationUtils.loadAnimation(itemView.context, R.anim.fade_out)
}
fun bind(model: PriceModel) {
// Only animate when the displayed value actually changes
if (switcher.currentView is TextView) {
val current = (switcher.currentView as TextView).text.toString()
if (current != model.displayPrice) {
switcher.setText(model.displayPrice)
} else {
// Keep state without animation
(switcher.currentView as TextView).text = model.displayPrice
}
} else {
switcher.setText(model.displayPrice)
}
}
}

This pattern prevents animations from firing purely because a view is being recycled.

Accessibility and UX: Doing It Right

Animations are great, but they can also be problematic if they’re overused or too fast. Here’s what I do to keep TextSwitcher accessible:

Respect system animation settings: If the user has reduced motion enabled, skip the animation by setting duration to 0 or using null animations.
Keep updates at a human pace: One update every 1–2 seconds is fine; faster is not.
Don’t rely on motion to convey meaning: The new text must still be understandable without the animation.

You can optionally query the animator duration scale to adapt:

private fun animationsEnabled(): Boolean {
return try {
android.provider.Settings.Global.getFloat(
contentResolver,
android.provider.Settings.Global.ANIMATORDURATIONSCALE
) > 0f
} catch (e: Exception) {
true
}
}

If animations are disabled, I simply skip setting in/out animations. The text will still switch, and the UI will feel consistent with the user’s preference.

State Restoration and Configuration Changes (Deeper Version)

I already showed the basic state save for the index, but in real apps I usually wrap it with a key and add a fallback if the data set changes.

For example, if the list of items is dynamic and can change (say, from a network request), you want to validate the restored index.

override fun onSaveInstanceState(outState: Bundle) {
super.onSaveInstanceState(outState)
outState.putInt("textswitcherindex", index)
}
private fun restoreIndex(savedInstanceState: Bundle?) {
val saved = savedInstanceState?.getInt("textswitcherindex") ?: 0
index = saved.coerceIn(0, items.lastIndex)
}

This avoids crashes if the saved index is out of bounds after a data update.

Live Updates: Integrating With Timers and Flows

A common real-world scenario is a text value that changes on a timer or from a Flow/LiveData. Here’s how I do it with Kotlin Flow:

lifecycleScope.launch {
repeatOnLifecycle(Lifecycle.State.STARTED) {
viewModel.statusFlow.collect { status ->
textSwitcher.setText(status)
}
}
}

If this Flow updates rapidly, I’ll add a debounce or distinctUntilChanged to avoid unnecessary animations:

viewModel.statusFlow
.distinctUntilChanged()
.debounce(400)
.collect { status ->
textSwitcher.setText(status)
}

This makes the animation feel intentional rather than frantic.

When TextSwitcher Is the Wrong Tool

I always tell teams that TextSwitcher is not a universal solution. Here are situations where I prefer other tools:

Multi-line paragraphs with spans or clickable links: I use a normal TextView and animate the container.
Crossfading entire layouts: I use MotionLayout or TransitionManager.
High-frequency counters (like stopwatch milliseconds): I avoid animation altogether and just update the text.
Complex text transformations (like rich spans changing color): I use a custom View or Compose and animate within that system.

TextSwitcher is best when a short, single-line or short multi-line text changes occasionally and you want the transition to look deliberate.

TextSwitcher in Jetpack Compose Projects

Even if your app is largely Compose-based, you might still interact with XML or legacy screens. But if you’re fully in Compose, you probably won’t use TextSwitcher at all. Instead, you can use AnimatedContent or Crossfade in Compose.

I mention this because it’s important to know when to shift tools. If you’re in a hybrid app, TextSwitcher is still valid for the XML part. If you’re fully Compose, keep it native to Compose so you don’t fight lifecycle or view interop.

Practical Use Case 1: OTP Helper Text

OTP screens often update a helper line like “We sent a code to…” then “Didn’t receive? Resend in 00:30.” TextSwitcher can animate that helper line cleanly.

Key points I follow:

Keep text size small and consistent so the view height doesn’t jump.
Keep updates slow (once per second at most).
Use fade animations rather than slide for a calm, non-distracting feel.

Example helper snippet:

private fun setupOtpHelper(textSwitcher: TextSwitcher) {
textSwitcher.setFactory {
TextView(this).apply {
textSize = 14f
setTextColor(Color.DKGRAY)
gravity = Gravity.CENTER
}
}
textSwitcher.inAnimation = AnimationUtils.loadAnimation(this, R.anim.fade_in)
textSwitcher.outAnimation = AnimationUtils.loadAnimation(this, R.anim.fade_out)
}

Then update it when the timer ticks. If the countdown updates every second, I usually disable animation and only animate when the message changes (e.g., when it switches from “Resend in 00:30” to “Resend now”).

Practical Use Case 2: Scoreboard Updates

For a sports scoreboard or a game score, the text changes are meaningful. I often use a slide-up animation to reinforce the idea of “progress.”

When score increases, I use a quick upward slide.
When score decreases (rare but possible), I use a downward slide.

This directional mapping helps users interpret change subconsciously.

Practical Use Case 3: Onboarding Step Indicators

A minimal onboarding screen might show “Step 2 of 5” and update it as the user progresses. This is a perfect TextSwitcher use case because:

The text changes only when the user moves to the next step.
The motion reinforces progress.
The logic is simple and safe.

In these cases, I keep the TextSwitcher inside a small container and disable layout transitions on the parent to avoid double animations.

Troubleshooting Checklist (What I Do First)

When TextSwitcher “doesn’t work,” I run this quick checklist:

Is setFactory called before setText?
Are inAnimation and outAnimation set?
Is the TextSwitcher actually visible (no zero height, no gone)?
Is the TextView inside the factory properly styled (text color, size)?
Is text updated on the UI thread?

If all of those are correct, it usually works. The most common culprit is just forgetting to call setFactory.

Small Quality-of-Life Improvements

A few small enhancements make the code more reusable and safer:

1) Wrap TextSwitcher setup in an extension function

fun TextSwitcher.setupTextSwitcher(textSize: Float, textColor: Int, gravity: Int = Gravity.CENTER) {
setFactory {
TextView(context).apply {
this.textSize = textSize
setTextColor(textColor)
this.gravity = gravity
}
}
}

Then you can just call:

textSwitcher.setupTextSwitcher(24f, Color.BLACK)

2) Wrap animation setup in a helper

fun TextSwitcher.setSwitcherAnimations(context: Context, @AnimRes inAnim: Int, @AnimRes outAnim: Int) {
inAnimation = AnimationUtils.loadAnimation(context, inAnim)
outAnimation = AnimationUtils.loadAnimation(context, outAnim)
}

These helpers reduce repeated boilerplate and keep your Activity or Fragment clean.

Testing TextSwitcher Behavior

I don’t often unit test TextSwitcher because it’s mostly visual, but I do a few practical checks:

Manual device preview at 60Hz and 90/120Hz (the animation can feel faster on higher refresh rates).
Screenshot tests if the text is part of a critical flow and its size/position matters.
Accessibility checks with reduced motion turned on.

If you’re doing screenshot tests, I recommend capturing before and after states rather than trying to snapshot mid-animation.

Common Questions I Get From Teams

Here are some quick answers to questions I hear often:

Q: Can I use a custom TextView subclass in TextSwitcher?

A: Yes. Just return your custom view from setFactory. This is great for applying consistent typography or custom fonts.

Q: Why does TextSwitcher sometimes show the same text twice?

A: That’s usually because you’re calling setText with the same string repeatedly. Add a check to skip updates when the text hasn’t changed.

Q: Can I set different animations for different updates?

A: Absolutely. You can change the in/out animations right before calling setText.

Q: Does TextSwitcher support Spannable text?

A: Yes. setText takes CharSequence, so spans are supported. Just be mindful of layout and remeasure costs if the spans are heavy.

Summary: My Practical Rules for TextSwitcher

To wrap it up, here are the rules I follow every time I use TextSwitcher:

Always set the factory before setting text.
Keep animations subtle and under ~260ms.
Don’t animate rapid changes; rate-limit or disable animation.
Treat direction as meaning: forward vs backward can have different motion.
Keep TextSwitcher usage small and intentional; it’s great for micro-transitions.

If you implement it this way, TextSwitcher becomes one of those subtle UI touches that make your app feel polished without adding complexity.

Expansion Strategy

Add new sections or deepen existing ones with:

Deeper code examples: More complete, real-world implementations
Edge cases: What breaks and how to handle it
Practical scenarios: When to use vs when NOT to use
Performance considerations: Before/after comparisons (use ranges, not exact numbers)
Common pitfalls: Mistakes developers make and how to avoid them
Alternative approaches: Different ways to solve the same problem

If Relevant to Topic

Modern tooling and AI-assisted workflows (for infrastructure/framework topics)
Comparison tables for Traditional vs Modern approaches
Production considerations: deployment, monitoring, scaling