You can use the browser Navigator API from an EXT_Component in a MDriven Turnkey app to capture device data—such as a camera image or location—and store the result in your model; this guide is for developers extending a MDriven Designer model with browser-based device features.

What the Navigator API provides

The Navigator API is the browser interface for information about the browser and device environment. It can expose device capabilities when the browser and device support them.

In a MDriven app, an EXT_Component is the integration point for JavaScript. The component calls a browser API, then passes the result into data represented by the app's model and ViewModel.

For example, a TakePicture component can request camera access through navigator.mediaDevices.getUserMedia, capture an image, and save that image in the app.

Capability	Navigator API area	Example use in an MDriven app
Geolocation	Location access	Read the user's geographic location for a field on a form.
Network information	Connection details	Record or react to information about the current network connection.
Camera and microphone	navigator.mediaDevices	Let a user take a picture and store it with an object in the app.
Vibration	Vibration API	Request haptic feedback after a user action on a supporting device.
Bluetooth	Bluetooth API	Communicate with a nearby Bluetooth device when the browser permits it.
Battery status	Battery information	Read the device battery level where that information is available.

Start with the NavigatorThings example

Use the NavigatorThings merge model when you want a working starting point rather than beginning with an empty component. The example demonstrates Navigator API access through EXT_Components and includes a camera-oriented TakePicture component.

1. In MDriven Designer, refresh the local copy of the repository that contains merge models. Refresh it again when you need newly published example updates.
2. Select and merge the NavigatorThings model into your model.
3. Review the additions before changing them. The walkthrough describes a ViewModel named OutFormThingWithImage and a related image-oriented addition, which provide a starting structure for device-image scenarios.
4. Start your app in the local Turnkey prototyper and open it in the live editor or browser.
5. Exercise the included device feature on the device and browser you intend to support. For the camera example, allow camera access when the browser prompts for it.
6. Adapt the merged classes, ViewModel, and component to your own business object. For example, replace a generic image-bearing form with an inspection record that receives the captured image.

The example model is available through TK Live View or GitHub. For other ready-to-apply models and data, see Documentation:Example Gist.

Implement a device feature

Build each integration around a model destination, a ViewModel interaction, and an EXT_Component call.

1. Define what the app must retain

Decide what result your app needs from the device before writing JavaScript. Model a destination for that result and expose it in the relevant ViewModel.

For a picture workflow, the destination is an image associated with the object the user is editing. A user opens an inspection form, chooses Take picture, and the component captures an image that is saved with that inspection.

For a location workflow, the destination might be location data associated with the current form object. A user chooses to obtain a location, and the component retrieves it only after the user grants permission.

2. Create or adapt the EXT_Component

Create an EXT_Component, or adapt the component supplied by NavigatorThings, for the browser operation. Put browser-specific JavaScript in the component rather than in the model.

The component should:

• Check whether the required Navigator API is available before attempting to use it.
• Call the relevant JavaScript function, such as navigator.mediaDevices.getUserMedia for camera access.
• Request and handle the browser permission flow.
• Return or save the successful result to the data exposed by the ViewModel.
• Handle cancellation, denial, and unavailable hardware so that the user can continue using the app.

3. Connect the component to the ViewModel flow

Place the component in the ViewModel where the user needs the device feature, and ensure that its result has a defined destination in the model.

A camera flow has these steps:

1. The user opens a ViewModel that includes an image destination.
2. The user invokes the TakePicture component.
3. The component verifies that navigator.mediaDevices and camera access are available.
4. The browser asks the user for permission when required.
5. The component captures the image and saves it to the image destination associated with the current object.
6. The app shows the saved image in the form.

Keep the browser call and its result handling within the EXT_Component. Keep the business meaning of the result—for example, that the image belongs to an inspection—in the model and ViewModel.

Check availability and permissions

Navigator capabilities depend on the browser, device, user settings, and permissions. Do not assume that a capability listed on this page is available everywhere.

Before using a capability:

1. Check that the relevant API exists in the user's browser or device.
2. Explain the action in the UI before the browser asks for permission. For example, label a button Take picture rather than requesting camera access unexpectedly when a form opens.
3. Request permission as part of the user-initiated action.
4. Handle refusal or cancellation without losing the user's current form data.
5. Provide a fallback workflow when the capability is unavailable. For example, let a user continue without a camera image if the camera cannot be used.

Permission is controlled by the browser and device. Your EXT_Component must therefore handle both success and failure paths.

Test on the target device

Test the component in the browser and device environment where users will run the app. A feature that is present in one browser can be unavailable, blocked, or behave differently in another environment.

Use this test checklist:

• Confirm that the component detects an unavailable API and presents a usable outcome.
• Confirm that a first-time permission request is understandable to the user.
• Deny permission and verify that the form remains usable.
• Allow permission and verify that the expected result is saved to the intended model object.
• Test again after changing the ViewModel or image destination, so that the component still writes to the correct data.

When testing locally, make sure that the Turnkey version and the example model copy are the versions you intend to test. The NavigatorThings walkthrough also recommends refreshing the example repository periodically, while recognizing that a stable version may be preferable when you need consistent behavior.

Scope and limitations

This approach integrates browser-exposed device features. The Navigator API is a collection of browser capabilities, not a guarantee that every device can provide every feature.

The NavigatorThings model is a starting example that MDriven intends to extend as new needs arise. Use it to learn the component pattern, then keep your own component focused on the capability and model data your app requires.

See also

• Documentation:Getting MDriven benefits on devices
• Documentation:Integration
• Documentation:Designer
• Documentation:Example Gist
• HowTos:HowTo