After Compose-First: Choosing Which View Screens to Migrate, Ranked by Churn Instead of Count

Pulling change frequency out of git

What you actually need to know is whether you will keep touching a screen. That is a fact about the future, but past change history is a surprisingly honest proxy. In my experience, a screen you have not touched in six months rarely becomes next month's active work.

So I wrote a script that ranks by churn (the number of commits touching a file in a window) multiplied by View dependency.

#!/usr/bin/env python3
"""Rank View-based screens for Compose migration using git history.
 
Usage:
    python3 screen_churn.py <repo> --since 12
Prints each screen's churn (commits in the window), its View dependency,
and the product of the two as a priority score.
"""
import argparse
import re
import subprocess
import sys
from collections import Counter
from datetime import date, timedelta
from pathlib import Path
 
# Traces of View-based code. These are the lines that disappear under Compose.
VIEW_MARKERS = (
    re.compile(r"\bfindViewById\b"),
    re.compile(r"\bsetContentView\s*\("),
    re.compile(r"\bViewBinding\b|\bDataBindingUtil\b"),
    re.compile(r":\s*(AppCompatActivity|Fragment|DialogFragment)\b"),
)
# Screens already on Compose, or already bridged via interop, are out of scope.
COMPOSE_MARKERS = (re.compile(r"\bsetContent\s*\{"), re.compile(r"@Composable"))
 
 
def git(repo, *args):
    out = subprocess.run(["git", "-C", str(repo), *args],
                         capture_output=True, text=True)
    if out.returncode != 0:
        sys.exit(f"git failed: {out.stderr.strip()}")
    return out.stdout
 
 
def view_score(path: Path) -> int:
    """View dependency. Marker occurrences are the weight, as-is."""
    try:
        text = path.read_text(encoding="utf-8", errors="ignore")
    except OSError:
        return 0
    if any(m.search(text) for m in COMPOSE_MARKERS):
        return 0  # already migrated; don't count it again
    return sum(len(m.findall(text)) for m in VIEW_MARKERS)
 
 
def main():
    ap = argparse.ArgumentParser()
    ap.add_argument("repo")
    ap.add_argument("--since", type=int, default=12, help="months to look back")
    ap.add_argument("--glob", default="*.kt")
    args = ap.parse_args()
 
    repo = Path(args.repo).resolve()
    since = (date.today() - timedelta(days=30 * args.since)).isoformat()
 
    # Only count files actually touched in the window.
    # A screen that merely exists lands at churn 0.
    log = git(repo, "log", f"--since={since}", "--name-only",
              "--pretty=format:", "--", args.glob)
    churn = Counter(l for l in log.splitlines() if l.strip())
 
    rows = []
    for rel in sorted(set(git(repo, "ls-files", args.glob).splitlines())):
        p = repo / rel
        v = view_score(p)
        if v == 0:
            continue  # no View surface, or already on Compose
        c = churn.get(rel, 0)
        rows.append((c * v, c, v, rel))
 
    if not rows:
        print("No View-based screens found")
        return
 
    rows.sort(reverse=True)
    top = rows[0][0] or 1
    print(f"{'score':>6} {'churn':>6} {'view':>5}  tier    file")
    for score, c, v, rel in rows:
        ratio = score / top
        tier = "move  " if ratio >= 0.5 else ("watch " if ratio >= 0.15 else "leave ")
        print(f"{score:>6} {c:>6} {v:>5}  {tier}  {rel}")
    moved = sum(1 for r in rows if r[0] / top >= 0.5)
    print(f"\n{len(rows)} screens / {moved} to move first"
          f" / window {args.since} months (since {since})")
 
 
if __name__ == "__main__":
    main()

Zeroing out files that hit COMPOSE_MARKERS keeps half-migrated screens from resurfacing at the top on every run. If migrated screens keep counting as "still has View code," the list stops reflecting progress, and a list that does not reflect progress gets ignored within a week.

--glob is separate so projects with leftover Java can run *.java as its own pass. Mixed into one run, the ranking drifts toward whichever language happens to have longer files.

Add churn and the ranking splits open

Same six screens, now with twelve months of history:

$ python3 screen_churn.py . --since 12
 score  churn  view  tier    file
    36     12     3  move    app/src/main/java/net/dolice/wall/ui/MainActivity.kt
    14      7     2  watch   app/src/main/java/net/dolice/wall/ui/DetailFragment.kt
     8      4     2  watch   app/src/main/java/net/dolice/wall/ui/CategoryActivity.kt
     6      3     2  watch   app/src/main/java/net/dolice/wall/ui/PaywallDialog.kt
     2      1     2  leave   app/src/main/java/net/dolice/wall/ui/SettingsActivity.kt
     2      1     2  leave   app/src/main/java/net/dolice/wall/ui/AboutActivity.kt

6 screens / 1 to move first / window 12 months (since 2025-07-23)

The five-way tie is gone. Top score 36, bottom score 2 — an 18x spread across screens that a dependency count called equivalent.

And the answer came out as: of six screens, start with one.

That number is what unlocked this for me. Migrating six screens is a plan I abandon before I finish estimating it. Migrating one is something I can start with an evening. A large share of why migrations stall is not technical. The unit of work is simply too big to pick up.

Reading the tiers — and why "leave" is the important one

Tiers are cut on a ratio against the top score, not on absolute numbers, because commit granularity varies wildly between projects. A team that squashes and a developer who commits every save cannot share a threshold.

Making "leave" an explicit, named outcome is the part of this table I care about most. Migration plans fail on the things you decide not to do, not the things you decide to do. Rewriting AboutActivity in Compose delivers nothing to a single user.

Three things churn does not see

Being honest about the gaps in this score:

It cannot see your plans. Churn is entirely backward-looking. If you have already decided to rework billing next month, PaywallDialog gets promoted to "move" by hand, churn of 3 or not. The script's output is a starting order for a decision, not the decision.

It cannot tell dormant from dead. Git does not distinguish "stable" from "abandoned." For anything in the leave tier, I now ask whether the screen should exist at all before asking whether to migrate it. Migrating a screen you could have deleted is a loss twice over.

It cannot see coupling across screens. Migrating one screen often forces changes to how arguments reach the Fragment it navigates to. Churn is per-file and misses that blast radius. Trace the transitions out of a screen by eye before you start.

Where to put the seam

Once the "move" screen is chosen, start with ComposeView interop rather than a full rewrite — an island of Compose inside the existing XML layout.

// Assumes activity_main.xml contains:
//   <androidx.compose.ui.platform.ComposeView
//       android:id="@+id/compose_grid" ... />
 
class MainActivity : AppCompatActivity() {
 
    private val viewModel: WallpaperViewModel by viewModels()
 
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
 
        findViewById<ComposeView>(R.id.compose_grid).apply {
            // Dispose with the host's lifecycle. The default
            // (DisposeOnDetachedFromWindow) keeps the composition alive
            // while the page sits in ViewPager2's offscreen pool.
            setViewCompositionStrategy(
                ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed
            )
            setContent {
                // Apply the Compose theme explicitly. The island does not
                // inherit the XML Theme.AppCompat — skip this and only the
                // island changes color.
                WallpaperTheme {
                    val items by viewModel.items.collectAsStateWithLifecycle()
                    WallpaperGrid(
                        items = items,
                        onFavorite = viewModel::toggleFavorite
                    )
                }
            }
        }
    }
}

I don't leave setViewCompositionStrategy at its default because it has cost me time. The default disposes when the view leaves the window, so on a screen where users swipe horizontally between categories, offscreen pages keep their composition — and their state — alive behind you.

WallpaperTheme is there for the same class of reason. A Compose island inherits nothing from the XML theme. Forget it and you get the most confusing failure mode available: correct everywhere except inside the island.

For the recomposition trap you hit immediately after migrating a list, I wrote up what I measured when one favorite tap redrew the entire wallpaper grid.

Three places partial migration duplicates state

While View and Compose coexist, what I lost track of was not functionality. It was configuration living in two places.

The third one bites hardest. Nested back-press handling settles its own precedence implicitly, and implicit precedence is miserable to debug six weeks later. After getting burned by exactly this in an ad gate, I write back handling as flat, independent checks rather than nesting them. I apply the same rule when adding Compose's BackHandler.

What to hand an agent, and what to keep

Of the work above, the split between what Antigravity's agents can take and what they cannot is unusually clean.

The dividing line is whether every input to the judgment lives in the repository. For churn, it does. For tiers, it does not. Blur that line by handing over "plan my migration" wholesale and you get back a plausible-looking order whose reasoning you cannot check against facts the agent never had.

On keeping agent-produced diffs reviewable, I've also written about cutting parallel agent changes into auditable units. One screen at a time turned out to be the fast path, not the slow one.

The numbers to watch before it's fully out

Ship the migrated screen through a staged rollout. On the wallpaper apps I go 5% → 25% → 50% → 100%, confirming crash-free users at or above 99.7% and ANR under 0.20% before widening each step.

Those thresholds matter more than usual when you're swapping out a UI foundation. Compose migration bugs rarely show up as "the feature doesn't work." They show up as rendering breaking on one device family, or one OS version, which your own handset will never reveal.

I once found a crash affecting only Android 6.0.1 users early in a rollout and closed it with a single build configuration line. Had I shipped at 100%, I'd have learned about it from one-star reviews instead.

Where to start

Run screen_churn.py against your repository once, with --since 12. If one or two screens come back in the "move" tier, that's your migration work for the month.

If three or more come back, rerun with --since 6. A shorter window weights recent attention more heavily, and recent attention is the better predictor.

I'm still mid-migration on my own View code. I've drafted and abandoned full-migration plans for years. What finally got me started wasn't deciding the order — it was deciding which screens I'm never going to touch.

Thanks for reading.