appsflyer_analytics_impl Free

Docs/Bricks/appsflyer_analytics_impl

Tier

Freeversion 1.3.6

Command

archipelago generate appsflyer_analytics_impl

Generates

• infrastructure/appsflyer_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 appsflyer_analytics_impl to a project

AppsFlyer vendor plugin for analytics_sdk — implements AnalyticVendor on top of the AppsFlyer Flutter SDK and registers itself for AnalyticsInitializer's vendor discovery.

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

Selected alongside other analytics vendors during flutter_modular_monorepo generation — see analytics_sdk, not a variable of this brick itself.

Usage

Interactive

archipelago generate appsflyer_analytics_impl

Non-interactive (CI)

archipelago generate appsflyer_analytics_impl --config my_config.json

Generated Structure

infrastructure/
└── appsflyer_analytics_impl/
    ├── pubspec.yaml
    ├── lib/
    │   ├── appsflyer_analytics_impl.dart         # Barrel export
    │   └── src/
    │       ├── appsflyer_analytics_vendor.dart   # AppsFlyerAnalyticsVendor
    │       └── di/
    │           ├── injector.dart                 # microPackage init
    │           ├── injector.module.dart          # Generated DI module
    │           └── register_module.dart          # AppsFlyerSdk + AppsFlyerConfig
    └── test/src/
        ├── appsflyer_analytics_vendor_test.dart
        └── di_wiring_test.dart

API

@LazySingleton(as: AnalyticVendor)
@Named(AnalyticInjectorKey.appsFlyerImpl)
class AppsFlyerAnalyticsVendor(
  final AppsFlyerSdk _sdk,
  final AppsFlyerConfig _config,
) extends AnalyticVendor {
  Future<void> initialize();                              // _sdk.init(devKey:, appId:)
  Future<void> track(TrackData data);                      // _sdk.logEvent(name, eventValues: params)
  Future<void> setUserId(String userId);                   // _sdk.setCustomerUserId
  Future<void> setUserProperty(String key, String value);  // _sdk.setAdditionalData({key: value})
  Future<void> setCollectionEnabled(bool enabled);        // _sdk.stop(!enabled) — called on consent revoke/grant
  Future<void> reset();                                    // _sdk.setCustomerUserId('') — best effort, no native reset API
}

You never call this class directly — install the brick, and AnalyticsInitializer discovers it through AnalyticVendorRegistry and routes analytics_sdk calls to it alongside every other installed vendor.

Real behavior worth knowing (verified against source, changed in 1.1.1):

• initialize() calls the real AppsFlyerSdk.instance.init(devKey:, appId:) — as of 1.1.1 this vendor is the first to give AnalyticVendor.initialize() non-no-op behavior. The call happens lazily, inside initialize(), not eagerly at DI construction — AnalyticsInitializer calls it post-launch, after consent is granted.
• setCollectionEnabled(false) calls stop(true) so revoking analytics consent stops the SDK; true resumes it (requires analytics_sdk 4.0.0, since 1.3.0).
• reset() only clears the customer user ID — AppsFlyer's SDK has no dedicated "reset" API, so this is a best-effort approximation, not a full data wipe.

Configuration

AppsFlyerRegisterModule provides both the SDK singleton and its config, and self-registers with the vendor registry as a side effect of construction:

@module
abstract class AppsFlyerRegisterModule() {
  this {
    AnalyticVendorRegistry.instance.register(AnalyticInjectorKey.appsFlyerImpl);
  }

  @lazySingleton
  AppsFlyerSdk get appsflyerSdk => AppsFlyerSdk.instance;

  @lazySingleton
  AppsFlyerConfig get appsflyerConfig => AppsFlyerConfig(
    devKey: AppEnv.appsflyerDevKey,
    appId: AppEnv.appsflyerAppId,
  );
}

devKey/appId come from app_config's AppEnv.appsflyerDevKey / AppEnv.appsflyerAppId — supply these via your .env/build-time config, no hardcoded credentials ship in the brick output.

Dependency injection

Like the monitoring vendors, this package declares AppsflyerAnalyticsImplPackageModule under its own archipelago: di_modules manifest, and post_gen.dart wires it into the app's injector.dart plus adds appsflyer_analytics_impl as a dependency of the app's pubspec.yaml (analytics_impl depends only on analytics_api so it is never touched). AppsFlyerRegisterModule's constructor calls AnalyticVendorRegistry.instance.register(AnalyticInjectorKey.appsFlyerImpl) as a side effect of the module running — this is what makes AnalyticVendorRegistry-driven discovery find the vendor when AnalyticsInitializer's AnalyticTracker is first resolved.

Dependencies

• analytics_api — the AnalyticVendor/TrackData contract
• app_config — AppEnv for the dev key / app ID
• appsflyer_sdk: 7.0.2+2
• dependencies (shared workspace injectable/get_it re-export)

This package's own code imports analytics_api. When infrastructure/analytics_api is missing, pre_gen generates analytics_sdk first. post_gen never patches analytics_impl (it depends only on analytics_api).

Known Limitations

• setUserProperty/reset cannot express AppsFlyer's actual multi-property "additional data" semantics beyond a single key/value overwrite each call.

Changelog

Run archipelago brick info appsflyer_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 AppsFlyer also declares appsflyerDevKey/appsflyerAppId in shared/app_config (Env, AppEnv, every .env* file), so no manual edit is needed.