Choosing Between MethodChannel and PlatformView: A Real Decision, Not a Rule of Thumb

Victor Loveday — Thu, 24 Sep 2026 19:31:31 +0000

I Embedded a Native Camera Preview in Flutter (And Learned Exactly Where MethodChannel Stops Being Enough)

Seven years into mobile engineering, I wanted to answer a question I've seen a few times: when do you actually need PlatformView instead of MethodChannel? Most answers I've seen are either "PlatformView is for native UI" (true, but not useful) or skip straight to copy-pasteable boilerplate with none of the failure modes that actually teach you anything.

Over the weekend, I built a small Flutter app that embeds a native Android camera preview with a live ML Kit face-detection overlay, drawn natively, not through a Flutter widget stacked on top. This article is the build and, more usefully, the three things that broke along the way and what each one taught me about how Flutter's native bridging actually works under the hood.

Why MethodChannel wasn't the question

Before touching code, it's worth being precise about something I initially framed loosely myself: MethodChannel isn't "too weak" for native work; it's just the wrong tool for a specific job. It's a request/response bridge. Dart calls a method, native code handles it, returns a result. For one-off calls, biometric auth, reading an NFC tag, taking a photo, it's genuinely the right tool, no asterisk needed.

What it categorically cannot do is put a native View inside your Flutter widget tree. It moves data, not UI. The moment you need an actual native surface rendering live inside your layout- a camera preview, a map SDK's own view- you need PlatformView. That's not a performance tradeoff or a style preference. It's the only mechanism Flutter gives you for that job.

So the real architecture question for LensBridge wasn't "MethodChannel or PlatformView". It was "PlatformView for the pixels, MethodChannel for the commands," running side by side, each doing what it's actually built for.

The architecture

PlatformView hosts a PreviewView (CameraX) wrapped in a FrameLayout, with a second custom View stacked on top for drawing detection boxes
ImageAnalysis (a separate CameraX use case from Preview) feeds frames to ML Kit's on-device face detector
MethodChannel handles the three things Dart needs to tell native code to do: switch lens, stop, start

class CameraPlatformView(
    private val context: Context,
    viewId: Int,
    private val lifecycleOwner: LifecycleOwner
) : PlatformView {

    private val previewView: PreviewView = PreviewView(context).apply {
        implementationMode = PreviewView.ImplementationMode.COMPATIBLE
    }
    private val overlayView: OverlayView = OverlayView(context)
    private val container: FrameLayout = FrameLayout(context).apply {
        addView(previewView, FrameLayout.LayoutParams(MATCH_PARENT, MATCH_PARENT))
        addView(overlayView, FrameLayout.LayoutParams(MATCH_PARENT, MATCH_PARENT))
    }

    override fun getView(): View = container
    // ...
}

Two lines in there, implementationMode and the explicit LayoutParams, look unremarkable. They cost me two separate debugging sessions. More on both below.

What actually broke

1. `unbindAll()` doesn't clear the surface

After wiring MethodChannel controls for Stop, hitting it left the last camera frame frozen on screen instead of going blank. Not a bug. PreviewView is backed by a SurfaceView/TextureView, and unbindAll() stops new frames from being pushed but never explicitly clears the existing buffer. Nothing tells the GPU to draw anything else over it, so the last frame just sits there.

Confirmed it was genuinely stopped (not stalled) by waving a hand in front of the camera. No update. Fixed it by explicitly toggling previewView.visibility on stop/start rather than relying on frame delivery to communicate state.

2. A completely silent 0×0 view

Once ML Kit was wired up and logcat confirmed detection was running (face_count=1 in the stats), nothing appeared on screen. No crash, no warning. The overlay simply didn't render.

The cause: I added the overlay view to its container with addView(view) and no explicit LayoutParams. Default behavior is WRAP_CONTENT, and since OverlayView has no intrinsic content, it's just a custom View doing manual canvas drawing, it measured out to 0×0. onDraw() was being called the whole time, just onto a canvas with no area to draw into.

addView(
    overlayView,
    FrameLayout.LayoutParams(
        FrameLayout.LayoutParams.MATCH_PARENT,
        FrameLayout.LayoutParams.MATCH_PARENT
    )
)

This is the one I'd flag hardest to anyone stacking a custom-drawn view over a CameraX preview: the pipeline can be entirely correct and you'll still see nothing, because the bug isn't in your detection logic at all.

3. SurfaceView doesn't respect view z-order

Even after fixing #2, the overlay still didn't show, except for a single frame that flashed the instant I hit Stop. That flash was the clue.

PreviewView defaults to ImplementationMode.PERFORMANCE, which renders through a SurfaceView. SurfaceView content composites through a separate hardware layer, outside Android's normal view-drawing pass, meaning it can visually sit above other views in the same layout regardless of their z-order in code. My overlay was drawing correctly the entire time. It was just being painted over, every frame, by the camera feed's hardware-composited layer underneath it.

The fix is a documented tradeoff, not a hack:

previewView.implementationMode = PreviewView.ImplementationMode.COMPATIBLE

COMPATIBLE forces a TextureView instead, which renders as a normal part of the view hierarchy, with predictable layering, at the cost of losing PERFORMANCE mode's hardware-layer fast path. For a demo like this, that's the right trade every time.

The part I'd actually reconsider

If I rebuilt this today, I'd add the COMPATIBLE implementation mode from the start rather than discovering it two bugs deep. It's a known CameraX behavior. I just hadn't hit it firsthand before.

Code's on GitHub: https://github.com/droidchief/lense_bridge

Kotlin for Server-Side

Victor Loveday — Tue, 02 Nov 2021 16:19:27 +0000

With Kotlin, we can create different applications for different platforms. Server-side applications are no exception. Similarly to Java, Kotlin can be used to set up and run server side applications. Several frameworks like Spark and Spring which is used with Java also have support for Kotlin. I will show you four of them as we proceed. But first;

Ktor

Ktor (pronounced Kay-tor) is an asynchronous open source framework for creating micro services and web applications. It was developed with Kotlin by Jetbrains. The framework is lightweight and has a great support for coroutines and KMM (Kotlin Multi Platform).

Four frameworks for server-side development with Kotlin

Spring Boot: This framework is widely used for creating stand-alone Spring Based Applications. Applications created with Spring Boot are of large-scale, production-grade, while you just need to trigger the run button.
Javalin: This framework is referred to as the most lightweight for Kotlin and Java server-side development. Javalin supports network configuration components such as Web Sockets, HTTP2 and async requests and so on. Javalin was initiated as a clone of Java. Although it was not anticipated by its developers, still Javalin emerged into a wider framework. It was moulded into a ground-up rewrite, with reference to the JavaScript framework koa.js.
Spark: Spark is one of the earliest expressive Kotlin or Java web framework built for rapid development. It can also be used in higher-level Kotlin development. It is not so popular. Spark is not so trusted with respect to micro-services.
Vert.X: Just like Java and Kotlin, Vert.X is an ecosystem used for building reactive applications in different programming languages. Vert.X comes with a powerful set of tools. However, it is not advisable for everyone. It comes with detailed documentation and is thoroughly compatible with Kotlin libraries. It creates reactive Web applications for the Java Virtual Machine.

Why Ktor ?

It is a very lightweight framework that reduces the effort required to create web applications in Kotlin. It doesn’t manipulate the underlying technologies of a project and is compatible with most of them, with very rare exceptions.

It is highly reliable, as it is a product of the Kotlin team, itself. It allows developers to rapidly create both, client and server-side applications that target multiple platforms. Ktor exploits Kotlin Coroutines for providing high scalability and offers an efficient and idiomatic API for developers.

It works on a minimum memory footprint and comes in as a lightweight thread. It is analogous to Javalin, it is also a real micro-framework plus it's simplicity. Left to me, I'd say it's the most suitable for prototyping.

DEV Community: Victor Loveday