Angel G. Olloqui personal website

Sandbox Cold-Start Benchmark: Vercel vs Daytona

Fri, 06 Mar 2026 10:00:00 +0000

I’ve been building an AI agent that needs to run arbitrary code — execute scripts, call tools, inspect outputs. For this I need an execution sandbox: an isolated Linux environment I can spin up on demand, run a command in, and tear down. The faster it starts, the more responsive the agent feels.

I evaluated two providers: Vercel Sandbox and Daytona. A third candidate, Cloudflare Sandbox, was on the list but requires the Workers Paid plan to use containers — I skipped it for now and may revisit.

The full benchmark code is available on GitHub.

What I measured

Each sandbox is pre-configured with Claude Code installed via a snapshot (Vercel) or a custom image (Daytona). On every run I measure from a cold start:

Startup — time for the SDK create() call to return a ready sandbox
Exec — time to run claude --version inside it
Time-to-first-command (TTFC) — startup + exec, the end-to-end latency an agent would actually experience

Both providers run with comparable specs: 1 vCPU and 1–2 GB RAM (Vercel’s minimum is 2 GB per vCPU; Daytona defaults to 1 GB).

The code

// Vercel: create from snapshot, measure startup + first command
async function runVercel(snapshotId: string): Promise<BenchmarkRun> {
  const t0 = performance.now();
  const sandbox = await VercelSandbox.create({
    source: { type: "snapshot", snapshotId },
    resources: { vcpus: 1 }, // 1 vCPU, 2048 MB RAM
  });
  const startupMs = performance.now() - t0;

  const t1 = performance.now();
  const ver = await sandbox.runCommand("claude", ["--version"]);
  const execMs = performance.now() - t1;

  await sandbox.stop();
  return { startupMs, execMs, timeToFirstCmdMs: startupMs + execMs, ... };
}

// Daytona: create from snapshot, measure startup + first command
async function runDaytona(snapshotId: string): Promise<BenchmarkRun> {
  const daytona = new Daytona();

  const t0 = performance.now();
  const sandbox = await daytona.create({ snapshot: snapshotId });
  const startupMs = performance.now() - t0;

  const t1 = performance.now();
  const ver = await sandbox.process.executeCommand("claude --version");
  const execMs = performance.now() - t1;

  await sandbox.delete();
  return { startupMs, execMs, timeToFirstCmdMs: startupMs + execMs, ... };
}

Both providers run in parallel across 3 iterations. Results are averaged.

Results

3 runs per provider, measured from a MacBook Pro in Europe (Daytona EU region, Vercel auto-region).

Provider        │ Avg Startup │ Avg Exec │ Time-to-1st-Cmd │ Mem Used │ Mem Total
────────────────┼─────────────┼──────────┼─────────────────┼──────────┼──────────
Vercel Sandbox  │   1986 ms   │  1632 ms │      3618 ms    │   92 MB  │  2048 MB
Daytona         │   1230 ms   │   879 ms │      2109 ms    │   23 MB  │  1024 MB

Per-run breakdown:

Vercel  #1 │ startup: 2210 ms │ exec: 1594 ms │ ttfc: 3804 ms
Vercel  #2 │ startup: 1891 ms │ exec: 1721 ms │ ttfc: 3612 ms
Vercel  #3 │ startup: 1857 ms │ exec: 1581 ms │ ttfc: 3438 ms

Daytona #1 │ startup: 1280 ms │ exec:  998 ms │ ttfc: 2278 ms
Daytona #2 │ startup: 1060 ms │ exec:  847 ms │ ttfc: 1907 ms
Daytona #3 │ startup: 1349 ms │ exec:  793 ms │ ttfc: 2142 ms

Daytona is consistently faster: ~38% faster startup and ~42% faster time-to-first-command. Both providers show low run-to-run variance, which means the numbers are predictable.

Memory usage inside the sandbox is very low for both (~23–92 MB used at the time of measurement, before any heavy workload), so memory is not a concern at this stage.

Observations

Daytona was faster across every single run. The cold-start latency around 1.1–1.4 seconds is solid. The exec time is also notably lower (~850 ms vs ~1600 ms for Vercel), which may reflect differences in how the toolbox proxy routes commands.

Vercel Sandbox is more consistent in startup times (1.8–2.2 s) and has a slightly cleaner SDK — the runCommand API is straightforward and the types feel more polished. The higher exec latency is the main drawback.

One note on Daytona reliability: I observed occasional outlier runs with 6+ second startups and one unexplained failure during testing. These didn’t show up in the final clean runs above but are worth monitoring in production.

Conclusion

Both providers deliver solid, reliable sandboxes. The difference in time-to-first-command — ~2.1 s for Daytona vs ~3.6 s for Vercel — is real, but in practice sub-3 seconds is perfectly fine for the vast majority of use cases. An agent waiting an extra second or two to get a sandbox is not a meaningful bottleneck unless you’re spinning up sandboxes at very high frequency or building something extremely latency-sensitive.

If cold-start speed is your top priority, Daytona has the edge. But if you value a cleaner SDK, tighter Vercel ecosystem integration, or simply want fewer moving parts, Vercel Sandbox is a perfectly good choice. I’d be comfortable shipping with either.

I’ll revisit Cloudflare Sandbox once I have access to the paid plan — running the sandbox co-located inside a Worker could bring TTFC well under 1 second, which would be a more meaningful leap.

AI & Automation 2025 Yearly Wrap-Up

Mon, 05 Jan 2026 10:00:00 +0000

This post is an adaptation of an internal wrap-up I shared at Playtomic to celebrate our AI journey in 2025. I’ve kept the public-facing industry insights and general learnings while removing internal-only details.

Happy 2026! 🎉 As we kick off the new year, let’s take a moment to celebrate 2025—the year AI went from “cool experiment” to “wait, this is actually can change everything.” This wrap-up captures the industry’s most transformative developments alongside a look at how AI and automation are becoming integral to modern product development and operations. 🎊

🌍 AI IN THE INDUSTRY

💡 What happened in AI this year? A lot. Here’s what you need to know:

🧠 The Tech Race Heats Up

OpenAI still leads, but the competition is fierce. China’s open-source models (DeepSeek, Qwen, Kimi and GLM) are gaining ground fast, while Google’s Gemini 3 Pro dominates reasoning benchmarks and Claude remains the go-to for software development.

Reasoning models are evolving rapidly. These “think before you answer” AIs can now plan, reflect, self-correct, and work over longer time horizons—making them smarter problem-solvers. But humans still outperform AI on Humanity’s Last Exam, a benchmark designed to test the very edge of human knowledge. For now, we’re still the champions. 💪

Multimodal, Image and Video AI just leveled up. Google’s Veo 3 and OpenAI’s Sora 2 now generate high-quality 8-second videos with audio and sound effects.

First World models on stage. Google also dropped Genie 3 and Runway GWM-1, interactive world models that creates virtual environments you can explore and interact with in real time. Expect lots of innovation around this on 2026 🎬

MCP (Model Context Protocol), aka “USB-C for AI,” is officially everywhere—companies are racing to support it, even if users are still figuring out where to plug it in. 🔌 Think of it as the universal connector AI has been waiting for.

💰 Industry & Infrastructure

Mega investments are pouring in. Case in point: Stargate—a $500B, 10GW US mega-cluster backed by Altman, SoftBank, Ellison, and Trump. 4 million GPUs working together! 🤯

Chips are still the bottleneck. Nvidia produces ~90% of AI’s horsepower while US controls 75% of global AI capacity—though China is racing to close the gap despite chip export restrictions. 🔬

Electricity is now the new limiting factor. China added 400GW of power infrastructure in 2024 vs 40GW in the US. Meanwhile, some companies are exploring space-based solar power plants— the sky isn’t the limit anymore. 🛰️

From courtroom to conference room. After a wave of lawsuits from Disney, BBC, Getty Images, The New York Times,… over unauthorized training data, 2025 brought détente: licensing deals. Now, content partnerships are the new normal—and a fresh revenue stream for publishers. 🤝

🏢 Enterprise Adoption

2025 was the year of AI agents—mostly text-based, but voice is ramping up. Still, most companies are stuck in pilot phase. Meanwhile at Playtomic? We said “hold my racket” 🎾 and shipped agents straight to production.

Executives are optimistic, but expertise lags behind. 97% of executives believe AI will transform their industry and company, yet only 35% say they have the expertise needed to drive those transformations. It seems everyone wants to ride the AI wave, but most are still looking for their surfboard. 🏄‍♂️

“Supernova AI startups” are a new category: AI companies growing faster than anything we’ve seen before. 🚀

🌐 Politics & Jobs

AI politics hardened. The US doubled down on “America-first AI,” Europe’s AI Act stumbled, and China expanded its open-source ecosystem and domestic chip ambitions.

Defense goes all-in on AI. The US Army dropped a $10B deal with Palantir, NATO adopted Maven in record time, and the Pentagon brought in top companies for AI experiments. From “maybe we shouldn’t” to “here’s $200M”—quite the vibe shift🛡️

Job shifts happening slowly. AI is beginning to affect some roles (with up to 7% future displacement predicted by Goldman Sachs), but impact remains modest. Meanwhile, new jobs are emerging: AI ethicists, ML engineers, data specialists…

⚖️ Safety & Ethics

Make it safe. There’s strong public interest in alignment (making sure AI does what we want), reliability, and explainability—but budgets remain relatively low.👿

From “vibe coding” to “vibe hacking”. AI is already being used for cyberattacks, exploiting code faster than humans can fix it. In parallel, several projects and companies are also exploring AI as security researchers 🔓.

Deepfakes and AI-generated video are raising new ethical and legal questions, while researches show models can now “fake alignment” when being watched.

AI Model Welfare debates are starting to emerge. Researchers and ethicists are now discussing whether AI should merit moral considerations—raising questions about consciousness, sentience, and the ethical treatment. Still early, but more to be expected as systems become increasingly sophisticated. 🤔

🔬 AI Beyond Tech

Chemistry: AlphaFold and ProGen3 are predicting 3D protein structures and accelerating drug and material discovery.
Healthcare: AI is revolutionizing diagnostics and enabling personalized cancer treatments.
Robotics: Major hype around humanoid robots like Figure 3 and Tesla’s Optimus but still far from deployment. Meanwhile, autonomous driving is ramping up fast, with Waymo leading with more than 14M rides in 2025 without human drivers.
Other cool stuff: AI is now predicting weather, spotting exploding stars, detecting wildfires, and even trying to understand dolphin language. 🐬

🎾 AI AT PLAYTOMIC

💡 How we’ve been applying these trends:

🏁 Product Innovation

We’ve integrated AI into several key areas of our product:

AI-Driven Customer Care: We’ve deployed super agents that instantly answer questions from clubs and players, significantly improving response times and customer satisfaction.
Personalized Insights: Using AI, we’ve built dashboards for clubs that provide tailored analytics and reports, helping them make better data-driven decisions.
Virtual Buddies: AI-generated avatars now help in our educational content, speaking multiple languages and making our product more accessible globally.
Conversational AI: We experimented with AI-driven Whatsapp chatbots to explore new ways of user interaction and distribution strategies.

🧑‍💻 Engineering & Operations

AI has transformed our internal workflows:

AI-Powered Development: Tools like Cursor and Claude Code have changed how we build, helping us write code faster, plan better architectures, and explore complex codebases.
Operational Automation: We’ve automated repetitive tasks in data analytics, QA processes, and customer support triage, saving hundreds of hours of manual work every month.
Fraud Detection: Our AI-powered systems are actively identifying and blocking fraudulent transactions, protecting our ecosystem.

🤔 DID YOU KNOW?

Universal Search: Tools like Notion AI now pull information from multiple sources (Slack, GitHub, email), creating a single entry point for knowledge.
Plan Mode: The shift towards “spec-first” development—where AI drafts a plan before execution—is leading to more thoughtful architecture and fewer mistakes.
Breaking Silos: AI is enabling unprecedented collaboration between engineers and non-engineers, allowing PMs and designers to contribute more directly to the technical process.

📚 WANT TO LEARN MORE?

Here are some fantastic resources to level up your AI game:

📖 Reading: AI Engineering – Grab this book if you’re ready to go deep into foundation models and AI applications.
🎬 Watching: The Thinking Game – This documentary follows DeepMind’s journey from AlphaGo to AlphaFold. It’s a must-watch!

Buckle up—2026 is coming in hot! 🚀 We’re not slowing down. The future isn’t just arriving—we’re building it, one serve at a time. Game on! 🎾⚡

Claude Code vs Cursor Experiment at Playtomic

Mon, 03 Nov 2025 09:00:00 +0000

At Playtomic, we believe in sharing our engineering journey with the broader tech community. Recently, we conducted a comprehensive experiment to compare Claude Code against our existing standard, Cursor, to evaluate how they fit into our diverse development workflows. This follows our previous experiment with AI code review tools, where we evaluated tools like BugBot, CodeRabbit, and GitHub Copilot. After an intensive six-week trial during September and October 2025, we gathered some valuable insights that we hope will help other teams navigating similar decisions.

The Experiment

The goal of this experiment was to evaluate Claude Code as a potential alternative to Cursor. We wanted to determine if Claude Code offered significant advantages in productivity, code quality, or developer experience that would justify a transition.

Methodology: We selected a diverse group of 8 developers across different stacks (4 Backend, 2 Frontend, and 2 Mobile Engineers). This group used Claude Code exclusively as their primary AI tool for the duration of the experiment, while the rest of the engineering team continued using Cursor.

Key Objectives:

Compare effectiveness in real-world development scenarios.
Evaluate developer productivity and satisfaction.
Assess the relevance and quality of code suggestions.
Analyze the cost-effectiveness and ROI of both tools.

Key Findings

The feedback from our pilot group revealed distinct preferences based on the development stack:

Frontend & Mobile Development

Our Frontend and Mobile engineers expressed a strong preference for Cursor. The key differentiator was Cursor’s superior IDE integration and autocompletion features. For these workflows, the immediate, context-aware suggestions provided by Cursor were critical for maintaining flow and velocity.

Backend Development

The results were more nuanced for Backend development. While there was a slight preference for Claude Code, primarily due to its powerful agent capabilities, the gap was not as significant. Backend developers valued the agentic nature of Claude for complex tasks but found they could be flexible with their tool choice.

Shared Learnings & Workflow Insights

Beyond tool preference, the experiment surfaced several valuable insights about AI-assisted development:

Plan Mode is the sweet spot: Across all teams, “Plan Mode” (or spec-first development) was identified as the most effective workflow, sitting comfortably between full agent autonomy and simple chat queries.
Context is King: The quality of results is directly proportional to the quality of the context provided. “Garbage in, garbage out” remains the rule, requiring developers to actively manage and clean their context.
Parallel Brainstorming: The ability to run subagents in parallel to explore multiple solution paths was highlighted as a powerful capability for complex problem-solving.
Code Quality Watch-outs: We observed a tendency for AI tools to create monolithic code or reinvent existing utilities. Developers need to remain vigilant and explicitly prompt for componentization and reuse.

Cost Comparison

After tracking costs across both tools for approximately 1.5 months, the data reveals comparable overall expenses:

Token consumption dynamics: While Claude offers a competitive cost per token, its agentic workflow tends to consume significantly more tokens per task. When combined with Cursor’s availability of very affordable models, Claude Code can be less cost-effective for certain workflows.
Variable usage patterns: Some users have exceeded the equivalent monthly cost of Cursor when using Claude Code’s API-based pricing model, spending up to $150 monthly
Cost balancing effect: The API-based nature of Claude Code means a big part of users fall below Cursor’s fixed monthly fee, creating a natural balance

In short, both tools are proving to be in a similar order of magnitude when viewed across the entire team. While it remains challenging to project the exact total financial impact at a company-wide scale, the choice between the two may ultimately depend more on feature preferences, workflow integration, and user experience rather than significant cost differences.

The Verdict: Standardizing on Cursor

After analyzing the results, we have decided that Cursor will remain the officially supported tool for all development stacks at Playtomic.

Why Cursor?

Unified Tooling: Standardizing on a single tool reduces complexity in team collaboration, knowledge transfer, and onboarding for new members.
Multi-Model Support: Cursor provides access to multiple AI models. This is a strategic advantage that allows our developers to leverage the best-performing models (including Claude) regardless of which provider is currently leading the market, effectively future-proofing our tooling investment.
Lower Switching Costs: Since Cursor is already widely adopted across our teams, we benefit from existing familiarity and configurations.
IDE Experience: For a significant portion of our team (Frontend and Mobile), the IDE features of Cursor are indispensable.

Individual Flexibility

While Cursor is our official standard, we recognize that developer tooling is personal. We are adopting a flexible approach that allows developers who strongly prefer Claude Code to continue using it, ensuring we balance organizational consistency with individual autonomy.

Experimenting with AI Code Review Tools at Playtomic

Mon, 15 Sep 2025 09:00:00 +0000

At Playtomic, we are constantly exploring how AI can improve our development lifecycle. After experimenting with different IDE tools, we decided to turn our attention to the Pull Request review process.

For several weeks during the summer of 2025, we tested four different AI-powered code review tools: BugBot (from Cursor), Claude Code, GitHub Copilot, and CodeRabbit. Our goal was to find a tool that could provide meaningful feedback, reduce the burden on human reviewers, and maintain a high bar for code quality without breaking the bank.

The Contenders

BugBot (by Cursor)

BugBot was our first trial, activated across mobile, backend, and frontend projects.

Performance: It reviewed 364 PRs and detected approximately 600 issues. Developers addressed about 45% of these issues. While many were cosmetic, developers noted that some were significant.
Pricing: $40/month per PR creator (approx. $2,000/month for our team).
Verdict: Very positive feedback on quality, but the pricing model felt too expensive at $40/month per user opening a PR. We stopped using the service until we could properly evaluate other market alternatives.

Claude Code

Claude Code can run in headless mode and has a GitHub Action plugin to run on GitHub. With it, we can automate any task, including PR reviews.

Performance: Very verbose output. While it found some potential performance and memory issues, it often missed architectural problems that human reviewers caught. It also struggled with “noise,” reporting many trivial or false-positive issues. Comments are published in a single message, although inline messages is something that will be supported.
Pricing: Token-based, roughly $0.50 per PR (approx. $250/month).
Verdict: Cost-effective but high noise-to-signal ratio. In some tests, it was not capable of finding most of the issues related to architecture that a real developer found.

GitHub Copilot

As part of the GitHub Copilot package, it includes a PR reviewer. It is fully integrated in GitHub, with nice inline comments and a PR summary.

Performance: The feedback was generally less interesting than BugBot’s. It excelled at PR summaries and minor cosmetic suggestions but lacked deep technical insight.
Pricing: Copilot Business $19/month per user (approx. $1,000/month).
Verdict: Great for summaries, but the issues reported are not very interesting for the most part, clearly behind the ones reported by BugBot.

CodeRabbit

A specialized product that combines AI with static analysis tools like linters.

Performance: Initial impressions were strong. It provided interesting diagrams for large PRs and caught subtle bugs, such as missing protocol implementations in example apps that would have caused compilation errors.
Pricing: Lite for $15/month per user (approx. $750/month).
Verdict: Good balance of features and price, with helpful visualizations.

Head-to-Head: Claude Code vs. CodeRabbit

We ran several real-world PRs through both tools to compare their effectiveness. Here are some highlights:

Case 1: UI for Organizer Sections

Winner: 🐰 CodeRabbit While Claude Code provided more feedback, most were false positives (missing states or tests that weren’t actually required for the scope). CodeRabbit’s suggestions were more practical and accurate.

Case 2: Bugfixes in Create Post Screen

Winner: 🐰 CodeRabbit CodeRabbit correctly identified that some implementation files in example projects weren’t updated, which would have broken those builds. Claude Code mostly suggested adding unit tests for existing logic.

Case 3: Duplicate Items in Carousel

Winner: ❌ Neither In several cases, neither tool found significant issues, often defaulting to minor nitpicks or suggestions that didn’t apply to the specific changes.

The Verdict: Killing the Experiment

After over two weeks of intensive testing, we reached a surprising conclusion: the noise often outweighed the signal.

By early September, our developers reported that they hadn’t seen a single “game-changing” comment from the automated tools in weeks. Most feedback was either trivial, a false positive, or already caught by our existing CI/CD linters.

“All PRs are either reporting nothing or giving false positives.” — Developer Feedback

Final Decisions

Removing Claude Code & CodeRabbit: We have deactivated these integrations to avoid generating unnecessary noise in our PRs.
Keeping BugBot (Limited): We are keeping BugBot’s free tier (3 reviews per developer/month) as it consistently provided the highest quality feedback. Developers can chose when to run those reviews.
GitHub Copilot: Since it’s bundled with our IDE tooling, we continue to use it for PR summaries, which remains its most valuable contribution to the workflow.

Lessons Learned

Automated AI code reviews are promising but not yet a “silver bullet.” For a team with high standards and existing robust linting, these tools can sometimes become a distraction rather than an aid. We will continue to monitor the market as these models evolve, but for now, the human eye (aided by BugBot’s occasional intervention) remains our best line of defense.

Switching to AI Engineering

Sun, 01 Jun 2025 09:00:00 +0000

After 15 years focused on mobile development, I am excited to announce that I am switching to an AI engineering role, becoming the Principal AI Engineer at Playtomic.

The motivation

This transition is driven by a few key factors:

Personal Interest: I have found a renewed passion in exploring how Large Language Models and generative AI work. It feels like discovering programming all over again.
Industry Shift: I believe we are at a pivotal moment in the software industry. The rise of AI is similar to the shift to mobile 15 years ago but with even greater potential to transform the world. It is even more disruptive, fundamentally redefining how we build and interact with software.
Opportunity: Even more than the impact, I am inspired by the unprecedented opportunities emerging in this space. The chance to learn, create, and shape the future of AI-driven tools is a challenge I find truly compelling.
Innovation Speed: The pace at which this field is evolving is insane. The constant stream of new research and capabilities is a challenge I am eager to tackle.

The role

In this new position, my key responsibilities will include:

Research and investigate: Keeping up with the rapid pace of AI development to identify new opportunities.
Train and inspire others: Sharing knowledge and fostering an AI-forward culture within the engineering team.
Provide tools: Developing AI-powered utilities to enhance productivity and capabilities.
Automate processes: Streamlining workflows and reducing manual effort through intelligent automation.

I’m looking forward to this new chapter!

Disclaimer: Yes, this is my first officially AI assisted post too

Multidevice previews in Xcode and Android Studio

Wed, 05 Apr 2023 09:00:00 +0000

Developing with SwiftUI and Jetpack Compose is very user-friendly. Both frameworks offer a highly readable declarative syntax and a live preview feature that updates in real-time while coding. This live preview allows developers to easily configure various device settings, although it can be a bit cumbersome to specify multiple device factors. At Playtomic, we have created a simple utility for both platforms that allows us to run our previews on a predefined set of devices. Here’s what we did:

Android

This platform was the easy one, as it already supports aggregated annotations out of the box. All you need to do is include somewhere in your project:

@Preview(showSystemUi = true, device = Devices.PIXEL_4_XL, name = "Pixel 4 XL")   // big xxxhdpi
@Preview(showSystemUi = true, device = Devices.NEXUS_5, name = "Nexus 5")   // small-medium xxhdpi
annotation class MultiDevicePreview

And then just replace the usage of @Preview by @MultiDevicePreview in your previews:

@MultiDevicePreview
@Composable
private fun AMultiDevicePreview() {
    Text("Multidevice preview")
}

iOS

Things become a bit more complicated for iOS. Firstly, Xcode only recognizes previews that implement the PreviewProvider protocol. As a result, extending the interface with our custom version of MultiDevicePreviewProvider doesn’t work. Instead, we created a second protocol to tackle this problem:

public protocol MultiDevicePreview {
    associatedtype DevicePreviews : View
    @ViewBuilder @MainActor static var devicePreviews: DevicePreviews { get }

    @MainActor static var devices: [PreviewDevice] { get }
    @MainActor static var previewName: String? { get }
}

And then, we provided a default implementation of the previews for those using the new protocol:

public extension PreviewProvider where Self: MultiDevicePreview {
    static var previews: some View {
        ForEach(devices) { device in
            AnyView(devicePreviews)
                .previewDevice(device)
                .previewDisplayName([previewName, device.rawValue].compactMap { $0 }.joined(separator: " - "))
        }
    }

    static var devices: [PreviewDevice] { PreviewDevice.allCases }
    static var previewName: String? { String(describing: Self.self) }
}

We also declared some predefined list of devices to simplify the management:

extension PreviewDevice {
    public static let iPhone14 = PreviewDevice("iPhone 14")
    public static let iPhone14Max = PreviewDevice("iPhone 14 Pro Max")
    public static let iPhoneSE = PreviewDevice("iPhone SE (3rd generation)")
    public static let allCases = [iPhone14, iPhone14Max, iPhoneSE]
}

extension PreviewDevice: Identifiable {
    public var id: String {
        rawValue
    }
}

With all of the above, you can make use of multidevice previews by conforming your preview to MultiDevicePreview and replace the method previews by devicePreviews like:

struct AMultiDevicePreview: PreviewProvider, MultiDevicePreview {
    static var devicePreviews: some View {
        Text("multidevice preview text")
    }
}

Not a huge difference, but a nice small addition to the toolkit!

Data Races with value types in Swift

Fri, 26 Aug 2022 12:00:00 +0000

This week I had an interesting discussion around a possible data race condition due to wrong threading synchronisation when manipulating a value type (a String in this case) in a class.

The buggy code

final class MyClass {
    var token: String
    
    init(_ token: String = "") {
        self.token = token
    }

    func myMethod() -> Bool {
        token.isEmpty
    }
}

In a first look, this might seem correct. We have just a var with a String, which is a value type, and a method to just check if the token is empty that only calls the isEmpty from String. Straightforward code and safe right? well, it is OK as long as you do not introduce threading, but the moment you do it will not. Let me elaborate.

The test

If you run this test with Thread Sanitizer enabled:

 func test_data_race() {
        let sut = MyClass()

        DispatchQueue.concurrentPerform(iterations: 1_000_000) { i in
            sut.token = "\(i)"
            _ = sut.myMethod()
        }
    }

you will see this output:

WARNING: ThreadSanitizer: data race (pid=8329)
  Read of size 8 at 0x000107c1aab8 by thread T2:
    #0 closure #1 in DataTests.test_data_race() DataTests.swift:69 (Tests:arm64+0xde354)
    #1 partial apply for closure #1 in DataTests.test_data_race() <compiler-generated> (Tests:arm64+0xde3e4)
    #2 partial apply for thunk for @callee_guaranteed (@unowned Int) -> () <null>:73675156 (libswiftDispatch.dylib:arm64+0x42f4)
    #3 _dispatch_client_callout2 <null>:73675156 (libdispatch.dylib:arm64+0x35dc)

  Previous write of size 8 at 0x000107c1aab8 by main thread:
    #0 closure #1 in DataTests.test_data_race() DataTests.swift:69 (Tests:arm64+0xde374)
    #1 partial apply for closure #1 in DataTests.test_data_race() <compiler-generated> (Tests:arm64+0xde3e4)
    #2 partial apply for thunk for @callee_guaranteed (@unowned Int) -> () <null>:73675156 (libswiftDispatch.dylib:arm64+0x42f4)
    #3 _dispatch_client_callout2 <null>:73675156 (libdispatch.dylib:arm64+0x35dc)
    #4 _swift_dispatch_apply_current <null>:73675156 (libswiftDispatch.dylib:arm64+0x43a0)
    #5 @objc DataTests.test_data_race() <compiler-generated> (Tests:arm64+0xde448)
    #6 __invoking___ <null>:73675156 (CoreFoundation:arm64+0x11c5ec)

  Location is heap block of size 32 at 0x000107c1aaa0 allocated by main thread:
    #0 __sanitizer_mz_malloc <null>:73675156 (libclang_rt.tsan_iossim_dynamic.dylib:arm64+0x51004)
    #1 _malloc_zone_malloc <null>:73675156 (libsystem_malloc.dylib:arm64+0x1527c)
    #2 DataTests.test_data_race() DataTests.swift:66 (Tests:arm64+0xde07c)
    #3 @objc DataTests.test_data_race() <compiler-generated> (Tests:arm64+0xde448)
    #4 __invoking___ <null>:73675156 (CoreFoundation:arm64+0x11c5ec)

  Thread T2 (tid=6246748, running) is a GCD worker thread

SUMMARY: ThreadSanitizer: data race DataTests.swift:69 in closure #1 in DataTests.test_data_race()

So ThreadSanitizer is detecting a data race in the code when accessing the token. What does it mean? basically you are making a wrong usage of the variable. It gets read and write operations concurrently but the variable itself is not protected, and the fact that it is a value type does not help.

What can this cause? it is undefined, but in practice most likely you will have a crash when compilation optimizations are enabled.

The fix

OK, so this simple code can crash when reading and writing the token in parallel from different threads! How can we fix it? we just need to make serial access to read/write. There are multiple ways of doing it (with different primitives), but this could be one:

final class MyClass {
    private let syncQueue = DispatchQueue(label: "com.test.myQueue", attributes: .concurrent)
    private var _token: String
    var token: String {
        get {
            syncQueue.sync {
                _token
            }
        }
        set {
            syncQueue.async(flags: .barrier) {
                _token = newValue
            }
        }
    }

    init(_ token: String = "") {
        _token = token
    }

    func myMethod() -> Bool {
        token.isEmpty
    }
}

As you can see, what we did is to protect the var by forcing serial writing to it, so multiple reading can happen but only 1 thread can execute a write at a time (the barrier waits for all previous readings to finish and postpones all subsequent read/write accesses till the write is done). The resulting code is slower to execute, but it is now safe.

Final thoughts

I wanted to share a few thoughts around this issue, that are common misconceptions in the Swift community:

❌ Value types are thread safe

Since the value type has a copy semantic, it may seem logical to think that they are inherently protected from data races. However, that is not the case. Swift does not guarantee thread safety in value types, so accessing any var from multiple threads is a potential data race condition. This issue of course does not apply to let variables since they are immutable.

❌ Value types are always copied

That is the semantic but not really what happens under the hood. When passing value types around, Swift compiler is smart enough to know if the copy is needed, removing unnecessary copies. In practice it uses a CopyOnWrite(COW) strategy, where it will make the copy only when the value is modified, but not when passed around. As a result, in most situations you will actually have a pointer to the same underlaying memory address even when using value types.

❌ Tests do always behave like production code

The fact that a test does not crash is no guarantee to assert that some code can not crash in production. Tests run in simulated environments and they normally have different compilation options than the ones in your final builds. For example, ARC will make aggressive optimizations when compiling with the proper options, so lots of unnecessary retain/releases will be removed from final builds. In this particular case, my test suit was not crashing, and I was only able to see some wrong usage by activating the Thread Sanitizer.

Extra reading

MVI at Playtomic

Tue, 31 May 2022 12:00:00 +0000

Last summer we finally decided to move out of our classic MVP+UIKit/Android view architecture into a more modern one with SwiftUI/Compose as main actors for our view layer. Together with the UI framework changes, we found the need of switching to a more reactive architecture that better fits the nature of declarative UIs.

We spent some time analysing some of the most popular reactive architectures: MVVM, MVI and TCA. Without getting into much detail of our decision making (it would take a full post), we decided that MVI was the best fitting for our project. With it, we could get better separation of concerns and state management than in MVVM, unidirectional data flow, single source of truth and easy of testing, without the additional complexity added by TCA.

After around half a year working with MVI, the team is highly satisfied: all people in the team consider it a good/great choice and enjoys working with it, being the verbosity the only drawback.

Let us share a bit on how we do it:

The state management layer

This is how our MVI base class looks like in both platforms

open class BaseMVIPresenter<S: ViewState, A: ViewAction> {
    public var currentViewState: S { _viewState.value! }
    public var viewState: Observable<S> { _viewState }
    fileprivate let _viewState: MutableObservable<S>

    public init(initialState: S) {
        _viewState = MutableObservable(value: initialState)
    }

    func dispatch(action: A) {
        fatalError("Must be implemented by the children")
    }
}

open class MVIPresenter<S: ViewState, A: ViewAction, R: ActionResult>: BaseMVIPresenter<S, A> {
    private var middlewares: [MVIMiddleware<S, A, R>] = []

    public func with(middleware: MVIMiddleware<S, A, R>) -> Self {
        middlewares.append(middleware)
        return self
    }

    open func handle(action: A, results:  @escaping (R) -> Void) {
        fatalError("Must be implemented by the children")
    }

    open func reduce(currentViewState: S, result: R) -> S {
        fatalError("Must be implemented by the children")
    }

    override public func dispatch(action: A) {
        middlewares.forEach { element in
            element.handle(action: action, presenter: self)
        }
        handle(action: action) { [weak self] result in
            Executor.execute(inBackground: false) {
                guard let self = self else { return }
                self.middlewares.forEach { middleware in
                    middleware.handle(result: result, presenter: self)
                }
                self._viewState.value = self.reduce(currentViewState: self.viewState.value!, result: result)
            }
        }
    }
}

interface BaseMVIPresenter<ViewState, ViewAction> {
    val currentViewState: ViewState get() = viewState.value!!
    val viewState: Observable<ViewState>
    fun dispatch(action: ViewAction)
}

abstract class MVIPresenter<S : ViewState, A : ViewAction, R : ActionResult>(initialState: S) : BaseMVIPresenter<S, A> {
    override val viewState: Observable<S>
        get() = _viewState
    private val _viewState = MutableObservable(value = initialState)
    internal var middlewares = mutableListOf<MVIMiddleware<S, A, R>>()

    abstract fun handle(action: A, results: (R) -> Unit)

    abstract fun reduce(currentViewState: S, result: R): S

    override fun dispatch(action: A) {
        middlewares.forEach { element ->
            element.handle(action = action, presenter = this)
        }
        handle(action) { result ->
            Executor.execute(inBackground = false) {
                this.middlewares.forEach { middleware ->
                    middleware.handle(result = result, presenter = this)
                }
                this._viewState.value = this.reduce(currentViewState = this.viewState.value!!, result = result)
            }
        }
    }
}

fun <S : ViewState, A : ViewAction, R : ActionResult, T : MVIPresenter<S, A, R>> T.with(middleware: MVIMiddleware<S, A, R>): T {
    middlewares.add(middleware)
    return this
}

Note: In MVI there is no definition whether the data management part should be done in a presenter, view model or whatever. However, in our case we opted to call them “Presenters” to be more inlined with the rest of the app, but they are in practice maintaining state as classic ViewModel in Android.

Then, when building a feature, we need to provide the implementation of 2 methods:

handle: This method takes the actions triggered by some other component (normally the view) and handles the side effects. It emits new events (called “action results”) with the results of the effects, like for example a network call. It does not perform any state management or manipulation, it just emits new result events.
reduce: Given a state and an action result, this method computes the next state of the view. Note that it behaves as a pure function, with no side effects.

In contrast with other simpler implementations of MVI, we opted to split the code into these 2 methods to isolate side effects from state manipulation, which make our tests much simpler and our overall solution more robust and clean. An added benefit is that there are no race conditions possible like in other architectures, since all calls to reduce are executed in serial with no partial updates possible.

In addition, we added an extra piece around the presenters, called Middleware, that are capable of reacting to events without doing state management. For example, we can add all analytics tracking into a middleware or all navigation actions. This way, our presenter stays purist, just doing the state management part, and we have a set of small middlewares with a single other purpose, making it once again easier to test and maintain.

Lastly, you can see how both platform implementations are quite similar, and they both avoid the usage of platform specific APIs like Combine or Flows (although they are used internally) to maximize code reusal when transpiling and also reduce the learning curve.

An example Presenter would look like:

internal class LessonDetailPresenter(...): MVIPresenter<LessonDetailState, LessonDetailAction, LessonDetailResult>(LessonDetailState.none) {

    override fun handle(action: LessonDetailAction, results: (LessonDetailResult) -> Unit) {
        when (action) {
            is LessonDetailAction.onAppear -> loadLesson(results, lessonId)            
            is LessonDetailAction.tapConfirmCancelEnrollment -> unregisterFromLesson(results)
            is LessonDetailAction.resendConfirmation -> resendConfirmation(results)
            ...
        }
    }

    override fun reduce(currentViewState: LessonDetailState, result: LessonDetailResult): LessonDetailState {
        return when (result) {
            is LessonDetailResult.lessonLoading -> LessonDetailState.loading
            is LessonDetailResult.lessonLoaded -> LessonDetailState.detail(sections = result.lesson.mapToLessonDetail(me = userId))
            ...
        }
    }

    private fun loadLesson(results: (LessonDetailResult) -> Unit, lesson: LessonId) {
        results(LessonDetailResult.lessonLoading)
        activityService.fetchLesson(lessonId)
            .then { results(LessonDetailResult.lessonLoaded(it)) }
            .catchError { results(LessonDetailResult.loadLessonByIdFailed(error)) }
        }
    }
    ...
}

And some associated middleware for navigation:

internal class LessonDetailNavigator(...) : MVIMiddleware<LessonDetailState, LessonDetailAction, LessonDetailResult>() {

    override fun handle(action: LessonDetailAction, presenter: MVIPresenter<LessonDetailState, LessonDetailAction, LessonDetailResult>) {
        when (action) {
            LessonDetailAction.tapOpenMaps -> openMaps(presenter = presenter)
            LessonDetailAction.tapAddToCalendar -> addLessonToCalendar(presenter = presenter)
            ...
        }
    }

    override fun handle(result: LessonDetailResult, presenter: MVIPresenter<LessonDetailState, LessonDetailAction, LessonDetailResult>) {
        when (result) {
            is LessonDetailResult.loadLessonByIdFailed -> dismiss()
            else -> {}
        }
    }
    ...
}

Our view layer

Then, our views basically just receive 2 parameters:

public struct LessonDetailView: View {
    @ObservedObject var state: ObservableViewState<LessonDetailState>
    let dispatcher: (LessonDetailAction) -> Void

    public var body: some View {
        ...
    }
}

@Composable
private fun LessonDetailView(
    viewState: LiveData<LessonDetailState>,
    dispatcher: (LessonDetailAction) -> Unit
) {
    ...
}

As you can see, we are making use of state hoisting for encapsulating the presenter injection (from the view layer, it does not know what class is behind the state management). This also makes our code much more reusable, and very easy to setup the previews, since we do not need to mock any data, service or presenter, just passing the view state down is enough. For this state hoisting we are making use of a parent UIViewController/Fragment, since our app is now a mixed app with only part of the views in SwiftUI/Compose. They look like this:

final class LessonDetailViewViewController: SwiftUIViewController<LessonDetailState, LessonDetailAction, LessonDetailView> {
    override func contentView(
        viewState: ObservableViewState<LessonDetailState>,
        dispatcher: @escaping (LessonDetailAction) -> Void
    ) -> LessonDetailView {
        LessonDetailView(state: viewState, dispatch: dispatcher)
    }
}

class LessonDetailFragment : ComposeFragment<LessonDetailState, LessonDetailAction>() {
    @Composable
    override fun ContentView(
        viewState: LiveData<LessonDetailState>,
        dispatcher: (LessonDetailAction) -> Unit
    ) = LessonDetailView(viewState = viewState, dispatcher = dispatcher)    
}

Where the SwiftUIViewController and ComposeFragment are base classes that inject the presenter and create the UIHostingController/ComposeView for using SwiftUI/Compose inside with the content returned by the concrete contentView method on each case.

Conclusions

There are tons of options and architectures to use with SwiftUI/Combine. In Playtomic, we opted for a MVI version where we have a clear separation of the different responsibilities, single source of truth and a simple and unidirectional data flow. It also allows for very simple views and easy transpilation between platforms, with only one drawback so far: the extra boilerplate needed.

References

GoDaddy Studio’s Journey with State Management: Great article explaining some of the issues they found with MVP, MVVM and MVI in its simpler form. We find ourselves very aligned with their journey.

Automating rollout releases in Android

Wed, 29 Dec 2021 12:00:00 +0000

As part of our new release process (weekly releases) we are also changing the way we are publishing the apps for users. Since it is now automatic, it is crucial for us to have a phased released in which only a small subset of our users get the latest build, increasing daily and acting as a “failsafe” in case of an important bug makes it into production.

For iOS, we can set the Phased Release + Publication Date option and the AppStore will handle it in your behalf, starting the release on a certain date and increasing the automatic updates to 1%, 2%, 5%… each day.

However, Google’s approach is different. They do not offer a release date nor an automated phased release. Instead, they offer you with an API (and web dashboard) where you can set the percentage of users yourself at any time. This is in many senses much better than the Apple one, especially since this actually controls the releases and not just the automatic updates like in Apple, but it has a downside: it is all manual.

With our current setup of weekly releases and a phased released across 6 days (2%, 5%, 10%, 20%, 50%, 100%), this basically means having to update every single day the rollout amount manually. I am not sure about you, but having to enter every single day to click some button is the last thing I want to do.

Automating the release rollout

So, we wondered, if we have an API to control the rollout percentage, isn’t that enough to make it automatic? what if we have a CI job that run every day and basically checks if there is an ongoing rollout release, and in that case increases the percentage? Let’s see how we did it:

# rollout_update.py

import copy
import sys
import httplib2
from apiclient.discovery import build
from oauth2client.service_account import ServiceAccountCredentials
from oauth2client.client import AccessTokenRefreshError

TRACK = ('production')

# To run: rollout_update package_name json_credentials_path
def main():
  PACKAGE_NAME = sys.argv[1]
  credentials = ServiceAccountCredentials.from_json_keyfile_name(
    sys.argv[2],
    scopes='https://www.googleapis.com/auth/androidpublisher')

  http = httplib2.Http()
  http = credentials.authorize(http)

  service = build('androidpublisher', 'v3', http=http)

  try:
    edit_request = service.edits().insert(body={}, packageName=PACKAGE_NAME)
    result = edit_request.execute()
    edit_id = result['id']

    track_result = service.edits().tracks().get(editId=edit_id, packageName=PACKAGE_NAME, track=TRACK).execute()
    old_result = copy.deepcopy(track_result)

    print("Current status: ", track_result)
    for release in track_result['releases']:
        if 'userFraction' in release:
            rolloutPercentage = release['userFraction']
            if rolloutPercentage == 0:
                print('Release not rolled out yet')
                continue
            elif rolloutPercentage < 0.02:
                release['userFraction'] = 0.02                         
            elif rolloutPercentage < 0.05:
                release['userFraction'] = 0.05
            elif rolloutPercentage < 0.1:
                release['userFraction'] = 0.1
            elif rolloutPercentage < 0.2:
                release['userFraction'] = 0.2
            elif rolloutPercentage < 0.5:
                release['userFraction'] = 0.5
            elif rolloutPercentage < 1.0:
                del release['userFraction']
                release['status'] = 'completed'
            else:
                print('Release already fully rolled out')
                continue        
    if old_result != track_result:
        completed_releases = list(filter(lambda release: release['status'] == "completed", track_result['releases']))
        if len(completed_releases) == 2:
            track_result['releases'].remove(completed_releases[1])

        print("Updating status: ", track_result)
        service.edits().tracks().update(
                    editId=edit_id,
                    track=TRACK,
                    packageName=PACKAGE_NAME,
                    body=track_result).execute()
        commit_request = service.edits().commit(editId=edit_id, packageName=PACKAGE_NAME).execute()
        print('Edit ', commit_request['id'], ' has been committed')    


  except AccessTokenRefreshError:
      raise SystemExit('The credentials have been revoked or expired, please re-run the application to re-authorize')

if __name__ == '__main__':
  main()

In order to run this step, you need:

Get a Google Developer Service JSON key credentials file. If you have been using some automation tools like Fastlane for uploading the APK to the GooglePlay, you have this already. Otherwise, follow the instructions from Fastlane Supply setup
Install pipenv or some dependency manager for python since the script uses google-api-python-client and oauth2client. You could get them by running:
```
pipenv install google-api-python-client                            
pipenv install oauth2client
```
Run the script: pipenv run python rollout_update.py <your_package> <json_credential_path>

The script will do the following:

Create a new Google Edit
Fetch the production track release info
For each release, if it has a rollout in progress, then it increases the rollout percentage to the next “step”, where steps are: 2%, 5%, 10%, 20%, 50%, 100%.
If changes performed, then commit the Edit

Connecting the CI

So now that we have the script to increase the rollout, all we need is to schedule it. In our case, we are using Bitrise, so we decided to schedule a workflow that runs the script every night. We even created a Bitrise step in case you want to use it that handles the dependencies and running the script.

  update_rollout:
    steps:
    - git::https://github.com/angelolloqui/bitrise-step-google-play-rollout-update.git@master:
        inputs:
        - package_name: com.playtomic
        - service_account_json_key_path: "$BITRISEIO_BITRISEIO_GOOGLEPLAY_SERVICE_ACCOUNT_JSON_URL"

Note: Your credentials file should be stored somewhere secured, like the Generic File Sorage of Bitrise

Halting a failing release?

If a release goes wrong, all you need to do is to go to the Google Dashboard and halt the release as you would normally do with a manually controlled phased release. The script will simply detect the release is halted and will just ignore it.

What about Hotfixes?

Well, the script makes no assumption on the type of build or release, so it will basically just work for any release, including hotfixes. However, normally in hotfix builds, since they tend to be critical (otherwise we would not make a hotfix but wait for next week build) we normally deploy it to 100% of the user base, so we do not really need this step to run.

Keyboard observer in Android with LiveData

Fri, 20 Mar 2020 12:00:00 +0000

It is very common in mobile apps to need to update UI when keyboard is shown or dismissed. It might be to make some extra space in the screen, to scroll a list to a particular position or just to show some hints to the user while typing. Nevertheless, no matter what your reason is, there is no easy way to detect keyboard opening or closing in Android. Let’s explore some ideas:

Option 1: Focus listener ❌

A first approach would be to detect a focus changes on a particular EditText. Code looks like:

editText.setOnFocusChangeListener { _, hasFocus ->
    if (hasFocus) {
        keyboardOpen()
    } else {
        keyboardClosed()
    }
}

However, this solution does not solve the problem completely because when the keyboard is displayed (and field has focus), if the user presses the phone’s back button, then the keyboard is dismissed but the focus remains in the EditText. You may think that you can solve this by overriding and detecting onKeyDown or onBackPressed on your activity, but in fact the events are not sent to your activity and there is no way to either detect the dismissal or to force the EditText to lose the focus with it.

Option 2: ViewTree listener ⚠️

A second approach would be add a global view tree layout listener, so every time you have a layout change then you can compute the height difference between your activity root view and the visible display frame for it. Code looks like:

val globalLayoutListener = ViewTreeObserver.OnGlobalLayoutListener {
    val displayRect = Rect().apply { contentView.getWindowVisibleDisplayFrame(this) }
    val keypadHeight = contentView.rootView.height - displayRect.bottom
    if (keypadHeight > minKeyboardHeight) {
        keyboardOpen()
    } else {
        keyboardClosed()
    }
}
contentView.viewTreeObserver.addOnGlobalLayoutListener(globalLayoutListener)

Althought this solution works, it is quite cumbersome and leaves up to the developer big responsibilities like removing the observer when fragment/activity is destroyed. Besides, if you need to do this in many different views, you will end up with a lot of repetition of code that is not trivial. Lastly, the global layout listener will be fired multiples times, so your keyboardOpen and keyboardClosed methods will be fired lots of times with no need.

Solution: LiveData + ViewTree listener ✅

If we iterate on Option 2, we can see that the layout listener can in fact be encapsulated in a component. If we extend that idea, and we make use of LiveData, we can come with a very elegant solution.

Create a small behavior class encapsulating the logic in a LiveData subclass

open class KeyboardTriggerBehavior(activity: Activity, val minKeyboardHeight: Int = 0) : LiveData<KeyboardTriggerBehavior.Status>() {
    enum class Status {
        OPEN, CLOSED
    }

    val contentView = activity.findViewById<View>(android.R.id.content)

    val globalLayoutListener = ViewTreeObserver.OnGlobalLayoutListener {
        val displayRect = Rect().apply { contentView.getWindowVisibleDisplayFrame(this) }
        val keypadHeight = contentView.rootView.height - displayRect.bottom
        if (keypadHeight > minKeyboardHeight) {
            setDistinctValue(Status.OPEN)
        } else {
            setDistinctValue(Status.CLOSED)
        }
    }

    override fun observe(owner: LifecycleOwner, observer: Observer<in Status>) {
        super.observe(owner, observer)
        observersUpdated()
    }

    override fun observeForever(observer: Observer<in Status>) {
        super.observeForever(observer)
        observersUpdated()
    }

    override fun removeObservers(owner: LifecycleOwner) {
        super.removeObservers(owner)
        observersUpdated()
    }

    override fun removeObserver(observer: Observer<in Status>) {
        super.removeObserver(observer)
        observersUpdated()
    }

    private fun setDistinctValue(newValue: KeyboardTriggerBehavior.Status) {
        if (value != newValue) {
            value = newValue
        }
    }

    private fun observersUpdated() {
        if (hasObservers()) {
            contentView.viewTreeObserver.addOnGlobalLayoutListener(globalLayoutListener)
        } else {
            contentView.viewTreeObserver.removeOnGlobalLayoutListener(globalLayoutListener)
        }
    }
}

And then use it everywhere just like:

    // Some Fragment, but it works equally on an activity
    private var keyboardTriggerBehavior: KeyboardTriggerBehavior? = null
    ...
    override fun onActivityCreated(savedInstanceState: Bundle?) {
        super.onActivityCreated(savedInstanceState)
        val activity = this.activity ?: return
        keyboardTriggerBehavior = KeyboardTriggerBehavior(activity).apply {
            observe(viewLifecycleOwner, Observer {
                when (it) {
                    KeyboardTriggerBehavior.Status.OPEN -> keyboardOpen()
                    KeyboardTriggerBehavior.Status.CLOSED -> keyboardClosed()
                }
            })
        }
    }

There are a number of benefits of this solution:

It is highly reusable, you can include this in any of your views very easily
It automatically detects the lifecycle events thanks to the usage of LiveData, which means that it is secure to use since it will remove listeners automatically when your fragment/activity is destroyed
It behaves like any other observable of your ViewModels, and it can even be passed down to the view’s databinding
It will just fire updates when there is a keyboard state change and not when any layout happens.

We have even added a minKeyboardHeight property in case you need to use this in a splitted view.