Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/CodexaCP/DG_APK/llms.txt

Use this file to discover all available pages before exploring further.

Dragon Guard Handheld can deliver a strong demo, but only if the physical device, network, backend server, and tenant configuration are validated beforehand. The most common demo failures are not code bugs — they are network mismatches, unregistered devices, wrong backend URLs, or operators assigned to the wrong tenant.
Run through this checklist on real hardware with the real network you will use in the demo. Emulator testing does not catch device authorization failures, cleartext network blocks, or RFID hardware issues.
Do a full rehearsal end-to-end (login → receipts → shipments) at least once on the demo device before the presentation. The 30-minute rehearsal eliminates 90% of demo risk.

​
Checklist Sections

  • The APK compiled successfully on your development machine
  • The APK installed on the demo device without errors
  • The app opens without crashing on startup
  • The startup splash screen (SafeBootPage) appears while session is restored
  • The app does not depend on fast deployment — debug builds use EmbedAssembliesIntoApk=true
  • The version installed on the device is the correct one for this demo
  • The backend URL configured in the APK points to the correct server
  • The demo device can reach the backend API from the demo Wi-Fi
  • If it is a debug build: the Settings screen shows the correct URL
  • If it is an official build: no Settings connection screen is visible; the APK boots directly to login against the compiled server
  • You have already tested connectivity from the same Wi-Fi you will use in the demo
In debug builds, if the IP address changes or you switch Wi-Fi networks, the APK will lose connectivity even if the backend is healthy. Always confirm the URL matches the active network before the demo.
  • Demo credentials (username and password) work against the target backend
  • Credentials have been tested today, not just assumed to be valid
  • Login error messages are human-readable (not raw stack traces)
  • If the backend is unreachable, the app shows a clear timeout message — not a hang
  • After a successful login, the app navigates to the main home screen
  • The demo device’s MAC address or ANDROID_ID has been identified
  • That device identity is registered in the Supreme Admin allow-list for the demo tenant
  • The device is set to active in the tenant’s device list
  • The demo tenant has not exceeded its active handheld limit from the assigned plan
  • If the device uses ANDROID_ID instead of MAC (Android 10+), the correct ID is registered
The device’s real MAC/ANDROID_ID appears in the login error message when authorization fails. Use that value — not a guessed one — when registering in Supreme Admin.
  • After login, the session token is persisted (closing and reopening the app skips login)
  • The active company shown matches the expected demo tenant
  • The demo operator user has exactly one company assigned — zero or multiple blocks login
  • Logout works and navigates back to the login screen
  • After logout, pressing the hardware back button does not reopen protected pages
  • The receiving header list loads from GET /api/ReceivingHeaders
  • A receipt header can be selected and its detail loads
  • Receipt lines load from GET /api/ReceivingLines/by-header/{id}
  • A QuantityReceived value can be entered on a line
  • Bin assignment is saved with the quantity
  • POST /api/ReceivingHeaders/{id}/post succeeds for a demo receipt
  • After posting, the receipt status updates to reflect the new state
  • Already-posted receipts show the correct status and cannot be re-posted
  • The shipment header list loads from GET /api/shipmentheaders
  • A shipment header can be selected and its detail loads
  • Shipment lines load from GET /api/shipmentlines?shipmentId={id}
  • A ShippedQty value can be entered on a line
  • POST /api/shipmentheaders/{id}/post succeeds for a demo shipment
  • After posting, the shipment status updates correctly
  • Already-posted shipments cannot be re-posted
  • Navigating forward and back between lists and detail screens does not break the session
  • Returning from a detail page refreshes the header list with fresh data from the server
  • No screens display stale data from a previous session or navigation
  • No out-of-scope modules (Users, Companies, Picks) appear on the home screen
  • With the backend offline, the app shows a readable “server unreachable” message — not a crash
  • A failed login shows a clear, human-readable error message
  • If the device is not authorized, the error message includes the device MAC/ID so the admin can register it
  • If the tenant plan limit is exceeded, the message is understandable
  • After any recoverable error, the app remains in a usable state
  • The handheld device battery is fully charged
  • Screen brightness is sufficient for the demo environment
  • Wi-Fi signal is stable at the demo location
  • The backend server is accessible from the demo Wi-Fi (tested, not assumed)
  • Demo credentials are written down somewhere accessible
  • The demo tenant and data (a receipt and a shipment to process) are prepared in advance

​
Commercial Demo Minimum

Before any customer-facing demo:
1

Choose one device

Pick a single demo handheld. Test everything on that specific unit — not on a different device.
2

Prepare demo data

Create at least one demo receipt and one demo shipment in the backend that are in Released state and ready to process.
3

Rehearse end-to-end

Run the complete flow — login → select receipt → enter quantity → post → select shipment → enter quantity → post — on the real network.
4

Confirm the operator knows what to tap

The operator should not be exploring the UI during the demo. Walk through the flow once together before the presentation.

Build docs developers (and LLMs) love

Get started for freeTalk to us