# Dagger Published articles for Dagger. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Koin Skills: Koin, the Right Way, with Your Agent DevFeed: [Koin Skills: Koin, the Right Way, with Your Agent]() Original publisher: [Read original article]() Author: Arnaud Giuliani Published: 2026-11-05T09:01:03Z Content type: release Language: en Sources: [Koin developers]() Topics: [Dependency injection](), [koin](), [Agent Skills](), [Claude Code](), [Dagger](), [dagger-hilt]() Tags: [agent](), [ai](), [ai-agent](), [android](), [android-compose](), [annotations](), [compile](), [compiler](), [compose](), [crashes](), [dagger](), [dagger-2](), [dependency](), [dependency-injection](), [di](), [diagnose](), [frameworks](), [hilt](), [koin](), [kotlin](), [skills]() ### AI overview The Koin plugin for Claude Code provides four skills for setup, writing Koin code, DI migration, and diagnosis, plus an optional Kotzilla MCP server. The skills target Koin 4.x and adapt to Annotations or DSL workflows; the Compiler Plugin is recommended but optional, and checks Koin DSL graphs at build time. Migration from Hilt, Dagger 2, Toothpick, Kodein, or older Koin versions is staged so both containers can coexist while modules move incrementally. Code-level diagnosis works without Kotzilla; runtime investigations such as slow startup, memory issues, duplicate instances, and scope leaks require the Kotzilla SDK for session data. The plugin is built for Claude Code; other agents can use skill archives and configure the MCP endpoint manually. ### Source excerpt Hello, dear Koin community 👋 AI agents write good Kotlin. With Koin, it's another story: outdated patterns, wrong DI decisions, or a build error fixed without looking at what happens at runtime. Today, I'm happy to share the official Koin skills for AI agents, released as the koin plugin for Claude Code. They help your agent write today's Koin: compile safety for all Koin DSL with Koin Compiler 1.2, migration from Dagger 2, Toothpick and other DI frameworks (Hilt...), and a koin skill that pushes back on DI mistakes. With the Kotzilla MCP Server, included in the plugin, your agent can also investigate how your app really behaves. Let's go through what it does, and how it helps you every day. Your coding agent, now writing today's KoinTL;DR The koin plugin brings four skills and one MCP server. Your agent picks the right one when a task touches dependency injection, and you can always call a skill by name. koin-setup: adds Koin to a new or legacy project (Android, Compose, KMP, Ktor), compile-safe from day one. koin: writes definitions, modules and injection in your project's style, and pushes back on DI mistakes. di-migration: moves you from Hilt, Dagger, Toothpick, or Kodein, one module at a time, while your app keeps shipping. It also upgrades Koin 3.x and Koin KSP projects. koin-diagnose: fixes Koin errors and crashes, and explains slow startup or instances created twice. Kotzilla MCP Server: included and optional. Once you sign in, it brings runtime data from your debug and production sessions. All skills target Koin 4.x and adapt to your project: Koin Annotations, Koin DSL with the Compiler Plugin, or Koin DSL without it. The Compiler Plugin is recommended, never forced. Why skills, why now Ask any AI agent to add Koin to your project today, and there is a good chance you get something like this: // Old Koin generate ... // build.gradle.kts ksp("io.insert-koin:koin-ksp-compiler:1.3.1") // KSP: replaced by the Koin Compiler Plugin // Application startKoin { module ## Aero-VPA: Few-Step Flow-Matching Control over Non-Reconstructive JEPA Latents for Agile Flight on Edge Hardware DevFeed: [Aero-VPA: Few-Step Flow-Matching Control over Non-Reconstructive JEPA Latents for Agile Flight on Edge Hardware]() Original publisher: [Read original article]() Author: Yeonseok Lee Published: 2026-11-04T05:00:00Z Content type: news Language: en Sources: [arXiv: Machine Learning]() Topics: [Physical AI](), [Embedded Systems](), [Embedded Software Dev]() Tags: [2](), [3d](), [agile](), [autoregressive](), [benchmark](), [benchmark-dataset](), [code](), [command](), [conditional](), [control](), [crashes](), [cs-lg](), [cs-lo](), [cs-ro](), [dagger](), [deployment](), [dispersion](), [edge](), [embedded](), [evaluation](), [flight](), [flow-matching](), [hardware]() ### AI overview Aero-VPA combines a compact RGB-D Vision Transformer, a five-head predictor trained without pixel reconstruction, and a Conditional Flow Matching controller that produces velocity and yaw-rate chunks in two Euler steps, using five sequential network evaluations per decision. In PX4 software-in-the-loop forest missions, behaviour cloning failed on all 60 missions, while DAgger policies reached 11.1-21.1% success. Adding a map-free runtime shield with depth memory, barrier constraints, a field-of-view motion cap, and path backoff raised the first DAgger policy's success from 21.1% to 52.2% over 180 paired missions and reduced crashes from 72.2% to 22.2%; timeouts increased from 2.8% to 23.3%. All six checkpoints gained 30.0-34.4 percentage points. These are simulation results; the excerpt does not report real-flight evaluation. ### Source excerpt arXiv:2611.04392v1 Announce Type: cross Abstract: Vision-Language-Action (VLA) models generalize across tasks, but their autoregressive decoders need sequential forward passes in proportion to the action horizon, each bounded below on embedded aerial platforms by streaming billions of parameters from memory. We present Aero-VPA, a lightweight Vision-Predictor-Action architecture for 3D navigation on edge hardware. A compact RGB-D Vision Transformer and a five-head ensemble predictor, trained without pixel reconstruction, forecast the next latent state; a Conditional Flow Matching solver generates a velocity and yaw-rate chunk in two Euler steps, so each decision takes five sequential network evaluations; and the ensemble dispersion drives an uncertainty fallback. Version 1 specified the architecture, deployment and protocol without results. This version reports the first closed-loop evaluation: PX4 software-in-the-loop simulation of quadrotor missions in procedurally generated forests. Behaviour cloning failed on all 60 missions despite open-loop errors of 0.02-0.04 m/s: the policy copies its last command, a copycat form of causal confusion. DAgger with a privileged, safety-gated supervisor gave the first successes but plateaued at 11.1-21.1% across six checkpoints. A map-free runtime shield with a 15 s depth memory, barrier constraints, a cap on motion outside the 73-degree field of view and backoff along the flown path raised the first DAgger policy's success on 180 paired missions from 21.1% to 52.2% (95% CI [45.0, 59.4]; exact McNemar p = 1.2 x 10^-10) and cut its crashes from 72.2% to 22.2%, while timeouts rose from 2.8% to 23.3%. All six checkpoints gained 30.0-34.4 percentage points, at mean speeds of 1.16-1.36 m/s. The code (https://github.com/ylee-sling/Aero-VPA), the trained policy (72.6 MB, https://huggingface.co/ylee-sling/aero-vpa) and the full benchmark dataset are public. ## I3L: Iterative Interactive Imitation Learning for Whole-Body Mobile Manipulation DevFeed: [I3L: Iterative Interactive Imitation Learning for Whole-Body Mobile Manipulation]() Original publisher: [Read original article]() Author: Wensi Ai, Christopher Luey, Karthik Dharmarajan, Evans Han, Yunfan Jiang, Stef Ren, Jianwen Xie, Jiajun Wu, Li Fei-Fei, Ruohan Zhang Published: 2026-11-02T05:00:00Z Content type: article Language: en Sources: [arXiv: Artificial Intelligence]() Topics: [Robot Manipulation](), [Amazon robotics research]() Tags: [abstract](), [amplify](), [arm](), [arxiv](), [autonomous](), [base](), [body](), [can](), [combines](), [cost](), [coverage](), [cs-ai](), [cs-ro](), [dagger](), [deployment](), [distribution](), [imitation](), [interactive](), [learning](), [manipulation](), [mobile](), [mobile-manipulation]() ### AI overview I3L combines a low-cost, open-source JoyLo+ interface for coordinated whole-body corrections with iterative deployment and retraining, letting operators target failures of the updated policy. In evaluations across three robot embodiments and eight simulated and real-world tasks, four-round HG-DAgger achieved the highest final success in controlled simulations on both tested tasks. Under this protocol, autonomous success rose by an average of 68.3 percentage points over base policies and reached at least 90% on every task; it exceeded demonstration-only training by 35.6 points on average with the same number of training trajectories. Average takeover duration per episode fell 72% over four rounds. The abstract does not provide further experimental details. ### Source excerpt arXiv:2610.17748v2 Announce Type: replace-cross Abstract: Policies trained offline from teleoperated demonstrations can degrade outside their training distribution. This gap is particularly acute in long-horizon whole-body mobile manipulation, where long horizons amplify compounding errors and coordinated arm, torso, and base motion makes exhaustive demonstration coverage impractical. We introduce I3L, an integrated hardware and learning system that combines whole-body correction with iterative policy refinement to address this last-mile reliability gap. Its low-cost, open-source JoyLo+ interface uses policy-tracking leader arms and touch-triggered takeover to enable coordinated corrections across the body parts, while iterative deployment and retraining allow operators to target failures of the updated policy. We evaluate I3L across three robot embodiments and eight simulated and real-world tasks, including four long-horizon whole-body mobile manipulation tasks. Controlled simulation experiments show that four-round HG-DAgger achieves the highest final success on both tasks. Under this protocol, I3L improves autonomous success over the base policies by an average of 68.3 percentage points and achieves at least 90% success on every task, outperforming demonstration-only training by 35.6 percentage points on average with the same number of training trajectories. Averaged across tasks, takeover duration per episode decreases by 72% over four rounds. Together, these results show that I3L helps close the last-mile gap between offline training and reliable deployment and provides practical insights into collecting and using corrections for long-horizon whole-body mobile manipulation. Videos, visualizations, and appendix are at https://i-3l.github.io/. ## WNM-3D: A World Navigation Model with 3D Scene Conditioning for Closed-Loop VLN DevFeed: [WNM-3D: A World Navigation Model with 3D Scene Conditioning for Closed-Loop VLN]() Original publisher: [Read original article]() Author: Yuehao Huang, Yunzi Wu, Xiaotao Zhang, Xinhai Li, Jiankun Dong, Sunyao Zhou, Jiajun Lv, Chi Zhang, Chenjia Bai, Yong Liu, Xuelong Li Published: 2026-10-30T04:00:00Z Content type: article Language: en Sources: [arXiv: Artificial Intelligence]() Topics: [World models](), [Robot Navigation](), [grpo](), [Physical AI](), [diffusion-transformers](), [model architecture]() Tags: [3d](), [attention](), [continuous](), [cs-ai](), [cs-cv](), [cs-ro](), [dagger](), [diffusion](), [generative](), [language](), [language-models](), [learning](), [model](), [navigation](), [policies](), [rgb](), [robot](), [training](), [transformer](), [video](), [view](), [vision](), [world]() ### AI overview WNM-3D combines future-view and action generation for continuous vision-language navigation, conditioning both on persistent 3D scene context. A frozen geometry encoder derives cross-view features from monocular RGB history, and a trainable adapter turns them into a fixed-length prefix that remains available to each future video-action block during joint denoising. Training combines supervised world-action learning, DAgger-style adaptation on policy-visited states, and Counterfactual DanceGRPO refinement. The abstract reports consistent gains over backbone-matched WNM-2D on GN-Bench and VLN-CE, stronger results than VLN baselines on GN-Bench, and closed-loop deployment on a physical robot. Ablations support the adapter and the complementary roles of adaptation and reward-guided refinement; numerical effect sizes are not provided. ### Source excerpt arXiv:2608.07267v3 Announce Type: replace Abstract: Recent vision-language navigation (VLN) systems increasingly adapt pretrained vision-language models (VLMs) into vision-language-action (VLA) policies that map egocentric observations and language instructions directly to navigation actions. Although semantically capable, such action-centric training does not explicitly model how the agent's visual observations evolve under its predicted motion. Generative world-action models (WAMs) jointly predict future observations and actions, yet existing WAMs for continuous VLN do not condition joint future-view and action generation on geometry-aware representations inferred from the observation history. We present WNM-3D, a generative World Navigation Model with 3D scene conditioning for continuous VLN. A frozen feed-forward geometry encoder extracts cross-view representations from monocular RGB history, and a trainable 3D Scene-to-Token Adapter converts them into a fixed-length scene prefix for the world-action Diffusion Transformer. Through block-causal attention, this prefix remains visible to every future video-action block throughout joint denoising, providing persistent geometric context. We train WNM-3D with supervised world-action learning, DAgger-style adaptation on policy-visited states, and Counterfactual DanceGRPO refinement. Across GN-Bench and VLN-CE, WNM-3D consistently outperforms the backbone-matched WNM-2D counterpart, demonstrating gains from 3D scene conditioning across distinct visual domains. WNM-3D further outperforms strong VLN baselines on GN-Bench and demonstrates closed-loop deployment on a physical robot. Component and stage-wise ablations support the Adapter design and the complementary roles of DAgger-SFT and subsequent reward-guided refinement. ## Migrating a Real Android App to Kotlin Multiplatform 1/4 -- Before the Migration DevFeed: [Migrating a Real Android App to Kotlin Multiplatform 1/4 -- Before the Migration]() Original publisher: [Read original article]() Author: Daniel Voko Published: 2026-10-29T17:33:38Z Content type: article Language: en Sources: [ProAndroidDev]() Topics: [Kotlin](), [Android](), [Jetpack Compose](), [compose-multiplatform](), [CI/CD]() Tags: [android](), [android-app-development](), [androiddev](), [app](), [architecture](), [best-practices](), [bike](), [browser](), [case-study](), [code](), [compose](), [compose-multiplatform](), [core](), [dagger](), [data](), [domain](), [feature](), [ios](), [jetpack](), [kotlin](), [kotlin-multiplatform](), [migration](), [multiplatform]() ### AI overview BikeHub moved from native Android to Kotlin Multiplatform while keeping Android releasable at every step; about 84% of its Kotlin now lives in commonMain, with Android, iOS and WebAssembly targets. The migration benefited from early choices of KMP-compatible Ktor Client, Koin and SQLDelight, so networking, dependency injection and persistence mostly moved rather than needing replacement. Modularization provided a module-by-module migration order, limited failures to individual modules and made it practical to pause between releases. Android-specific code was pushed behind interfaces at platform boundaries, and the iOS app was kept to a thin Swift entry point and platform wiring. The author says they would add another target to CI as soon as the first module is converted, since Android-only code can compile in commonMain while still failing on other platforms; smaller, single-responsibility core modules would also have saved time. ### Source excerpt BikeHub is KMP app that runs on Android, on iOS and in the browser via WebAssembly. It started as native Android. Around 84 percent of its Kotlin code lives in commonMain. At no point during the migration did the Android app stop being releasable. This isn't a story about a heroic rewrite. The real story is less dramatic and, I think, more useful: the migration was easier than it could have been because of choices made long before it started. How much a platform shift hurts is decided largely by architectural decisions made years earlier, often for entirely different reasons. This series isn't a KMP tutorial either. This is a case study of a real app that already had users, history and assumptions baked into its code: what moved easily, what hurt, and what I'd do differently. Part 1 covers the foundations. Where it started BikeHub is a bike maintenance tracker. It pulls your mileage from Strava, tracks wear on parts like chains, cassettes and brake pads, and tells you when something is due for a service. It is a side project, that has its own story. Initially started to try out new libraries and best practices and was for an audience of one. Later it turned into something I wanted to release to wider audiences. It started as a native Android app, split into 24 feature modules and 14 core modules (before the start of the migration). Today it has both more feature modules and more granularized core modules: Where it started Kotlin, Jetpack Compose, a layered architecture, UDF in the presentation layer, and a reasonable number of modules make it a fairly standard modern Android stack. What made the difference later wasn't how modern each piece was, but how portable it turned out to be. Choices made before the migration Ktor Client and Koin were in the app from day one, and both already supported Kotlin Multiplatform. Ktor Client is something I prefer over Retrofit, and Koin is something I prefer over Dagger. When the data and domain layers moved to shared code, the net ## Projected Distillation: On Learning to Solve Hard Problems from Close, Correct Targets DevFeed: [Projected Distillation: On Learning to Solve Hard Problems from Close, Correct Targets]() Original publisher: [Read original article]() Author: Shripad V. Deshmukh, Christian Bock, Kangrui Ruan, Abhijeet Awasthi, Vijay Lingam, Rein Houthooft, Manish Prajapat Published: 2026-10-21T04:00:00Z Content type: article Language: en Sources: [arXiv: Machine Learning]() Topics: [Post-training optimization](), [Machine learning](), [post-training](), [Language models](), [grpo](), [llm-reasoning]() Tags: [capabilities](), [code](), [cs-ai](), [cs-lg](), [dagger](), [distillation](), [distribution](), [fail](), [failed](), [grpo](), [horizon](), [learning](), [math](), [model](), [online](), [retention](), [reward](), [rl](), [solve]() ### AI overview Projected distillation addresses hard problems where a student's attempts all fail: it minimally edits failed attempts into correct targets, uses contrastive updates to favor corrections, and refreshes them as the student changes. The abstract argues that smaller edits keep training closer to the student's distribution: regret grows linearly with horizon under minimal correction, versus quadratically under full-answer replacement. Across Qwen3-8B and OLMo-2-7B in five domains, it reports the highest specialization-retention frontier in 8 of 9 cells against GRPO and OPD, and 7 of 9 against SPOT and SODA. Ablations report retention falling from 0.916 to 0.744 when minimal corrections are replaced with student-agnostic gold solutions. These are abstract-level claims; the supplied text does not provide experimental details. ### Source excerpt arXiv:2610.27467v1 Announce Type: new Abstract: On-policy learning is central to post-training: training on a model's own generations limits distribution shift and helps preserve existing capabilities. On hard problems, however, on-policy RL provides no reward-based learning signal when all attempts fail. On-policy distillation provides next-token supervision from a teacher, but on hard problems, if a rollout goes wrong early, subsequent supervision is conditioned on prefixes that already contain the mistake. Correct behavior can instead come from a gold or teacher solution, but such off-policy targets can differ substantially from the model's generations and, as we show, may erode existing capabilities. We therefore treat on-policyness as a continuum and propose projected distillation, which minimally edits the student's failed attempts into correct targets. The method uses contrastive updates to favor corrections over failed attempts and refreshes these corrections as the student evolves, enabling near-on-policy learning even when all student attempts fail. Theoretically, we prove that the student's learning regret grows with the edit size: it scales linearly with the horizon under minimal correction, as in DAgger, and quadratically under full-answer replacement, as in behavior cloning. Empirically, across two students (Qwen3-8B and OLMo-2-7B) and five domains spanning math, code, science, and tool use, projected distillation gives the highest area under the specialization-retention frontier (best on 8 of 9 cells against GRPO and OPD, and 7 of 9 against SPOT and SODA). Our ablations highlight the importance of online corrections, the contrastive loss, and on-policyness: moving targets farther off-policy steadily worsens the specialization-retention trade-off, with retention falling from 0.916 to 0.744 when minimal corrections are replaced by student-agnostic gold solutions. ## Metro DI for KMP mobile: From God Objects and manually checked Singletons to Compile-Time Injection DevFeed: [Metro DI for KMP mobile: From God Objects and manually checked Singletons to Compile-Time Injection]() Original publisher: [Read original article]() Author: FunkyMuse Published: 2026-05-24T17:30:00Z Content type: tutorial Language: en Sources: [FunkyMuse]() Topics: [Mobile](), [Code](), [Android](), [iOS](), [Java](), [Dagger]() Tags: [android](), [code](), [dagger](), [di](), [ios](), [jvm](), [kmp](), [kotlin](), [mobile]() ### AI overview This article describes migrating the mobile side of the Rudio Kotlin Multiplatform project from God Objects, custom thread-safe singletons, and manually managed lazy dependencies to Metro's compile-time dependency-injection graph. It explains different startup and platform-binding requirements for Android, iOS, and JVM desktop, including Android integration with Room and platform-specific Metro hooks. ### Source excerpt The Starting Point: God Object, Custom Singletons, and Lazy Maps In the previous article i talked about how the Ktor backend replaced a God Object BackendComponent with Metro's compile-time graph. The mobile side of Rudio had a remarkably similar story, except it was more interesting because there were actually two God Objects working together and someone (looks in the code, realizes it was me... ## Introducing the Koin Migration Skills DevFeed: [Introducing the Koin Migration Skills]() Original publisher: [Read original article]() Author: Arnaud Giuliani Published: 2026-04-22T13:23:59Z Content type: release Language: en Sources: [Koin developers]() Topics: [koin](), [dagger-hilt]() Tags: [android](), [bridging](), [claude](), [claude-code](), [compiler](), [dagger](), [dagger-hilt](), [dependency-injection](), [di](), [dsl](), [github](), [hilt](), [human-in-the-loop](), [install](), [inventory](), [kodein](), [koin](), [kotlin](), [ksp](), [mapping](), [migration](), [skills]() ### AI overview The Koin Migration Skill is an open-source Claude Code plugin for moving Kotlin and Android projects to Koin 4.x, with the Koin Compiler Plugin when possible. It supports migrations from Hilt, Dagger, Toothpick, Kodein, older Koin versions, classic Koin DSL, and Koin KSP annotations. It inventories modules and bindings, ranks them by complexity and dependencies, then recommends a leaf-first sequence. Migrations proceed module by module, with the old container kept alongside Koin and Hilt bindings bridged through koin-android-dagger or @EntryPoint bridges. Before editing files, the skill presents a plan and asks about key choices, including whether to make a project-wide Kotlin version update or use Safe DSL without the compiler plugin. Its stated safeguards include per-module, configuration-group, and full-graph compile-time checks, which can be temporarily disabled. The excerpt also notes KMP support and modern Koin conventions. ### Source excerpt Hello all 👋 Migrating a Kotlin or Android project between DI frameworks (Hilt, Dagger, Toothpick, Kodein, or older Koin versions) is one of those strategic refactors that every team puts off. It touches every module, the call sites are everywhere, and the migration plan never quite survives contact with the real codebase. We wanted to take the pain out of it. So we built the Koin Migration Skill: a Claude Code plugin that automates DI migrations to Koin 4.x and the Koin Compiler Plugin, module by module, with compile-time verification and a human-in-the-loop at every step. Koin Migration Project -- 1.0.0What it covers Initially, this project is intended to help Koin developers to migrate to use the new Koin Compiler Plugin. The skill supports every realistic migration path into modern Koin, with Koin Compiler if possible. This uses either annotations or the safe DSL: Hilt -> Koin (with koin-android-dagger bridging during migration) Dagger -> Koin Toothpick -> Koin Kodein -> Koin Koin 3.x -> Koin 4.x upgrade Classic Koin DSL -> Safe DSL Koin KSP Annotations -> Koin Compiler Plugin All paths converge on the same target: Koin 4.x with Annotations or Safe DSL, powered by the Koin Compiler Plugin for compile-time DI graph verification. How it works Project documentation is available: https://github.com/InsertKoinIO/koin-migration. Point Claude at your project and describe what you want to migrate. /plugin marketplace add InsertKoinIO/koin-migration /plugin install koin-migration@koin-migrationAdding Skill in current project The skill opens with a full inventory of your DI setup: every module, binding, qualifier, and scope. It immediately produces a ranked migration table. The NowInAndroid project below has 35 DI files across core, feature, app, and sync layers. The skill maps each one: bindings count, downstream dependants, complexity rating, and a recommended order. Modules inventory, DI features usage and mapping You can't go "big-bang" in that kind of approach. You need to st ## Re: Dependency Injection vs. Service Locators DevFeed: [Re: Dependency Injection vs. Service Locators]() Original publisher: [Read original article]() Author: Zac Sweers Published: 2026-02-20T05:10:16Z Content type: opinion Language: en Sources: [Zac Sweers]() Topics: [Dependency injection](), [Dagger](), [koin](), [Kotlin](), [service](), [multiplatform]() Tags: [dagger](), [dependency-injection](), [koin](), [kotlin](), [metro](), [service]() ### AI overview The article compares dependency injection frameworks with service locators, focusing on compile-time validation, testing, isolation, generated performance, and the tradeoff of requiring more explicit code. It discusses Metro, Dagger, Hilt, Anvil, kotlin-inject, Koin, and manual dependency injection. ### Source excerpt This is a port of a write-up I did in the Kotlin Lang slack here in response to the question "Dagger vs. Hilt vs. Koin vs. Metro vs. . Serious question: Are there any compelling reasons to switch from Koin to Metro in a ## From Dagger to Metro DevFeed: [From Dagger to Metro]() Original publisher: [Read original article]() Author: Andrius Semionovas Published: 2026-02-12T00:00:00Z Content type: article Language: en Sources: [Vinted]() Topics: [Dagger](), [dagger-hilt](), [Kotlin]() Tags: [android](), [anvil](), [dagger](), [dagger-android](), [dependency-injection](), [di](), [hilt](), [kotlin](), [metro](), [migration]() ### AI overview Vinted migrated its Android codebase, spanning a few hundred Gradle modules, from Dagger and Anvil to Metro as Anvil's Kotlin compiler plugin support left the team on Kotlin 1.9/K1 without incremental compilation while Kotlin 2.x and K2 adoption became pressing. The excerpt presents Metro's interoperability with Dagger, Anvil, and kotlin-inject as the key migration advantage: it let the team adopt K2 with less business-code migration than other options, reducing the time and risk of the change. The account describes the migration as bumpy; the excerpt does not provide its implementation steps or full results. ### Source excerpt Metro - modern and kotlin injection framework created by Zac Sweers. And we, Android developers at Vinted, officially and fully migrated to it! It was quite a bumpy ride for our huge codebase. Our story begins... ## Cash Android Moves to Metro DevFeed: [Cash Android Moves to Metro]() Original publisher: [Read original article]() Author: Egor Andreevich Published: 2025-11-18T00:00:00Z Content type: article Language: en Sources: [Cash App Code Blog]() Topics: [migration](), [Android](), [Dependency injection](), [Kotlin](), [Dagger]() Tags: [android](), [dagger](), [dependency-injection](), [kotlin](), [migration]() ### AI overview The Cash Android team completed a migration from Dagger and Anvil to Metro, a compile-time dependency injection framework. The move was driven by the Kotlin-heavy codebase, the complexity of Dagger's Java-based build pipeline, and Anvil's lack of K2 support. ### Source excerpt The Cash Android team have completed the migration to Metro. ## Container Use for Locally Sandboxed, Background Agents in Zed DevFeed: [Container Use for Locally Sandboxed, Background Agents in Zed]() Original publisher: [Read original article]() Author: Jeremy Adams Published: 2025-07-30T00:00:00Z Content type: tutorial Language: en Sources: [Zed Industries]() Topics: [container](), [AI-assisted coding](), [Git](), [Command-line interface](), [Model Context Protocol](), [Dagger]() Tags: [agents](), [ai-coding-agents](), [cli](), [container](), [dagger](), [git](), [mcp]() ### AI overview This article explains how to use Zed with Container Use to run background coding agents in isolated containerized environments while maintaining parallel Git worktrees. It describes using MCP, Dagger containers, and CLI commands to manage and inspect agent environments. ### Source excerpt Run AI agents in parallel without interference using containerized environments and Git Worktrees. ## Introducing Metro, a Kotlin compiler-plugin dependency injection framework DevFeed: [Introducing Metro, a Kotlin compiler-plugin dependency injection framework]() Original publisher: [Read original article]() Author: Zac Sweers Published: 2025-04-03T16:14:23Z Content type: article Language: en Sources: [Zac Sweers]() Topics: [Dependency injection](), [Compiler](), [Kotlin](), [multiplatform](), [build performance](), [Benchmark]() Tags: [anvil](), [benchmarking](), [build-performance](), [compilation](), [compiler](), [dagger](), [dependency-injection](), [error-messages](), [kotlin](), [metro](), [multiplatform]() ### AI overview The article introduces Metro, a Kotlin compiler-plugin framework for compile-time dependency injection. It combines ideas from Dagger, Anvil, and Kotlin-Inject, and describes features including dependency graph validation, code generation, multiplatform support, IDE integration, and diagnostics. The author reports benchmarked build-time improvements in a CatchUp app and notes that Metro 0.1.1 is in active development. ### Source excerpt I'm excited to share something new I've been working on the past few months! ## This Month in Julia World (August 2024) DevFeed: [This Month in Julia World (August 2024)]() Original publisher: [Read original article]() Author: Stefan Krastanov Published: 2024-09-08T00:00:00Z Content type: news Language: en Sources: [JuliaLang - The Julia programming language]() Topics: [The Julia Language](), [Tool]() Tags: [best-practices](), [binaries](), [cache](), [ci](), [community](), [compiler](), [course](), [coverage](), [dagger](), [dependencies](), [dispatch](), [extension](), [julia](), [newsletter]() ### AI overview The August 2024 newsletter highlights tradeoffs in Julia's compiler and package ecosystem. An ahead-of-time compiler aims to produce small static binaries, but its near-term plan excludes highly dynamic code, raising concerns that it could leave important Julia idioms and projects such as Dagger.jl unsupported. SciML is splitting its differential equation libraries into smaller packages to reduce dependencies and avoid compiling unused solvers, while prompting discussion about improving package extensions. The newsletter also notes a package-management configuration intended to prevent adding a package from triggering broad recompilation, JET's integration with Cthulhu for investigating runtime dispatch and inference failures, and the setup-julia CI action's support for reading the minimum Julia version from Project.toml. Other updates include a ChainRules maintainer search, funded SciML and quantum-network projects, and tools and learning resources across the Julia community. ### Source excerpt Community Newsletter for August 2024 ## Crafting Android bytecode analysis tooling using a secret ingredient (Part 1) DevFeed: [Crafting Android bytecode analysis tooling using a secret ingredient (Part 1)]() Original publisher: [Read original article]() Author: Konstantin Zolotov Published: 2024-02-09T11:50:19Z Content type: article Language: en Sources: [Bumble Tech]() Topics: [R8](), [Developer Tools](), [Android](), [obfuscation](), [Compilers and Linkers](), [APK]() Tags: [analysis](), [andriod-app-development](), [android](), [annotation](), [apk](), [apt](), [bytecode](), [compilation](), [compiler](), [dagger](), [debug](), [dependencies](), [inspection](), [java](), [jvm](), [kotlin](), [map](), [obfuscation](), [r8](), [source-code](), [tooling]() ### AI overview Inspecting compiled Dex output can reveal how source changes and dependency-provided R8 rules affect an Android app's binary, including whether debug code remains. Java or Kotlin source first becomes JVM .class files; annotation processors and Kotlin compiler plugins may generate or alter code at that stage. D8 converts classes and JAR/AAR dependencies into .dex files. When obfuscation or minification is enabled, R8 optimizes and obfuscates the bytecode and produces a mapping file recording name changes. The excerpt introduces tree shaking, which removes unused or unreachable code, and mentions inlining and outlining as structural optimizations. ### Source excerpt During the development process, we often focus on the source code but rarely inspect the compiled bytecode. This means we're missing out on a valuable source of information and data for analysis. How? Let's delve into Dex file inspection and build a tool that demonstrates how source code changes impact the compiled binary. Have you ever set R8 rules to obfuscate your app? Have you used an APK analyzer or a diffuse tool to understand how the code is compiled? Are you confident that debug code hasn't leaked into production? There's another potential pitfall: libraries may provide obfuscation rules (e.g., Gson) that merge with the ones in your project. This means third-party dependencies can alter configurations for the entire app. We often assume everything is fine and that we'll notice if something isn't right. But will we? Does this make you feel uneasy? Does it concern you? Because it certainly concerns me. Here, we'll attempt to enhance the situation and enable you to see precisely how your code changes impact the compiled binary. To better comprehend this, let's start with the code compilation process: It all begins with the Java and/or Kotlin source code, which is then compiled into JVM .class files. Note that at this stage, Java and Kotlin compilers can execute annotation processing tools (APT/KAPT) to generate source code (e.g., Dagger), and Kotlin compiler can run plugins to modify the internal code representation. Then, the D8 compiler takes these compiled classes, third-party libraries (JARs, AARs), and converts them into .dex files. However, if obfuscation and/or minification are enabled (which is almost always the case for release builds), R8 comes into play after D8. R8 obfuscates and optimises the bytecode, and additionally, R8 produces a source map file -- a special file listing all the changes and replacements. Obfuscation replaces human-readable names of various entities (classes, functions, fields, etc.) with very short, yet still unique names, for e ## What Every Android Developer Should Have in Their GitHub? DevFeed: [What Every Android Developer Should Have in Their GitHub?]() Original publisher: [Read original article]() Author: Ban Markovic Published: 2024-02-05T11:00:04Z Content type: article Language: en Sources: [Ban Markovic]() Topics: [Android](), [GitHub](), [MVVM](), [dagger-hilt](), [Dagger](), [REST API](), [RxJava](), [Test-driven development]() Tags: [android](), [android-development](), [androiddev](), [architecture](), [asynchronous-communication](), [coroutines](), [dagger](), [dependency-injection](), [fetching](), [github](), [hilt](), [jetpack-compose](), [koin](), [kotlin](), [livedata](), [mvi](), [mvvm](), [navigation](), [portfolio](), [rest-api](), [rxjava](), [unit-tests]() ### AI overview The article recommends a compact Android GitHub showcase with two screens: fetch a list from a REST API, display it, and let users open an item's details. It advises demonstrating either MVI or MVVM, organizing files by feature or type, handling asynchronous work with a library such as Kotlin Coroutines, LiveData, or RxJava, and using dependency injection with Hilt, Dagger, or Koin. It also recommends unit tests for ViewModel, UseCase, and Repository classes. The article presents these as ways to show core Android development skills to potential employers; it does not compare the listed architecture or library options. ### Source excerpt In the competitive world of Android development, having a strong GitHub portfolio is crucial for showcasing your skills to potential employers. One effective way to demonstrate your expertise is by creating a concise yet comprehensive project that highlights key aspects of Android development. In this article, we'll explore the essential components that every Android developer should have in their GitHub, focusing on a project that encapsulates fundamental skills. The Project Overview A successful showcase project should include two screens and cover the following key functionalities: Fetching and Displaying Data - Utilize a REST API to fetch a list of items. - Display this list on the first screen of the app. Navigation and Detailed Information - Enable users to navigate to a second screen by clicking on a specific item. - On the second screen, display more detailed information about the selected item. Key Considerations for the Showcase ProjectArchitecture -- MVI or MVVM Clearly implement and showcase your understanding of the chosen architecture (MVI or MVVM). Organize code files in a logical and easily understandable structure. File Organization Demonstrate a well-organized project structure, separating concerns and making codebase easily maintainable (feature-based or type-based folders structure). Asynchronous Communication Showcase your proficiency in handling asynchronous tasks by using an appropriate library (e.g., Kotlin Coroutines, LiveData, RxJava). Unit Tests Impress potential employers by including unit tests to validate the functionality of critical components (cover your ViewModel, UseCase, Repository classes with unit tests). Dependency Injection (DI): Implement and demonstrate your use of dependency injection for managing component dependencies (Hilt, Dagger, Koin). Why This Project Matters This concise project effectively showcases your abilities in: Displaying a list of items Fetching data from the internet Implementing navigation between screens ## DIY: your own Dependency Injection library! DevFeed: [DIY: your own Dependency Injection library!]() Original publisher: [Read original article]() Author: Pierre-Yves Ricau Published: 2024-01-18T20:08:04Z Content type: tutorial Language: en Sources: [Py's blog]() Topics: [Dependency injection](), [Dagger](), [Library]() Tags: [android](), [api](), [build](), [compiler](), [dag](), [dagger](), [dagger-2](), [dagger-hilt](), [dependencies](), [dependency-graph](), [dependency-injection](), [di](), [diy](), [extension-function](), [factory](), [implement](), [internals](), [java](), [kotlin](), [library](), [map](), [module]() ### AI overview The article builds intuition for dependency injection by progressing from manual construction to simplified versions of Google Guice, Dagger 1, and Dagger 2. Manual injection creates dependencies in order at a dedicated configuration point, but becomes difficult as collaborators grow. The excerpt defines an ObjectGraph as the entry point that supplies requested instances, a Factory as the creator of a type using dependencies from the graph, and a Module as the provider of factories for particular types. The article frames a dependency graph as a DAG and provides Kotlin examples; the supplied text ends while introducing Module, so later implementation details are not available here. ### Source excerpt Dependency Injection libraries are powerful tools, but they're often also intimidating & confusing. When that happens to me, I find that understanding how a tool works helps me get over the initial scare of the dark magic internals. In this article, ... ## Dependency Injection in Legacy Code DevFeed: [Dependency Injection in Legacy Code]() Original publisher: [Read original article]() Author: blundell Published: 2023-10-19T12:26:59Z Content type: tutorial Language: en Sources: [Blundell]() Topics: [Dependency injection](), [dagger-hilt](), [Android](), [Dagger](), [legacy systems](), [software-development]() Tags: [android](), [dagger](), [dagger-hilt](), [dependency-injection](), [di](), [hilt](), [intermediate](), [legacy-code](), [reference]() ### AI overview For Android legacy singletons or other classes outside the architecture managed by Hilt, the excerpt describes using a Hilt EntryPoint to retrieve dependencies from the existing Dagger graph. Define an interface annotated as an entry point, add a function for each required binding (including qualifiers), and install it in the appropriate component. The legacy code can then use the entry point through a Context reference. The approach assumes the required Dagger modules and bindings already exist; the excerpt says it does not work if the class cannot obtain a Context. ### Source excerpt This post explains how you can inject dependencies into Android legacy singletons, or any classes that aren't conforming to your current Android architecture, using Dagger & Hilt. I'll cut straight to the chase, if you have a reference to Context, (which you usually always do in spaghetti legacy code) then you can use your normal [...] The post Dependency Injection in Legacy Code first appeared on Blundell. ## Why Dagger's Provider Interface Is Simple and Flexible DevFeed: [Why Dagger's Provider Interface Is Simple and Flexible]() Original publisher: [Read original article]() Published: 2023-08-10T02:55:50Z Content type: opinion Language: en Sources: [Blogs on Ryan Harter]() Topics: [Dagger](), [Dependency injection](), [Code]() Tags: [apis](), [dagger](), [dependency-injection](), [interface](), [jvm]() ### AI overview The article examines how Dagger's javax.inject.Provider interface supports generated dependency providers and flexible object-creation strategies. It discusses shared instances, lazy and eager instantiation, and lifecycle scoping. ### Source excerpt I recently gave a presentation about how Dagger works under the hood, and I was once again struck by the elegance of the javax.inject.Provider interface. The interface is so simple it almost seems useless, but it's also incredibly flexible, and forms the basis of much of the code generated by Dagger. Like many dependency injection frameworks for JVM languages, Dagger uses and builds on the standard set of annotations for injectable classes defined in JSR-330 and provided in the javax.inject package. ## On the Road to CDI Compatibility DevFeed: [On the Road to CDI Compatibility]() Original publisher: [Read original article]() Author: Ladislav Thon Published: 2023-07-12T00:00:00Z Content type: article Language: en Sources: [Quarkus - Supersonic Subatomic Java]() Topics: [Quarkus](), [Dependency injection](), [Dagger](), [Framework]() Tags: [build](), [dagger](), [dependency-injection](), [framework]() ### AI overview The article explains Quarkus's ArC dependency injection container and its build-time architecture. It contrasts ArC with runtime-oriented CDI implementations such as Weld and Guice, and with Dagger's build-time dependency wiring, while discussing CDI Portable Extensions as a compatibility challenge. ### Source excerpt Ever since the very first days of Quarkus, the days that are now covered by the blissful fog of oblivion and the survivors only talk about them after a few pints of beer, dependency injection container was an integral part of the envisioned framework. And not just any dependency injection container -- a CDI implementation, of all things. At the very beginning, the CDI implementation used was Weld. Very soon, the Masterminds and Deep Thoughts behind the CDI work in what eventually became Quarkus, Martin Kouba and Stuart Douglas, realized that Weld cannot possibly unlock the full potential that a build-time oriented framework conceals. Thus, ArC was born. When I first heard of ArC, I thought, surely that means A reduced CDI, especially with that capitalization! Alas, I was deeply mistaken. It is a reference to an activity that I could never possibly indulge in out of the simple concern for my health and safety: arc welding. (That indeed is a backreference to Weld. There are some clever people here!) Arc Welding ArC started with one important architectural constraint that was significantly different to all other existing CDI implementations at that time: it ought to perform the heavy lifting during application build. Among others, this includes the entire bean discovery process. If you are familiar with AtInject and its various implementations, this concept doesn't come as a surprise. For example, Guice is a popular dependency injection container that does all the work at application runtime, while Dagger is a popular alternative that precomputes dependency wiring at build time. With CDI, the situation is not that simple. CDI 2.0, the latest version at that time, includes features that ultimately preclude running bean discovery at build time; most notably, the Portable Extensions API. To be able to execute portable extensions, you need to have a running CDI container (to deliver events or use the BeanManager API), you need to be able to reflect on application classes (t ## Slim down your Android components with LifecycleObserver DevFeed: [Slim down your Android components with LifecycleObserver]() Original publisher: [Read original article]() Author: james shvarts Published: 2022-11-17T21:11:40Z Content type: tutorial Language: en Sources: [Android Blog - Mobile Dev Notes]() Topics: [Android](), [dagger-hilt](), [Dagger](), [software-development]() Tags: [android](), [android-development](), [custom](), [dagger](), [dagger-hilt](), [hilt](), [jetpack](), [lifecycle]() ### AI overview A custom LifecycleObserver can move lifecycle callbacks out of oversized Android components. Implement the observer interface and override only the callbacks you need, then register it with an Activity or Fragment lifecycle; observe a Fragment's view lifecycle through its viewLifecycleOwner, which is unavailable in onCreate. Observers need not be explicitly removed, and multiple observers can organize or share lifecycle work. The excerpt also describes observing the Application/process lifecycle and says the observer can be injected with Dagger or Hilt, but its scoping discussion is truncated, so it does not establish how to configure or reuse scoped instances. ### Source excerpt Learn to create custom LifecycleObserver components and inject them with Dagger/Hilt ## Basic Auth with OkHttp and Retrofit DevFeed: [Basic Auth with OkHttp and Retrofit]() Original publisher: [Read original article]() Author: James Shvarts Published: 2022-11-05T22:25:12Z Content type: tutorial Language: en Sources: [Android Blog - Mobile Dev Notes]() Topics: [Kotlin](), [client library](), [Dagger]() Tags: [android](), [annotations](), [api](), [auth](), [authentication](), [basic](), [configure](), [custom](), [dagger](), [dagger-hilt](), [dependencies](), [gradle](), [header](), [hilt](), [http](), [kotlin](), [kotlin-android](), [okhttp](), [project](), [retrofit]() ### AI overview The post outlines a Kotlin Android example that uses OkHttp and Retrofit for an HTTP GET request to an endpoint requiring Basic Authentication. It describes routing outgoing requests through a custom component that sets the authentication header, then wiring the repository interface and implementation through Dagger/Hilt for use in a ViewModel. Moshi is listed for JSON handling, with its annotations tied to the API contract. The excerpt does not include the code or specify the exact header construction. ### Source excerpt Basic Auth example using OkHttp, Retrofit, Dagger in a Kotlin project ## Things you can do in Android Studio DevFeed: [Things you can do in Android Studio]() Original publisher: [Read original article]() Published: 2022-06-18T08:38:44Z Content type: tutorial Language: en Sources: [Posts on Adam Bennett]() Topics: [Android Studio](), [IntelliJ IDEA](), [Dagger](), [Code]() Tags: [algorithms](), [android](), [android-studio](), [blog](), [career](), [code](), [compose](), [copy](), [dagger](), [dependency](), [development](), [engineering](), [finance](), [function](), [functional](), [growth](), [intellij](), [java](), [jetpack](), [kotlin](), [money](), [opinions](), [productivity](), [scopes](), [software](), [startups](), [thoughts](), [tooling](), [training](), [tutorial]() ### AI overview A practical list of Android Studio and IntelliJ productivity features, including excluding generated files with Scopes, using scratch files to test ideas, editing multiple lines simultaneously, and accessing clipboard history. ### Source excerpt Based on a recent discussion on Twitter: a list of things that you can do in Android Studio which can make your life much easier. Hide files you don't care about If you work in a project with lots of generated code (e.g.: you use Dagger), you can exclude generated files from searches using Scopes: ## Slope-intercept library design DevFeed: [Slope-intercept library design]() Original publisher: [Read original article]() Published: 2022-04-05T00:00:00Z Content type: opinion Language: en Sources: [Jake Wharton]() Topics: [Library](), [Picasso](), [Android](), [configuration](), [Dependency injection](), [Scala]() Tags: [android](), [configuration](), [dagger](), [dependency-injection](), [http](), [jvm](), [library](), [picasso]() ### AI overview The article proposes using slope-intercept form as a way to evaluate library design. The intercept represents the initial learning and setup cost, while the slope represents how complexity changes as requirements grow. It compares Picasso, Retrofit, and Dagger to show how libraries can trade a low initial barrier for steeper long-term complexity, or require more conceptual investment up front to remain easier to extend. ### Source excerpt The equation y=mx+b defines a line in slope-intercept form. The line will intercept the y-axis at the value b and for each change in x its slope (the amount the line goes up or down) will change by m. Slope-intercept gives me a way to think about the design of libraries in relation to each other. The intercept is the initial cost of learning and setup for a library, and the slope is how the library's complexity changes over time. There's no real units here and the values are entirely subjective. Let's try it! Picasso Exactly 10 years ago today I introduced Picasso internally at Square. As an image loading library for Android, its primary selling point was a low intercept. It required no real configuration and only one line of code (even in a ListView adapter). Picasso.with(context).load("https://...").into(imageView); At the time this was a refreshing change from the existing libraries which required a lot of up-front and per-request configuration. The downside, however, was that as your needs grow the slope of complexity also grows faster than desired. Configuring the global instance, managing multiple instances, intercepting requests, and transforming images are all possible but more difficult than if the library was designed differently. Retrofit Retrofit is a declarative HTTP client abstraction for the JVM and Android. It requires configuration of a central object before you can use it to create instances of service interfaces. interface GitHubService { @GET("users/{user}/repos") Call> listRepos(@Path("user") String user); } var retrofit = new Retrofit.Builder() .baseUrl("https://api.github.com/") .addConverter(MoshiJsonConverter.create()) .build(); var service = retrofit.create(GitHubService.class); This up-front configuration gives Retrofit a higher intercept on the y-axis. Exposure to these APIs gives you an entrypoint to discover functionality and encourages you to manage their lifetimes in an efficient way for your usage allowing the slope of com [Next page]()