Document Scanner SDK

Choosing an Integration Path Pixelnetica™ Document Scanning SDK for Android

The SDK offers two kinds of building blocks: ready-made screens you launch, and a processing pipeline you call. Most integrations use one of three combinations. This page describes what each path gives you, what it costs, and when to move from one to another — worth deciding before you write code, because the path determines which modules you add and which guides apply to you.

Path 1: Ready-Made Screens

Add the camera and design modules and assemble scanning from finished parts: the Smart Camera activity captures pages with live document detection and automatic shot, the crop editor lets users adjust the detected outline, the language manager handles OCR language downloads, and the recognized-text editor lets users fix recognition results. Your code launches screens and receives results; the core pipeline still does the processing between them.

Choose this when you want a working scanner in days, your UI requirements fit what the screens provide, and a consistent, tested scanning flow matters more than a custom look. The screens follow your application’s theme (see theming), but their layout and flow are fixed.

Path 2: The Core Pipeline with Your Own UI

Add only the scanning module and build every screen yourself. The pipeline takes any image URI — from your camera code, the system photo picker, or a file — and gives you document detection, cropping, colour profiles, text recognition, and export to images or searchable PDF. You decide what the user sees at every step.

Choose this when your product has its own design language, you need a flow the ready-made screens do not offer (batch capture with review, say, or scanning inside a chat), or you are adding scanning to an application whose UI framework the components do not match. Expect to build and test the camera experience yourself — live detection feedback is the part users notice most.

Path 3: Mix the Two

The paths combine freely because everything exchanges the same types. A common mix: launch the Smart Camera for capture — it is the hardest screen to build well — then run your own processing and review UI on the URIs it returns. Or build your own capture and hand pages to the ready-made crop editor.

Choose this when one screen’s polish matters and the rest must be yours.

Switching Later

Starting on the ready-made path does not lock you in. The screens sit on the same public pipeline, so replacing one screen with your own is an incremental change, not a rewrite. The usual direction is path 1 first to ship, then path 3 as the product’s own design takes over — replacing screens one at a time while capture and processing keep working.

Where to Go Next

Top