Logging in Native Apps

Introduction

In Mendix Studio Pro 9.16 and above, native mobile apps are able to send logs to the Mendix Runtime. Read this guide for information on native app logging configuration.

Enabling Native App Logging

Sending logs from native apps is disabled by default. However, sending logs can be enabled from your native phone profile by selecting the Enable sending logs to runtime checkbox inside the Logging group box.

Log Levels

For more information on log levels, see the Log Levels section of Logging.

Critical

Critical is reserved for rare cases where the application may not be able to function reliably anymore. This should normally not occur. If it does, you should immediately take action.

Error

Error is used to log all unhandled exceptions. These are unexpected events that should not occur, but are not critical. The application should be able to function normally afterwards.

Warning

Warning is often used for handled exceptions or other important log events. For example, if your application requires a configuration setting but has a default in case the setting is missing, then the Warning level should be used to log the missing configuration setting.

Information

The Information level is typically used to output information that is useful to the running and management of your system. Information is typically the level used to log entry and exit points in key areas of your application.

However, you may choose to add more entry and exit points at the Debug level for more granularity during development and testing.

Debug

Debug should be used for debugging systems during development, but never in a production system. It can be used to easily assess problems as well as your app’s general flow.

Trace

Trace is the most verbose logging level, and should be used if you want more detailed logging than Debug.

Native Client Default Log Nodes

This section provides some details on specific log nodes used by the Mendix native client. Mendix recommends that if you write your own log messages, you should also use your own log node names to avoid confusion with the Mendix log messages.

Default Mendix Native Client Log Nodes

The following log nodes are used by Mendix when writing log messages:

Sending Log Messages to Runtime

The native client stores logs on the device’s memory. When Enable sending logs to runtime is selected, the native client will attempt to send logs whenever a quota of 1,000 logs has been reached or after 1 hour from the last sending attempt.

When the app goes to the background or closes, the native client will save buffered log messages on the file system and will restore them once the app is active again.

In this scenario, it will discard older messages so that it will not overflow with too many logs. An additional info log message will be added with the number of discarded logs and the timestamps of when these log messages were ignored.

The body of the log message consists of the timestamp in which the message was logged (which differs from the timestamp that is normally shown in the Cloud Portal as that one refers to the timestamps the log messages were collected), a unique session ID so that the log messages can be grouped by device or origin, and the main content of the log message itself.

Extending Logging

It is possible to add a custom log handler to react to all log messages, including errors, as they arise. This can be used to integrate with your own custom logging and error handling infrastructure, such as Google Crashlytics.

The following JavaScript code demonstrates how to add and remove a custom log handler. This JavaScript code must be executed on the mobile client, for instance via a JavaScript action or a pluggable widget:

import { addLogListener } from "mendix/logging";

// Start handling logs
const removeListener = addLogListener((logLevel, logNode, ...args) => {
    const message = args.map(arg => arg instanceof Error ? arg.message : String(arg)).join(", ");
    alert(`Incoming ${logLevel} log from ${logNode}: ${message}`);
});

// To remove the listener, call the returned function
removeListener();