Avo Inspector React Native SDK

Quick Start Guide

Find the Quick Start Guide in our GitHub repo.

Installation

Inspector library is available through npm. Run the following command to install it:

npm install react-native-avo-inspector

The SDK also needs these peer dependencies, depending on your platform and features.

Install @react-native-async-storage/async-storage on both platforms. On Android, the SDK stores its data in it. iOS uses the native Settings at runtime, but Metro still needs the package to build the iOS bundle.

npm install @react-native-async-storage/async-storage

If you pass a publicEncryptionKey, install react-native-get-random-values and import it at the very top of your entry file (index.js), before any other import. Hermes doesn’t include crypto.getRandomValues, which encryption needs.

npm install react-native-get-random-values@^1.1.0

Both packages include native code. On iOS, install their pods and then rebuild the app:

npx pod-install

Import

import * as Inspector from 'react-native-avo-inspector/dist-native';

Initialization

Obtain the API key in Inspector tab in your Avo.app workspace.

You will need to create an instance of AvoInspector with the constructor:

constructor(options: {
    apiKey: string;
    env: AvoInspectorEnv;
    version: string;
    appName?: string;
});

All the following methods are available in the AvoInspector class.

Parameters:

  • apiKey - the API key you get in your Avo account
  • env - current environment: "dev", "staging" or "prod"
  • appVersion - your application version. A lot of Inspector features rely on versioning and you need to provide a comparable string here to get value from them. We recommend using semantic versioning or integers that are incremented in every release.
  • appName - your application name. Optional; Provide it to make it easier to distinguish between data from different apps.

Sending event schemas to Avo Inspector

This is the core of the Avo Inspector SDK.

Call **one of the methods** in this section every time an event is tracked.

Option 1

trackSchemaFromEvent(eventName: string, eventProperties: {
    [propName: string]: any;
}): void;

Extracts the event schema from event properties represented by the second parameter ({ [propName: string]: any; }) and sends the schema to Avo for analysis.

Parameters:

  • eventName - string event name, also known as event type.
  • eventProperties - The actual event properties, which will be converted to an event schema on the device and the event schema sent to Avo. The resulting keys will be object field names and the values will be object field value types converted to schema types.
Example format:
var eventProperties = {
  userId: 1337,
  emailAddress: 'jane.doe@avo.app',
  key: 'value',
};

Option 2

trackSchema(eventName: string, eventSchema: Array<{
    propertyName: string;
    propertyType: string;
    children?: any;
}>): void;

This method allows you to process the event schema before sending it. It’s handy to extract the schema from your event properties with extractSchema (see below), process it, and then provide it to this method.

Parameters:

  • eventName - string event name, also known as event type.
  • eventSchema - actual event schema that will be sent to Avo. Keys are event parameters names and values are event parameters types.

Example format:

var returnedSchema = [
  {
      propertyName: 'userId';
      propertyType: 'int';
  },
  {
      propertyName: 'emailAddress';
      propertyType: 'string';
  },
  {
      propertyName: 'key';
      propertyType: 'string';
  },
];

See supported schema types here.

Other methods

1. Extract schema from event properties

extractSchema(eventProperties: {
    [propName: string]: any;
}): Array<{
    propertyName: string;
    propertyType: string;
    children?: any;
}>

This is the method used by trackSchemaFromEvent internally. The event schema is extracted from the event properties’ JS object, itself in the form of a JS object as well.

Parameters:

  • eventProperties - An event properties object. Keys are event properties’ names and values are event properties’ values. The format is the same as the eventProperties parameter in the trackSchemaFromEvent method.

Return Value:

  • A JS object containing the event schema of the given event properties. The keys are the event properties’ names and the values are the event properties’ types. The format is the same as eventSchema parameter in the trackSchema method.

2. Print logs

enableLogging(enable: boolean): void;

enableLogging controls printing of tracked event schemas and other helpful information to the console (the Metro output, and logcat or the Xcode console on the device). Enabled by default in development environments. With logging enabled, the SDK prints the raw values of the event properties you track, not only their types, so don’t leave it enabled where those values may contain personal or sensitive data. The same setting is the static AvoInspector.shouldLog property, which you can also set before creating an instance.

A few problems are printed even with logging disabled: a missing or unsupported environment, a failure to set up storage, event spec validation or the anonymous ID, an unexpected internal error, an event that can’t be prepared for sending, and a property value that fails to encrypt. Network failures and timeouts while sending events are printed only with logging enabled.

Since version 2.0.0, an explicit setting is remembered. It applies immediately to every Avo Inspector instance created from the same copy of the SDK, including instances created later, and creating an instance no longer resets it. Until you set it, each new instance applies its environment’s default (on in development, off in staging and production). The setting lasts until the JavaScript bundle reloads, for example when the app restarts.

Upgrading to 2.0.0: before 2.0.0, creating an Avo Inspector instance reset logging to the environment default, which cancelled any earlier call. From 2.0.0 the call stays in effect, in both directions:

  • After enableLogging(true) or AvoInspector.shouldLog = true, a later production instance keeps printing logs. Before upgrading, remove any leftover calls, such as ones added while debugging.
  • After enableLogging(false) or AvoInspector.shouldLog = false, a later development instance no longer turns logging back on.

Parameters:

  • enable - boolean flag that sets whether Avo Inspector SDK will print logs.

3. Controlling the batch size

setBatchSize(newBatchSize: number): void;

Enables manual control over events batching. The default batch size in production is 30, i.e. the library attempts to send event schemas to the server when it has 30 or more schemas. In development batching is disabled by default.

Parameters:

  • int newBatchSize - sets batch size.

4. Controlling the batching interval

setBatchFlushSeconds(newBatchFlushSeconds: number): void;

Enables manual control over events batching. The default production batch flush interval is 30 seconds, i.e. the library attempts to send event schemas to the server when 30 or more seconds pass, given that there are unsent schemas.

Parameters:

  • int newBatchFlushSeconds - sets batch flush time in seconds.

What’s next?

Now when you’ve set up Inspector we recommend to start using the mobile debugger.

Avo is the analytics governance platform for product data that lets you define it consistently, implement it correctly and trust it everywhere. Using an AI agent? Connect it to the Avo MCP at https://mcp.avo.app/mcp and it can read and change your tracking plan on a branch.