Открытые данные атрибуции AppsFlyer не всегда сообщаются на iOS с помощью cordova-plugin-appsflyer-sdk
После того, как мы заметили, что у некоторых из наших пользователей отсутствуют данные об атрибуции открытых приложений, мы глубже изучили источник cordova-plugin-appsflyer-sdk, чтобы найти причину, и нашли его:
Мы устанавливаем onInstallConversionDataListener в true при инициализации SDK для получения соответствующих обратных вызовов. Тем не менее, onSuccess обратный вызов не вызывается во всех случаях с данными атрибуции. Причиной этого является способ родных обратных вызовов (onConversionDataReceived & onAppOpenAttribution) обрабатываются в AppsFlyerPlugin.m, При запуске приложения с глубокой ссылкой AppsFlyer мы должны получить обе данные конверсии (нативные: onConversionDataReceived) и информация о глубоких ссылках (родной: onAppOpenAttribution). Проблема в реализации плагина состоит в том, что только первый из этих двух обратных вызовов перенаправляется в часть кода Java-скрипта, а тот, который идет вторым, игнорируется, потому что conversionListeners будет установлен в нуль после первого onSuccess вызов (AppsFlyerPlugin.m строки 386, 394 и 375 https://github.com/AppsFlyerSDK/cordova-plugin-appsflyer-sdk/blob/master/src/ios/AppsFlyerPlugin.m)
Наше наблюдение показывает, что родные обратные вызовы onConversionDataReceived & onAppOpenAttribution оба они вызываются правильно, когда мы открываем приложение по глубокой ссылке, но они вызываются в разной последовательности, в зависимости от того, находится приложение в фоновом режиме или нет. Это приводит к тому, что если вы откроете приложение с глубокой ссылкой, только данные о преобразовании будут отправлены в JavaScript с onSuccess обратный вызов в случае, если приложение вообще не было запущено, и в случае, если приложение находилось в фоновом режиме, отправляются только данные об атрибуции открытого приложения (приложение возобновляет работу). Правильное поведение будет то, что оба onConversionDataReceived & onAppOpenAttribution должны быть направлены в обоих случаях.
Держать conversionListeners (= не установка в ноль в строке 386, 394 и, возможно, также 375), кажется, решает проблему, но мы не знаем причину, по которой эти слушатели в настоящее время удаляются после их первого вызова.
Есть ли причина для сброса этого обратного вызова на ноль?