moengage_analytics_impl Free

Docs/Bricks/moengage_analytics_impl

Tier

Freeversion 1.3.7

Command

archipelago generate moengage_analytics_impl

Generates

• infrastructure/moengage_analytics_impl

Generates first

analytics_sdkwhen needed and missing, so there is nothing to install first

Depends on

shared_app_configgenerate these first

Tutorial

Step-by-step: add moengage_analytics_impl to a project

MoEngage Analytics vendor implementation for the analytics_api contract.

Variables

Variable	Type	Default	Description
appName	string	—	The name of your application
isForMonorepo	boolean	true	Whether this is being generated as part of a monorepo

Prerequisites

Needs analytics_sdk (4.0.0 or newer). This package's own code imports analytics_api. When infrastructure/analytics_api is missing, pre_gen generates analytics_sdk first, so the brick can be added on its own. post_gen patches the app's pubspec.yaml and injector; it never touches analytics_impl.

Architecture

This brick generates a single vendor implementation package that plugs into the analytics_sdk orchestration layer:

• MoEngageAnalyticsVendor — Implements AnalyticVendor using MoEngageFlutter, registered as @Named(AnalyticInjectorKey.moEngageImpl)
• MoEngageRegisterModule — Injectable module whose constructor registers the vendor key with AnalyticVendorRegistry.instance, and provides the MoEngageFlutter singleton, constructed as MoEngageFlutter(AppEnv.moengageAppId)
• MicroPackage DI — initMoengageAnalyticsImplModule() (@InjectableInit.microPackage()) generates MoengageAnalyticsImplPackageModule. This package declares that class under its own archipelago: di_modules manifest, and post_gen.dart wires it into the app's injector.dart (via ServiceLocatorUpdater) and adds itself as a dependency of the app's pubspec.yaml — analytics_impl depends only on analytics_api and is never touched

The vendor reads the app ID from app_config (AppEnv.moengageAppId). Event parameters are mapped through MoEngage's MoEProperties builder, which provides typed attribute handling.

Android build setup

post_gen adds implementation(platform("com.moengage:android-bom:4.2.0")) to the app's android/app/build.gradle(.kts). moengage_flutter_android 6.x pins its SDK versions only through that BOM and does not export it, so without it the build fails with "Could not find com.moengage:moe-android-sdk:.". Keep the BOM version in step with moengageNativeBomVersion in the moengage_flutter_android release you resolve. Its Gradle plugin also needs a JDK 19 or newer for Gradle: Flutter's default (the Android Studio JDK) works, a JDK 17 set through flutter config --jdk-dir or org.gradle.java.home does not . The generated GitHub Actions Android jobs set up JDK 21 (actions/setup-java, Temurin); the GitLab image already has it. Today moengage_flutter 11.0.0 pins moengage_flutter_android 6.0.0, which uses BOM 4.2.0.

Generated Structure

infrastructure/
└── moengage_analytics_impl/
    ├── lib/
    │   ├── moengage_analytics_impl.dart        # Package barrel export
    │   └── src/
    │       ├── moengage_analytics_vendor.dart  # AnalyticVendor impl
    │       └── di/
    │           ├── injector.dart               # microPackage DI entry
    │           ├── injector.module.dart        # pre-built generated output, committed
    │           └── register_module.dart        # MoEngageFlutter provider
    ├── test/src/moengage_analytics_vendor_test.dart
    ├── pubspec.yaml
    └── README.md

Key Features

• Properties builder pattern — Event parameters from data.params are iterated and added to a MoEProperties instance via addAttribute(key, value) before being passed to trackEvent, providing MoEngage's typed attribute handling
• User identification — setUserId calls moEngage.identifyUser(userId)
• User attributes — setUserProperty maps to moEngage.setUserAttribute(key, value) for MoEngage user profile attributes
• Reset / logout — reset() calls moEngage.logout(), ending the current user session
• Consent — setCollectionEnabled maps to disableDataTracking / enableDataTracking, so revoking analytics consent stops data tracking
• Named DI — Registered under AnalyticInjectorKey.moEngageImpl for unambiguous resolution alongside other vendors

Configuration

The following environment value must be present in app_config (AppEnv):

Key	Description
moengageAppId	MoEngage App ID from the MoEngage dashboard

This is injected at build time via app_config — no runtime secrets are needed in this package.

Initialization and consent

MoEngageAnalyticsVendor.initialize() starts the SDK with MoEngageFlutter.initialise() and the app ID above. The analytics orchestrator calls it only after analytics consent is granted, so nothing is collected before opt-in and no event is sent by an uninitialized SDK.

Do not add MoEngage.initialiseDefaultInstance to the Android Application class or initializeDefaultInstance() to the iOS AppDelegate. That native (file-based) setup starts the SDK at app launch, before consent. The brick generates no native init code. Push and in-app messaging still need the platform steps in the MoEngage Flutter integration guide (Firebase/APNs).

Dependencies

Package	Version	Purpose
moengage_flutter	^11.0.0	MoEngage Flutter SDK
analytics_api	workspace	Vendor contract (AnalyticVendor, TrackData)
app_config	workspace	Access to AppEnv for the App ID
dependencies	workspace	Shared DI annotations (injectable)

Changelog

Run archipelago brick info moengage_analytics_impl to see the latest published version. Enterprise customers can read the full CHANGELOG.md in the brick source repository.

Adding this brick to a project generated without MoEngage also declares moengageAppId/MOENGAGE_APP_ID in shared/app_config (Env, AppEnv, every .env* file), so no manual edit is needed.