Hybrid & Native Packaging

Choose how FieldOps reaches the people who use it. Dispatchers can work in a browser, while technicians need delivery options suited to devices and unreliable connections. The first decision is about their work, before choosing a package.

Compare four clients that connect to the same Wisej.NET server. A browser or progressive web application uses web capabilities; a desktop WebView2 shell or Wisej.NET Hybrid mobile shell adds a host that can expose native device features.

Evaluate offline behavior, device access, distribution, updates, and cost together. A server change can reach everyone quickly, while a signed shell has a longer release path. That difference affects which responsibilities should remain on the server.

Keep each shell focused on hosting the browser engine and exposing device features. Shared screens and business behavior remain in one server deployment. Thin shells reduce the amount of platform-specific work you must maintain and release separately.

Ask the host what it supports before showing a device action. Checking only for Android cannot distinguish a plain browser from a capable shell. A capability check ties the available command to an actual implementation instead of a platform label.

Resolve the capabilities once for the session and let all screens use that result. Keep status-change rules in WorkOrderService, where every client follows the same behavior. Device differences should change available actions without duplicating business rules.

The four clients display the same work-order list from one server. Notice that Take Photo appears only on the phone with the reported capability. The difference comes from the session’s capability information, while the shared screen remains the same.

When connectivity drops, distinguish cached information from live work. The shell and last synchronized summary remain available, but an unseen order cannot load. The queued status is explicitly identified so the technician does not mistake it for a completed server update.

Build the initial list, detail, and status workflow in the browser. Then document which delivery targets you will support, their order, and the capability checks and acceptance criteria. The working browser version becomes the shared baseline for later shells.

Make FieldOps installable while keeping its offline promise honest. The technician gets an icon and a separate window, but the interface still depends on a Wisej.NET server session. The offline page must explain what remains available when that connection disappears.

Follow the technician from depot connectivity into a room with no signal. Caching the application shell helps it open, but does not preserve a live Wisej.NET session. Design the offline experience around that boundary instead of treating cached files as a running server.

Connect the installation pieces: a secure connection, the manifest linked from Default.html, the registered service worker, and the captured installation event. Retaining that event lets the page offer installation later, when the user deliberately chooses it.

Give shell files and session traffic different routes. The worker can serve known shell assets from cache, but session requests must reach the network. If navigation cannot reach the server, show the saved offline page instead of replaying session responses.

In the worker, match an explicit shell-file list and skip requests that are not reads. Restrict the offline fallback to navigation. These rules prevent cached responses from an expired session being presented as if the current session had answered.

Version the cache so the update has a clear destination. The worker activates and takes control through its lifecycle methods, while the server writes the offline summary. Offer installation only after one successful session has demonstrated that FieldOps works.

Check the manifest, worker, and nine cached shell files before accepting the installation offer. The page’s own click invokes the stored prompt. FieldOps then opens in its standalone window, showing that installation changes the launch experience rather than moving the server onto the phone.

Without signal, read the cached summary and its synchronization time. Status changes are disabled in this version, so nothing suggests they have been queued. When connectivity returns, the Reload bar gives the technician control over returning to the live application.

Deliver the manifest, icons, versioned worker, and offline summary as one installation experience. Test the first-session offer and the update path. Confirm that old caches are removed so the next launch does not keep using an obsolete shell.

Wrap the existing FieldOps application in a desktop host for technicians who use it throughout a shift. The window, tray integration, and installer belong to the shell, while the familiar screens continue to come from the Wisej.NET application.

Use the WebView2 host to provide the desktop integration this delivery needs: a launch icon, tray notifications, a native folder picker, and an installable package. These additions surround the existing application, so they do not require duplicating its screens.

Follow the folder request across the boundary. The server invokes JavaScript, the page messages WebView2, and the host opens the native dialog. Its structured reply returns through a client event to C sharp, completing a request that spans both processes.

Check IsDesktopShell before sending the host command, then match the reply’s identifier to the request. The shell handles folder picking and tray notification separately. Correlating the reply ensures that an unrelated response cannot supply the export destination.

Choose the server location as part of the deployment. A remote server centralizes the application; a local process on the laptop provides the fallback for disconnected work. The launch probe selects the path and makes that choice visible to the technician.

Read the launch configuration and probe server health before starting the local fallback. Stop that local process when the shell exits. Keep the update check nonblocking, so a failed version lookup does not prevent the technician from starting work.

Export demonstrates the complete round trip: choose a native folder, return its path with the matching identifier, then write the report. The assignment notification exercises the other direction, reopening the window on the relevant order when the technician responds.

Test a newly prepared laptop where the WebView2 runtime is not yet present. The installer supplies it, the timed-out probe selects the local server, and the offline strip explains the mode. An available update is offered without interrupting the current job.

Deliver the desktop window and tray integration together with the folder and notification bridge. Configure the remote server and local fallback, then verify installation and the launch-time update offer. The result should be a complete desktop delivery, not just a hosted page.

Host FieldOps in a small native mobile shell while keeping its existing server screens. The Android and iOS projects add device hosting and lifecycle behavior. They let the same Wisej.NET application reach mobile users without recreating its forms for each platform.

The mobile host must handle more than displaying a page. It can be suspended during a reading, occupy a screen with a notch, or receive a back gesture. Plan these interruptions and navigation behaviors alongside the installation and device features.

The native project contains a platform web view connected securely to the FieldOps server. A shell change follows the store’s release process; changes to the hosted application stay on the server. Keeping this boundary clear avoids rebuilding the shell for ordinary screen changes.

Read the lifecycle sequence as a pause-and-return scenario. The application can deactivate, stop, resume, and activate again while the technician is away. Whether the original session survives depends on elapsed time, so resuming needs an explicit decision.

Do not reload the address automatically on every resume. Save the relevant state when the host stops, then decide whether to reconnect to the session or reload and reopen the saved work order. This preserves continuity without assuming an expired session still exists.

Route the back gesture into FieldOps and report that the host handled it. Apply safe-area padding from the platform’s actual insets. These responsibilities belong to the host, so individual server screens do not need device-specific pixel offsets.

Run the Android build in its emulator and the iOS build through the Mac simulator path. Both load the same FieldOps server. Compare their work-order screens to confirm that the native targets share the application instead of carrying separate screen implementations.

The incoming call interrupts a reading, so the stop handler saves the draft and time. On return, one hundred seventy-four seconds is still within the six-hundred-second timeout. Reconnecting restores the same order without asking the technician to retype the reading.

Build both mobile targets and test backgrounding as carefully as first launch. Include session recovery, back navigation, and safe-area handling. Capture the work-order list in both emulators so the hand-in demonstrates the shared experience on each platform.

Connect FieldOps actions to native device features through the shell bridge. The technician can photograph equipment or capture a signature, while the Wisej.NET controls remain on the server. The bridge carries the request and returns the device’s eventual result.

Trace the camera request from the server, through the page, to the host object. The result arrives later as an event, after the original command has returned. Push the resulting interface change with Application.Update so the technician sees the completed action.

Use the capability descriptor reported at session start to choose the available actions. A browser’s platform name does not prove that the native bridge exists. Where that bridge is unavailable, Upload still provides the browser-based path for selecting or capturing an image.

Explain why access is needed when the user chooses the action, then request permission. Treat granted, temporarily denied, and permanently denied as different outcomes. Repeatedly opening the same prompt cannot solve a permanent denial and only blocks the workflow.

The click handler checks support, creates a request token, and returns promptly. OnShellResult later verifies that the answer is still relevant, handles cancellation, and stores successful image data. Matching the token prevents an old response from updating the wrong state.

For the browser path, resize the uploaded image before storing it outside publicly addressable locations. Navigation separately explains its location request. If permission is refused, accept a typed address so completing the route does not depend on granting location access.

Watch the Android shell complete two photographs and a signature. Each operation appears as a separate bridge call in the log. The original click already returned before the data arrived, confirming that device operations complete asynchronously through their result events.

Open the same screen in a plain browser and compare its available actions. Upload replaces the unsupported native camera command. Refuse location, enter an address, and continue to the route; the fallback preserves the task even when device access is unavailable.

Implement the photo, signature, navigation, and assignment-notification actions with their capability rules. Include the browser upload fallback and denied-permission paths. The capability matrix should explain why each client offers its particular actions and how the user continues when access fails.

Prepare FieldOps for delivery beyond the development machines. One server supports four client forms, but the three native packages each need an accepted signing identity. Release readiness therefore includes distribution and compatibility as well as working application screens.

A successful server deployment does not guarantee a successful release. An unknown desktop publisher, expired mobile profile, or old shell calling a removed method can still block technicians. Review these independent failure points before calling the rollout complete.

Treat each platform’s signing identity as proof of origin. Windows uses its certificate and timestamp, Android its upload key and signing service, and Apple its distribution certificate and profile. Signing identifies the publisher; it does not replace compatibility testing.

Choose the distribution channel separately for each native platform: managed stores, device management, or a signed download. Browser and progressive web application delivery follow the web deployment path instead. The channel determines how technicians actually receive and update the package.

Enforce the shell version when the session starts instead of merely displaying it. AdmitShell compares the reported version with the platform’s minimum and records the result in session state. The server can then admit, warn, or require an update deliberately.

Collect evidence from both sides of the boundary. A crash-reporting library inside the shell sees failures the server cannot see. Device-feature events add outcome, platform, and shell version, helping distinguish a device integration problem from a server-side problem.

Compare the three clients reaching the updated server. Desktop proceeds, iOS receives a dismissible notice, and the old Android shell stops at the update screen. The check happens before loading orders, so an incompatible client cannot begin the workflow.

Use one release-checklist row per delivery path so no package hides behind the server’s successful deployment. Review the location-denial events as workflow evidence: a permission request made too early needs a timing change rather than assuming the location feature is broken.

Complete the capstone with signed packages, chosen enterprise channels, and a draft listing. Add startup compatibility checks and crash and usage reporting. Hand over the release checklist so another person can verify the delivery, update, and recovery paths for every client.