El's Blog

A2UI, AG-UI, and GenUI Beyond the Chat Box

2026-05-15T00:00:00Z

I recently took another look at Google's A2UI and AG-UI. Compared with my first pass last year, my view is clearer now: both are valuable, and they complement each other, but they should not be simplified into "dynamic UI protocols are finally standardized."

More precisely, A2UI and AG-UI are still clearly centered around a chat-like style today: agent conversations, copilots, search/chat, and assistant panels inside productivity tools. This is a large market, of course, and it explains why tools and protocols in this direction are moving so fast. But AI application forms cannot be fixed inside the chat box. The many existing apps, especially in content, media, education, consumer products, and communities, still leave a lot of space worth watching.

Image source: Google Developers Blog, component gallery example from Introducing A2UI: An open project for agent-driven interfaces

Spec and Protocol

Google introduced A2UI in December 2025. The core idea is to let an agent return not just text, but a safe, declarative UI description, which the host application then renders with its own components. By the A2UI v0.9 update in April 2026, the direction became clearer: use the existing component catalog from a design system, let the agent "speak UI," and avoid having the agent directly emit HTML/JS or arbitrary code.

AG-UI sits on another layer. It is not a GenUI spec, but an interaction protocol between an agent backend and a user-facing frontend. The official docs state this directly: A2UI is a generative UI specification, while AG-UI is an Agent-User Interaction protocol. This is also why AG-UI naturally feels chat-oriented: it deals with long-lived connections, streaming, tool calls, state sync, human-in-the-loop flows, cancel/resume, and the runtime reality of "an agent and a user are working through something together."

If we only look at these two protocols:

A2UI describes what UI the agent wants to show, which components to use, what data is bound, and what actions exist.
AG-UI describes how the agent and frontend keep talking, passing text, state, tool calls, UI intent, and user interactions.

Who Is Using This Now

A2UI's official landing zone is still mostly agentic apps: Google Opal, Gemini Enterprise, Flutter GenUI SDK, ADK examples, AG2's A2UIAgent, and CopilotKit/AG-UI integration. The Flutter GenUI SDK is worth paying attention to because it shows Google has at least seriously considered mobile/native rendering, instead of only building browser scenarios. On the A2UI roadmap, Lit, Angular, React, and Flutter are marked stable, while SwiftUI and Jetpack Compose are still planned.

AG-UI feels more like "agent app plumbing." It is closely tied to CopilotKit, and the official docs list integrations with LangGraph, CrewAI, Google ADK, Microsoft Agent Framework, Pydantic AI, Agno, and others. Its strength is turning events from different agent frameworks into typed events that a frontend can consume. In other words, if you are building a web-based copilot, agent chat, or workspace, it may be useful. Otherwise, it is probably not the first layer of the answer.

This is where I think there is still a lot of space. LLMs are NOT only here to make search boxes, chat boxes, and workspaces smarter. News apps still need reading pages, podcast apps still need show notes, magazines still need features, and children's stories still need supportive reading and interaction. The question is not "should these apps become chatbots?" The question is whether the content surfaces inside existing products can begin to understand the content itself, and dynamically place layout, comments, sharing, ads, related reading, and action entry points where they make more sense.

FAQ

I talked with agents about this topic quite a bit. Here are a few of the questions.

What is the relationship between A2UI and AG-UI?

A2UI describes the UI payload itself. AG-UI describes the interaction process between the agent and the frontend. A2UI is closer to a payload/schema, while AG-UI is closer to a runtime pipe. They can be used together, but they are not the same thing.

What is A2UI's JSONL? Can it be parsed incrementally?

JSONL means JSON Lines: each line is a complete JSON object. It is often used with SSE streaming because the client can parse line by line, receiving createSurface, updateComponents, and updateDataModel while updating the local model.

Why does AG-UI feel so chat-like?

Because agent app interaction is rarely a single request/response. The agent streams text, calls tools in the middle, pauses for user confirmation, and continues updating state. AG-UI models these events, so it naturally appears in chat, copilot, and agent workspace products.

Do A2UI demos for marketing emails or Twitter/X cards make sense?

Yes, but mainly during generation and preview, not at the final delivery layer. Email ultimately becomes HTML/MJML. Twitter/X ultimately becomes an image, metadata, or a platform-native card. A2UI can help the admin side preview, approve, rewrite, and schedule through a unified renderer. If the output is only a one-off static artifact, the value of A2UI becomes much thinner.

References

Harness Engineering Essentials: Nine Practices for Taming AI Coding Agents

2026-04-12T00:00:00Z

In late 2025, Anthropic published Effective Harnesses for Long-Running Agents, introducing the concept of a harness — using architectural means to constrain an unstable model into a sustainably running engineering system. They later expanded on multi-agent division of labor and evaluation separation in Harness Design for Long-Running Application Development.

The book Harness Engineering: Claude Code Design Guide takes this idea further by analyzing Claude Code's source code to systematically break down the engineering design across prompt control planes, execution loops, tool permissions, context governance, error recovery, multi-agent verification, and team adoption. The book contains extensive source-level analysis of Claude Code internals — this article strips that away and retains only the transferable best practices.

1. Why Harness Engineering

Models don't deserve inherent trust. A talking probability distribution, once given access to terminals and files, escalates risk from the rhetorical level to the execution level. A text-only model that makes mistakes merely adds communication overhead, but a tool-wielding model that makes mistakes leaves real consequences — deleted files, killed processes, rewritten Git history. Agent systems entering real engineering environments must first acknowledge that their core component is unstable. Ignore this, and the problems will eventually surface in logs and incident reports.
Constrained execution is the core capability. Models make mistakes, tools amplify their consequences, context bloats, state pollutes the next turn, users interrupt, and failures recur. A system cannot maintain order through "cleverness" alone — only through structure. Structure isn't as flashy as cleverness, but it's usually more reliable. A truly usable agent system cannot rely on a single "magic prompt" to solve everything; it must decompose control into layers, and layers into responsibilities.
A harness is an entire control plane. It encompasses prompt constraints, execution loops, tool scheduling, permission approval, error recovery, and more — all converging on one goal: making the model produce tolerable behavior despite being unreliable. High-risk capabilities demand high-density constraints — the more powerful the capability, the finer the control, because the real world won't automatically forgive an erroneous execution just because the model sounded confident. Taken together, Harness Engineering isn't mysterious; it simply insists on a few commonly overlooked engineering fundamentals.

2. Prompts Are a Control Plane, Not a Persona

Persona and control operate on different layers. Persona descriptions address "what it resembles"; a control plane addresses "what it can do, when it should act, what happens when it fails, and who backstops it." A system can have a likable persona while completely lacking discipline at the execution level — such systems tend to seem very sincere when things go wrong, because they're great at apologizing, but apologies cannot substitute for runtime design. For an agent that reads files, invokes tools, touches the shell, handles permissions, and executes across turns, the prompt is closer to a runtime protocol than a character biography.
Prompts should be assembled in layers, not written as a single monolithic text. Mature systems don't pin their faith on a single version of a prompt but treat it as a hierarchical configuration system: identity declarations, system-level rules, engineering constraints, and domain behaviors each managed independently. When newly added reminders and prohibitions conflict with each other, system behavior becomes unpredictable — decomposing into layers and responsibilities is the proper approach. A model that automatically "optimizes everything it touches" may seem enthusiastic from a product perspective, but it's quite dangerous from an engineering perspective, which is why engineering constraints (don't overstep scope, don't conceal verification failures, don't create unnecessary abstractions) must be explicitly specified in the prompt.
Prompts must have a priority mechanism. Different contexts (coordinator mode, agent mode, user overrides) should have an explicit priority ordering, rather than last-write-wins. The key principle: new agent instructions can only layer domain behavior on top of default constraints — they cannot replace the entire discipline. Think of it as general regulations plus a job description — the job description can add responsibilities but cannot override the foundational regulations, or the system will quickly devolve into anarchy. Customizability without structure ultimately degenerates into just another form of chaos.
Prompts must also connect to the memory system. A mature prompt doesn't just prescribe "how to execute this turn" — it also prescribes "how long-term memory should be formed": what to save, what not to save, how to separate indexes from content, and how plans and tasks shouldn't be misused as memory. Once you reach this point, the prompt can no longer be merely a matter of tone — it necessarily enters the domain of institutional design. It extends the prompt's responsibility from "constraining current behavior" to "constraining how future knowledge is accumulated," making it closer to a knowledge governance protocol for runtime participants.

3. The Query Loop: Heartbeat of an Agent System

Agents depend on stateful execution loops, not request-response. To gauge whether an agent is mature, first check if it maintains cross-turn execution state: message history, recovery counts, compaction tracking, tool context, turn counters, and more. Once designed this way, the system formally acknowledges that problems left over from the previous turn will enter the next, and the system must be capable of continuing to handle them. Whether a system deserves to be called an agent often depends not on whether it can speak, but on whether it still knows what it's doing after several turns. Scripts only care whether this step finished; agent systems must also care whether, after this step fails, the next step can pick up the state left behind.
Context governance precedes model inference. Before invoking the model, the runtime should complete a series of housekeeping tasks: extracting valid messages, trimming tool results, compressing history, and collapsing context. Many systems do the opposite: stuff massive context in first, then hope the model figures out what's important on its own. That approach seems efficient but is really offloading the runtime's responsibility onto a probability distribution. Don't hand the model the job of extracting order from chaos — have the runtime complete governance first, then pass cleaner input to the model. Tidy the scene before starting execution; this approach isn't glamorous, but it's usually more dependable.
Interruptions and recovery must be first-class semantics. Whenever a system has committed to an execution sequence, it must settle the books upon interruption — it cannot pretend previous actions never happened just because the user interrupted. Tool calls already dispatched but not yet completed must generate compensating results, ensuring the execution trace remains explainable. Recovery isn't simple retry but a layered attempt from lowest to highest cost and destructiveness. Stop conditions must also be differentiated: streaming completion, user interruption, prompt-too-long, output truncation, hook blocking — each taking a different path. Distinguishing "retry on failure" from "knowing when not to retry" is a hallmark of a mature system.

4. Tools, Permissions, and Interrupts

Tools are managed execution interfaces, not extensions of model capability. Tools are not opinions — tools are actions. Actions leave consequences; consequences touch the real world. The model proposes actions; whether they proceed is decided by the runtime, rules, and the user. Permission outcomes should have at least three states: allow, deny, and ask. The "ask" third state is crucial — it acknowledges that the system itself shouldn't make every decision on the user's behalf. Understanding intent does not equal having authorization, let alone having ongoing authorization. The system must separate "being capable" from "being permitted."
Tool scheduling must preserve causal order. Once a tool system allows concurrency, it must answer an old question: who determines context changes, and in what order do they take effect? The correct approach is that even when execution is concurrent, semantic context evolution maintains a deterministic order — cache modifications first, then replay in original order. Concurrency can improve throughput but must not break causal order. A tool system without scheduling discipline only amplifies the model's instability into the external world; unconstrained concurrency widens the blast radius.
High-risk tools must be treated differently. An interface like Bash, which is virtually unconstrained by domain boundaries, must be treated as a special case — it can directly touch files, processes, networks, and Git repositories, and carries complex shell semantics like redirection and piping. The correct approach is to build dedicated permission checks, command prefix parsing, subcommand count limits, and exhaustive operational rules specifically for it. High-risk capabilities should not receive the same treatment as general capabilities — the more general the capability, the more special oversight it needs. Treating Bash as an ordinary tool is usually just laziness in design.
The tool system protects not just the user, but also the system itself. Incomplete execution results, out-of-order context modifications, unbounded concurrent side effects, and unclear interruption semantics — these problems most quickly destroy system consistency. The purpose of constraining tools is to ensure that "what was executed, what wasn't completed, and why it stopped" always forms a traceable causal chain. Many constraints appear to prevent user errors on the surface, but at a deeper level they prevent the system itself from becoming an inexplicable heap of state fragments. Unexplainable execution traces inevitably become ops problems, audit problems, or long-term liabilities that nobody on the team can untangle.

5. Context Governance: Memory and Compaction

Context is a budget, not a warehouse. "More information makes the system smarter" is a common myth. Context is first and foremost an expensive, bloat-prone, self-contaminating resource — an agent system is not a library, and the model is not a librarian. Long-term rules, persistent memory, session continuity, and ephemeral conversation should be governed in separate layers, not mixed into one pot. Stable team conventions and repository constraints have lifespans far exceeding any single user message; if everything gets stuffed into chat history, you either redundantly inject every turn wasting context, or rely on the model to recall things on its own, which will eventually fail.
Memory entry points must stay small. Index files are naturally loaded frequently, and once frequently-loaded content grows fat, it slowly drags down the entire context system. Long-term memory should be split into "entry points" and "body": entry points for low-cost addressing, body for high-density content. Entry point files should have hard limits — exceed them and the system truncates with a warning, moving details to separate files. Once an entry point serves as both directory and content, it ends up being neither — just an abandoned summary nobody wants to read a second time.
Session continuity requires structured summaries, not chat logs. Session memory should be distilled into a continuation-ready operating manual: current state, pitfalls encountered, files modified, and what to pick up next. It doesn't aim to fully replicate the conversation but to compress the essential skeleton needed to keep working. Summary budgets must also be controlled, prioritizing "current state" and "error corrections" — the parts most useful for the next execution step. A truly mature system treats "preserving the most useful parts for continuing work" as a virtue, because context budget is working memory, and working memory's first duty is to be actionable.
Compaction's goal is rebuilding work semantics, not writing a nice summary. Post-compaction context must restore plan state, file state, skill constraints, tool attachments, and other runtime environment — the summary is merely an intermediate artifact, and the real goal is to lay flat "the work foundation needed to keep going." Compaction is therefore more like a controlled restart than a chat summary — old context gets translated into a new work foundation. Systems that only do the first half may "roughly remember" after compaction, but they've already lost tool and plan state, and will spend the next several turns finding themselves again. Context systems should prioritize preserving what maintains action semantics over what appears to have the most information density.

6. Errors and Recovery

Error recovery must be layered — don't use one heavy hammer for every problem. Judging whether an agent system is mature should not be based on how human it sounds when things go smoothly, but on how systematic it looks when things break. For example, when a prompt is too long, first try draining known backlogs, then attempt heavier full-text compression — don't immediately rebuild the world. A good recovery system first tries to preserve the finest-grained context, then accepts coarser summary replacements only when necessary. Some errors should be handed to the recovery system for an attempt before deciding whether to surface them to the user — what users truly care about is usually whether the system can keep working.
Recovery logic must prevent self-referential loops. If compaction doesn't help, continuing to compact will most likely just replay the same failure in a different pose. The most dangerous errors in a system are when failure branches and recovery branches bite each other and begin infinite self-replication. Any automatic recovery mechanism must be countable, limited, and circuit-breakable — a recovery system that can't stop is like a car without brakes: both are technically called systems, but neither should be on the road. Even "repair actions" themselves need repair strategies, because in practice, a compaction request can itself fail due to context being too long. At that point, the priority is to restore breathing first and discuss information fidelity later.
The best recovery after truncation is continuation, not summarization. When output is truncated, the system should continue directly from the breakpoint rather than first apologizing, recapping, or writing elegant filler. First try raising the token cap and re-running directly; if that's still insufficient, append an instruction telling the model to continue from where it was cut off, explicitly requesting no apologies and no review. Every post-truncation recap further consumes budget and increases semantic drift, until the system is no longer doing the task itself but round after round of reviewing itself doing the task. An engineering system's true courtesy lies in not trapping users in a failed state.
Interruption is also a failure state that requires semantic closure. A user interruption isn't just "I don't want to watch anymore" — it's a state transition that requires proper wrap-up. Tool calls already dispatched but not yet completed must generate compensating results, ensuring previously committed actions don't become dangling debts. What error recovery truly repairs is not just the error itself, but the system's ability to explain its own behavior — whether the system can articulate "what I just attempted, why it didn't work, and whether to continue or stop now." Once explanatory ability breaks, the system degrades from an engineering object into a mystical one.

7. Multi-Agent and Verification

Forking is first and foremost a runtime economics problem. Sub-agents must share cache-critical parameters with the parent (system prompt, context, tool configuration, etc.); otherwise, each fork re-burns the entire token budget, appearing to parallelize for efficiency while actually just parallelizing waste. State isolation is the default ethic — all mutable state is isolated first, and sharing must be explicitly declared, preventing a sub-agent's local chaos from contaminating the main thread. The most valuable aspect of a sub-agent is precisely that it can avoid polluting the main thread with its local messiness: misguided research, temporarily read file states, and one-off reasoning branches. If all of these write directly back to the main context, you only get faster contamination.
Research can be delegated; synthesis cannot. What's truly scarce in multi-agent systems is synthesis — compressing the local knowledge each worker brings back into clear, executable, verifiable next steps. The coordinator must digest research results before writing specific instructions; subsequent prompts must reference specific files, specific locations, and specific changes, rather than abstractly stating "based on the previous findings." Without this layer, multi-agent systems quickly degenerate into politely-worded task forwarding machines — every agent is busy, but the system as a whole hasn't gotten any smarter. This is classic engineering division of labor: research can be distributed, but understanding must be re-converged.
Verification must be an independent stage. Between "I modified the code" and "the code is therefore correct" lies a very wide river, and models are especially good at building paper bridges across it. Implementers naturally tend to believe their changes are "probably fine," and models even more so — they'll give you changes, explanations, and even plausible-looking test output, but none of that equals the feature actually standing on its own. Verification must become an independent role: those who implement focus on making changes; those who verify focus on questioning whether those changes deserve to survive. The goal of verification is to prove code works, not merely to confirm code exists — otherwise "done" quickly degrades into "I wrote it and I think it's fine."
Sub-agents need complete lifecycle management. They should be observable at startup, intervenable before shutdown, with traceable transcript paths, and when the parent task aborts, child tasks must follow. Whether output files should be retained, whether cleanup callbacks have leaked, how to handle state residue after an agent ends — all of these require explicit handling. A multi-agent demo that merely achieves "I can spawn another agent" falls far short; agents must be treated as runtime entities that can leak resources, leave residual state, and become orphans when parent processes end. The real value of multi-agent isn't parallelism for speed — it's compartmentalizing different kinds of uncertainty into different containers and having the coordinator reassemble them.

8. Team Adoption

Start by drawing the minimum controllable boundary. Teams don't need to start with hooks and complex skill directories. First, get four things clear: which tasks agents are allowed to participate in, which changes must go through human review, what verification must run after changes, and which resources are strictly off-limits. These four things matter more than any grand slogan. If the acceptable scope isn't defined, people will use agents for things that shouldn't be automated; if review responsibility isn't defined, nobody knows who's the last line of defense when things go wrong; if no-go zones aren't defined, efficiency gains merely widen the blast radius. Many teams ultimately fail not because the agent isn't powerful enough, but because they skipped this step at the start.
Unify verification definitions before expanding skill count. The most common failure in adopting an AI coding agent isn't in the prompt or the model — it's that the team has no unified definition of "done." Some think "it runs" is enough; some think "half the tests passed" is fine; some think "the model's explanation sounded convincing" counts. Under these conditions, even the smartest system will only learn to meet the lowest bar. Skills can replicate workflows, but only verification definitions can replicate quality. First define which tasks require independent verification, what verification must minimally include, and how to mark verification failures — once these three things are unified, even with few skills, the quality floor holds.
CLAUDE.md is more like a foundation than a bulletin board. Team-level instruction files are suited for stable rules: codebase hard constraints, unified verification standards, collaboration discipline, and output style. They're unsuited for frequently changing temporary processes, operational details used by only a handful of tasks, or steps that belong in scripts or skills. Once written into an encyclopedia, they lose stability and credibility — team members can no longer tell whether it describes current rules or a discussion left over from six months ago. The system will also learn a terrible pattern: treating expired conventions as current law.
Layer approvals by risk; introduce hooks last. Permission approvals should be layered by irreversibility and environmental sensitivity (read operations < write operations < pushing code / accessing sensitive environments), rather than applying blunt per-tool toggles, because what teams actually need to control is consequences, not button names. Hooks are an advanced automation interface, best introduced after foundational governance has stabilized — otherwise they easily introduce new complexity: scripts nobody maintains, trigger timing nobody can explain, and debugging costs higher than manual operations. The more mature judgment is to first stabilize the floor with review, CI, and minimal documentation, then consider more complex orchestration.

9. Ten Principles

The book closes by condensing everything into ten principles:

Treat the model as an unstable component, not a colleague. A model may talk like a colleague, but it won't automatically acquire stability, accountability, or sustained judgment. The sooner you accept this, the sooner the system starts adding permissions, recovery, verification, and rollback.
The prompt is part of the control plane. Together with the runtime, tool schemas, memory, and hooks, it forms the control plane. Treat the prompt as a persona setting, and you'll end up with a system that performs well but isn't constrained.
The query loop is the agent system's heartbeat. Input governance, streaming consumption, tool scheduling, recovery branches, and stop conditions are all part of this heartbeat. A system without an execution loop may produce demos, but it doesn't qualify as a runtime.
Tools are managed execution interfaces. Once a model starts touching shell and filesystem, the question shifts from "can it speak" to "will it leave consequences." The more dangerous the tool, the less it should be treated as an ordinary capability.
Context is working memory. Being able to stuff something into context doesn't mean you should. Compaction's goal is preserving the semantic foundation for continued work — the standard isn't "enough" but "governable."
The error path is the main path. Prompt-too-long, output truncation, interruptions, hook loops, and compaction failures are all routine weather for long-session agents. Recovery and circuit breaking must exist by design, not be retrofitted after incidents.
Recovery's goal is to keep working. The best action after truncation is usually continuation; when compaction fails, the top priority is restoring the system's ability to breathe.
Multi-agent's purpose is partitioning uncertainty. Research, implementation, verification, and synthesis go into different containers, with the coordinator converging understanding. The real value of parallelism isn't speed — it's clearer responsibility boundaries.
Verification must be independent — systems cannot grade their own work. For any important task, verification should be an independent stage, ideally with an independent role.
Team institutions matter more than individual skill. An expert can tame an agent through experience alone; a team cannot. Only by institutionalizing individual experience can an agent system become an organizational capability rather than a personal party trick.

Building the Team While Building the Product: Notes from an AI Startup

2026-04-04T00:00:00Z

Over the past few years, I have grown into a hands-on Tech Lead Manager (TLM) role. I still deliver technical work while managing engineers, making product decisions, and building the team. After reading several books, I tried some of their ideas in practice. I wanted to record what worked, what fell short, and what I am still figuring out. These notes cover the role itself, management planning, team building, and day-to-day execution.

I currently work at a small, geographically distributed vertical AI company. These are personal observations shaped by that specific environment, with no claim to being a universal management playbook. I have omitted identifying details, and the people in the examples below are fictional.

Defining the Role

A lot of people move into technical leadership this way: the previous lead leaves, and someone else has to step up. That was my path. When the Tech Lead at my previous company left, I became the de facto Tech Lead. I took over delivery, technical decisions, mentoring, code reviews, and cross-team coordination, including finishing a half-built external SDK across three client platforms.

Many of my friends love code for its own sake and care deeply about elegant architecture. About a year after moving to Singapore, I realized I was becoming more of a problem solver. Two and a half years on infrastructure teams let me explore difficult technical problems. I also supported other engineers and the long-term evolution of our products. That experience gave me enough material to write Extending Android Builds.

Later, moving countries and companies widened my path again. Writing the book and becoming a Google Developer Expert shifted my focus as well. I began working more on communication, design, and projects where a broader perspective could help others.

My technical scope is now wider. It includes Android and iOS architecture, UI/UX systems, evaluation for AI workflows, and data analysis that can reveal product needs. In a first-line startup role, I still stay close to implementation. "Vision" is not a reason to lose touch with the details.

Today I work as a hands-on Tech Lead Manager and cover part of the Product Owner role. The work moves between collecting data, writing a PRD, and making architecture decisions. As the company evolved, I became part instrumentalist and part conductor: a supportive, highly engaged player-coach.

Two opposite management failure modes help explain the distinction:

One manager called themselves supportive but had little technical context. They could distribute fixed resources from above, yet made no serious attempt to create room for experimentation. Career support remained verbal, and rewards were based on tenure.
Another manager came from engineering and expected everyone to work at their pace. They sent team-wide messages at three or four in the morning. Their own capacity was limited, and they never learned how to develop people who could take ownership outside their strengths. No one can stay at the front of every problem forever.

Support requires context and concrete action. Involvement should help other people take ownership.

Early in my current role, I wrote down a few reminders for myself:

Finishing a job properly matters more than making it perfect.
We are here to build a viable business while maintaining a culture where everyone can work with dignity.
Simplicity, maintainability, and efficiency usually matter more than extreme performance or clever optimization.
Building a company and sustaining one are both hard. Push hard when it is time to push, and stabilize carefully when it is time to stabilize.

I also follow a few quieter rules as an engineering manager:

I will always have rough edges. At the very least, I should not be a jerk.
Do not compete with your own team for ownership, especially on technical work.
Give credit loudly, and make sure collaborators know who earned it.

Teamwork is the clearest thread running through how I define the role:

Maintain backup coverage so people can take leave without pressure. If iOS is short-handed today, I can write some iOS code. If I am away tomorrow, someone else can watch a holiday campaign release.
Give senior and junior engineers opportunities beyond code, including operational coordination, product design, and data analysis. Durable collaboration helps people see what else they can contribute.
Share context early, prepare for likely scenarios, and let other people make technical decisions. Listen to ideas and frustrations, find the pain points, and turn them into concrete work.

Management Planning

I organize management planning around four questions: mandate, goals, team, and execution path. Maintaining the Android and iOS products is the baseline mandate of a Mobile App team. I also ask what additional value that team can create:

While maintaining App A, identify architectural pieces that a future App B could reuse and prepare them early.
Platform changes can also create shared work. Android 16 or 17 and responsive iPad layouts may require similar UI/UX work across Mobile and Web.
After a year of learning how to use AI Coding tools, bring that experience into adjacent areas. The team may help with internal AI tools or selected frontend and backend tasks, and discover growth opportunities from a different angle.

Goals deserve the same scrutiny. Doing the work correctly is often easier than finding the right work. In many startups, taking the right goal to 80 percent matters more. It often beats improving an established area from 90 to 92 percent. Keeping the mandate flexible and adjusting direction have been some of the most rewarding parts of the job.

The technical path depends on the team and how the business makes money. Some consumer companies acquire users through paid ads and run a portfolio of products, hoping a few become hits. A vertical subscription business grows through long-term retention. The two need different technical paths.

A portfolio business may prioritize reuse, low launch costs, and fast experiments. A subscription business may care more about reliability, product quality, and long-term maintainability.

A popular technology is not always the right choice. The real question is whether it helps the business retain users and stay ahead of competitors.

When several technologies fit both the business and the team, my checklist looks roughly like this:

Can we contain a failure? If a cross-platform framework misses an important case, can we fall back at a reasonable cost? If an open-source compiler or dependency breaks, can we find the cause quickly? Access to an expert or an enthusiast on the team changes the risk.
Who builds and stewards the technology? I trust ecosystems backed by organizations that use the technology in production and maintain it for the long term. It also helps when important work stays in a healthy core project.
Can we adapt the smaller pieces ourselves? A maintained fork may fit the team's workflow, while a small adapter can make one capability reusable across internal projects.

Coding Agents do not remove the human side of these decisions. Asking an agent to understand a codebase as large as AOSP and find the right solution remains difficult. High-impact choices still depend on context and access to expertise.

The remaining question is the team itself: who we need, and how their strengths fit together.

Building the Team

A team feels more like an orchestra to me. There are different players, principal players, and a conductor, but everyone contributes to the same performance.

Large companies often standardize hiring for consistency and scale. Standardized interviews often favor candidates who know how to prepare for them. Strong candidates with less conventional backgrounds may be overlooked. A startup can collect a wider set of signals:

A strong academic record and an impressive GitHub project show discipline and sustained learning in different ways.
Between similar technical backgrounds, the person who understands the product and follows the industry may be better prepared for startup work.
Ten years on one stack and ten stacks in ten years tell different stories. Either candidate loses credibility if they never look at what the company uses before the interview. "I can learn it after I join" needs evidence.

No one can understand another person in a one-hour call. Three to five focused conversations can provide independent signals, as long as the process respects the candidate's time. I would build a Mobile App team around complementary people, rather than a checklist of Android, iOS, and Flutter job titles. It might include:

An Android engineer with deep technical foundations who has also learned some iOS and shipped a small iOS app independently.
A mobile lead who has worked across very different organizational cultures and practices UI/UX design as a serious hobby.
A former English teacher who became a programmer, built several independent products, and contributed many pull requests to open-source projects.

Working in multinational companies broadened my view of what a team could look like. Demographic representation matters, and so do differences in professional background, product exposure, language, and problem-solving habits. Together, they affect team resilience and the range of options available during planning. Hiring can never be perfectly objective, but team composition can still be deliberate.

Experience is also harder to read now. One candidate may have eight years of professional experience but resist AI-assisted development. A recent graduate may have eight years of programming experience. Similar trade-offs appear between technical depth and breadth, or between business knowledge and familiarity with the current stack. AI can produce a lot of code. An experienced specialist can still spot a weak signal and act on years of context. I value people who can see what they need to learn and close the gap to a useful 60 percent quickly. They also need to work with the untidy constraints of real products.

A friend uses an interview question I like: "Tell me about a product you think is well made, and explain why." I browse Mobbin for design references for the same reason. Real products expose judgment in a way an abstract question cannot. For some roles, another standard interview round may not tell us much. A paid, time-boxed trial or a short pair-working exercise can reveal more. So can asking a candidate to build a small tool with a Coding Agent.

Back to the Work

Most experienced technical professionals already have the basic discipline to manage tasks, and clear SOPs can improve it over time. I think task management and Agile receive more attention than they deserve in small, experienced teams. Coordination roles lose leverage when they are detached from product and technical context. In a large, regulated, or dependency-heavy organization, a strong TPM or Scrum Master may still be essential. The test is whether the role resolves real constraints or maintains reporting machinery.

Even if a particular practice makes one step in an SOP five or ten percent more efficient, the returns eventually flatten. In practice, the process still has to fit the project. A mobile app rarely ships a new version every day, while a web product may ship several times a day.

Teams still need clear priorities, dependencies, and timelines, but heavier tracking does not create ownership. Avoid changing direction in a morning meeting and expecting results that evening. A written plan, agreed timing, and enough context remove a great deal of friction.

Day-to-day delivery is shaped by both team routines and what we expect from individual engineers. The 10x engineer is often misunderstood as someone who writes code ten times faster. I think the real multiplier is learning speed. An engineer who can enter an unfamiliar area and quickly become a domain expert may deliver far more than ten times faster. Coding Agents already generate code quickly, so raw coding speed is no longer a useful comparison. What matters is how fast someone can find the right problem, build the necessary context, and turn that understanding into a working result.

Many people spend years searching for the perfect to-do app and end up using the one built into their phone. At work, try a blank document: list what the team needs to do next, grouped by release, week, or sprint. Let the project determine the process, then return your attention to the work in front of you.

Responsive Layout Fundamentals

2026-03-16T00:00:00Z

Getting started with responsive design really comes down to two things: where to put the navigation, and how to arrange content. As screens get larger, each of these has a well-established set of patterns. Android's developer docs have the most thorough summary, complete with ready-made components. iOS and Web follow similar ideas but require more manual work.

The core question: as the screen gets wider, where does the navigation go?

Bottom Bar

The most common mobile navigation. 3-5 icons lined up at the bottom of the screen, within thumb reach. The default choice for phones in portrait.

┌───────────┐
│           │
│  Content  │
│           │
├──┬──┬──┬──┤
│🏠│📋│🔍│⚙️│
└──┴──┴──┴──┘

Top Bar

The traditional Web approach. Logo on the left, nav items on the right. Works well when there aren't too many items and brand presence matters. Rarely used as the primary navigation on native mobile apps, but extremely common on the Web — marketing sites, docs, SaaS products.

┌──────────────────────┐
│ Logo  Home  About  ▾ │
├──────────────────────┤
│                      │
│      Content         │
│                      │
└──────────────────────┘

On narrow screens, the Top Bar typically collapses into a hamburger menu that opens as a full or half-screen overlay. Web developers know this drill well.

Rail

A narrow sidebar with just icons and short labels, pinned to the left edge. The go-to choice for tablets and foldables — makes better use of horizontal space than a Bottom Bar, without eating as much area as a Drawer.

┌──┬───────────┐
│🏠│           │
│📋│  Content  │
│🔍│           │
│⚙️│           │
└──┴───────────┘

Drawer

A full sidebar with icons and complete labels. Can hold many items, supports grouping and nesting. The standard for large screens and desktops. Some implementations support expand/collapse.

┌──────────┬─────────┐
│ 🏠 Home   │         │
│ 📋 Orders │ Content │
│ 🔍 Search │         │
│ ⚙️ Settings│         │
└──────────┴─────────┘

Switching Logic

As screen width increases:

Phone        Tablet/Foldable    Desktop/Large
Bottom Bar  →    Rail       →   Drawer

Web has an additional path:

Phone              Tablet          Desktop
Hamburger(☰)  →  Top Bar    →  Top Bar (more items)
  or               or              or
Bottom Bar    →  Rail        →  Drawer

Which path to take on the Web depends on the product type. Tool-oriented products (admin panels, email, docs) go the Rail/Drawer route. Content-oriented products (blogs, marketing sites, e-commerce) go the Top Bar route. Native apps almost always follow the Bottom Bar → Rail → Drawer path.

Platform Support

	Android	iOS	Web
Bottom Bar	`NavigationBar`	`TabView`	Roll your own
Top Bar	Uncommon	Uncommon	Roll your own (trivial to find)
Rail	`NavigationRail`	No native component	Roll your own
Drawer	`NavigationDrawer`	No native component	Roll your own
Auto-switch	`NavigationSuiteScaffold`	None, manually check Size Class	None, use CSS breakpoints

Android is probably the only platform with a turnkey solution. NavigationSuiteScaffold takes your nav items and automatically switches between the three forms based on window size — one line of code. iOS and Web both require you to build this switching logic yourself, though Web often leverages Tailwind breakpoints and mature component libraries to get there.

2. Content Area (Canonical Layouts)

Once navigation is settled, the remaining question is how the content area adapts to different screen sizes. Google identified three canonical layouts that cover the vast majority of cases.

List-Detail

On small screens, the list and detail are separate pages — tap an item to navigate to its detail. On large screens, they sit side by side.

Small:                   Large:
┌──────────┐            ┌─────┬────────┐
│ Item A   │            │ A   │        │
│ Item B   │    →       │ B ● │ Detail │
│ Item C   │            │ C   │ of B   │
└──────────┘            └─────┴────────┘
  Tap → full-screen        Side by side

The most classic responsive pattern. Email clients, chat apps, settings pages, file managers — all List-Detail.

Platform implementations:

Android: ListDetailPaneScaffold, works out of the box
iOS: NavigationSplitView, functional but limited in customization
Web: CSS Grid/Flexbox + media queries, or simply grid-template-columns: 300px 1fr

Feed

Content comes in cards. Single column on small screens, multi-column grid on large ones.

Small:             Large:
┌────────┐        ┌────┬────┬────┐
│ Card A │        │ A  │ B  │ C  │
│ Card B │   →    │ D  │ E  │ F  │
│ Card C │        │ G  │ H  │    │
└────────┘        └────┴────┴────┘
  Single col        Multi-col grid

Social feeds, news, image galleries, product listings. The key is letting the column count adapt to screen width rather than hardcoding it.

Platform implementations:

Android: LazyVerticalGrid + GridCells.Adaptive(minSize)
iOS: LazyVGrid + GridItem(.adaptive(minimum:))
Web: grid-template-columns: repeat(auto-fill, minmax(280px, 1fr)) — one line of CSS, and Web actually wins here in simplicity

Supporting Pane

The main content takes the majority of space, with supplementary info alongside. Unlike List-Detail, this isn't a master-detail relationship — it's main content plus auxiliary information.

Small:                   Large:
┌──────────┐            ┌────────┬─────┐
│          │            │        │     │
│   Main   │    →       │  Main  │ SP  │
│          │            │        │     │
├──────────┤            └────────┴─────┘
│ Support  │              Main + side panel
└──────────┘
 Below or in a sheet

Maps + search results, video + comments, code editor + properties panel. On small screens, the supporting pane typically sits below, collapses into a bottom sheet, or becomes an expandable overlay.

Platform implementations:

Android: SupportingPaneScaffold
iOS: No equivalent component, build with HStack + GeometryReader
Web: CSS Grid or Flexbox, straightforward

Combining Layouts

In practice, these three often nest inside each other. Take an email client: the overall structure is List-Detail, the list itself is a Feed (email cards), and the detail view might have a Supporting Pane on the side showing attachments or contact info. Once you understand these three base patterns, every variation is just a combination.

Summary

Responsive layout = Navigation adaptation + Content area adaptation

Navigation:
  Bottom Bar → Rail → Drawer (native apps)
  Hamburger → Top Bar (Web content sites)

Content area (Canonical Layouts):
  List-Detail      List and detail, separate pages on small screens, side by side on large
  Feed             Card stream, single column on small, multi-column on large
  Supporting Pane  Main content + auxiliary panel

Android has the most complete story here, with dedicated Material 3 components for each pattern. iOS only has NavigationSplitView and LazyVGrid roughly covering List-Detail and Feed — the rest is manual. Web has the most flexibility — CSS Grid was designed for exactly these scenarios — but lacks high-level turnkey components, so you assemble them yourself.

That's the full picture. When building a screen, first identify which Canonical Layout it falls into, then decide which navigation form to use. The rest is platform API details.

Some Personal Takes on Metro DI

2026-03-15T00:00:00Z

Metro is a compile-time DI framework for Kotlin Multiplatform, created by Zac Sweers (formerly Android Infra at Slack). Cash App and Vinted are already using it in production. This post is aimed at developers who have some DI experience or are coming from other frameworks — not a comprehensive guide, just notes from my own exploration with some comparisons along the way.

Core Concept: Binding

At its core, any DI framework maintains a binding table: when someone asks for type A, give them instance B. Metro is no different — all its annotations are essentially adding entries to this table.

RepoA        → RepoAImpl
RepoB        → RepoBImpl
HttpClient   → HttpClient(CIO) { ... }
Json         → Json { ignoreUnknownKeys = true }

Once you internalize this, the number of annotations starts to feel more manageable. Starts to.

The Simplest Case: @Inject

Add @Inject to your own class, and Metro knows how to create it. Dependencies in the constructor are automatically resolved and injected:

@Inject
class ArticleRepositoryImpl(
    private val httpClient: HttpClient,
    private val json: Json,
) : ArticleRepository

One annotation covers both "I can be created" and "I need these dependencies." Compare this with Koin:

// Koin requires a separate registration
module {
    factory { ArticleRepositoryImpl(get(), get()) }
}

By default, @Inject creates a factory — a new instance every time. Add @SingleIn to make it a singleton:

@Inject
@SingleIn(AppScope::class)
class ArticleRepositoryImpl(...) : ArticleRepository

Unlike Koin's separate single {} and factory {} functions, the only difference here is whether @SingleIn is present. A clean design choice.

Aggregation

This is arguably Metro's biggest improvement over Dagger.

With traditional Dagger, you manually wire Modules into Components and maintain a large module list. Koin is similar — you need startKoin { modules(a, b, c, ...) } somewhere to chain everything together, or use its KCP plugin (or roll your own tool — I made one called Koncat). Some argue that this list becomes unwieldy in large projects; I'd say that's mostly a symptom of poorly structured modules =.= leading to oversized individual modules.

Metro's compiler-driven auto-collection looks like this:

// In the feature-article-domain module
@Inject
@SingleIn(AppScope::class)
@ContributesBinding(AppScope::class)
class ArticleRepositoryImpl(
    private val httpClient: HttpClient,
) : ArticleRepository

@ContributesBinding(AppScope::class) means: contribute the binding ArticleRepositoryImpl → ArticleRepository to the AppScope graph. When the compiler processes the module where the graph is defined, it automatically scans all dependent modules for classes annotated with @ContributesTo or @ContributesBinding and wires them in.

Declare and register in one place, no manual aggregation needed. This is a significant productivity gain for multi-module projects — you annotate the class and you're done, no need to update a registration file elsewhere. It's also more AI-coding friendly: an AI only needs to modify one file when adding a class, rather than remembering to register it in a separate module file.

Graph and Scope

Metro's scope doesn't bind to any lifecycle by itself — it's just a tag. One scope corresponds to one graph (DI container), roughly equivalent to a Koin instance.

// Declare a scope
@Scope
annotation class AppScope

// Declare a graph
@DependencyGraph(AppScope::class)
interface AppGraph

The lifecycle is entirely determined by when you create and destroy the graph instance: put it in Application and it lives with the app process; put it in a login session holder and it lives with the user session. Unlike Hilt, Metro doesn't provide predefined scopes like @ActivityScoped or @ViewModelScoped that automatically bind to Android components — more flexibility, but more responsibility.

Graphs can have parent-child relationships via GraphExtension:

@DependencyGraph(UserScope::class)
interface UserGraph : GraphExtension<AppGraph>

Child graphs can access parent bindings, but not vice versa. This is how you implement nested scopes like App → User → Feature.

Cross-Module Dependencies: Why Export Modules Exist

Say feature-a needs data from feature-b, and vice versa. Direct dependencies would create a cycle, so you extract the interfaces:

feature-a-export/   ← interfaces only: RepoA
feature-a-domain/   ← implementation: RepoAImpl, depends on feature-b-export
feature-b-export/   ← interfaces only: RepoB
feature-b-domain/   ← implementation: RepoBImpl, depends on feature-a-export

Feature modules know nothing about each other's implementations at compile time. In a KMP setup, the assembly happens when the shared module compiles — since shared depends on all feature modules, Metro's compiler plugin can see the complete dependency graph there and wire all contributed bindings into the AppScope graph. For a standard Android app, this would typically be the app module.

Trade-offs Worth Noting

BindingContainer and @Provides

For your own classes, @Inject + @ContributesBinding is concise. But for third-party classes where you can't add annotations, you need @Provides:

@ContributesTo(AppScope::class)
@BindingContainer
interface NetworkBindings {
    @Provides @SingleIn(AppScope::class)
    fun httpClient(): HttpClient = HttpClient(CIO) {
        install(ContentNegotiation) { json(json()) }
    }

    @Provides @SingleIn(AppScope::class)
    fun json(): Json = Json { ignoreUnknownKeys = true }
}

You need to create an interface, annotate it with @BindingContainer and @ContributesTo, then write @Provides functions inside.

Compare with Koin:

module {
    single { HttpClient(CIO) { install(ContentNegotiation) { json(json()) } } }
    single { Json { ignoreUnknownKeys = true } }
}

Koin feels more intuitive for this particular scenario. The name @BindingContainer is also less immediately obvious than Dagger's @Module — though @Module isn't exactly self-explanatory either. This is boilerplate you'll need to memorize.

AssistedInject

When a ViewModel needs runtime parameters (e.g., an ID), you use assisted injection:

@AssistedInject
class DetailViewModel(
    @Assisted val id: String,           // provided at call site
    private val repo: DetailRepository, // provided by DI
) : ViewModel() {

    @AssistedFactory
    interface Factory {
        fun create(id: String): DetailViewModel
    }
}

Compare with Koin:

class DetailViewModel(
    val id: String,
    private val repo: DetailRepository,
) : ViewModel()

// Registration
module {
    viewModel { params -> DetailViewModel(params.get(), get()) }
}

// Usage
val vm = koinViewModel<DetailViewModel> { parametersOf("some-id") }

Metro requires @AssistedInject, @Assisted, @AssistedFactory, plus a Factory interface. The mental model shifts from "how do I create a ViewModel with parameters" to "I need to declare a factory interface." On the other hand, Metro's approach is type-safe — create(id: String) uses named parameters, while Koin's parametersOf(...) relies on positional arguments where ordering mistakes won't be caught at compile time.

In the age of AI-assisted coding, the extra boilerplate is less of a concern since AI handles it well — and type safety arguably matters more when AI is generating the code too.

@ViewModelKey Redundancy

Registering a ViewModel into the DI map requires:

@Inject
@ViewModelKey(ArticleListViewModel::class)
@ContributesIntoMap(AppScope::class)
class ArticleListViewModel(...) : ViewModel()

@ViewModelKey(ArticleListViewModel::class) placed on class ArticleListViewModel — the key is the class itself, yet you must spell it out explicitly. I filed an issue suggesting default inference, but it was declined — the rationale being that special-casing ViewModel keys would set a precedent for other map keys. A reasonable stance, though it does mean repeating this line for every ViewModel.

Overall Impressions

Aggregation combined with @Inject + @ContributesBinding is where Metro shines — multi-module projects benefit from automatic registration, and missing bindings are caught at compile time.

The @Provides + @BindingContainer and @AssistedInject patterns carry more ceremony. The annotation count inherits the complexity of the Dagger lineage, which can feel like a steep learning curve for developers less familiar with that ecosystem. Zac Sweers comes from the Dagger/Anvil world, so this is a natural evolution for him — for others, it's a new set of concepts to absorb.

Metro is currently at 0.11.x, not yet 1.0, but development has been quite active.

Teaching AI Coding Agents with Submodules

2026-03-15T00:00:00Z

Coding agents have knowledge cutoff dates — they tend to hallucinate when dealing with new frameworks or newer API versions. Even Context 7's documentation knowledge is roughly a month-old snapshot, which can already be outdated for fast-moving frameworks. So "how to feed AI the correct framework knowledge" is a practical problem.

I recently came across antfu's skills repo. The idea is to process official documentation into AI-consumable skill files and load them into Claude Code as context. It's still at the proof-of-concept stage, but the architecture is worth learning from. I tested a similar approach in a KMP project.

antfu's Approach

He categorizes skills by source into three types:

Hand-maintained: Personal coding preferences — Composition API, TypeScript, pnpm workspace, etc. Pure taste files, no automation involved.

Generated from official docs: vue, nuxt, vite, vitest, etc. Official documentation repos are pulled in as submodules, then scripts extract and distill them into SKILL.md files. This is the main focus.

Vendored from external projects: Projects like slidev and vueuse maintain their own skills/ directories, which are synced over directly. This is essentially pushing an ecosystem norm — encouraging framework authors to maintain AI-facing documentation themselves. vueuse has already set up a dedicated vueuse/skills repo for this.

The core mechanism is submodules. .gitmodules has two categories of references:

# sources — official doc repos, used to generate skills
[submodule "sources/vue"]
    path = sources/vue
    url = https://github.com/vuejs/docs

# vendor — skills maintained by external projects, synced directly
[submodule "vendor/slidev"]
    path = vendor/slidev
    url = https://github.com/slidevjs/slidev

The output directory structure:

skills/vue/
├── SKILL.md              # distilled framework knowledge, the main file for AI
├── GENERATION.md         # metadata: source commit SHA, generation date
└── references/           # supplementary details
    ├── advanced-patterns.md
    └── core-new-apis.md

Generated skills have GENERATION.md, vendored ones have SYNC.md — both for version tracking with exact commit SHAs. You can tell at a glance which version of the official docs the current skill corresponds to, and whether it's outdated.

Putting It into Practice

As an example, I have a project using Metro (a compile-time DI framework for KMP — more details in my previous post). AI knows almost nothing about it. Following the approach above, I set up something similar:

skills/
├── sources/
│   └── metro/                   # git submodule → ZacSweers/metro
├── metro/
│   ├── metro-core.md            # @DependencyGraph, @Provides, createGraph...
│   ├── metro-injection.md       # @Inject, @AssistedInject...
│   ├── metro-aggregation.md     # @ContributesTo, @ContributesBinding...
│   ├── metro-scopes.md          # @Scope, @SingleIn, AppScope...
│   ├── metro-multiplatform.md   # KMP graph patterns...
│   └── metro-viewmodels.md      # ViewModelKey, MetroViewModelFactory...
├── update-skills.sh
└── README.md

The submodule is pinned to the tag matching the Metro version declared in libs.versions.toml. The skill files are then referenced in AGENTS.md (Claude Code's project instruction file), giving the AI correct API references when working with DI code.

Two additional things worth mentioning:

A Gradle version-check plugin. A convention plugin that compares the Metro version in libs.versions.toml against the submodule's git tag, and warns on mismatch. It's hooked to the debug build's package task, so it naturally triggers during daily development.

An update script. update-skills.sh reads the version from the toml file, checks out the submodule to the corresponding tag, diffs the documentation changes, and invokes Claude CLI to update the skill files.

Why This Works Well

Docs as data source. Instead of manually copying documentation into prompts, you reference the official repo directly. Submodules ensure you're working with first-party content, no second-hand drift.

Traceable. You can verify exactly which version a skill file corresponds to. When it's outdated, run the script to update — no need to manually review changelogs.

Extensible. Adding skills for another framework is straightforward: add a submodule, write a few markdown files, reference them in AGENTS.md.

Limitations

antfu's approach is centered around the frontend ecosystem (Vue/Vite/Nuxt), with skill installation via pnpm — not directly applicable to other tech stacks. My adapted version is simpler — submodule + hand-written skill files + shell script, without the meta.ts and vendor sync machinery. But for the scenario of "a project using two or three frameworks that AI doesn't know well," it gets the job done.

Skill file quality matters a lot. Too long and the AI may not read it all; too short and you miss critical APIs. I currently keep each file under 200 lines, split by topic (core / injection / aggregation / scopes / multiplatform / viewmodels). In practice, Claude Code has been able to find and reference the right files on demand.

Automated AI Workflow - We Localized Popular Documentation for the Community

2025-04-10T00:00:00Z

Recently, together with community partners, I built a site called Open AIDoc. It's a public welfare project powered by Gemini, aimed at tracking and translating popular open-source library documentation into Simplified/Traditional Chinese, Japanese, Korean, and multiple other languages. In today's v0.1.0 release, we've provided synchronized translations of the latest Kotlin and Koin documentation. Plans already include expanding to SqlDelight, Ktor, and other libraries we're familiar with, and continuously adding documentation translation sync services for different domains in the future.

The story began when I was helping Koin build a Chinese community recently, and found that some new members' first question was "Is there Chinese documentation?" This piqued my interest, and soon I found similar questions in some Kotlin community groups. I tried to understand the demand for localized documentation in the AI era, because I know quite a few browser plugins can already achieve high-quality translation. But digging deeper, I found this might still be a widespread problem, especially for novice engineers in East Asia. On one hand, East Asia overall has relatively strong language systems of their own. Although English learning has been added to compulsory education in most regions, there are numerous native language materials in the programming field, and many developers still prefer native language materials. On the other hand, just because browser plugins exist doesn't mean everyone uses them. AI development is still in its early stages. Documentation is a webpage that gets repeatedly viewed, and having to wait a few seconds for translation each time, plus repeatedly spending credits for this, is indeed not a great scenario.

Since this is the case, why not solve the several documentation problems I've encountered around me at once using AI? The generated content is stored on a site for repeated reading, which is very eco-friendly :) So I found a like-minded partner, zhuoxuan, to start pushing forward. Of course, we soon discovered things were a bit more troublesome than expected — we needed to add some sync update and format conversion steps. So we built a workflow that roughly looks like:

The biggest advantage of choosing Gemini 2.0 Flash is that it's fast and affordable. Even with room for prompt optimization, it already shows good translation results. Following the principle of "talk about completion before perfection," we went live with the v0.1.0 you see now in about a week.

Although it still has some issues, such as:

A small number of very long files have the very last bit truncated, limited by gemini 2.0 flash --> will switch to 2.5 pro later
A small number of custom formats are difficult to make compatible with the docusaurus engine using regex replacement, currently manually fixed a few --> will switch to vitepress/next.js which is more flexible and tolerant later
All heading links (with # signs) are broken because names don't match at all after translation --> still looking for solutions
Regex replacement scripts can't guarantee that all parts work properly after replacement --> need to optimize scripts or use other libraries to assist (via AST or similar)

But overall we've achieved the goal we wanted from the start: first solve the problems around us, then slowly upgrade and iterate. At the same time, we're also collecting community feedback:

Which documentation is English-only, or has outdated Chinese versions — we'll prioritize the high-demand ones;
Which Prompts aren't well-written — organize contribution guidelines for everyone to submit PRs to help fix together;

Additionally: Gemini costs are currently paid personally. Thanks here to the Google Developer Program Premium Membership (including GCP Credits) gifted by the Google Developer Expert program. It's natural to give back these Credits to the community. After the Credits expire, we'll consider other methods. Website deployment costs including domain, servers, and traffic will be sponsored by my personal consulting and solutions company BinaryTape.

Since it's a public welfare project, we can't guarantee time to do too much documentation adaptation. We hope more like-minded partners will join to build together. Everyone is also welcome to share, like, and forward more, so more developers can enjoy the latest localized documentation services and get updates on documentation changes.

Website: openaidoc.org

Four Ways to Optimize SDK Initialization Callbacks in Kotlin

2025-01-02T00:00:00Z

In Android development, we often need to carefully handle the initialization and callbacks of various SDKs, especially when asynchronous operations are involved. In this article, we'll discuss four ways to optimize these callbacks in Kotlin, primarily using several of Google's Android SDKs as examples like Firebase, AdMob, etc.

Problems with the Traditional Callback Mechanism

First, let's revisit the traditional callback mechanism. In Java, callback functions are commonly used to handle the results of asynchronous tasks, but this method has several drawbacks:

Poor code readability: Excessive callback nesting can easily lead to "callback hell."
Complex state management: Manually maintaining initialization states increases code complexity.
Inability to await: It's impossible to await for initialization to complete when calling methods; polling or blocking are the only options.

In Kotlin, although we have powerful tools like coroutines, callback issues still exist due to the need to maintain compatibility with a large amount of Java code and legacy projects. Taking Google's SDKs as an example, although some have provided KTX extension packages, they have not optimized the initialization process.

Four Optimization Methods

1. Using `AtomicBoolean` to Simply Record State

The most straightforward method is to use an AtomicBoolean to record whether the SDK has been successfully initialized.

private val sdkInitialized = AtomicBoolean(false)

MobileAds.initialize(context) { result: InitializationStatus ->
    // Check if all adapters are ready
    sdkInitialized.set(result.adapterStatusMap.values.any {
        it.initializationState == AdapterStatus.State.READY
    })
}

The issue is: This method requires manually checking sdkInitialized every time you call other SDK methods; it cannot await for initialization to complete (while yield the CPU resources).

Example:

fun prepareNextRewardedAd() {
    if (sdkInitialized.get()) {
        // Proceed with normal initialization
    } else {
        // Show error message
    }
}

Pros and Cons

Pros:
- Simple to implement, suitable for situations where the initialization process is short.
- Thread-safe, avoiding concurrency issues.
Cons:
- Requires manual state checks wherever the SDK is used, increasing code redundancy.
- Cannot await for initialization to complete, which may cause some functions to be unavailable when needed.

2. Using `CompletableDeferred` to Await

CompletableDeferred allows us to suspend a coroutine until a task is completed, making it ideal for scenarios where we need to wait for SDK initialization.

private val isSDKInitialized = CompletableDeferred<Unit>()

billingClient.startConnection(object : BillingClientStateListener {
    override fun onBillingSetupFinished(billingResult: BillingResult) {
        if (billingResult.responseCode == BillingClient.BillingResponseCode.OK) {
            // Initialization successful
        } else {
            // Initialization failed
        }
        // Mark as complete regardless of success or failure to avoid the coroutine being suspended indefinitely
        isSDKInitialized.complete(Unit)
    }

    override fun onBillingServiceDisconnected() {
        // You can attempt to reconnect
    }
})

Usage:

suspend fun queryMerchandise(...) = withContext(Dispatchers.IO) {
    // Wait for initialization to complete
    isSDKInitialized.await()

    billingClient.queryProductDetails(...)
}

Pros and Cons

Pros:
- Can await for initialization to complete, making the code more concise.
- Avoids the need for manual state checks, improving code readability.
Cons:
- If initialization never completes, the coroutine will remain suspended, so you need to handle timeouts and other potential issues.

3. Using `Channel` to Handle Producer-Consumer

When you need to handle a callback result in a single producer-consumer scenario, Channel is a good choice.

Example: Loading a rewarded ad from AdMob SDK

private val rewardedAdChannel = Channel<RewardedAd?>(1)

...
RewardedAd.load(
    activity,
    adUnitId,
    adRequest,
    object : RewardedAdLoadCallback() {
        override fun onAdLoaded(ad: RewardedAd) {
            rewardedAdChannel.trySend(ad).isSuccess
        }

        override fun onAdFailedToLoad(adError: LoadAdError) {
            rewardedAdChannel.trySend(null).isSuccess
        }
    }
)

Usage:

suspend fun showSingleRewardedAd(activity: Activity) {
    // Wait for the ad to load
    val ad = rewardedAdChannel.receive()

    if (ad != null) {
        ad.show(activity) { rewardItem ->
            // Handle reward logic
        }
    } else {
        // Handle loading failure
    }
}

Pros and Cons

Pros:
- Suitable for handling one-time or continuous producer-consumer single result, avoiding callback nesting.
Cons:
- Requires manual management of the Channel lifecycle to prevent memory leaks.
- If there are no consumers, the Channel may block; you need to set an appropriate capacity or handle timeouts.

4. Using `SharedFlow` to Handle Recurring Events

When you need to handle multiple initializations or state updates, SharedFlow is very suitable.

Example: Suppose we have a network status change that needs to be monitored multiple times

private val networkStatusFlow = MutableSharedFlow<NetworkStatus>(replay = 1)

fun startNetworkMonitoring() {
    networkMonitor.setOnNetworkStatusChangedListener { status ->
        networkStatusFlow.tryEmit(status)
    }
}

Usage:

fun observeNetworkStatus() {
    lifecycleScope.launch {
        networkStatusFlow.collect { status ->
            when (status) {
                NetworkStatus.Available -> // Network is available
                NetworkStatus.Unavailable -> // Network is unavailable
            }
        }
    }
}

Pros and Cons

Pros:
- Suitable for scenarios where events need to be sent and received multiple times.
- Subscribers can share the same data source, avoiding redundant work.
Cons:
- Need to pay attention to backpressure strategies to prevent event backlog.
- Requires manual management of subscriptions and cancellations to avoid memory leaks.

Conclusion

Depending on your specific needs, you can choose different methods to optimize callback handling:

Single use, single initialization: Use AtomicBoolean for simple initialization state recording.
Multiple uses, single initialization: Use CompletableDeferred when you need to wait for initialization to complete within coroutines.
Single use, multiple initializations: Use Channel for one-time result callbacks, such as ad loading.
Multiple uses, multiple initializations: Use SharedFlow when you need to monitor multiple state updates.

I hope this article provides some insights into handling SDK initialization callbacks. When you encounter similar issues in the future, you can try choosing the most suitable method to improve your code's readability and maintainability.

Adapting MediaPipe Demos for Kotlin Multiplatform: Object Detection

2024-10-04T00:00:00Z

Following our previous exploration of porting Mediapipe's LLM Inference, this article delves into migrating the Object Detection Demo. By reading this, you'll learn:

How to port Mediapipe's official Object Detection Android Demo to Kotlin Multiplatform (KMP), enabling it to run on iOS. Project link: https://github.com/2BAB/MediaPiper/tree/object-detection
Integrating Compose Multiplatform with iOS native controls (Camera Preview), including handling permission requests.
Tips for injecting iOS controls using dependency injection in KMP (based on Koin).
An introduction to the two Object Detection algorithms used in the Demo.

Object Detection Android Sample

First, let's examine the original Object Detection project. You'll notice that the Android portion includes both an android.view.View implementation and a Jetpack Compose version. Following our previous approach, we'll directly port the Jetpack Compose version to KMP.

Upon closer inspection, you'll find that this app is more complex. In the LLM Inference example, the SDK only provided text inference interfaces, which we could easily wrap in Kotlin to abstract platform-specific details (though we ultimately used an alternative due to some cinterop support issues). The UI was entirely reusable. However, Object Detection is based on real-time image processing and includes three modes in the demo: real-time camera detection, local video detection, and local image detection. Camera preview typically relies heavily on platform-specific implementations, and players rarely use custom rendering (i.e., they use native platform solutions).

In summary, from the outset, we need to reserve parts that are challenging to implement with Compose Multiplatform (CMP) (such as the CameraView shown above) and abstract them into separate expect Composable functions for each platform to implement individually. To simplify the learning process and reduce the demo's scale, we'll focus solely on implementing the CameraView component, leaving the Gallery (Video + Image) sections for you to explore. In essence, once you grasp how to embed a Camera Preview, you can implement the other two parts similarly, including Compose and UIKit interactions and iOS permission requests.

By cross-referencing the iOS version of the demo, we've broken down the UI layers related to CameraView into four components, as illustrated above:

The Camera Preview layer must be implemented separately on each platform.
The ResultOverlay, which draws bounding boxes and other results, could be implemented in the common layer. However, due to complexities like matching the overlay with the Camera Preview (since the preview size can vary depending on the camera's aspect ratio) and coordinate transformations, we'll delegate this component to platform-specific implementations in this demo.
The Scaffold and Inference Time Label will be implemented in the common layer.

Migration Process

Porting the Main UI and Data Structures

Building on the foundation from the previous section, we'll add a new folder named objectdetection to the Mediapiper project. With our prior experience, we realize that much of the UI content isn't overly complex—except for the focal point of this section, the camera preview interface. Therefore, we can proceed by migrating all files except for camera and gallery:

The necessary modifications can be categorized into two areas:

Data and Logic:
- Extract the ObjectDetectionResult declarations from original SDKs and create a common version as a data class. This allows both SDKs to convert their results into the common version, facilitating the display of inference time, unified logging, and even paving the way to potentially move ResultOverlay to the common layer in the future.
- Move utility classes and default value enumerations to the common layer with minimal changes—mainly replacing references to the inference result classes with the common version.
UI Components:
- Make uniform changes similar to the previous section, such as replacing R references with Res, adopting the unified theme, and adjusting some import packages.
- Notably, this demo doesn't use the CMP version of Navigation, so switching between the Home and Option pages is handled with a simple if...else... at the top level.

At this point, we can run an application that doesn't include camera functionality. The images below demonstrate how these CMP codes run on iOS across two pages.

Integrating CameraView Functionality

As previously analyzed, we need to extract the CameraView component for native implementation. Therefore, in the common CameraView, we'll use two expect Composable functions: CameraPermissionControl and CameraPreview:

@Composable
fun CameraView(
    threshold: Float,
    maxResults: Int,
    delegate: Int,
    mlModel: Int,
    setInferenceTime: (newInferenceTime: Int) -> Unit,
) {
    CameraPermissionControl {
        CameraPreview(
            threshold,
            maxResults,
            delegate,
            mlModel,
            setInferenceTime,
            onDetectionResultUpdate = { detectionResults ->
                // ...
            }
        )
    }
}

@Composable
expect fun CameraPermissionControl(PermissionGrantedContent: @Composable @UiComposable () -> Unit)

@Composable
expect fun CameraPreview(
    threshold: Float,
    maxResults: Int,
    delegate: Int,
    mlModel: Int,
    setInferenceTime: (newInferenceTime: Int) -> Unit,
    onDetectionResultUpdate: (result: ObjectDetectionResult) -> Unit
)

Android Implementation

The Android side is straightforward—we can directly copy the original Jetpack Compose code:

// Android implementation
@OptIn(ExperimentalPermissionsApi::class)
@Composable
actual fun CameraPermissionControl(
    PermissionGrantedContent: @Composable @UiComposable () -> Unit
) {
    val storagePermissionState: PermissionState =
        rememberPermissionState(Manifest.permission.CAMERA)
    LaunchedEffect(key1 = Unit) {
        if (!storagePermissionState.hasPermission) {
            storagePermissionState.launchPermissionRequest()
        }
    }

    if (!storagePermissionState.hasPermission) {
        Text(text = "No Storage Permission!")
    } else {
        PermissionGrantedContent()
    }
}

@Composable
actual fun CameraPreview(...) {
    // Define properties

    DisposableEffect(Unit) {
        onDispose {
            active = false
            cameraProviderFuture.get().unbindAll()
        }
    }

    // Describe the UI of this camera view
    BoxWithConstraints {
        val cameraPreviewSize = getFittedBoxSize(
            containerSize = Size(
                width = this.maxWidth.value,
                height = this.maxHeight.value,
            ),
            boxSize = Size(
                width = frameWidth.toFloat(),
                height = frameHeight.toFloat()
            )
        )

        Box(
            Modifier
                .width(cameraPreviewSize.width.dp)
                .height(cameraPreviewSize.height.dp)
        ) {
            // Use AndroidView to integrate CameraX, as there's no prebuilt composable in Jetpack Compose
            AndroidView(
                factory = { ctx ->
                    val previewView = PreviewView(ctx)
                    val executor = ContextCompat.getMainExecutor(ctx)
                    cameraProviderFuture.addListener({
                        val cameraProvider = cameraProviderFuture.get()
                        val preview = Preview.Builder().build().also {
                            it.setSurfaceProvider(previewView.surfaceProvider)
                        }

                        val cameraSelector = CameraSelector.Builder()
                            .requireLensFacing(CameraSelector.LENS_FACING_BACK)
                            .build()

                        // Instantiate an image analyzer for frame transformations before object detection
                        val imageAnalyzer = ImageAnalysis.Builder()
                            .setTargetAspectRatio(AspectRatio.RATIO_4_3)
                            .setBackpressureStrategy(ImageAnalysis.STRATEGY_KEEP_ONLY_LATEST)
                            .setOutputImageFormat(ImageAnalysis.OUTPUT_IMAGE_FORMAT_RGBA_8888)
                            .build()

                        // Execute object detection in a new thread
                        val backgroundExecutor = Executors.newSingleThreadExecutor()

                        backgroundExecutor.execute {
                            // Use ObjectDetectorHelper to abstract Mediapipe specifics
                            val objectDetectorHelper = AndroidObjectDetector(
                                context = ctx,
                                threshold = threshold,
                                currentDelegate = delegate,
                                currentModel = mlModel,
                                maxResults = maxResults,
                                objectDetectorListener = ObjectDetectorListener(
                                    onErrorCallback = { _, _ -> },
                                    onResultsCallback = {
                                        // Set frame dimensions upon receiving results
                                        frameHeight = it.inputImageHeight
                                        frameWidth = it.inputImageWidth

                                        // Update results and inference time if the view is active
                                        if (active) {
                                            results = it.results.first()
                                            setInferenceTime(it.inferenceTime.toInt())
                                        }
                                    }
                                ),
                                runningMode = RunningMode.LIVE_STREAM
                            )

                            // Set the analyzer and start detecting objects from the live stream
                            imageAnalyzer.setAnalyzer(
                                backgroundExecutor,
                                objectDetectorHelper::detectLivestreamFrame
                            )
                        }

                        // Unbind any currently open camera and bind our own
                        cameraProvider.unbindAll()
                        cameraProvider.bindToLifecycle(
                            lifecycleOwner,
                            cameraSelector,
                            imageAnalyzer,
                            preview
                        )
                    }, executor)
                    // Return the preview view from the AndroidView factory
                    previewView
                },
                modifier = Modifier.fillMaxSize()
            )

            // Display the results overlay if there are current results
            results?.let {
                ResultsOverlay(
                    results = it,
                    frameWidth = frameWidth,
                    frameHeight = frameHeight
                )
            }
        }
    }
}

iOS Implementation

The iOS side requires a bit more effort. For camera permission control, we'll directly call iOS's platform.AVFoundation APIs within this Composable function, asynchronously request permissions, and display appropriate messages based on the result—loading, failure, or success, where we show the camera preview. You'll notice that our iOS implementation is quite comprehensive, covering all three scenarios.

import platform.AVFoundation.*
import kotlin.coroutines.resume
import kotlin.coroutines.suspendCoroutine

@Composable
actual fun CameraPermissionControl(PermissionGrantedContent: @Composable @UiComposable () -> Unit) {
    var hasCameraPermission by remember { mutableStateOf<Boolean?>(null) }

    LaunchedEffect(Unit) {
        hasCameraPermission = requestCameraAccess()
    }

    when (hasCameraPermission) {
        true -> {
            PermissionGrantedContent()
        }
        false -> {
            Text("Camera permission denied. Please grant access from settings.")
        }
        null -> {
            Text("Requesting camera permission...")
        }
    }
}

private suspend fun requestCameraAccess(): Boolean = suspendCoroutine { continuation ->
    val authorizationStatus = AVCaptureDevice.authorizationStatusForMediaType(AVMediaTypeVideo)

    when (authorizationStatus) {
        AVAuthorizationStatusNotDetermined -> {
            AVCaptureDevice.requestAccessForMediaType(AVMediaTypeVideo) { granted ->
                continuation.resume(granted)
            }
        }
        AVAuthorizationStatusRestricted, AVAuthorizationStatusDenied -> {
            continuation.resume(false)
        }
        AVAuthorizationStatusAuthorized -> {
            continuation.resume(true)
        }
        else -> {
            continuation.resume(false)
        }
    }
}

Now, let's tackle the core camera preview functionality. According to the CMP documentation, we can embed a UIKit view within a Composable function using UIKitView:

// Example 1
UIKitView(
    factory = { MKMapView() },
    modifier = Modifier.size(300.dp),
)

// Example 2
@OptIn(ExperimentalForeignApi::class)
@Composable
fun UseUITextField(modifier: Modifier = Modifier) {
    var message by remember { mutableStateOf("Hello, World!") }
    UIKitView(
        factory = {
            val textField = object : UITextField(CGRectMake(0.0, 0.0, 0.0, 0.0)) {
                @ObjCAction
                fun editingChanged() {
                    message = text ?: ""
                }
            }
            textField.addTarget(
                target = textField,
                action = NSSelectorFromString(textField::editingChanged.name),
                forControlEvents = UIControlEventEditingChanged
            )
            textField
        },
        modifier = modifier.fillMaxWidth().height(30.dp),
        update = { textField ->
            textField.text = message
        }
    )
}

These examples applied some default iOS components, not custom ones. The corresponding reference headers are already converted to Kotlin by JetBrains, such as platform.UIKit.UITextField, which can be directly imported into the KMP project's iOS target.

In our case, we want to reuse a custom CameraPreview view with recognition capabilities. However, the app.framework produced by KMP is a shared layer upon which the iOS native code depends. Due to the dependency hierarchy, we can't directly call CameraPreview defined in the iOS app's source code. There are generally two solutions:

Package the relevant code into a separate module, producing cameraview.framework, which the KMP's app can depend on.
When initializing app.framework in the iOS app, pass a lambda that initializes and returns a UIView to app.

We'll opt for the second solution, defining IOSCameraPreviewCreator as the protocol for interaction between the two sides.

// Definition
typealias IOSCameraPreviewCreator = (
    threshold: Float,
    maxResults: Int,
    delegate: Int,
    mlModel: Int,
    setInferenceTime: (newInferenceTime: Int) -> Unit,
    callback: IOSCameraPreviewCallback
) -> UIView

typealias IOSCameraPreviewCallback = (result: ObjectDetectionResult) -> Unit

// Inject the implementation from the iOS side during startup and add it to Koin's definitions
fun onStartup(iosCameraPreviewCreator: IOSCameraPreviewCreator) {
    Startup.run { koinApp ->
        koinApp.apply {
            modules(module {
                single { LLMOperatorFactory() }
                single<IOSCameraPreviewCreator> { iosCameraPreviewCreator }
            })
        }
    }
}

// In the implementation of CameraPreview, 
// we inject and invoke this function to obtain a UIView instance
import androidx.compose.ui.viewinterop.UIKitView
import platform.UIKit.UIView

@Composable
actual fun CameraPreview(
    threshold: Float,
    maxResults: Int,
    delegate: Int,
    mlModel: Int,
    setInferenceTime: (newInferenceTime: Int) -> Unit,
    onDetectionResultUpdate: (result: ObjectDetectionResult) -> Unit,
) {
    val iOSCameraPreviewCreator = koinInject<IOSCameraPreviewCreator>()
    // Similar to how Android integrates the native Camera View
    UIKitView(
        factory = {
            val iosCameraPreview: UIView = iOSCameraPreviewCreator(
                threshold,
                maxResults,
                delegate,
                mlModel,
                setInferenceTime,
                onDetectionResultUpdate
            )
            iosCameraPreview
        },
        modifier = Modifier.fillMaxSize(),
        update = { _ -> }
    )
}

The above code leverages Koin for dependency injection, simplifying the interaction process. Now, let's follow the injection of startup parameters to check the iOS side.

MainKt.onStartup(iosCameraPreviewCreator: { threshold, maxResults, delegate, mlModel, onInferenceTimeUpdate, resultCallback in
    return IOSCameraView(
        frame: CGRectMake(0, 0, 0, 0),
        modelName: Int(truncating: mlModel) == 0 ? "EfficientDet-Lite0" : "EfficientDet-Lite2",
        maxResults: Int(truncating: maxResults),
        scoreThreshold: Float(truncating: threshold),
        onInferenceTimeUpdate: onInferenceTimeUpdate,
        resultCallback: resultCallback
    )
})

The IOSCameraView here is essentially the CameraViewController from the original iOS demo. We've modified some initialization and lifecycle content and simplified parameter change listeners to highlight the core migration aspects:

Lifecycle Handling: ViewController uses methods like viewDidLoad, while UIView uses didMoveToWindow to handle logic when the view is added or removed. ViewController initializes through its lifecycle, whereas UIView provides custom initializers to pass in models and detection parameters.
Subview Setup: ViewController uses @IBOutlet and Interface Builder, while UIView directly creates and adds subviews via a setupView method, manually setting constraints with AutoLayout and handling tap events.
Callbacks and Delegates: ViewController uses delegates, while UIView adds closure callbacks like onInferenceTimeUpdate and resultCallback. These are passed during initialization and set up for type conversion, facilitating callbacks to the KMP layer.

We also retain OverlayView, CameraFeedService, ObjectDetectorService, and parts of DefaultConstants, without modifying their code. Notably, ObjectDetectorService encapsulates the Object Detection SDK. If you examine its API calls, you'll find it's closely coupled with iOS's Camera APIs (like CMSampleBuffer), indicating the difficulty of abstracting it into the common layer.

With this, we can run the camera preview with Object Detection on iOS.

Simple Testing

The above GIF showcases the performance of EfficientDet-Lite0 running in CPU mode on an iPhone 13 mini. In official tests using the Pixel 6's CPU/GPU, switching to GPU execution can slightly improve performance. It's evident that the real-time performance is sufficient for production environments, and the accuracy is acceptable.

The demo comes with two optional models:

EfficientDet-Lite0: Uses 320x320 input, balancing latency and accuracy, suitable for lightweight applications. The demo includes its float32 version by default.
EfficientDet-Lite2: Uses 448x448 input, offering higher accuracy at the cost of speed, suitable for scenarios demanding greater precision. The demo includes its float32 version by default.

Both models are trained on a dataset containing 1.5 million instances and 80 object labels.

Summary

Traditional ML models on mobile devices are relatively mature and can handle many specific scenarios. The two models discussed are only 13–25 MB in size. Compared to LLM models that are often over 1 GB, these models are much more practical for deployment.
Embedding UIKit views within Compose Multiplatform allows us to address high-performance needs that require native APIs and hardware.
We kept ResultOverlay in the common layer, and the iOS side set up result callbacks to the KMP layer. However, on iOS, we still used native views for implementation due to the cost of migration. In real-world scenarios, we can further consider:
- If the business scenario is simple, such as rectangle recognition with a full-screen camera preview, we can easily reuse ResultOverlay at the Compose layer.
- For complex business scenarios, like facial recognition with sticker selection and rendering during video chats, the high complexity of the business logic makes reusing the same StickerOverlay highly valuable. In this case, regardless of the camera preview size, the cost of adaptation becomes acceptable. Moreover, there's potential for optimization in calculations within StickerOverlay, such as using sampled calculations and interpolated animations.
Complex dependency management scenarios, including UI view injection, can be simplified using dependency injection frameworks like Koin.

Adapting MediaPipe Demos for Kotlin Multiplatform: LLM Inference

2024-09-01T00:00:00Z

By reading this post, you'll learn about:

Porting the MediaPipe "LLM Inference" Android demo to Kotlin Multiplatform (KMP) to support iOS. Project repository: https://github.com/2BAB/mediapiper
Two common ways of calling iOS SDKs in KMP:
1. Directly invoking third-party libraries added via Cocoapods in Kotlin.
2. Calling third-party libraries from the iOS project in Kotlin.
Tips for dependency injection in KMP across platforms (based on Koin).
A brief background on On-Device Models and the Gemma 1's 2B LLM model.

On-Device Model

Large Language Models (LLMs) have been a hot topic for quite some time, and this year, the trend has reached mobile devices. Companies like Google have deeply integrated on-device model functionalities into their latest smartphones and operating systems. Google's current public strategy regarding On-Device Models involves two main types of LLMs:

Gemini Nano: Not open source, limited support for specific devices (some are accelerated by specific chips like Tensor G4), and demonstrates extremely strong performance. It's currently available on desktop platforms (Chrome) and some Android phones (Pixel 8/9 and Samsung S23/24, etc.). It will be available to more developers later for use and testing.
Gemma: Open source and supports all devices that meet the minimum requirements, with impressive performance as well. It uses the similar technology as Nano for training with primarily-English data from web documents, mathematics, and code. It can be experienced on multiple platforms (Android/iOS/Desktop). The MediaPipe adaptation for Gemma2 will also be available soon according to the announcement.

Since most developers do not yet have access to Gemini Nano, our focus today is on the 2B version of Gemma 1. To use Gemma directly on mobile platforms, Google has provided an out-of-the-box tool: MediaPipe. MediaPipe is a cross-platform framework that packages a series of pre-built on-device machine learning models and tools, supporting tasks like real-time gesture recognition, face detection, and more. It can also be used in applications like image generation and chatbots. For those interested, you can try the web version demo and explore the relevant documentation.

Among its features, the LLM Inference API (first row in the table above) is a component for running large language model inferences, supporting models like Gemma 2B/7B, Phi-2, Falcon-RW-1B, StableLM-3B, and more. Pre-converted models for Gemma (based on TensorFlow Lite) can be downloaded from Kaggle here and loaded into MediaPipe later.

LLM Inference Android Sample

The official LLM Inference Demo from MediaPipe includes support for Android, iOS, and Web platforms.

Opening the Android repository reveals several characteristics:

Pure Kotlin implementation.
The UI is implemented entirely with Jetpack Compose.
The LLM Task SDK it depends on is highly encapsulated, exposing only three methods.

Now, let's check out the iOS version:

The UI is implemented with SwiftUI, performing the same tasks as Compose but with some simplified elements (e.g., no top bar or send button).
The LLM Task SDK it relies on is also highly encapsulated, exposing the same three methods.

This led to an interesting idea: The Android version has a foundation that allows it to be ported to iOS. Porting would make the code on both platforms highly consistent, reducing maintenance costs, with the core implementation only requiring a bridge to the LLM Inference SDK on iOS.

Kotlin Multiplatform

The technology used for the porting project is called Kotlin Multiplatform (KMP), developed by the Kotlin team to support cross-platform development. KMP allows developers to use the same codebase to build applications for Android, iOS, Web, and other platforms. By sharing business logic code, KMP can significantly reduce development time and maintenance costs while preserving native performance and experience for each platform. At this year’s I/O conference, Google also announced first-class support for KMP, migrating some Android libraries and tools to the multiplatform, enabling KMP developers to use it conveniently on iOS and other platforms.

Although MediaPipe supports multiple platforms, this time we mainly focus on Android and iOS.

Porting Process

Initialization

Start by creating a basic KMP project using IntelliJ IDEA or Android Studio. You can use the KMP Wizard or templates from third-party KMP apps. If you're unfamiliar with KMP, you'll find its structure is quite similar to an Android project, except this time, we place the iOS container project in the root directory and configure iOS dependencies in the app module's build.gradle.kts with the KMP Gradle Plugin.

Wrapping and Calling LLM Inference

In commonMain, we abstract a simple interface based on the characteristics of the MediaPipe LLM Task SDK, written in Kotlin to cater to both Android and iOS. This interface replaces the InferenceModel.kt class in the original repository.

// app/src/commonMain/.../llm/LLMOperator
interface LLMOperator {

    /**
     * To load the model into the current context.
     * @return 1. null if successful, 2. an error message if failed.
     */
    suspend fun initModel(): String?

    /**
     * To calculate the token size of a string.
     */
    fun sizeInTokens(text: String): Int

    /**
     * To generate response for a given inputText in a synchronous way.
     */
    suspend fun generateResponse(inputText: String): String

    /**
     * To generate response for a given inputText in an asynchronous way.
     * @return A flow with partial response in String and completion flag in Boolean.
     */
    suspend fun generateResponseAsync(inputText: String): Flow<Pair<String, Boolean>>

}

On Android, since the LLM Task SDK was originally implemented in Kotlin, aside from initializing the model file, most of the functionality is essentially a proxy for the original SDK.

class LLMInferenceAndroidImpl(private val ctx: Context): LLMOperator {

    private lateinit var llmInference: LlmInference
    private val initialized = AtomicBoolean(false)
    private val partialResultsFlow = MutableSharedFlow<Pair<String, Boolean>>(...)

    override suspend fun initModel(): String? {
        if (initialized.get()) {
            return null
        }
        return try {
            val modelPath = ...
            if (File(modelPath).exists().not()) {
                return "Model not found at path: $modelPath"
            }
            loadModel(modelPath)
            initialized.set(true)
            null
        } catch (e: Exception) {
            e.message
        }
    }
    private fun loadModel(modelPath: String) {
        val options = LlmInference.LlmInferenceOptions.builder()
            .setModelPath(modelPath)
            .setMaxTokens(1024)
            .setResultListener { partialResult, done ->
                // Transforming the listener to flow,
                // making it easy on UI integration.
                partialResultsFlow.tryEmit(partialResult to done)
            }
            .build()

        llmInference = LlmInference.createFromOptions(ctx, options)
    }

    override fun sizeInTokens(text: String): Int = llmInference.sizeInTokens(text)

    override suspend fun generateResponse(inputText: String): String {
        ...
        return llmInference.generateResponse(inputText)
    }

    override suspend fun generateResponseAsync(inputText: String): Flow<Pair<String, Boolean>> {
        ...
        llmInference.generateResponseAsync(inputText)
        return partialResultsFlow.asSharedFlow()
    }

}

For iOS, we first attempt the direct invocation of libraries added via Cocoapods. In the app module, include the Cocoapods plugin and add the MediaPipe LLM Task library:

// app/build.gradle.kts
plugins {
    ...
    alias(libs.plugins.cocoapods)
}
cocoapods {
    ...
    ios.deploymentTarget = "15"

    pod("MediaPipeTasksGenAIC") {
        version = "0.10.14"
        extraOpts += listOf("-compiler-option", "-fmodules")
    }
    pod("MediaPipeTasksGenAI") {
        version = "0.10.14"
        extraOpts += listOf("-compiler-option", "-fmodules")
    }
}

Note the addition of the -fmodules compiler option in the above configuration to generate Kotlin references correctly (reference link).

Some Objective-C libraries, specifically those that serve as wrappers for Swift libraries, have @import directives in their headers. By default, cinterop doesn't provide support for these directives. To enable support for @import directives, specify the -fmodules option in the configuration block of the pod() function.

Afterward, in iosMain, you can directly import the relevant library code and replicate the Android proxy approach:

// Note these imports start with cocoapods
import cocoapods.MediaPipeTasksGenAI.MPPLLMInference
import cocoapods.MediaPipeTasksGenAI.MPPLLMInferenceOptions
import platform.Foundation.NSBundle
...
class LLMOperatorIOSImpl: LLMOperator {

    private val inference: MPPLLMInference
    
        init {
        val modelPath = NSBundle.mainBundle.pathForResource(..., "bin")

        val options = MPPLLMInferenceOptions(modelPath!!)
        options.setModelPath(modelPath!!)
        options.setMaxTokens(2048)
        options.setTopk(40)
        options.setTemperature(0.8f)
        options.setRandomSeed(102)

        // NPE was thrown here right after it printed the success initialization message internally.
        inference = MPPLLMInference(options, null) 
    }

    override fun generateResponse(inputText: String): String {...}
    override fun generateResponseAsync(inputText: String, ...) :... {
        ...
    }
    ...
}

However, we weren't as lucky this time. An NPE was thrown immediately after MPPLLMInference finished initializing. The likely issue is that since Kotlin's current interop target is Objective-C, the MPPLLMInference constructor has an extra error parameter compared to the Swift version, to which we passed null.

constructor(
  options: cocoapods.MediaPipeTasksGenAI.MPPLLMInferenceOptions, 
  error: CPointer<ObjCObjectVar<platform.Foundation.NSError?>>?)

Various attempts with different pointer inputs did not solve the problem:

// One of the attempts
memScoped {
    val pp: CPointerVar<ObjCObjectVar<NSError?>> = allocPointerTo()
    val inference = MPPLLMInference(options, pp.value)
    Napier.i(pp.value.toString())
}

Thus, we had to adopt a different approach: calling the third-party library from the iOS project.

// 1. Declare an interface similar to LLMOperator for easier iOS SDK adaptation.
// app/src/iosMain/.../llm/LLMOperator.kt
interface LLMOperatorSwift {
    suspend fun loadModel(modelName: String)
    fun sizeInTokens(text: String): Int
    suspend fun generateResponse(inputText: String): String
    suspend fun generateResponseAsync(
        inputText: String,
        progress: (partialResponse: String) -> Unit,
        completion: (completeResponse: String) -> Unit
    )
}

// 2. Implement this interface in the iOS project
// iosApp/iosApp/LLMInferenceDelegate.swift
class LLMOperatorSwiftImpl: LLMOperatorSwift {
    ...
    var llmInference: LlmInference?
    
    func loadModel(modelName: String) async throws {
        let path = Bundle.main.path(forResource: modelName, ofType: "bin")!
        let llmOptions =  LlmInference.Options(modelPath: path)
        llmOptions.maxTokens = 4096
        llmOptions.temperature = 0.9
        
        llmInference = try LlmInference(options: llmOptions)
    }
    
    func generateResponse(inputText: String) async throws -> String {
        return try llmInference!.generateResponse(inputText: inputText)
    }
    
    func generateResponseAsync(inputText: String, progress: @escaping (String) -> Void, completion: @escaping (String) -> Void) async throws {
        try llmInference!.generateResponseAsync(inputText: inputText) { partialResponse, error in
            // progress
            if let e = error {
                print("\(self.errorTag) \(e)")
                completion(e.localizedDescription)
                return
            }
            if let partial = partialResponse {
                progress(partial)
            }
        } completion: {
            completion("")
        }
    }
    ...    
}

// 3. iOS then passes back the delegated (initialization-focused) object to Kotlin
// iosApp/iosApp/iosApp.swift
class AppDelegate: UIResponder, UIApplicationDelegate {
    ...
    func application(）{
        ...
        let delegate = try LLMOperatorSwiftImpl()
        MainKt.onStartup(llmInferenceDelegate: delegate)        
    }
}

// 4. The initial implementation object for iOS in KMP 
//  are directly delegated to it (injected via constructor)
class LLMOperatorIOSImpl(
   private val delegate: LLMOperatorSwift) : LLMOperator {   
   ...
}

You might notice that the Impl instances on both platforms require different constructor parameters. This issue is generally resolved using KMP's expect and actual keywords. In the following code:

We take advantage of the fact that the expect class does not require constructor parameters, adding a layer of encapsulation (similar to an interface).
We use Koin to inject the necessary parameters for each platform, then uniformly inject the created interface instance into the Common layer as needed.

// Common
expect class LLMOperatorFactory {
    fun create(): LLMOperator
}
val sharedModule = module {
   // Create the LLMOperator required by the Common layer from different LLMOperatorFactory implementations
	single<LLMOperator> { get<LLMOperatorFactory>().create() }
}

// Android
actual class LLMOperatorFactory(private val context: Context){
    actual fun create(): LLMOperator = LLMInferenceAndroidImpl(context)
}
val androidModule = module {
    // Android injects the App's Context
    single { LLMOperatorFactory(androidContext()) }
}

// iOS
actual class LLMOperatorFactory(private val llmInferenceDelegate: LLMOperatorSwift) {
    actual fun create(): LLMOperator = LLMOperatorIOSImpl(llmInferenceDelegate)
}

module {
    // iOS injects the delegate passed in the onStartup function
    single { LLMOperatorFactory(llmInferenceDelegate) }
}

In summary, this case study gave us a taste of deep interaction between Kotlin and Swift. By leveraging the expect and actual keywords along with Koin's dependency injection, we made the overall solution smoother and more automated, achieving the goal of calling Android and iOS native SDKs from the Common module in KMP.

Porting UI and ViewModel

The InferenceMode in the original project has been replaced by the LLMOperator from the previous section, so we copy the remaining five classes excluding Activity:

Next, we make a few modifications to allow Jetpack Compose code to migrate easily to Compose Multiplatform.

First, the ViewModel. In the KMP version, I used Voyage, replacing it with ScreenModel. While an official ViewModel solution is also in the works, which you can refer to in this document.

// Android version
class ChatViewModel(
    private val inferenceModel: InferenceModel
) : ViewModel() {...}

// KMP version, converts ViewModel to ScreenModel and modifies the input object
class ChatViewModel(
    private val llmOperator: LLMOperator
) : ScreenModel {...}

Correspondingly, the ViewModel initialization method is also changed to the ScreenModel method:

// Android version
@Composable
internal fun ChatRoute(
    chatViewModel: ChatViewModel = viewModel(
        factory = ChatViewModel.getFactory(LocalContext.current.applicationContext)
    )
) {
    ...
    ChatScreen(...) {...}
}

// KMP version, initialized externally and passed in
@Composable
internal fun ChatRoute(
    chatViewModel: ChatViewModel
) {

// Here we use the default parameter injection solution for decoupling.
// koinInject() is a method provided by Koin for @Composable function injection in Compose.
@Composable
fun AiScreen(llmOperator:LLMOperator = koinInject()) {
    // Use the remember method from ScreenModel
    val

 chatViewModel = rememberScreenModel { ChatViewModel(llmOperator) }
    ...
    Column {
        ...
        Box(...) {
            if (showLoading) {
                ...
            } else {
                ChatRoute(chatViewModel)
            }
        }
    }
}

The corresponding LLM functionality calls within the ViewModel also need to be replaced:

// Android version
inferenceModel.generateResponseAsync(fullPrompt)
inferenceModel.partialResults
    .collectIndexed { index, (partialResult, done) ->
        ...
    }

// KMP version, moves Flow's return to the front, compatible with SDK design on both platforms
llmOperator.generateResponseAsync(fullPrompt)
    .collectIndexed { index, (partialResult, done) ->
        ...
    }

Next, adapt resource loading methods specific to Compose Multiplatform, replacing R with Res:

// Android version
Text(stringResource(R.string.chat_label))

// KMP version, this reference is mapped from xml by the plugin
// (commonMain/composeResources/values/strings.xml)
import mediapiper.app.generated.resources.chat_label
...
Text(stringResource(Res.string.chat_label))

At this point, we have completed the main UI and functionality migration of ChatScreen and ChatViewModel.

Finally, there are a few minor modifications:

For LoadingScreen, we replicate the approach of passing in LLMOperator for initialization (replacing the original InferenceModel).
ChatMessage requires only a single line API change for UUID (which won't be needed after Kotlin 2.0.20).
ChatUiState does not require any changes.
The remaining minor tweaks include changing log library and other small details.

In summary, setting aside log and R file replacing, the core changes less than 20 lines, allowing the entire UI to function as expected.

Simple Testing

So, how does the performance of Gemma 2B measure up? Let's look at some simple examples with Pixel 4a and iOS emulators. Here, we primarily test three versions of the model, defined in me.xx2bab.mediapiper.llm.LLMOperator (refer to the project README for deploying models on both platforms):

gemma-2b-it-gpu-int4
gemma-2b-it-cpu-int4
gemma-2b-it-cpu-int8

Key points to note:

it indicates an Instruction Tuned variant, better suited for conversational use because they are fine-tuned to better understand instructions and generate more relevant responses.
int4/8 refers to model quantization, which converts floating-point numbers in the model to lower-precision integers, thereby reducing the model's size and computation, making it suitable for small local devices like phones. However, the model's precision and response accuracy might decrease.
cpu and gpu refer to the target hardware platforms, allowing devices with weak or no GPUs to choose CPU execution. From the test results below, you'll find that CPU versions often outperform on current mobile devices, due to the small model size, simple computation (dialogue), and integer quantization favor CPU instruction execution.

First, we test a simple logic: "Is asparagus an animal?" As shown in the image below, the CPU version provides a more reasonable answer than both GPU versions (iOS and Android). The next test is translating the answer into Chinese, which doesn't perform well across all three attempts, but this is expected.

Next, we elevate the complexity of the question to word classification between animals and plants: both GPU and CPU versions perform well.

Raising the complexity further, asking it to output the answer in JSON format, leads to apparent issues:

The first image does not output a complete snippet, missing the closing three dots ```.
The second image shows a classification error, placing mangosteen under animals, and sunflowers appear twice under plants.
The third image mirrors the second error, and none of the three instances strictly outputs a JSON, failing to rigorously follow the role of a JSON Responder.

Lastly, this isn't the limit. Using the cpu-int8 version can answer the above questions with higher accuracy. Moreover, if you send the entry code for this demo's iOS version for analysis, it performs quite well.

Testing the Gemma 1's 2B version reveals that its inference capabilities still have room for improvement, but it excels in response speed. In fact, the 2B version of Gemma 2 was released recently, and according to official tests, its overall performance has surpassed GPT 3.5. This means that on a small mobile phone, local inference can now achieve the results of mainstream models from a year and a half ago. However, it has yet to be adapted to TFLite (on which MediaPipe is based).It's on the roadmap but without a specific date, you can track the following issues for the latest updates:

Conclusion

Migrating this local chat demo and conducting tests provided us with some firsthand experience:

The development of On-Device Models for LLMs is progressing rapidly. With the help of Google's infrastructure, third-party mobile app developers can quickly integrate related features across Android and iOS platforms.
Considering the current situation, On-Device Models for LLMs are likely to reach a preliminary usable state this year. Inference speed is already good, but accuracy still requires further testing (e.g., Gemma 2's 2B version + MediaPipe).
Adopting the "Kotlin First" strategy and boldly using Compose shows great promise—under a well-developed infrastructure, a small chat module of Android can be ported to iOS with just a handful of changes.

KotlinConf 2024 Experience

2024-05-31T00:00:00Z

The annual Kotlin festival has arrived again. I mentioned "Next year, see you again" in last year's KotlinConf 2023 Experience and delivered on that promise. This time I posted the ticket release information in some Android groups in mainland China at the first opportunity and naturally got myself a super early bird ticket. This article is also a quick note on my phone, so please forgive simplification or omission of some technical term explanations and formatting issues.

This year's venue is at Bella Center in Copenhagen, Denmark, with a much larger overall scale than last year (2000 people vs 1000 people). Although last year's dining menu was fancier and the venue building had a particularly historic feel, making this year seem slightly inferior, the event management level is still very high.

I suggest everyone follow the on-site quick tour video recorded together with Kotlin official evangelist Shengyou and several friends (expected to be released in two or three days), as well as the next episode's on-site special of "Kotlin Fireside Chat."

(Image shows last year's on-site recording published on JetBrains China's Bilibili account)

Due to limited space, this article's content will focus on my personal perspective.

Core Agenda

This year's core theme is ostensibly Kotlin 2.0 and K2, but actually leans more toward KMP. After KT2 was announced last year, the official has been publicly sharing various progress. So the features were actually all released before this conference, including the binary packages. The more important part of the conference is announcing the arrival of KT2's official version, marking that Kotlin has truly matured (according to former Kotlin language designer Roman), and the beginning of more teams and projects adapting. On the language itself, they're already talking about what will be beta in 2.1 and 2.2, looking ahead to the future.

But I must say, everyone has been waiting for KT2 for a long time. Whether it's the significant performance improvement of the Compiler, or some syntactic sugar that should have been there long ago, all can affect the actual development experience. The design changes for KCP, KSP, etc., are also more convenient for us plugin developers.

On the KMP side, it directly took over 20 sessions of related topic sharing, including some official sessions from JetBrains and Google, as well as best practices from the community. Google mentioned WorkSpace suite migration to KMP last year, and this year brought it out as a key case study, corresponding to the major KMP support announced at this year's I/O. In addition, other tools in Jetpack, especially Room, also have detailed migration sharing this year. Whether or not you're a Room user, you can find some useful information from their library migration experience, including how to simultaneously support KMP and the Java ecosystem on Android, how to update and solve testing issues, how to bridge underlying native libraries (sqlite) on the iOS platform, etc. KMP's open-source libraries have reached several thousand (for specifics, check John O'Reilly's KMP Libraries sharing replay), with growth rate no less than other cross-platform tools in their early stages.

On the Compose side, besides some regular performance optimization and common multi-platform practice sharing, the most interesting might be Jake's sharing on using Compose for embedded system UI (I haven't watched it yet, several friends highly recommend it).

Of course, I definitely went to listen to the Gradle content. This year's core marketing point is Gradle Declarative DSL, whose approach is to start from the needs of most developers and separate the build configuration part (only supports configuring some basic data types) from the logic part (complex build customization, with plugins as carriers and tasks as units). Currently only EAP is released, requiring a bunch of nightly versions to use together, and will continuously improve related functions and tools to enter beta by the end of this year.

Just looking at the above two sentences of explanation is still a bit abstract. Actually, there's quite complex work behind this. Based on Kotlin's syntax, they extracted a subset of KTS, which can basically be understood as only supporting current Gradle Extension configuration. The new configuration filename is "build.gradle.dcl", dcl being short for declarative. The benefit is being able to customize a parser to parse and handle this file instead of the standard complex kotlin compiler, achieving huge performance improvements in the Configuration phase (about 1/6 the time of KTS). When chatting with Slack people on-site, I mentioned that Configuration Cache is not fast enough for large projects — even if one module takes 0.3s, the time for a thousand modules (300s) is a bit too long. I believe after this new configuration file is supported, there will also be obvious improvements.

Additionally, this year I also paid attention to some more soft-skill oriented Talks, including "Tools & Techniques for Java to Kotlin Migration" on the first day afternoon, and "The best programmer I know" on the second morning. The first one would be very instructive for many friends wanting to join big companies — you can hear how various projects with millions of lines of code do this kind of technical migration step by step. How to fight for the internal funding and resource support needed for this, how to communicate with people and groups who resist, why to regularly collect feedback from internal developers, how to find the value of new technology, etc. The second one I personally think is more like Golden Rules for indie developers — if you haven't read this type of blog or production mode introduction, it would be quite instructive.

All edited videos will be released in a week or two. Currently you can watch previous live replays through this replay list: https://www.reddit.com/r/Kotlin/comments/1d08rv8/is_it_possible_to_watch_the_recordings_of_the/

Deep Conversations

I spent more time on deep conversations this year, with fewer shallow introductions to new friends. On one hand, I added many people last year, and when we meet again there's always more content to chat about. On the other hand, my throat was inflamed those two days (sad), so I saved my limited voice for some in-depth topics. Below, I'll excerpt a few interesting pieces of content.

The first piece is a conversation with Jeffrey, one of Google's language and developer tools leaders. I mainly asked why Google didn't mention Compose Multiplatform in this I/O blog post, instead summarizing Google's current cross-platform support on the client side as "use KMP for shared logic, use Flutter for both shared UI and shared logic." His answer was very interesting, summarized in mainly two points: 1. Compose still has a lot of development space. At this stage, we're still working hard to provide better support for Android and various performance improvements. Not mentioning it now doesn't mean never — we'll see when it's more mature. 2. Flutter is very convenient when doing unified projects, while KMP has its own characteristics, including more seamless interop with Native (like uikit bindings). CMP can actually achieve a lot on this basis.

I think what he said is very reasonable, including the imagination for several integration modes of kmp and cmp now. For example, you can integrate only the logic part like early KMP, used to develop data repository and infra, including some SDKs. Another example is cashapp's redwood which doesn't use cmp's UI components, only uses the underlying composition part to build virtual structures, with actual rendering mapped to Native, even supporting hot deployment for kt/js. The migration appeal of KMP is actually very obvious: native performance, progressive integration. Going forward you can integrate CMP (partial functions or pages, partial package levels, of course all can go on too), and when stepping back you can keep using it as a native SDK while other parts use some new technology in the future. It's hard for situations like a startup company going all-in on Flutter, then deciding to rewrite most features or even the entire app when wanting to support better performance and advanced requirements.

The second piece is a conversation with Gradle's Principal Engineer, Paul. We discussed the community's general view that Gradle is "very hard to learn." Actually, on the Android side, the problem isn't just Gradle — mainly AGP and a bunch of packaging and compilation tools including aapt2, r8, ksp, etc., which also don't have much public documentation and detailed user guides. For Gradle itself, I wrote last year that documentation needs improvement. They are actually working on this, including new organizational forms, more course sharing, and working with Android to promote recipes and cross-linking references. Gradle's open-source build tool side has only 18 core team members. From public channels we can see that new employees are mostly invested in enterprise projects (develocity), so there's quite a bit of pressure for supporting new requirements. Bragging a bit: he proactively said he's too busy working at the booth these two days, and will read my book in a while and give me some feedback.

Additionally, I also chatted with him and Sterling about Declarative DSL's tooling support. The Compose Desktop tool they demonstrated on-site was amazing, able to view all configurations of related Software Types under a dcl. And this tool is just a demo. I suggested they could merge it into the IDE plugin (after all, compose is also a technology supported by idea plugins). This tool will also be integrated with more other source code navigation support in the future — you can click to see documentation and declarations, and also link to the plugin source code behind.

The third piece is chatting with Slack's Boon for over an hour across multiple times. Boon is from Singapore and currently works on some Android business architecture at Slack in Seattle. Slack Android has over a thousand modules and has been using Kotlin and Compose for many years. Interestingly, their infrastructure and developer experience team (which feels more tool-oriented) are separate. After the company was acquired by SF, there's still support for many open-source projects. And recent pain points include Compose performance issues and compilation build execution time. It's quite emotional and consistent with my observations that Singapore has a relatively weak local tech atmosphere because many talents have gone to the US due to the h1b1 agreement with America. He attends tech conferences year-round — I/O, DroidCon, KotlinConf all go — and helped identify many experts on-site, like DroidCon's CEO, former and current Kotlin language designers, Uber's Ty Smith, etc. Including later when I went to chat with a table of cashapp people, it was because he tipped me off early that John, the paparazzi maintainer, was also on-site.

As a side note, I later went to the CashApp table to chat with John, Ty, Mohit and others for half an hour, and discovered John and Jake were still working on-site, merging PRs — true community legends.

Extending Android Builds (EAB)

EAB is the English version of my book "Android Build and Architecture in Practice," which was just published last month. Last year at the KotlinConf conference, I was somewhat green asking people to help review the 'Extending Android Builds' table of contents and manuscript. Thanks to that conference, the book's content became more complete. This year I was much more confident, going directly with the newly released paper book and poster.

At 8 am on the first day when I just arrived at the venue, I went to Gradle's booth. Gradle officially recommended my new book in their Newsletter last month, and coming this time to gift the book to the Gradle team on-site was like fulfilling a wish. We chatted about many things, and when they asked for a QR code for trial reading content, I gave them the poster just right.

Then, they actually put the poster at Gradle's booth and helped promote it for two days. When people passing by gathered around, they would also introduce this book! And Gradle team's enthusiasm didn't stop there — I was also invited to participate in a Gradle interview, discussing the book creation process, suggestions for newcomers, outlook on Gradle's future, etc. The video will be released on their YouTube channel later.

When I got to Google's booth, I immediately recognized Chris Willington from the AGP team. If I heard correctly, he said he's now the Manager of the AGP team in London. I said I've watched his previous sharing videos at ADS many times — what a late meeting. Ivan's help last year gave me a lot of help, and Chris this year similarly gave me a lot of confidence, affirming the coverage scope of the book. Unfortunately there was no opportunity to put the book or poster at Google's booth haha. After giving the book to him, he also shared it with other colleagues.

Besides that, Google's Jeffrey and Uber's Ty also flipped through the book and gave some suggestions that are very inspiring for the second edition update. Special thanks to all the experts for their help, and definitely cherish the few opportunities to chat in person.

Summary

Finally, what makes this year happier than last year is that the Chinese developer team has grown again. Besides me and Shengyou, there's also Android GDE and KUG Shanghai organizer Yuang, KMP expert Yinlong, as well as high school student Zhuoxuan in Sweden and SiaoJie in London.

Hope to meet again at next year's KotlinConf!

See you soon!

2023 Global Odyssey: My Six 'Firsts' in the Tech Community

2024-01-31T00:00:00Z

Having navigated through the Covid-19 pandemic, I believe many of us share a renewed emphasis on the importance of life experiences. In 2023, my second year as an Android GDE, I ventured into several "firsts" in tech community involvement. These experiences not only recharged me with new energy but also sparked fresh ideas, which I'm eager to share with everyone.

April at Kotlin Conf in Amsterdam: In April 2023, I attended Kotlin Conf in Amsterdam, marking my first journey outside Asia. Every detail of this trip, from the conference agenda and booth setups to the high-quality attendees and presentations, left a lasting impression on me. Beurs van Berlage, a venue brimming with history, I witnessed a tech event that masterfully blended the past with the modern. I delved into themes like Kotlin Multiplatform, Kotlin Compiler, Compose for iOS, and ecosystem tools—cutting-edge topics that enriched my knowledge and connected me with like-minded friends, a rarity in the Android or mobile development circles at the time. Networking with peers from Europe added a valuable international dimension to my professional circle. Interestingly, conversations about my E-ink phone sparked connections beyond tech, discussing various gadgets and innovations for our file. At the booth area, I had the opportunity to engage in-depth with some Google staffs, who offered precious advice on my book, Extending Android Builds.
May's Online "Community Talks - AGP Special" Event: In May, I took a significant step in volunteer sharing by organizing a special event titled "Community Talks - AGP Compilation & Build." This was my first dual role as a host and speaker and my initial foray into planning and executing an entire event. I experimented with a roundtable forum, a format seldom seen in China's GDG, discussing technical topics with several experts. This event bolstered my willingness to try new things and revealed my potential in organizing and conveying technical knowledge.
July's "Internationalized App Design" at Google Export Day in Hangzhou: In July, I shared insights on internationalized app design at an event in Hangzhou. This was my first time addressing a non-programming topic at a large offline event, focusing on how culture, behaviors, and legal regulations impact app design. Using vivid examples from around the globe, I challenged both my knowledge and public speaking skills.
September at Google IO Connect and the Greater China Community Mixer: In September, I participated in the Google IO Connect and the Greater China Community Mixer in Shanghai, my first attendance at a community event of this scale. Conversations with community members from Mainland China, Hong Kong, and Taiwan provided diverse perspectives and inspirations. This also marked my first insight into the operations of different chinese-speaking communities, greatly broadening my horizon. It represents a valuable chance for us, aiming to encourage increased technological dialogue among diverse areas.
September's Google Devfest - Experts BootCamp: Another September event took me to the Devfest - Experts BootCamp in Silicon Valley, my first participation in a global GDE gathering. It offered a close-up on the design philosophies behind various Google technologies and face-to-face interactions with official Google engineers. Discussions on industry-specific development pain points provided a fresh perspective on challenges faced by developers in specific business sectors.
December's Google Devfest Taipei: In December, at Devfest Taipei, I presented "Ten Years into Android Gradle Plugin: Unraveling the Mysteries of Gradle." My initial programming project began a decade ago with learning Android development, where Gradle and AGP were notably challenging for beginners. Yet, I found these experiences intriguing. I aimed to consolidate ten years of experience and technical evolution to share my learning techniques with more people. This was my first full presentation using the technical terminology of the Taiwan community, a step outside my comfort zone. Preparing the presentation took weeks, including additional checks and note organization. Speaking at National Taiwan University, I felt the enthusiasm and excitement of a full classroom, enhancing my adaptability and deepening my connection with Taiwan's tech community.

In conclusion, I extend my gratitude to all event organizers and passionate developers worldwide, whether from Singapore, Europe, the United States, Mainland China, Taiwan, or elsewhere, for adding vibrant colors to my life and tech evangelism spectrum.

Feel free to share your "first" experiences in the tech community in the comments. I'm looking forward to exploring new life experiences in 2024. Let's strive for greatness together!

I/O 23 and AGP's 10th Anniversary: Why Can't I Still Learn Gradle?

2023-06-06T00:00:00Z

It's been ten years since Google first released Android Gradle Plugin (AGP) 0.1 at I/O 2013. However, even experienced Android developers may feel confused about using and deeply mastering Gradle and AGP. I've written many Gradle/AGP related articles, done online sharing, and even written a book and a booklet. But through daily communication, I find it's still hard for most people to find a learning path, and even after investing time, there's no obvious progress. So on AGP's tenth anniversary, I decided to record some observations about "why I still can't learn Gradle/AGP" in brief words.

This article will review Gradle's evolution, especially past difficulties and recent improvements over the past two to three years. Finally, I'll provide some learning strategies to help beginners and experienced engineers better master this build system.

Disclaimer: Everything covered in this article is publicly available material, mainly from official public sharing or community voices.

Gradle itself has many difficulties, including but not limited to changing DSL, lifecycle details, many compatibility issues, and difficulties in debugging, locating, and optimizing. Overall, implementing an extension plugin requires mastering many concepts at once.

(Why not ask the magic conch)

But having many concepts and difficulties isn't the problem. Frameworks like React.js and Jetpack Compose are also quite complex conceptually, so why is getting started not that hard for people?

In fact, many common frameworks and tools can help developers quickly find applicable scenarios in the early stages of learning, while learning Gradle and AGP requires investing a lot of time before seeing results. For most beginners, even if your English is good and you can understand Gradle's official User Guide, you can't quickly find the right usage scenarios, let alone combine related components for best practices. And from another angle, we may have forgotten that as Android developers, this tool fundamentally needs to work in the Android App build process to maximize its value, and learning AGP is neglected by many people.

The above observations lead to two thoughts in this article:

Gradle's official documentation consists of scattered knowledge points, lacking practical tutorials oriented toward beginners, i.e., Tutorial-type documentation.
AGP's public APIs and extensibility have certain limitations. AGP's goals are long-term, with its primary purpose being to promote the overall development of the Android build ecosystem, but to balance maintenance costs, it's impossible to open all APIs.

Gradle's Documentation Problem

First point, the documentation problem. "Scattered" refers to two aspects:

Many necessary knowledge points lack guidance documentation: For example, everyone has used the android.buildTypes{...} definition, which is essentially basic use of the NamedDomainObjectContainer class and its series of parent classes. What you can find is API annotation documentation, but you can't find guidance on the User Guide, such as comparison of multiple similar APIs, CRUD in Groovy DSL, CRUD in Kotlin, how to migrate and use between the two DSLs, etc. The earliest reference material from Google searches on this is Mr.HAKi's Gradle Goodness series articles, which also has many other API use cases in the blog series.
The documentation has some 0-to-1 content, such as lifecycle and task basics. But a lot of other common components, API techniques, and how to combine and apply multiple tools are not detailed enough, or may be placed in obscure corners. The comprehensive reading experience is somewhat lacking: you clearly seem to have seen it somewhere, but can't remember, and even keyword searching is somewhat difficult. Users lack a learning roadmap of their own.

From this perspective, some well-known Gradle video series follow the design approach of official documentation and are not conducive to beginners getting started quickly. Of course, in terms of knowledge coverage, they remain a powerful supplement to official documentation.

But here we must insert a turning point: most framework/tool documentation, even with sufficient knowledge points, still has problems of being scattered and without priority, with specific reasons behind it. For many excellent framework developers, writing good API comments in each file, plus a lot of testing, constitutes a rigorous documentation that other developers can learn from on their own. And the exported API documentation is the core "documentation" — it doesn't require a lot of cases and guidance materials to be called "documentation"; that's the icing on the cake, which is Tutorials.

This is also why many tech companies and tech products hire special developer advocates, technical writers, etc. Guidance documentation and open-source Sample repositories are mostly released through their hands. A typical example is Now-In-Android.

Without certain complete guidance documentation, what remains most in Gradle documentation are Script Plugin examples. Due to DSL API reasons, although the documentation looks neat, once you need to write your own binary plugin (i.e., a plugin published after compilation, containing one or more Plugin implementations internally — libraries we reference are usually published as binary plugins), you often need native APIs. And in the previous seven or eight years due to the Groovy-dominated script ecosystem, finding corresponding native APIs from some DSLs was somewhat difficult — NamedDomainObjectContainer again becomes a typical case of this problem. The find-and-add integrated API implemented through Groovy's dynamic features means users actually don't know whether they're using create() or getByName() or named() etc. behind the scenes. This is an advantage when writing build.gradle configuration, but a disadvantage when really writing binary plugins. In my observation, Groovy amplified the difficulty for ordinary people wanting to master this tool; but for many industry pioneers, proficient Groovy skills made them feel Gradle was flexible and easy to use, and until K2 was released, Groovy kept configuration phase script compilation faster.

Finally, because of Gradle's product stance, it won't give too many Android ecosystem examples. For AGP, refer to the next issue's discussion. Unfortunately, due to some special reasons, many monitoring APIs haven't been released either. We've even seen some third-party plugins already calling private APIs, yet there's still no explanation for this part of the issue. This includes the deprecation of most public lifecycle hooks (due to Configuration Cache), and there's no complete explanation for alternatives to these public APIs. Some official best practices can only be seen from Gradle forums or Slack discussion groups.

AGP's Openness Problem

Gradle has a steep learning curve, but "learning a lot of basics" yet not being able to produce things is more because of lack of understanding of the ecosystem. Gradle as an underlying foundation supports not just Android, but also Java, Kotlin, Scala and other language ecosystems, as well as the nearly largest JVM backend framework ecosystem including Spring, etc. It's not hard to imagine that for Android developers, understanding the various details of Android Gradle Plugin (AGP) and related compilation tools is a core part of the packaging process.

In the first five or six years, AGP rarely publicized its development plans and community development support, and it was hard to find related technical documentation. In 2018 and 2019, it gradually spoke up at some important official conferences, understood third-party plugin developers' pain points and synchronized its progress on public API construction, and fully released major changes related to AGP 7.0 at the I/O conference in 2021, including documentation and Sample support.

From the issue tracker situation, although P1/S1 issues have been resolved, there are still many "secondary" issues to be improved. I personally found some problems while trying to help promote new APIs, such as:

Currently only a dozen or so public Artifact APIs, while private APIs have over 200 types.
Public bytecode modification Artifact API differs from private implementation, causing cache invalidation when there are multiple transformation tasks.

Based on the above objective content, developers have no intuitive path to learning AGP. Many articles directly list its task list and analyze one by one when introducing AGP, which is also a helpless choice. But the learning effect of this approach may... not be too good. Since there's no documentation and architecture design, systematic learning requires reading source code and understanding overall design paradigms. The reading process needs to be accompanied by thinking about multiple single-point problems encountered in practice, such as what paradigm AGP's task registration process has, how the chain structure behind the new Artifact API helps data transmission and final API exposure, etc. And the prerequisite for having these questions is that you, as an efficiency-focused developer, or putting yourself in that position, write one plugin after another that may not conform to Gradle and AGP "specifications," see problems from them, read source code, solve problems, and eventually grow. I call the plugins written this way "Android ecosystem cooperative plugins," which are worlds apart from some platform-independent plugins (like plugins that analyze Gradle dependencies).

Most people can't or don't get the opportunity to go through the above process, so the market only has two types of people: beginners and experts. And the middle levels have obvious gaps. This is also reflected in the distribution of topic exposure — over the past ten years, AGP topic sharing has often been mixed in with AS or Android development tool updates. It wasn't until recently that AGP finally has its own sub-tab in the documentation area (independent navigation).

Recent Improvements and Recommended Learning Strategies

Although the various problems mentioned above once made learning and applying Gradle difficult, there have been some major improvements in the past two to three years:

Kotlin became the default scripting language: Kotlin is now Gradle's default scripting language. For Android developers, this is good news because they can use the same language for both app development and build script development. Compared to Groovy, Kotlin is easier to get started with.
New features in AGP: AGP has followed Gradle's Lazy Property, Configuration Cache, Work Executor and other features; provided truly public APIs, including a complete developer-facing Variant lifecycle, Artifact exposure mechanism, and related Sample documentation. Developers can more easily extend AGP's functionality.
Compilation speed improvements: Collaboration between Google, JetBrains, and Gradle, for example:
1. Various caching mechanisms, parallel execution mechanisms, and lazy registration mechanisms have been introduced to AGP.
2. Kotlin's compilation speed continues to improve.
3. KSP symbol processing tool developed by Google has been introduced to various Android and Kotlin development tools, greatly improving symbol processor efficiency.
4. Android Studio's various Gradle peripheral function support, including AGP API migration, performance analysis tools, etc.
5. Future new Kotlin compiler K2 and complete compiler plugin ecosystem toolchain will bring more extreme performance improvements.

Based on the above improvements, if I were to give some learning advice to beginners and intermediate-advanced engineers, I believe it would be:

Strategies for beginners:
- 1.1 First learn basic concepts of Kotlin and Gradle, such as DSL, project organization structure, task mechanism, etc.
- 1.2 Then learn common plugins and their Extension usage, such as Android, Java, Kotlin, Maven publishing, etc.
- 1.3 Finally gradually delve into some advanced topics, such as simple script modifications, simple task writing, basic compilation problem locating, etc.
- 1.4 KOGE, an open-source booklet I organized, covers most of the above basic concepts. Welcome to read & provide suggestions & participate in writing.
Strategies for intermediate-advanced engineers:
- 2.1 Centered around "enhancing Android Gradle Plugin functionality," learn to write plugins that cooperate with the Android ecosystem. This is an important threshold for improving all-around compilation and build quality that must be firmly crossed. Driven by goals, discover problems, read source code, solve problems, repeat this cycle, and continuously improve understanding of ecosystem cooperative plugins.
- 2.2 Apply plugin technology to all aspects of production, such as resource modification, source code modification, bytecode modification, etc. Not only learn related compilation toolchains, but also think about problems from multiple angles, combining compile-time and runtime solutions to complement each other's advantages.
- 2.3 Learn more about AGP's core ideas and architecture design, optimize the above various plugin solutions, and bring excellent architectural ideas into the App's efficiency architecture, bringing the team a development experience of "low cost, low compilation time, high performance, high maintainability."
- For friends who want to accelerate learning, you can also get my new book "Extending Android Builds" to systematically learn Gradle plugin development and AGP core design.

In summary, although the early learning process of Gradle and AGP may seem daunting, with recent improvements and the right learning strategies, developers can better master this powerful build tool to improve productivity and code quality.

KotlinConf 2023 Experience

2023-04-15T00:00:00Z

Just finished the KotlinConf 2023 journey, my heart is surging with excitement. While the feeling is still fresh, I'm recording what I saw and heard. In just two days, I gained numerous life experiences I'd never had before. The conference's agenda arrangement, booth setup, high-quality attendees and content sharing, even the peripheral support like food, coffee, and Party band were all top-tier.

Note: This is a quick note written on my phone, so please forgive any formatting issues.

Venue

This year is the second time KotlinConf is held in Amsterdam, Netherlands. The last time was before the pandemic. The location is Beurs van Berlage, a historical building that has been renovated and now serves as a venue for conference rentals.

The main hall blending history and modernity carries substantial content and memories.

Many people from other countries said this was the most beautiful venue with the best food. Of course, since it's held in Europe, most of the on-site audience, including booth staff, came from European countries like UK, France, Germany, Czech Republic, Belgium, Italy, etc. The rest felt like they came from North America, plus a small number from Asia, Africa, and Latin America. Overall, there were various languages being spoken on site, and since most people aren't native English speakers, there's not much pressure when chatting in English together.

Agenda

Kotlin language is naturally the theme of the conference, but the Kotlin ecosystem has developed to the point today where it's far more than traditional JVM content. We see topics like Android, Backend, Multiplatform, Infrastructure & Tools, QA and automation, etc. Besides the Opening Keynotes every morning, the rest of the time has five or six events running in parallel, requiring you to make choices between multiple Sessions — this is actually a good thing, because judging conference quality is extremely subjective. When topic sharers find the right audience and audiences find the content most suited to their taste, the best chemistry happens.

(Some bookmarked topics)

For example, I mostly chose topics related to Kotlin Multiplatform, Kotlin Compiler, Compose for iOS, and ecosystem tools, leaning toward the novel or hardcore.

Two most important takeaways from listening to sessions on-site:

As often said, you can chat more with the speaker after they finish. For example, after listening to K2 Compiler Plugins, I chatted a bit more with Mikhail privately. He explained that "documentation has been released" mainly refers to API docs, not Tutorial docs. Then he opened Kotlin source code on-site and we looked together at where the public interfaces he just mentioned are located — the code is well-standardized with clear comments, so the generated documentation is naturally good. Combined with this session's video and several official real cases, I believe KCP will spawn more community ecosystem under K2's boost.

2. As mentioned earlier, parallel sessions have already diverted the crowd, so the people you meet in this breakout room must be well-matched to this topic. Taking K2 Compiler Plugins as an example again, although the topic is niche and the breakout room isn't large, when the Speaker did research asking how many people had written a Compiler Plugin, surprisingly 30-40% raised their hands, and there were four or five people raising hands during the Q&A session. So this small room has many new friends worth meeting — seize the opportunity!

Offline Networking

Continuing from the previous sharing, as the last questioner, due to limited English skills my expression was a bit wordy, and the speaker seemed a bit confused — so we ended that session. After he stepped down, we discussed with several other developers nearby about the pros and cons of K2's KCP plan to cancel the Gradle SubPlugin setting. Among them, I met a young guy from Belgium who had just graduated but was already quite skilled discussing these topics. We successfully exchanged contact information on the way back to the main hall.

Right after that, at the detekt session I met two friends who felt like kindred spirits — Nicola and Chao from the detekt core maintenance team. Chao and I even went to participate in recording "Kotlin Fireside Chat" together just an hour after meeting.

(Nicola, Chao, me, Shengyou)

Besides extending connections from breakout rooms, I also started chatting with people in the hall or lounge starting from breakfast on the first day. In fact, you can even sacrifice a bit of session time to participate in this once-a-year face-to-face moment. For example, if you've listened to too many sessions today, leave the remaining hour's session for later when the replay is online!

The people above are both industry experts and one-way online friends I've followed for years. The last two are even co-presenters. Since social media profiles use real photos, they're easy to recognize on-site. Get some water, approach, first listen to what others are chatting about, then slowly introduce yourself and learn more. For example, topics I first heard included: Maven Central publishing process being cumbersome, cycling from Paris to Amsterdam, side projects they're working on, etc. During second and third encounters for deeper chats, you can discuss more like career planning, technical questions.

(My E-ink phone attracted many people's attention / opened conversations)

The third way to approach people is going directly to Booths. For example, after Google's sharing, Jeffrey took me to Google's booth.

There he introduced me to Ivan. Ivan is one of the developers of AS & AGP tools. He answered many of my questions about current API design, version iteration, bug submission and fixing. Most importantly, he looked at the English table of contents of the book I'm writing on-site, and after discussion gave me multiple practical suggestions.

Then I saw Marton at Google's booth. He's one of the organizers of Android Worldwide conference, and we had online exchanges before when I was a speaker there. Recently he's been organizing and publishing KSP and Android development information (as shown above), so we even searched together on-site for my KSP sharing video from back then (forgot the sharing title, we searched for a minute or two, almost awkward).

There were also evangelists like Florina on-site. Due to limited time, we just said hello and shared what work we're doing, etc.

Booths usually have lots of swag. Here's a portion of stickers, pins and other swag I got. Later I hope to share them with local developers at other events, passing on KotlinConf's grand occasion and enthusiasm. Of course, there's also Kotlin's booth and swag, plus their staff and engineers.

Special thanks to Shengyou for helping me meet more friends from JetBrains, and for attending the evening Party together where we took photos with several German friends and chatted for nearly an hour. For more conversations with Shengyou, follow Kotlin's official account and "Kotlin Fireside Chat" podcast!

The final Easter egg is — a photo with Jake Wharton:

(YOU KNOW WHO)

Others

I haven't attended many offline conferences before. Earlier years I attended some GDG events in mainland China, and in '18, '19, '22 I attended several Google and DroidCon events in Singapore. From my discussions with friends on-site about tech conferences, this KotlinConf is still noteworthy among many conferences.

Communicating with the most interesting people in the same industry worldwide, meeting new friends, absorbing new knowledge and generating inspiration in a relaxed atmosphere. After experiencing Covid-19, I think everyone cherishes opportunities to talk face-to-face more. If I hadn't booked this early bird ticket a year in advance, I would definitely regret it.

Next year, see you again!

Build Guide #12 Enabling Plugin Features Based on Variant

2021-12-21T00:00:00Z

Anyone who has used third-party Gradle plugins in Android development should have encountered this problem: I only want to apply this plugin in certain buildTypes or flavors, but I can't find a suitable way.

The root cause of this problem is that Variant (buildType + flavor) is not a Gradle concept, but comes from Android Gradle Plugin (AGP)'s multi-channel configuration. So from Gradle's platform perspective, it's difficult to provide convenient support upward: plugin introduction within a project is global and platform-level, not changed by the will of any particular plugin (AGP).

OK, but our problem still needs to be solved, hence the four solutions below (fog). We'll explain the ideas in order from ineffective to highly effective.

Applying Plugins Based on Variant (Ineffective X)

flavorDimensions += "server"
productFlavors {
    ...
    create("production") {
        dimension = "server"
        applicationIdSuffix = ".production"
        versionNameSuffix = "-production"
        versionCode = 2
        apply("xxx") // Ineffective
    }
}

Many Android or Gradle beginners think, can't I just put apply(...) here? (Of course, you can't use plugins { id("xxx") }). The misconception here is that the apply(...) method has no association with the current context object:

The closure context of create("..."){} is this:ApplicationProductFlavor.
apply(...) is an extension method mounted on PluginAware (in build.gradle.kts), acting on the entire Project, so your plugin will still be introduced globally.

A similar classic misconception:

create("production") {
    dimension = "server"
    applicationIdSuffix = ".production"
    versionNameSuffix = "-production"
    versionCode = 2
    packagingOptions {
        jniLibs {
            excludes.add("...")
        }
    }
}

You might think this sets separate packagingOptions for this flavor, but actually this method is a method of the CommonExtension interface, not belonging to ApplicationProductFlavor. That is, it sets for the entire Android Gradle Plugin, not a single flavor. If you make different settings in each flavor, the last setting will override all previous ones. For solutions to this problem, refer to the "Secondary Configuration" section in my previous GDG sharing.

Applying Plugins Based on Command (Partially Effective X)

The problem we're discussing can also be found in some StackOverflow Q&As, with many answers about "parsing the entered command" for judgment.

if (gradle.startParameter.taskRequests.toString().contains("production")) {
    apply(...)
}

This approach can solve situations where your entered command is ./gradlew clean assembleProductionRelease etc., because such commands only contain information for one Variant (i.e., Production + Release). However, if the entered command is ./gradlew clean assembleRelease, which packages both Staging and Production flavors simultaneously, the if(...) condition above won't hold at all, and your build will be broken.

In most cases, taskRequests should not be obtained and used by third-party Android build plugin developers. Like the first misconception, it's Gradle's platform API, not optimized for AGP's upper-level Variant concept.

Disabling Corresponding Variant's Plugin Tasks (Effective Y)

Of course, there are also correct, effective, and universal approaches mentioned on SO — don't dynamically disable (or enable) plugins, disable the Tasks within the plugin instead.

plugins { id("com.example.ua") }
// or apply("com.example.ua")
...
tasks.whenTaskAdded {
    if (name.contains("production", true)
            && name.contains("release", true)
            && name.contains("UploadArchive", true)) {
        enabled = false
    }
}

Suppose there's an upload build result plugin called com.example.ua. No matter what situation, we reference it in build.gradle.kts. But looking below, we made a similar if(...) judgment as the previous misconception based on whenTaskAdded {...}, then set the matching task's enabled property to false. Why doesn't the previous method work while this one does?

Let's review this Gradle script and android{} DSL rule: no matter what command you enter in shell, whether clean or help, this script will be completely executed, and all Variant Tasks will be registered (though nowadays it's usually lazy registration with register(...) instead of create()). And whenTaskAdded{...} is a Gradle platform API. It doesn't care whether your upper-level registered Tasks are divided by Variant — it just provides a callback timing for developers for all registered Tasks that will definitely be added to the run graph (which is a DAG). Meanwhile, almost all Android ecosystem cooperative plugins name their Tasks based on Variant name (if it needs to be a VariantAware Task), such as "UploadArchiveWithLogForProductionRelease". This unwritten rule gives us the opportunity for string matching, which is the code you see above.

As for how to find all corresponding Tasks for a plugin, there's currently no automated way, nor an API (though in a recent AGP Team Q&A, they mentioned they're working with Gradle to advance this feature). What you can do is: print the Task List before introducing the plugin, print again after introducing it, and find the Diff between them. Of course, for some simpler plugins, you can just look at the documentation or source code to organize which Tasks there are.

So this solution can be summarized in one sentence: always reference the plugin, but disable unneeded Tasks.

Intercepting at Task Registration (Highly Effective Y)

I mentioned in the previous article Build Guide #11 BundleTool Gradle Plugin:

bundle-tool-gradle-plugin supports enabling plugin features by different variant channels.

Just hearing this sounds similar to the previous solution — could it be hiding enabled = false inside the Plugin, then exposing a DSL switch configuration for users to choose? Actually no, the solution approach is already very similar. But thinking a bit more, there are two areas for improvement:

Since we want to control the switch inside the plugin, why use task.enabled = false? Just skip the registration process directly (of course, this approach isn't suitable for all situations; sometimes dynamic disabling is still needed).
For most Android ecosystem cooperative plugins, their DSL is generally Variant-unrelated static configuration. If you want to design a Variant-related configuration, you might only be able to pass in a bunch of custom rules (as in the code below):

// Static DSL configuration
bundletool {
    enableByVariantRules {
        create("debugStaging") {
            enabledFeature1 = true
            enabledFeature2 = true
            enabledFeature3 = false
        }
        create("debugProduction") {
            ...
        }
    }
}

The complexity of such rules is hard to control. In the above code, it's a Cartesian product of 2 * 2 * 3, making configuration very inconvenient. The solution is also easy to think of: if it could be passed as a Kotlin Lambda (or Groovy Closure), wouldn't that be convenient? Just like the onVariants(...) {...} method we use for secondary configuration, we need something "dynamic," something users can interact with, to reduce configuration complexity.

// "Dynamic" DSL configuration, based on Kotlin Lambda and Groovy Closure
bundleTool {
    enableByVariant { variant, feature ->
        !(variant.name.contains("debug", true) && feature == BundleToolFeature.GET_SIZE)
    }
    ...
}

The variant parameter is com.android.build.api.variant.Variant, the Variant object from Variant API v2 we normally use; the feature parameter is a custom enum class, convenient for each plugin to customize. Now let's look at the implementation:

/**
 * Extract `enableByVariant(...)` function, can be reused in other plugins.
 * Currently the Lambda and Closure are defined by raw types, they can be encapsulated
 * by [Property] as well to fulfill "lazily produced/consumed" purpose.
 */
abstract class EnableByFeatureExtension<T> {

    var kotlinEnableByVariant: EnableByVariant<T>? = null

    var groovyEnableByVariant: Closure<Boolean>? = null

    // For Gradle Kotlin DSL
    fun enableByVariant(selector: EnableByVariant<T>) {
        kotlinEnableByVariant = selector
    }

    // For Gradle Groovy DSL
    fun enableByVariant(selector: Closure<Boolean>) {
        groovyEnableByVariant = selector.dehydrate()
    }

    internal fun isFeatureEnabled(variant: Variant, t: T): Boolean = when {
        kotlinEnableByVariant != null -> {
            kotlinEnableByVariant!!.invoke(variant, t)
        }
        groovyEnableByVariant != null -> {
            groovyEnableByVariant!!.call(variant, t)
        }
        else -> false
    }

}

internal typealias EnableByVariant<T> = (variant: Variant, t: T) -> Boolean

abstract class BundleToolExtension: EnableByFeatureExtension<BundleToolFeature>() {

    abstract val buildApks: NamedDomainObjectContainer<BuildApksRule>

    abstract val getSize: NamedDomainObjectContainer<GetSizeRule>

}

enum class BundleToolFeature {

    // It's currently a predecessor for GET_SIZE,
    // and the first job that plugin does,
    // disable it will cause the task registry got removed.
    // The work action that transforms .aab to .apks using `build-apks` command.
    BUILD_APKS,

    // The work action that gets the transformed .apks file size using `get-size total` command.
    GET_SIZE

}

Here we defined Closure/Lambda for both Groovy and Kotlin Gradle DSL. They accept Variant and a custom generic parameter, returning a Boolean value indicating whether to enable the corresponding feature. Then we defined the isFeatureEnabled(..,): Boolean method to integrate both language branches, convenient for internal plugin calls. When actually using this EnableByFeatureExtension, we let the plugin's BundleToolExtension inherit from it, thus isolating the plugin's main functionality from the general switch feature. Any other plugin can conveniently copy this class and add it to their own Extension.

androidExtension.onVariants { variant ->
    if (!config.isFeatureEnabled(variant, BundleToolFeature.BUILD_APKS)) {
        return@onVariants
    }
    val featureGetSize = config.isFeatureEnabled(variant, BundleToolFeature.GET_SIZE)
    ...
    val buildApksTaskProvider = project.tasks.register<BundleToolTask>(
        "TransformApksFromBundleFor${variantName}"
    ) {
        enableGetSizeFeature = featureGetSize
        ...
    }
}

abstract class BundleToolTask : DefaultTask() {

    @get:Input
    var enableGetSizeFeature: Boolean = false
    ...

    @TaskAction
    fun transform() {
        ...
        if (!enableGetSizeFeature) return
    }
}

Finally, we demonstrated examples of using this switch in two places:

If a Feature affects the entire Task, we can use the switch to skip its registration.
If a Feature only affects part of a Task's functionality, we pass the switch value into the Task for internal judgment.

The above process is not entirely fixed; this idea can be adjusted in combination with other switch methods. I've already used this solution in bundle-tool-gradle-plugin and ScratchPaper, making plugin feature introduction more flexible.

Of course, you may have also noticed that this solution is from the plugin development perspective. Unless all plugin developers use a similar solution for optimization, Solution 3 remains the only universal approach from the user's perspective. But the advantage of this solution is finer granularity control and more convenience — developers can customize as they wish.

Summary

This article mainly discussed solutions for enabling plugin features based on different Variant channels. It may also be the first time there's been such detailed and complete multi-solution comparative discussion anywhere online. The thinking and solutions in this article can actually be applied to other Gradle scenarios as well — feel free to use your imagination. That's it for the last technical article of 2021. See you next year!

Build Guide #11 BundleTool Gradle Plugin

2021-12-19T00:00:00Z

App Bundle (.aab) as the officially promoted new delivery format for Android has been around for a while. This year's PlayStore policy mandating that "all new apps must use .aab" for submission has become a major driver for everyone to make the switch. Making your app compatible with and packaging into .aab format is not complicated - simply add the corresponding DSL configuration and replace the packaging command with bundle${VariantName}. However, the .aab obtained after packaging cannot be directly installed on debugging devices using adb locally. You need to use bundletool to convert it to .apks before calling its install command to install.

Common Scenarios

The BundleTool official documentation lists various uses of CLI commands. In more complex environments, you might have encountered these scenarios with BundleTool:

During local testing, you need to manually run conversion and installation commands using BundleTool's CLI;
In CI environments, you need to configure the BundleTool CLI tool, then write some Shell scripts to control the post-packaging conversion process;
Real device labs, cloud device testing platforms need to integrate BundleTool into corresponding tests, making it convenient to generate apks packages for specific device models.

These scenarios often come with the following issues:

Some internal test package distribution channels don't support aab and apks. We need to do quick functional tests on these non-GP, non-real-device-lab platforms where universal apk is the best choice for such scenarios (but packaging a new apk from scratch is obviously a waste of resources);
After uploading the aab package to GP's Console, you can clearly see the estimated download size for all supported devices, but this data metric is not convenient to collect and quantify on CI using Shell scripts (though it might be possible with some effort or Python);
AGP actually integrates the BundleTool package, so having to configure BundleTool's CLI separately each time seems somewhat redundant.

This made me wonder: AGP has BundleTool as a dependency - doesn't it have these subsequent BundleTool conversion Tasks? Wouldn't using Gradle for these subsequent operations actually be more suitable?

Deep Dive into AGP & BundleTool

If we open the IDE's Gradle Task list and search for the "Bundle" keyword, we'll easily find tasks like makeApkFromBundleForXxxx etc. Their implementation is the com.android.build.gradle.internal.tasks.BundleToApkTask class.

When checking the associated usage of this class in the source code, you'll find that besides registration, there's no trace of this class being used anywhere else. And the specific role of this task itself is actually just:

Depends on PackageXxxBundle, waiting for it to produce an unsigned Bundle;
Inputs the Bundle from the previous step, executes the BuildApksCommand command from the BundleTool package to produce an .apks package.
From its input parameters, you can see that the only configuration it actually exposes to users is enableLocalTesting, while everything else uses the default values of BundleTool's build-apks command;
From its output result (see below), you'll discover it's actually just an "intermediate product" (located in the /intermediates folder), not a final product.

This is a bit like "food that's tasteless but a pity to throw away": there's an existing Task but its usage scope is very limited. Why not... wrap our own Gradle Plugin using the BundleTool library?

How to Wrap bundle-tool-gradle-plugin?

After simple analysis of BundleTool's several commands, we found their dependency relationships as follows:

Among them:

In terms of sequence, build-apks is a required prerequisite task (solid line) for the other commands, and get-device-spec is an optional prerequisite task (dashed line) for several commands.
In terms of interaction, build-apks and get-size (italicized parts) are closely related to the build process and don't require test devices; other commands require test devices.
get-device-spec exporting json files is a one-time task, we can assume this part is already complete;

Thus, our involved domain is also clear: build-apks and get-size commands that are directly related to final products. install-apks and extract-apks can be completed locally using CLI based on the current device, and in CI or cloud testing platforms there are usually dedicated scripts to handle them in combination with BundleTool.

Then we consider how to get and modify the final output Bundle. The new Variant API actually already provides convenient methods to modify and get the final Bundle. The entire process can refer to the running screenshot below. You can see that compared to the previous intermediate product mode, Variant API products are all output to the /outputs folder now. Since we don't need the intermediate aab, we just need to simply call variants.get(SingleArtifact.BUNDLE), pass the obtained .aab file to a custom Task, and then borrow from AGP's code to wrap various commands:

// A simple Task to verify the idea. The complete plugin implementation is more complex than this. Please refer to the repository link at the end
abstract class ConsumeBundleFileTask : DefaultTask() {

    @get:InputFiles
    abstract val finalBundleProperty: RegularFileProperty

    @get:Internal
    abstract val buildToolInfo: Property<BuildToolInfo>

    @get:Nested
    lateinit var signingConfigData: SigningConfigDataProvider

    @get:OutputFile
    abstract val apksFileProperty: RegularFileProperty

    @TaskAction
    fun taskAction() {
        val aapt2Path = buildToolInfo.get().getPath(BuildToolInfo.PathId.AAPT2)
        println(".get(SingleArtifact.BUNDLE)")
        println("[ConsumeBundleFileTask][input]:" + finalBundleProperty.asFile.get().absolutePath)
        println("[ConsumeBundleFileTask][output]:" + apksFileProperty.asFile.get().absolutePath)
        val signingConfigData = signingConfigData.resolve()!!
        val command = BuildApksCommand.builder()
            .setBundlePath(finalBundleProperty.asFile.get().toPath())
            .setOutputFile(apksFileProperty.asFile.get().toPath())
            .setAapt2Command(
                Aapt2Command.createFromExecutablePath(
                    File(aapt2Path).toPath()
                )
            )
            .setSigningConfiguration2(
                keystoreFile = signingConfigData.storeFile,
                keystorePassword = signingConfigData.storePassword,
                keyAlias = signingConfigData.keyAlias,
                keyPassword = signingConfigData.keyPassword
            ).setLocalTestingMode(false)
        command.build().execute()
    }
    ...
}

Friends unfamiliar with the new Variant API can refer to my sharing this month at GDG community "Extend Android Build Process - Based on New Variant/Artifact APIs" (replay).

Finally, let's briefly look at BundleTool's BuildApksCommand.Builder. This Builder's setXxx-related APIs have only had two minor changes in the past year, one of which was a new method addition that doesn't really affect original compatibility - it's relatively stable compared to AGP.

At this point, the theoretical construction cost and maintenance cost of the entire plugin are within acceptable range.

Using the Plugin

The plugin development is no different from several others I've written before. Let's look directly at plugin usage.

0x01. Add the plugin to classpath:

buildscript {
    repositories {
        ...
        mavenCentral()
    }
    dependencies {
        classpath("com.android.tools.build:gradle:7.0.4")
        classpath("me.2bab:bundle-tool-plugin:1.1.0")
    }
}

0x02. Apply Plugin:

// For your application module
plugins {
    id("me.2bab.bundletool")
}

0x03. Advanced Configurations

import me.xx2bab.bundletool.*

bundleTool {
    // This is a very interesting configuration item - it can enable/disable
    // plugin features by different variant channels. For example, here we disable
    // the debug + GET_SIZE feature combination.
    // You can adjust and enable needed features according to your project's actual buildtypes and flavors.
    enableByVariant { variant, feature ->
        !(variant.name.contains("debug", true) && feature == BundleToolFeature.GET_SIZE)
    }

    // Each configuration item corresponds to a `build-apks` command execution
    buildApks {
        create("universal") {
            buildMode.set(ApkBuildMode.UNIVERSAL.name)
        }
        create("pixel4a") {
            deviceSpec.set(file("./pixel4a.json"))
        }
    }

    // Each configuration item will calculate the size of all apks output from `buildApks` above in sequence.
    // With the current configuration, it will output 2 * 1 = 2 csv files
    getSize {
        create("all") {
            dimensions.addAll(
                GetSizeDimension.SDK.name,
                GetSizeDimension.ABI.name,
                GetSizeDimension.SCREEN_DENSITY.name,
                GetSizeDimension.LANGUAGE.name)
        }
    }
}

0x04. Build your App and Enjoy!

# Make sure the Variant in the command is allowed in `enableByVariant`
./gradlew TransformApksFromBundleForProductionRelease

Finally, you can find the output results in /app/outputs/bundle/${variantName}/bundletool.

Summary

I hope this small tool can help everyone when integrating the new Android Bundle. The plugin is open-sourced on my Github: bundle-tool-gradle-plugin. For the idea of enabling/disabling plugin features by Variant, please refer to the next Build Guide #12.

Build Guide #10 Android Development Tool Compatibility

2021-08-07T00:00:00Z

"Build Guide" is a series of articles exploring Android build-related topics, covering Gradle, Android Gradle Plugin, Kotlin Script, and other tools, as well as their architectural applications. Discovering problems, solving problems, sharing new knowledge, and improving efficiency.

Due to my CPU burning out a few months ago, I was forced to switch to an M1 Mac Mini, so I rebuilt the entire development environment. Taking this opportunity, I want to organize the version matching strategies, compatibility, and performance on M1 chips for several basic tools. The discussions about version matching and compatibility are not limited to the current versions and platforms being used.

The versions mentioned below are:

Zulu JDK: 11.0.11
Kotlin: 1.5.21
Gradle: 7.1.1
Android Gradle Plugin (AGP): 7.0 & 7.1
Android Studio: Arctic Fox 2020.3.1 & BumbleBee 2021.1.1 Canary 6

JDK

Starting from AGP 7.0, JDK 11 is the minimum requirement. JDK 11 has been an LTS (Long-term Support) version for nearly 3 years (Sep 2018), and has gone through 12 minor versions (11.0.12) of iteration, making it relatively mature now. For comparison, the previous LTS JDK 8 was released in 2014 and has accompanied us through 7 years and 300 minor version iterations. In fact, as Android developers, even if the project is primarily Java, the Language Level generally only targets 1.8 (some features from 9-12 are supported by D8, R8, and Android 11, 12 have incorporated them). Although Android officially says they won't abandon Java, support for Kotlin is indeed stronger in practice.

From this perspective, JDK 11 brings us more of:

Performance upgrades at the Kotlin Compiler, Gradle, and IDE levels;
Continued security assurance when JDK 8 stops maintenance (in 3 years);
Adapting to the new release mechanism - a minor version every six months, an LTS major version every three years, reducing legacy baggage and running faster;

And I believe the JDK upgrade strategy should be:

Conservative: If you don't care about new language features, you can decide the JDK version based on the annual AGP upgrade, since IDE generally bundles a JDK, Kotlin compiler, Gradle keeps up with the latest JDK and has good backward compatibility - so based on the barrel principle, just wait for AGP to upgrade first. Currently it looks like AGP may only follow relatively stable LTS versions;
Aggressive: Test after Gradle supports it;

On M1 Mac, since Oracle doesn't have an ARM64 version yet, the current mainstream approach is to install Zulu JDK11 maintained by Azul.

Note that the commonly used JDK management tool SDKMAN! in my testing still runs under Rosetta 2 translation. This causes even if you install Zulu JDK11, starting through SDKMAN! scripts will still show Gradle java processes running under Intel ABI. So currently it's recommended to download and install from the official website, and consider switching after supporting tools are ready.

Kotlin

Kotlin version matching has relatively few restrictions. Generally I consider three points:

Are there particularly attractive new features, such as newly released stable versions of Coroutine, Flow, or better support for new versions of Kotlin Multiplatform Mobile;
Whether to use the first version of a major iteration, such as observing the just-released 1.4.0, 1.5.0 - this actually applies broadly to various Libraries;
The Kotlin version currently bundled/tested by Gradle, e.g., the latest 7.1.1 stable still uses Kotlin 1.4.31 (7.2 RC jumps to 1.5.21);

Regarding the last point, if the Kotlin version used is inconsistent with what Gradle bundles, you'll see this Warning:

w: Runtime JAR files in the classpath should have the same version. These files were found in the classpath: ... /Users/2bab/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib-jdk7/1.4.31/84ce8e85f6e84270b2b501d44e9f0ba6ff64fa71/kotlin-stdlib-jdk7-1.4.31.jar (version 1.4) /Users/2bab/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib/1.5.21/2f537cad7e9eeb9da73738c8812e1e4cf9b62e4e/kotlin-stdlib-1.5.21.jar (version 1.5) /Users/2bab/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib-common/1.5.21/cc8bf3586fd2ebcf234058b9440bb406e62dfacb/kotlin-stdlib-common-1.5.21.jar (version 1.5) w: Consider providing an explicit dependency on kotlin-reflect 1.5 to prevent strange errors w: Some runtime JAR files in the classpath have an incompatible version. Consider removing them from the

Let's look at a simple example of how the problem occurs:

plugins {
    id("com.android.application")
    // No version specified, using Gradle's bundled version,
    // Gradle 7.1.1 corresponds to Kotlin 1.4.31's various libraries and compilation tools
    kotlin("android")
}

dependencies {
    // But here we use the latest 1.5.21 Kotlin, causing the above problem
    implementation("org.jetbrains.kotlin:kotlin-stdlib:1.5.21")
}

The solution is also simple:

plugins {
    id("com.android.application")
    // Manually specify the version
    kotlin("android") version "1.5.21"
}

The official Kotlin documentation directly demonstrates the writing with version number. However, this version is Kotlin tested based on Gradle, but Gradle itself hasn't tested and packaged it yet (see the image in the Gradle section). If problems occur, they may be difficult to solve:

So my recommended upgrade strategy is:

Conservative: Wait until Gradle upgrades to upgrade. For example, from 1.5.0 to 1.5.21 was only two months apart, and Gradle followed up;
Aggressive: Upgrade when there are practical new features or the first patch version after a major iteration.

Gradle

Previously I mentioned that Kotlin's official documentation explains various compatibility situations with Gradle. Conversely, Gradle also has a support document indicating support for various languages and platforms including Java, Kotlin, Android, etc.

Like the Java version support and Kotlin version support mentioned earlier, you can see everything at a glance here. Except that Kotlin support lags by a month or two, compatibility with the latest versions of other tools is not a problem. Gradle's own backward compatibility I think is quite good - I basically upgrade every version. But the upper-level AGP DSL, especially older versions, often has major changes (fortunately it's much better after 7.0).

So my recommended upgrade strategy is:

Conservative: Upgrade according to AGP's documentation at minimum version (see image below). For example, AGP 4.2.0+ corresponds to Gradle 6.7.1+;
Aggressive: Upgrade every patch version (x.y.1/2/3) or every version (Gradle doesn't have a -betaX version habit, usually just Nightly and RC).

Additionally, Gradle 7.0 and later natively supports M1, and my personal experience has been quite good.

Android Gradle Plugin

We've basically covered AGP version matching restrictions earlier. Taking 7.0 as an example, let's look at the official Release Note compatibility description:

One additional point: Starting from AGP 7.0, its version will sync with Gradle's major version, strictly following the Semantic Versioning system (previously it synced with AS's version). That is, AGP 7.x will adapt to Gradle 7.x versions. However, AGP's release time is still together with AS, and currently it looks like its alpha/beta numbers follow AS, so actually the three have formed some kind of tacit synchronization mechanism.

So my recommended upgrade strategy is:

Conservative: Upgrade with AS stable releases (or appropriately skip the first major version iteration);
Aggressive: Upgrade every version, or start upgrading from alpha/beta, such as for Gradle plugin adaptation.

Android Studio

AS basically has no matching restrictions. As long as you're using a previous stable version of AGP, AS can be backward compatible. My recommended upgrade strategy is:

Conservative: Appropriately skip the first major version iteration;
Aggressive: Upgrade every version, or start upgrading from alpha/beta, such as for IDE plugin adaptation or needs for new features like Compose, debugging tools, etc.

Additionally, since AS is based on secondary development of IDEA Community Edition, overall stability and speed of new feature support are not as good as IDEA Ultimate. For example, Gradle's nested Composite Build is currently not in AS's supported scope, see this issue.

Finally, starting from Arctic Fox 2020.3.1, AS natively supports M1, but for a smoother experience, I think BumbleBee 2021.1.1 Canary is better.

IDEA

IDEA's main matching restrictions come from Android Plugin (Android IDE plugin) version adaptation. Generally speaking, after a new stable version of AS is released, the next stable version of IDEA will come with the new plugin version, thus supporting Android development including AGP.

Occasionally there are longer waits. For example, this year AS&AGP 4.2 was released in April, but it wasn't until July when IDEA 2021.2 was released that the Android Plugin was updated. The official explanation was that Google released AGP 4.2 source code late, missing the 2021.1 version.

My recommended upgrade strategy is:

Conservative: Only upgrade stable versions;
Aggressive: Start upgrading from EAP or RC, such as for better Kotlin support, earlier AGP support, and M1 platform optimizations.

Finally, 2021.2 is also the version that made me feel there's no longer any lag on M1.

Summary

I personally use the M1 platform + adapt some Gradle Plugins, so I often use beta or even alpha AGP (as a Runtime library), and developing with the latest IDEA Ultimate is quite smooth.

For company projects, at this stage on x86 platforms I think you can use the following configuration, adjusting corresponding tool versions for ARM M1 based on the above:

JDK 11 (will have to upgrade sooner or later since AGP upgraded)
Gradle 7.1.1 (can upgrade after 7.2 supports 1.5.21)
Kotlin 1.4.31
AGP 4.2.2 (7.0 stabilized the new Variant API, soon 7.1 will also stabilize the new DSL, can wait and see if you don't need Compose)
AS 4.2.2 (can wait and see if you don't need Compose)
IDEA 2021.2

Moving Forward: Google I/O 21 Android Gradle Plugin Update Summary

2021-06-17T00:00:00Z

It's been nearly a month since Google I/O 2021. In the past few days, I've been reviewing the Android Gradle Plugin (AGP) content, mainly focusing on the "What's new in Android Gradle plugin" session. However, since there was no Google I/O in 2020 and all offline events were suspended due to the pandemic, this 11-minute session contains an enormous amount of information - it's essentially a condensed highlight of the past two years' updates (I watched it three times). Therefore, in this article, I'll include many additional reference materials, digging into talks/posts/repos that you might have missed in the past year or two. The overall structure still follows the session's agenda.

Performance Improvements

Configuration Cache

Gradle's lifecycle is divided into three major parts: Initialization Phase, Configuration Phase, and Execution Phase. The task execution part can already be well cached and reused if handled properly - reusing existing caches is a crucial part of speeding up compilation. If this mechanism is applied to other phases, it should naturally bring some benefits as well. The next most time-consuming phase after execution is usually the configuration phase, and this year AGP brings us Gradle Configuration Cache support, a new feature that has been incubating since Gradle 6.6. It enables the main output of the configuration phase - the Task Graph - to be reused. In the example project, this optimization can eliminate about 8 seconds of unnecessary waiting (if Gradle script configuration hasn't changed).

To experience this optimization, simply add --configuration-cache when executing Gradle commands, such as ./gradlew --configuration-cache help. Since Configuration Cache is not yet fully stable, if you want to keep it enabled (including optimization during IDE Sync), you need to use the following properties:

org.gradle.unsafe.configuration-cache=true

On first use, you'll see a prompt about calculating the Task Graph:

Calculating task graph as no configuration cache is available for tasks: :test-app:assembleDebug

On success, it will prompt at the end of the Build:

Configuration cache entry stored.

Then the Cache can be reused by the next build (if there are no build script modifications):

Reusing configuration cache.

...

51 actionable tasks: 2 executed, 49 up-to-date

Configuration cache entry reused.

As a plugin user, if you find that commonly used plugins are unsupported, you can first search whether the same issue has already appeared. For example, here's an issue that occurred with Kotlin 1.4.32 plugin and Gradle 7.0:

In this YouTrack issue, we can see that upgrading the Kotlin plugin to version 1.5.0 or above solves the problem.

In fact, the core plugins of AGP/Kotlin/Gradle (mainly the Tasks behind them) already support Configuration Cache in recent versions. You can learn more through these documents/issues:

As a plugin developer, you also need to be concerned with Configuration Cache adaptation work. The key point is: Task parameters and internal implementations need to avoid directly passing in/using Gradle's Context classes and some non-serializable classes. Taking my maintained Seal plugin as an example, it's a small plugin that solves AndroidManifest.xml conflicts. Running /gradlew --configuration-cache :test-app:assembleDebug reveals two issues to fix:

Through the Configuration Cache HTML Report output at the end of the build, we can view the detailed stack trace:

For this error, we simply need to change project.logger to a this.logger reference:

For more complex rules and use cases, refer to Gradle's documentation and AGP's journey to Configuration Cache compatibility (fixing over 400 issues):

Finally, there's an official Gradle-maintained android-cache-fix-gradle-plugin. For some special AGP build cache and configuration cache issues, you can check here - it might be exactly what your project encountered.

Non-transitive R-classes

In fact, R file features like this have been developing for many years. You can refer to this article organized in chronological order. However, the latest nonTransitiveAppRClass feature requires AGP 7.0 or above. Currently there's limited documentation, with partial mention in the Android Studio Arctic Fox release notes:

Non-transitive R class refactoring: Using non-transitive R classes in Android Gradle Plugin can bring faster build speeds for apps with multiple modules. It prevents resource duplication by ensuring that each module only contains references to its own resources without pulling references from dependencies. You can use this feature through Refactor > Migrate to Non-transitive R Classes.

Enable it as follows:

This operation helps you automatically add two lines of feature-enabling code to gradle.properties and rebuilds the project:

Cacheable Lint Task

Lint has always been a time-consuming task. After AGP 7.0 (originally planned for 3.5, see this document), it finally becomes a cacheable Task.

Others

Additionally, AS + AGP have had some improvement points since 4.x:

Gradle Kotlin DSL experience and performance improvements - you can see the Google I/O Android App project has been completely converted to *.gradle.kts scripts;
AAPT2 performance improvements;
Performance improvements from JDK 11;
...

You can find this information in the AGP/AS Release Notes.

New DSL

DSL Doc Migration to android.com

The old AGP DSL documentation hasn't been updated since 3.4. The new documentation has migrated to android.com, making it more unified. You can still view by version:

Current Release: i.e., stable version 4.2;
Preview Releases: i.e., beta 7.0 and alpha 7.1 test versions;
Past Releases: all previous old versions, but due to transitions/switches in between, documentation for versions 3.5 -> 4.0 is actually missing;

This change is also reflected in google source tags. For AGP source code, gradle-x.y.z tags no longer exist after 3.4. Currently you can use studio-x.y.z such as studio-4.2.0 to reverse-locate AGP versions.

AGP Upgrade Assistant Provided by Android Studio

To help developers upgrade AGP conveniently and smoothly, AGP in cooperation with AS has launched the upgrade assistant feature. This new feature has iterated through several versions and is currently very useful for upgrading Gradle Groovy DSL scripts. When you see an upgrade prompt (usually when first opening a project):

Clicking Upgrade will also have a preview function (screenshot from session slide):

However, support for Gradle Kotlin DSL still needs to be completed. For example, migration of deprecated DSL like basic compileSdkVersion is not yet supported:

Of course, complex object references also cannot be directly modified for you, such as classpath(Deps.agp) - this is beyond the scope of what the tool can do. You can treat it as an auxiliary tool similar to Java to Kotlin conversion - first use it to quickly upgrade and organize basic DSL, then manually modify the small portions that have errors by referring to the DSL documentation.

New Variant API

Variant API is the most important update related to Android and plugin development in the past two years. For friends who haven't developed cooperative plugins for AGP before, you can understand "what is Variant" through the image below:

The Variant API update can be summarized as: To make cooperative plugin developers depend on more stable APIs, the original com.android.tools.build:gradle package has been split into gradle and gradle-api packages, achieving separation of interface and implementation. From a practical perspective, we can focus on two parts: Variant traversal entry changes and simplification of some custom Tasks.

Variant Traversal Entry Changes

Most AGP ecosystem cooperative plugins need to register Variant-aware Tasks, i.e., traverse Variants to register corresponding custom Tasks, such as the Seal plugin's postUpdateDebugManifest and postUpdateReleaseManifest mentioned above. You must have seen code like this (Groovy):

def android = project.extensions.android
android.applicationVariants.all { variant ->
    def variantName = variant.name.capitalize()
    createTask(project, variantName)
}

Or the Kotlin version:

val androidExtension = project.extensions.findByType(AppExtension::class.java)!!
androidExtension.applicationVariants.all { variant ->
    val variantName = variant.name.capitalize()
    createTask(project, variantName)
}

For plugins applicable to libraries, you need LibraryExtension and libraryVariants.

This type of API has now changed to new API calls within gradle-api:

val androidExtension = project.extensions.getByType<ApplicationAndroidComponentsExtension>()
androidExtension.onVariants { variant ->
    ...
}

The Variant obtained here is com.android.build.api.variant.ApplicationVariant, and the Extension comes from com.android.build.api.extension.ApplicationAndroidComponentsExtension. Another interface you might use is beforeVariants(...), used to control Variant building, such as globally modifying some Variant properties. From this Snippet we might not see the specific changes in Variant, but behind these changes are standardized Variant state transitions, public APIs, etc.

Simplification of Some Custom Tasks

This type of simplification refers to simplification of Task insertion points and Task parameter acquisition (injection). APIs providing such features are also called Artifact APIs. In the classic pattern: for insertion points, we generally manually find the Task's dependency relationships and use Gradle APIs to reorganize dependencies (you might even need to customize some new lifecycle anchor Tasks to assist); for Task parameters, various tricks are employed to find the data we need from existing Task parameters/intermediate products/private objects, then inject them into custom Tasks. Now Artifact APIs standardize a set of operations, enabling us to easily interact with existing data and intermediate products. From a practical perspective, we can divide into two patterns:

Complex Transform/Append/Create operations: one-stop service for inserting Tasks at specific nodes and Task parameter injection, generally suitable for needing to define a specific insertion point;

androidComponents {
    val gitVersionProvider = tasks.register<GitVersionTask>("gitVersionProvider") {
        gitVersionOutputFile.set(
            File(project.buildDir, "intermediates/gitVersionProvider/output"))
        outputs.upToDateWhen { false }
    }
    onVariants { variant ->
        val manifestProducer = tasks.register<ManifestProducerTask>("${variant.name}ManifestProducer") {
            gitInfoFile.set(gitVersionProvider.flatMap(GitVersionTask::gitVersionOutputFile))
        }
        variant.artifacts.use(manifestProducer)
            .wiredWith(ManifestProducerTask::outputManifest)
            .toCreate(SingleArtifact.MERGED_MANIFEST)
    }
}

Pure Get: actively obtaining intermediates, generally suitable for relatively independent Tasks without strict insertion position requirements (but there are implicit Task dependencies through Provider passing), without replacement operations needed:

androidComponents {
    onVariants { variant ->
        project.tasks.register<DisplayApksTask>("${variant.name}DisplayApks") {
            apkFolder.set(variant.artifacts.get(SingleArtifact.APK))
            builtArtifactsLoader.set(variant.artifacts.getBuiltArtifactsLoader())
        }
    }
}

From a practical perspective, the new Variant interface and Extension interface have fewer public APIs than before, but they're more standardized. Artifacts as a supplement to manually obtaining Task input/output currently has relatively few public APIs. I hope plugin developers will submit more issues to the AGP team when encountering reasonable APIs that should be public but aren't yet :).

Additionally, due to space limitations, I cannot introduce all Variant API updates here, including the introduction of new Provider<T> API (Lazy Configuration), Variant state transitions, more types of Artifacts API usage, how to learn from its design to solve those interfaces that haven't been encapsulated/exposed yet, etc. You can get more inspiration from these materials:

From Gradle properties to AGP APIs - Android Dev Summit '19: Explains the cornerstone of Variant API — Provider<T> API and its multiple derived subclasses, Variant state transitions and multiple usage patterns of its API;
New APIs in the Android Gradle Plugin - Android Developers Blog: Introduces the origin of Variant API design ideas and use of new APIs;
android/gradle-recipes: Provides Groovy/Kotlin DSL sample code for common Variant API usage;
Android Gradle Plugin DSL/API migration timeline: Milestones for New DSL and Variant API over the next three years;
Lazy Configuration: Task configuration lazy acquisition, Provider<T> and its various subclasses, Task implicit dependencies, etc.

New ASM API

ASM API is a replacement for the previous Transform API, aimed at providing a lower-cost insertion point between Class -> Dex for modifying bytecode. It no longer has the flexibility of the previous Transform API - for example, it currently appears to be bound to the ASM bytecode tool and doesn't support Javassist or Aspect. However, at the same time, it has better performance, lower usage cost (referring to implementing the transform itself, because ASM is actually a lower-level API compared to Javassist and Aspect - more flexible but with higher learning cost), and easier adaptation to new Gradle features. It's currently just starting incubation. From the API Doc perspective, developers are not yet recommended to use it to build production environment plugins.

abstract class ExamplePlugin : Plugin<Project> {

    override fun apply(project: Project) {

        val androidComponents = project.extensions.getByType(AndroidComponentsExtension::class.java)

        androidComponents.onVariants { variant ->
            variant.transformClassesWith(ExampleClassVisitorFactory::class.java,
                                 InstrumentationScope.ALL) {
                it.writeToStdout.set(true)
            }
            variant.setAsmFramesComputationMode(FramesComputationMode.COPY_FRAMES)
        }
    }

    interface ExampleParams : InstrumentationParameters {
        @get:Input
        val writeToStdout: Property<Boolean>
    }

    abstract class ExampleClassVisitorFactory :
        AsmClassVisitorFactory<ExampleParams> {

        override fun createClassVisitor(
            classContext: ClassContext,
            nextClassVisitor: ClassVisitor
        ): ClassVisitor {
            return if (parameters.get().writeToStdout.get()) {
                TraceClassVisitor(nextClassVisitor, PrintWriter(System.out))
            } else {
                TraceClassVisitor(nextClassVisitor, PrintWriter(File("trace_out")))
            }
        }

        override fun isInstrumentable(classData: ClassData): Boolean {
            return classData.className.startsWith("com.example")
        }
    }
}

The APIs used in the code above can be referenced in these documents:

For friends unfamiliar with classic Transform, you can check out several well-known Transform library encapsulations (coincidentally all from Chinese companies' open-source projects):

ByteX (active)
Booster (active, partially used)
Lancet (inactive)

Summary

From a developer's perspective, the Android Tools team is paying more attention to Engineering Experience in AGP & AS. While solving many legacy issues, this session also revealed long-term plans for building the AGP ecosystem. I hope to see these things truly accepted by more Android developers next year, and I'll definitely write another summary and outlook for 2022.

Pitfalls of MavenCentral Publishing Integration

2021-05-09T00:00:00Z

Due to JCenter shutting down, I recently migrated the publishing process of several active open-source projects to MavenCentral. The two reference articles below already explain the details of each step quite well:

However, I still encountered some pitfalls during this process, as well as some baffling operations, which prompted me to write this article to share.

Don't Apply for a Single Artifact

When applying for an OSSRH Ticket, what we're actually applying for is a Group ID. The key parameter is the Group Id; the title doesn't even need to mention the specific Artifact.

Generally, the Group ID is the reversed domain name. You'll be asked to verify domain ownership, Github repository ownership, JCenter Group ownership, etc. Just follow the corresponding reply instructions. Once approved, all future new package publishing won't require another application. For example: if I apply for the me.2bab group, then all future me.2bab.* publishing will be supported.

Implicit Configuration of Signing Plugin

To verify the legitimacy of uploads, we sign the packages to be uploaded using GPG, using Gradle's official The Signing Plugin. When I first integrated it, I followed the steps in the two tutorials above and always felt something was off: I didn't see myself passing the key information needed by the signing plugin into the plugin.

// The most basic DSL configuration for the plugin is just this one line
signing {
    sign(publishing.publications)
}

After briefly browsing the documentation, you'll discover that it actually defines some Keys by convention, and the plugin configuration reads directly from the Project's Properties.

// So you can see the reference tutorial writes it like this
ext["signing.keyId"] = ...
ext["signing.password"] = ...
ext["signing.secretKeyRingFile"] = ...

And this convention that I never knew was possible, referring to Build Environment:

// Using the following setup, you can pass the secret key (in ascii-
// armored format) and the password using the
// ORG_GRADLE_PROJECT_signingKey and ORG_GRADLE_PROJECT_signingPassword
// environment variables, respectively:
signing {
    val signingKey: String? by project
    val signingPassword: String? by project
    useInMemoryPgpKeys(signingKey, signingPassword)
    sign(tasks["stuffZip"])
}

I really dislike this overly "implicit" convention - you can't know what you've actually written without carefully reading the documentation. Fortunately, there's also an explicit configuration method:

signing {
    val signingKeyId: String? by project // Where to put it is optional, not necessarily using Project Properties
    val signingKey: String? by project
    val signingPassword: String? by project
    useInMemoryPgpKeys(signingKeyId, signingKey, signingPassword) // This line is the key
    sign(tasks["stuffZip"])
}

Similar approaches are used in some experimental configs of Android Gradle Plugin, but due to their widespread existence and usage, perhaps people are too tired to complain (though most switches can still be configured directly from the DSL). If you don't see the problem here, consider this scenario:

Obviously, DSL can provide constrained configuration. With excellent DSL, you can understand what APIs are available and how to interact just through IDE completion;
If all plugins use such implicit configuration, losing the advantages of DSL, it's no different from writing a JSON configuration - too loose, error-prone, hard to get started. You might not know which configuration file corresponds to which module, whether this Key is correct, etc.;

Next time I update the plugin, I plan to change to useInMemoryPgpKeys(...), otherwise after a year I'll forget this pitfall, or anyone taking over your project who doesn't understand the Signing plugin will be confused again.

Signing Plugin Key Path Specification

If you use the signing.secretKeyRingFile configuration, you need to consider different configurations for local and CI environments:

Local: ../local/secret.gpg, recommended to place in the project root directory or create a local folder and add the entire folder to gitignore. The reason is that one machine might use more than one secret.gpg; keeping the key with the project makes it easier to find, and setup is also convenient for other collaborators;
CI: /secret.gpg, placed directly in the virtual environment root directory, convenient for coordinating with the RingFile generation script;

Batch Upload + Control Panel Operations

I recently saw someone's MavenCentral publishing tutorial on Juejin mentioning not to upload multiple packages and then Close together. In fact, this is supported and recommended - packages with the same Group ID will be placed in one staging repo, and can then be closed & released together. If you've referenced plugins that automatically handle the close & release process, aggregate upload (batch upload) can actually improve the success rate of subsequent operations (SonaType's API and webpage are not very stable). For example, this project of mine has six modules and actually uses the Batch Upload strategy.

Build Guide #9 Debugging Gradle Scripts

2021-02-14T00:00:00Z

"Build Guide" is a series of articles exploring Android build-related topics, covering Gradle, Android Gradle Plugin, Kotlin Script, and other tools, as well as their architectural applications. Starting from problem discovery and resolution, and landing on sharing new knowledge to improve productivity.

This article discusses the current debugging support for *.gradle.kts scripts in IDEA / Android Studio.

Debugging Capabilities

Regarding the definition of debugging capabilities, let me give an example. We add various script snippets to a common build.gradle.kts, including but not limited to property declarations, file reading, Gradle API operations, AGP API operations, etc., then set multiple breakpoints. When compiling, we remote attach to check whether it can suspend at the correct location, whether it can get context information, and whether it can perform Expression Evaluate operations.

Specific test points:

Context information inside the android { default { ... } } closure;
Context information inside the dependencies { ... } closure;
A small custom script snippet in build.gradle.kts, containing property definitions, Gradle API calls, AGP API calls - context information at these three points;
A small custom script snippet in prebuilt.gradle.kts inside /buildSrc, also containing the same three points;
A custom plugin inside /buildSrc - context information when running the plugin's apply method (as a reference for complete debugging capability).

I conducted two experiments. The first was about half a year ago using Android Studio 4.0 + IDEA 2020.1, and the second was recently using Android Studio 4.2.0-beta04 + IDEA 2021.1.EAP. The test results below all use the second IDE version plus:

Android Gradle Plugin 4.1.1
Kotlin 1.4.30
Gradle 6.8.2

Here we focus on Kotlin DSL; the Groovy DSL situation can be analyzed similarly.

Multi-module Android Project

For the first test, we used a multi-module (and multi-Application) project, with the following results:

#	Test Item	IDEA & Android Studio
1	`android { default { ... } }`	Y
2	`dependencies { ... }`	Y
3	`build.gradle.kts`
3.1		N
3.2		Y
3.3		Y
4	`prebuilt.gradle.kts`
4.1		N
4.2		Y
4.3		Y
5	plugin	Y

Quick summary:

The results from both IDEs are completely consistent (not surprising even though AS is the community edition);
Breakpoints at 3.1 and 4.1 can be correctly recognized but cannot get context information;
When debugging breakpoints in build.gradle.kts, you must manually specify which script the current source corresponds to, as shown in the dropdown menu in the image above; the basis for judgment is the context information provided by the this object in the Variables section of the current debug panel. For example, here this points to DefaultConfig, and we only set breakpoints on the defaultConfig of the app module across multiple scripts, so we select app;
In this test, Gradle script debugging support is still not comprehensive enough.

Single-module Kotlin Project

Next, let's test a simple Kotlin project:

#	Test Item	IDEA & Android Studio
1	`java { ... }`	Y
2	`dependencies { ... }`	Y
3	`build.gradle.kts`
3.1		N
3.2		Y
3.3		N/A
4	`prebuilt.gradle.kts`
4.1		N
4.2		Y
4.3		N/A
5	plugin	Y

The results are no different from the previous multi-module Android project.

Common Debugging Issues

Here are some common issues for reference:

Breakpoint Line Jumping

When dealing with some simple requirements, such as modifying generated APK names, we often write and debug scripts directly in build.gradle.kts. During debugging, although breakpoints appear to be set in AS or IDEA, various situations occur during execution where the source code cannot be matched, causing line jumping. In this case, you need to manually specify the corresponding script using the method mentioned in the summary above.

IDEA Support for Android Plugin

Note that IDEA generally supports new features faster, but support for Android Gradle Plugin lags behind Android Studio. For example, after the current 4.1.1 version of Android Studio was released, IDEA announced support for 4.1 in 2020.3.2 (but actual testing shows it doesn't support 4.1.1; the issue says 2021.1.EAP actually supports it).

Using Plugin Wrapping

In the early days based on Groovy DSL + build.gradle scripts (around AGP 2.x era), debugging support was even worse. But there was a workaround for the third test point above: wrap the custom script block in build.gradle into a Plugin. However, this is currently not viable in AS 4.2.0-beta04 or IDEA 2021.1.EAP testing. On the Kotlin DSL side, although the API documentation looks supportive, the plugin cannot actually be created, causing script compilation failure, making debugging moot. Here's a reference issue.

Run Button Displayed in build.gradle(.kts) in IDE

Additionally, some colleagues may have seen a "run button" and "menu" like this in build.gradle + IDEA 2020.x environment, similar to running a unit test or a Java main method:

However, its principle should be consistent with manually executing Gradle Sync / Build, and it hasn't changed our test results.

Summary

Gradle script (specifically *.gradle.kts, though *.gradle should be similar) debugging support is currently weak. Complex logic should use precompiled plugins/standalone plugins in buildSrc, which have complete debugging capabilities.

El's Blog

A2UI, AG-UI, and GenUI Beyond the Chat Box

Spec and Protocol

Who Is Using This Now

FAQ

References

Harness Engineering Essentials: Nine Practices for Taming AI Coding Agents

1. Why Harness Engineering

2. Prompts Are a Control Plane, Not a Persona

3. The Query Loop: Heartbeat of an Agent System

4. Tools, Permissions, and Interrupts

5. Context Governance: Memory and Compaction

6. Errors and Recovery

7. Multi-Agent and Verification

8. Team Adoption

9. Ten Principles

Building the Team While Building the Product: Notes from an AI Startup

Defining the Role

Management Planning

Building the Team

Back to the Work

Responsive Layout Fundamentals

1. Navigation

Four Navigation Patterns

Switching Logic

Platform Support

2. Content Area (Canonical Layouts)

List-Detail

Feed

Supporting Pane

Combining Layouts

Summary

Some Personal Takes on Metro DI

Core Concept: Binding

The Simplest Case: @Inject

Aggregation

Graph and Scope

Cross-Module Dependencies: Why Export Modules Exist

Trade-offs Worth Noting

BindingContainer and @Provides

AssistedInject

@ViewModelKey Redundancy

Overall Impressions

Teaching AI Coding Agents with Submodules

antfu's Approach

Putting It into Practice

Why This Works Well

Limitations

Automated AI Workflow - We Localized Popular Documentation for the Community

Four Ways to Optimize SDK Initialization Callbacks in Kotlin

Problems with the Traditional Callback Mechanism

Four Optimization Methods

1. Using AtomicBoolean to Simply Record State

Pros and Cons

2. Using CompletableDeferred to Await

Pros and Cons

3. Using Channel to Handle Producer-Consumer

Pros and Cons

4. Using SharedFlow to Handle Recurring Events

Pros and Cons

Conclusion

Adapting MediaPipe Demos for Kotlin Multiplatform: Object Detection

Object Detection Android Sample

Migration Process

Porting the Main UI and Data Structures

Integrating CameraView Functionality

Android Implementation

iOS Implementation

Simple Testing

Summary

Adapting MediaPipe Demos for Kotlin Multiplatform: LLM Inference

On-Device Model

LLM Inference Android Sample

Kotlin Multiplatform

Porting Process

Initialization

Wrapping and Calling LLM Inference

Porting UI and ViewModel

Simple Testing

Conclusion

1. Using `AtomicBoolean` to Simply Record State

2. Using `CompletableDeferred` to Await

3. Using `Channel` to Handle Producer-Consumer

4. Using `SharedFlow` to Handle Recurring Events