DEV Community: orelzion

Phonebook: a Storybook-style preview gallery for SwiftUI and Compose, built for agents

orelzion — Tue, 25 Aug 2026 17:26:17 +0000

TL;DR I built Phonebook, an open-source CLI and MCP server that turns existing Jetpack Compose @Previews and SwiftUI #Previews into a static, self-hosted HTML gallery.

Think Storybook-style component catalog, but for native mobile previews you already have in your codebase.

No SaaS account.
No extra Storybook files to maintain.
No asking designers to install Xcode, Android Studio, or your debug app just to review a loading state.

You can also see the live gallery or watch the promo video.

The problem

Ok, ok, let's start from the beginning.

Mobile developers actually have pretty good tools for rendering UI in isolation.

If you're building Android with Jetpack Compose, you probably already have something like this:

@Preview(name = "Button/Enabled")
@Composable
private fun PrimaryButtonEnabledPreview() {
    PrimaryButton(
        title = "Continue",
        isEnabled = true,
        onClick = {}
    )
}

@Preview(name = "Button/Disabled")
@Composable
private fun PrimaryButtonDisabledPreview() {
    PrimaryButton(
        title = "Continue",
        isEnabled = false,
        onClick = {}
    )
}

And if you're building iOS with SwiftUI, you probably have something like this:

#Preview("Button/Enabled", traits: .sizeThatFitsLayout) {
    PrimaryButton(title: "Continue", isEnabled: true, action: {})
}

#Preview("Button/Disabled", traits: .sizeThatFitsLayout) {
    PrimaryButton(title: "Continue", isEnabled: false, action: {})
}

This is great when you are the developer sitting inside the IDE.

But then a designer asks:

"Can I see all the button states?"

Or a PM asks:

"What does the empty state look like now?"

Or QA asks:

"Do we have a dark mode version of this?"

And suddenly the preview is not enough.

Because the preview is trapped inside a developer workflow.

The awkward part

On web teams, this problem has a very familiar answer: Storybook.

You put components in stories, publish the Storybook, and now everyone has a place to see buttons, forms, empty states, loading states, weird edge cases, and all the other things that are annoying to reach through the real app.

But native mobile is different.

Brad Frost, who has written a lot about design systems, described the native tooling layer as still being immature and mentioned the recurring question: "is there a Storybook for iOS and Android?"

That question comes up because the pain is real, and you can see the same pattern in public write-ups from teams who already hit it.

The team at rebuy wrote about building their own "Storybook light" for apps after they couldn't find a suitable off-the-shelf tool. Doist wrote about building an automated Android component catalog because their design team had trouble knowing what reusable UI existed and how implementation compared to specs.

Pavel Sharanda's NativeBook took another run at the same idea for iOS: catalog app, previews, snapshot tests, and HTML docs from the same snippets.

So this is not a new problem.

Actually, that is part of why I wanted to build Phonebook.

When enough teams keep building their own internal version of the same thing, there is probably a missing tool hiding there.

What I wanted

I didn't want to invent a new way to describe mobile UI.

Developers already have previews.

They are already close to the production component.
They are already written in the same language as the app.
They already know how to render disabled buttons, error states, empty states, loading states, dark mode, and all the other tiny pieces we keep pretending are "just UI".

So my thought was:

Why not harvest those?

Not write a second Storybook-style codebase.
Not maintain a separate sample app until everyone forgets about it.
Not upload screenshots to some external service and hope the pricing still makes sense next year.

Just take the previews already in the repo and turn them into a static website.

That's Phonebook.

How Phonebook works

Phonebook has two main commands:

phonebook generate
phonebook build

generate renders the native previews and writes a bundle:

phonebook-out/
  manifest.json
  images/
    ...

build takes that bundle and writes a static site:

phonebook-out/
  index.html
  manifest.json
  images/
    ...

That's it.

Plain HTML, CSS, JavaScript, and image files.

You can open it from file://.
You can upload it to GitHub Pages.
You can attach it as a CI artifact.
You can put it on S3, Vercel, Netlify, an internal static host, or whatever your company already uses.

Phonebook does not care.

And honestly, that is the point.

Android: Compose previews into a gallery

On Android, Phonebook uses:

Roborazzi
ComposablePreviewScanner
Robolectric/JVM rendering

So it can run on Linux CI without an emulator.

The rough setup looks like this:

// app/build.gradle.kts
plugins {
    id("io.github.takahirom.roborazzi")
}

roborazzi {
    generateComposePreviewRobolectricTests {
        enable = true
        packages = listOf("com.example.app")
    }
}

dependencies {
    testImplementation("org.robolectric:robolectric:4.14.1")
    testImplementation("io.github.takahirom.roborazzi:roborazzi:1.72.0")
    testImplementation("io.github.takahirom.roborazzi:roborazzi-compose:1.72.0")
    testImplementation("io.github.sergio-sastre.ComposablePreviewScanner:android:0.9.3")
    testImplementation("io.github.takahirom.roborazzi:roborazzi-compose-preview-scanner-support:1.72.0")
    testImplementation("androidx.compose.ui:ui-test-junit4")
}

Then add phonebook.config.json:

{
  "appName": "My Android App",
  "platform": "android",
  "android": {
    "modules": [":app"],
    "variant": "debug"
  }
}

And run:

npx @stag-build/phonebook generate -C /path/to/your/android/repo
npx @stag-build/phonebook build -C /path/to/your/android/repo

iOS: SwiftUI previews into a gallery

On iOS, Phonebook uses SnapshotPreviews through xcodebuild test.

You add a small XCTest target:

import SnapshottingTests

final class PhonebookSnapshotTests: SnapshotTest {
    override class func snapshotPreviews() -> [String]? {
        return nil // record every #Preview
    }
}

Then add phonebook.config.json next to your .xcodeproj:

{
  "appName": "My iOS App",
  "platform": "ios",
  "ios": {
    "project": "MyApp.xcodeproj",
    "scheme": "MyApp",
    "simulator": "iPhone 17 Pro"
  }
}

And run:

npx @stag-build/phonebook generate -C /path/to/your/ios/repo
npx @stag-build/phonebook build -C /path/to/your/ios/repo

Open phonebook-out/index.html, and there's your gallery.

The naming trick

Phonebook does not require a new annotation.

It reads the preview names and turns them into component / state.

So this:

@Preview(name = "UserCard/Loading")
@Composable
private fun UserCardLoadingPreview() {
    UserCard(isLoading = true)
}

And this:

#Preview("UserCard/Loading", traits: .sizeThatFitsLayout) {
    UserCard(isLoading: true)
}

Both become:

component: User Card
state: Loading

If you add:

UserCard/Default
UserCard/Loading
UserCard/Error
UserCard/Dark

Phonebook groups them together as one component card with multiple states.

This sounds small.

But in practice, this is where the value is.

Because people usually don't ask, "Can you render one preview?"

They ask, "Can I see all of it?"

All the buttons.
All the badges.
All the cards.
All the empty states.
All the dark mode states.
All the weird combinations we forget to check until the release is almost out.

The grid is the product.

Why not just use Storybook?

If you are using React Native, Storybook already has native and web options. The React Native Storybook docs explain the tradeoff pretty clearly: native is higher fidelity because it runs in the actual app, while web is easier to publish and share.

But Phonebook is aimed at a different workflow.

It is for native Compose and SwiftUI codebases where the team already uses previews and wants a shareable artifact without creating a parallel story system.

So instead of:

component code
preview code
storybook story code
catalog app code

The goal is:

component code
preview code
generated gallery

Less ceremony.
Less drift.
Less "wait, does anyone still update this?"

Why static?

Because static things are boring in the best way.

They are easy to host.
Easy to archive.
Easy to attach to CI.
Easy to send in Slack.
Easy to open on a designer's machine.
Easy to diff across builds if you want to get fancy later.

There is no Phonebook cloud.
There is no login.
There is no organization setup.
There is no "please ask your admin to approve this workspace integration" moment.

You own the output.

For a lot of mobile teams, this matters.

Not because SaaS is bad.
SaaS is great when you want a service.

But sometimes all you need is an HTML folder with screenshots of your actual components.

The agent part

This is the part I care about more than I expected.

Phonebook is not only a CLI. It also ships an MCP server:

npx @stag-build/phonebook mcp

So a coding agent can help with the workflow inside your actual mobile repo.

For example, you can ask an agent:

Use the phonebook MCP and create a catalog for my designer.

And the MCP server exposes tools for things like:

checking setup
analyzing preview coverage
getting preview guidance
running generation
building the static gallery

The MCP server does not need to be magical.

Actually, I prefer that it isn't.

It should tell the agent what exists, what is missing, what command to run, and what generated successfully. The coding agent can then make the repo changes: add missing previews, fix naming, add the config file, or wire CI.

This feels like the right boundary to me.

Phonebook knows Phonebook.
The agent knows how to edit your repo.

What this looks like in CI

For Android, a GitHub Actions job can run on Ubuntu:

name: phonebook-android
on: [push]

jobs:
  gallery:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: '17'

      - uses: gradle/actions/setup-gradle@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - run: npx @stag-build/phonebook generate -C .
      - run: npx @stag-build/phonebook build -C .

      - uses: actions/upload-artifact@v4
        with:
          name: phonebook-site
          path: phonebook-out

For iOS, use a macOS runner because SnapshotPreviews needs a simulator:

name: phonebook-ios
on: [push]

jobs:
  gallery:
    runs-on: macos-15
    steps:
      - uses: actions/checkout@v4

      - name: Select Xcode
        run: sudo xcode-select -s /Applications/Xcode.app

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - run: npx @stag-build/phonebook generate -C .
      - run: npx @stag-build/phonebook build -C .

      - uses: actions/upload-artifact@v4
        with:
          name: phonebook-site
          path: phonebook-out

You can publish the same static folder to GitHub Pages or any internal host.

Phonebook does not publish anything by itself. It just gives you the artifact.

The thing I don't want Phonebook to become

I don't want this to become another place where teams have to describe the same UI again.

That is how tools rot.

Someone adds a component.
Someone forgets to add the story.
The design system site looks complete, but the app has moved on.
Then everyone stops trusting it.

And once people stop trusting the catalog, it becomes a museum.

Very professional.
Very nicely organized.
Completely useless.

Phonebook's bet is that previews are already close enough to the source of truth that harvesting them is better than asking teams to maintain a second catalog manually.

Will this solve every design-system problem?

Of course not.

It will not replace Figma.
It will not tell you whether the component API is good.
It will not magically clean up years of duplicated buttons.
It will not make naming conventions appear by themselves. Sadly.

But it gives you a real, shareable, desktop-friendly view of the mobile UI that already exists.

And that is a surprisingly big step.

Try it

Install it:

npm install -g @stag-build/phonebook

Or run it without installing:

npx @stag-build/phonebook generate -C /path/to/your/repo
npx @stag-build/phonebook build -C /path/to/your/repo

Or add it to your agent as an MCP server:

{
  "mcpServers": {
    "phonebook": {
      "command": "npx",
      "args": ["-y", "@stag-build/phonebook", "mcp"]
    }
  }
}

Links:

GitHub: https://github.com/stag-build/phonebook
npm: https://www.npmjs.com/package/@stag-build/phonebook
Live gallery: https://stag-build.github.io/phonebook/
Promo video: https://youtu.be/trHbUaG784w

If you have a real Android or iOS repo with previews already in it, try generating a gallery from that repo and open the result with someone who does not live inside your IDE.

That's the test I care about.

I tried vibe coding, and survived to tell (well kinda) - Part 1

orelzion — Sun, 10 Aug 2025 09:38:26 +0000

TL;DR I'm still in the early stages of the project; vibe coding is fine and all — until you need to do something that's slightly customized. Then, a developer's eye is needed.

📖 The Why

Ok, ok, let me start the story like it should—from the beginning.

So, I'm writing a book (it's about being moral, but you never asked, so I won't tell), and when I was searching for ways to properly edit and design it, I came across several options but didn't like any of them.

They were either too complicated or cost more than I wished to afford.

I spent hours researching and asking ChatGPT for brilliant ways to overcome this, but to no avail.

But then myself told me: "Orel! You're a programmer, right?"

"Well, yes," I replied, as I am quite polite.

"Then why," myself continued, "don't you develop an app tailored to your needs by yourself?!"

I must admit that myself posed a good question, but I didn't want to admit it — so I came up with an even better idea:

"You know what?" I told myself, "why write an app when you clearly don't know enough JS, when you can vibe code it?"

Oh, did I not mention? I'm a mobile developer; I barely know the basics of web development. So I went to ask the smartest person I know.

No, not me, I'm not that pretentious.

I meant ChatGPT.

So I asked him, and he agreed with myself. Now they were two against one, so I had to do the democratic thing and agree.

And thus began the crazy journey of a mobile developer vibe coding his first desktop app. Stay tuned—there will be bears 🐻.

🛠️ The Plan

I started by asking ChatGPT to come up with a plan. We discussed my needs, technologies, and features until I thought it was enough.

Then, I asked it to craft a PRD and created a new directory on my computer.

I ran Claude Code from the VSCode terminal and asked it to read the PRD first and explain what its plan was to develop it.

Claude Code is my favorite AI code assistant. I like that it's a CLI tool and that it seems to really understand the requirements of the project.

It gave me a comprehensive plan, broken down into steps and divided into MVP and future implementation milestones. After some back and forth with it, I agreed to the plan.

Then I asked it to write that plan down into a development_plan.md file so we would have a reference.

We decided to use react for the frontend, built on top of Tauri.

I saved my project and was ready to start coding—or, actually, vibe coding.

🚩 The Struggle

The first struggle came when I asked Claude to start with installation. To its credit, it did try — but it kept failing. Eventually, I told it to just give me instructions and I'd handle the heavy lifting myself.

I reverted all generated code and went through the installation process on my own: the Tauri CLI, the NPM packages, everything I needed. At last, everything was ready, and I did my first commit.

Then I asked it to save our progress to a development_log.md file so we could track progress. I ran /clear to reset the context and save money.

Next, I asked what our next step was, and it went ahead and started developing. I approved everything without reading the code. I mean, I could’ve, but this is vibe coding we’re doing—and like I said, I’m not a web developer.

Anyway, it tried to run the app but had a hard time doing it from the CLI. So I told it I'd run it from the terminal myself. A good choice, and you’ll see why later.

The first iteration was great: the editor was usable, I could write text, emphasize it, and do text-editor-y stuff. Excited, I asked it to add a chapters menu—and it did!

I asked for more steps, but then my session was stopped. You see, my Claude subscription is the $20/month one, and I have a limit on tokens. So after a while, I got blocked. Kindly, it showed me when I could return to vibe — so I waited.

😍 The Honeymoon

Waiting can teach you patience. And patience is everything, or something — I don’t know, I’m not great at Buddhism. Anyway, after my detention time ended, I returned to programming.

We reviewed the structure of the saved files and agreed on how to store the markdown content. But something kept breaking. No matter how hard Claude tried to get the saving feature working, it wouldn’t cooperate.

Then I realized a permission was probably missing. I mentioned this, and we searched together. Turns out, it did request the permission—but the Tauri package was missing, so I installed it manually. Once I did that, saving worked smoothly.

We went back and forth on other features and made great progress. We implemented themes, I18N, tons of text features, chapters, and subchapters — I really felt like I didn’t need to do anything. An entire app was being built by a computer. Amazing.

I got so excited I told anyone reckless enough to ask how it was going.

And then I read the code...

I discovered it didn’t always implement I18N and had hardcoded strings scattered throughout. It also didn’t consistently follow the theme approach and used inline styling in random places.

So I read more about it and realized I needed to add a CLAUDE.md file with proper instructions. I used Claude’s code to generate it, naturally.

In this file, I stated some rules, like so:

## Important Rules
- **NEVER run the Tauri app** – always tell the user what to test and let them test manually
- **ALWAYS use i18n text** – never hard code strings, use translation keys from i18n config
- **Structure components in folders** – organize components into logical folder structures
- **No automatic tests** – we don’t run automated tests, manual testing only
- **ONLY use react-icons** – never use SVGs, always use icons from react-icons/fa6 package

It also explained the project purpose, the technologies, and basically everything Claude needed to know. Now it mostly complies with my preferences — and if not, I just mention it broke the rules, and it apologizes and fixes things immediately.

I mean, I’d prefer it didn’t break the rules in the first place, but you know what they say: “You can’t have it all.”

💻 The Debug

Debugging with Claude is surprisingly pleasant. No, I really mean it.

After some trial and error, I discovered the best way to actually fix problems: tell it to add logs.

Yes, plain old logs.

I just review the logs, paste them into Claude, and suddenly it understands exactly where the problem stems from.

This feels a lot like pair programming to me.

Of course, sometimes — or should I say too many times — Claude claims it figured out the problem and fixed it, only for you to test the app and discover it's gotten worse.

But let's be honest: how many times has that happened to you? Don’t answer me.

Still, this isn't quite the same. Like I said, I’m not a web developer, so I can't really verify that Claude isn't writing complete nonsense. But sometimes you just sense something's off.

You know what I mean? Like you can't read TypeScript code, but you recognize a code smell when you see one.

You notice how it sprinkles setTimeout calls throughout the code and you're not sure why, but you're pretty sure that's not how things should work.

So you ask why, and Claude responds with something like "You're right, let's completely change that." Then it rewrites everything and the app stops working entirely.

Moments like this lead to great frustration. Honestly, there were times when I thought this whole thing was a big mistake, and I just couldn't fight with it anymore.

Over time, I learned how to question it properly.

If it tries to fix some problem in a way that looks odd to you, just stop and ask why — like why did it choose this particular solution?

Sometimes you need to tell it to go look up the problem on the internet. Hell, sometimes I did it myself, came up with a solution, told Claude about it, and it implemented it perfectly.

So yes, don’t automatically accept every one of its fixes. Question it.

For example, if there's an error with a library it's using, Claude might just completely change it and use another library. You need to stop it from doing so and tell it to show pros and cons of that library — or to search for the issue online first. Just so you know, Claude can search the internet—it just won’t do it unless you specifically ask for it.

🐻 The Bears

Ok, ok, so there were no bears, I’m sorry for that. But we did reach the end of this post, and that's something, isn't it?

If you followed along, you saw that I have my moments with Claude's code. Sometimes I'm like “God, this is genius - I love you!” and other times I'm like “How can you be so stupid?”

But this isn't really the end. I'm only at the beginning of the project, so other posts will surely follow.

Maybe there weren’t any bears — yet. But give it time. Claude might generate one.

First impressions on Maestro - The simplest mobile testing framework

orelzion — Sat, 17 Sep 2022 19:13:51 +0000

Photo by Mark Williams on Unsplash

Last week I participated in Droidcon NYC and outside the main conference room was a stand of mobile.dev. I usually don't stop at stands (unless I see some great t-shirts or socks 😄) but something caught my eyes.

It was this demo
// Detect dark theme var iframe = document.getElementById('tweet-1565004345355079680-189'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1565004345355079680&theme=dark" }

What caught my eye was the simplicity of this framework. I have some experience with Espresso and I know how hard it is to write the same test in it.

So I promised myself to go and check it out when I return, and so I did.

In this post I'll share my first impressions and maybe this article will actually become a series 😄

Installation

Installation was actually a breeze, I head over to the guide and everything is explained there.

I decided to first install it locally, and since I want to test both Android and iOS I didn't install it into gradle but via homebrew.

Android

Running my first test on Android was easy.

I created a new file simple_login_test.yml that looks like this

appId: "ai.viz.notifier"
---
- launchApp:
    clearState: true

Then, I headed over to Android Studio to open an emulator.

And then I run this line from my terminal
maestro test simple_login_flow.yml

And that was it!
The app has launched!

iOS

For iOS though things have been a little bit harder.

I first needed to add another installation from homebrew

brew tap facebook/fb
brew install idb-companion

This is a library from Facebook that will allow us to connect to an iOS simulator.

After installing run this command in your terminal

idb_companion --list 1

it will list all of the available simluators, find one that you like (for me it was iPhone 13 mini) and copy its udid.

Then you will launch it with this command

idb_companion --boot 85921D77-E655-4FA4-B202-D705E66E0D8A

After it's launch you'll need to connect to it with this command

idb_companion --udid 85921D77-E655-4FA4-B202-D705E66E0D8A

Now you should be able to start your test.

So I created another file simple_login_flow-ios.yml with the same code just replacing the android's appId with a iOS' bundle id.

appId: "viz.ai.VizAINotifier"
---
- launchApp:
    clearState: true

But it didn't launch 😥

Apparently I had to shut down the Android emulator first, and only then it launched.

I guess they first try to find if there's an Android emulator and if there is they will try to launch on it. Then, it didn't find any app with that appId, so it just quite the test.

Running a simple flow

So the first flow we're going to run is a simple login flow. I want to launch the app, enter wrong credentials, see an error, fix the credentials and login successfully.

Simple, right?

Well, with other frameworks (Espresso ☕️ I'm looking at you 👀), this would take one class to set all the views to their IDs, another to launch the app and dozen functions or so to interact and assert it.

If you have to wait between actions, you'd have to also implement a timer to keep checking if your view is already displayed.

Not with maestro!

In here, to start the app all I need is this

appId: "ai.viz.notifier"
---
- launchApp:
    clearState: true

To tap a button to continue to the login screen, all I need is

# Welcome screen (yes, this is a comment)
- tapOn: GET STARTED

To do some assertions on views, to check that the views that suppose to be there are actually there, I needed

- assertVisible: "Email"
- assertNotVisible: "Password"
- assertNotVisible: "Reset Password"

The way that this works is that instead of looking for a view id, it looks for the text, the same way as your QA engineer will do it.

But what if you don't have a text? I wanted to assert if some icon was showing.

Fortunately, you can use IDs as well.

- assertVisible:
    id: "ai.viz.notifier:id/fingerPrintButton"

Maestro hierarchy

How did I get this id? Do I need yo open Android Studio and try to find it there? Hell no!

We want simplicity and simplicity will shall get 😄

To get all the views from a current screen, just run maestro hierarchy in your command line. The output will be all your view tree, with texts and IDs.

This is how I knew what ID to use here.

Other assertions

I did have one more thing I wanted to test.

In our app we disable the next button if you don't have text, this is part of the QA process and I wanted Maestro to do the same, but I didn't find any option to assert whether or not a view is clickable.

So I asked in their Slack channel whether they plan on having more assertions types.

And this is how they answered

Make sense!

So what I did was to tap on the button and check that the screen hasn't changed.

- assertVisible: "Email"
# Test next button is disable when no text entered
- tapOn: "Next"
- assertVisible: "Email"

iOS

I have other assertions in my file but I won't bore you with details 😄.

I now wanted to have the same test with iOS.

I started with the same test

appId: "viz.ai.VizAINotifier"
---
- launchApp:
    clearState: true
- assertVisible: "Enter your email"
- assertNotVisible: "Password"

But my first assertion failed. Although the text was there as a hint in the edit text, Maestro didn't find it.

So I posted another question in the slack channel.

Just 3 days after reporting, the issue got fixed!

This is an amazing pace for a library, and I think that this shows how hard they work to improve it and this is indeed a good sign.

But to test the icon that was there, I didn't test by its ID, in iOS it actually use the image id as the text, so I was able to test it like this,

- assertVisible: "sfIcon60"

Problems?

But then I got stuck, after the initial login flow, we have a view pager for a walkthrough. But no matter what I tried I wasn't able to test it.

Running maestro hierarchy on this screen gave me absolutely nothing.

orelzion@N9QFJYD6GW maestro % maestro hierarchy
{
  "attributes" : { },
  "children" : [ {
    "attributes" : {
      "text" : "VizDebug",
      "bounds" : "[0,0][375,812]"
    },
    "children" : [ ],
    "clickable" : null
  }, {
    "attributes" : {
      "resource-id" : "screen.onboarding.container",
      "bounds" : "[0,0][375,812]"
    },
    "children" : [ ],
    "clickable" : null
  } ],
  "clickable" : null
}

I was also trying to ask in the Slack channel, but this time, although they did try to help me, it just didn't work.

I'm guessing I'm gonna need to investigate that some more to understand what is so special about this screen 😄.

Wrap up

This post will probably have a follow up, the maestro framework is great! Super simple and intuitive, and I liked the philosophy of it.

This is defiantly a library that I will continue to investigate, and I look forward to integrate that into our projects.

Stay tuned!

Optimising markers performance on Google Maps using RxJava

orelzion — Sun, 14 Oct 2018 17:22:30 +0000

So today I ran into an interesting problem. I needed to display a large amount of markers on Google Map, and we decided that too many markers will just not look good, and so we are eliminating markers that intersect by over 70 percent, and display just one of them instead.

And so I wrote this little function that takes two Rect objects to see if they intersect.

But how do you get a rect object if all you have is a Lat/Lng of where you want to position your marker?
Well, luckily for us Google Maps already has a utility function, that converts a lat/lng on map into a Point object.

mGoogleMap.getProjection().toScreenLocation(latLng)

And so, I was able to create a Rect object based on that point plus the icon width and height.

Now we need to iterate over all lat/lngs and check which of them are intersecting.

Since this can be heavy (iterating over each object and check it against all other object in the list), I decided to run it inside an RxJava observable.

Seems legit, right?

Well, I thought, let's give it a run. Oh boy, that sucked terribly. I ran the app on a Google Pixel 2 device, and whenever I moved the screen and the markers needed redrawing, the app just stuck for a second.

So I looked at my code again, and although the method 'getPoiForVisibleRegion' is running in the background, the map operation that comes next is not! This is so because I only added the subscribeOn and observeOn methods inside 'getPoiForVisibleRegion' so the map operation that was called later was not included.

Ok, so I just need to include the subscribe method after the map declaration, right?

Not so fast, my friend.
Here's the catch. Google Maps can't get you the screen point while in background, so that means that I was able to run every other parts of my algorithm in RxJava but the intersection filter.

Back to the drawing table then.

Now I thought, what if I could get all the points for the currently visible markers before the filter, and make the actual filter run in background when it already has all the points?

And so I did just that. I created a HashMap that updates every time the map bounds changes (so that means zoom level has changed, or the map moves). I get the currently visible region of the map while still on the UI thread

mGoogleMap.getProjection().getVisibleRegion().latLngBounds;

Then I go and filter out only the markers that I should draw now. And I save a mapping between those locations to their point on screen

Viola!

The result was very satisfying! The map moves smoothly and the markers are getting removed or appeared on screen with a nice animation (not described in this post), without the user has to wait more than a fraction of a second, and more importantly without the screen ever gets stuck