The Callback given to Branch.reInitSession() is not called because an exception in Answer event (my supposition)

[Danyaga]

After the Branch.reInitSession(), I get this error in the logcat and then Callback object is not called.

I think you just forgot to limit the size of a parameter you send in the Answer event, that in same cases, it can be even long.

This issue is still the last current version available: 4.1.1.

2019-10-15 14:06:20.636 31557-31557/? E/Answers: Invalid user input detected java.lang.IllegalArgumentException: String is too long, truncating to 100 characters at com.crashlytics.android.answers.AnswersEventValidator.limitStringLength(AnswersEventValidator.java:38) at com.crashlytics.android.answers.AnswersAttributes.put(AnswersAttributes.java:38) at com.crashlytics.android.answers.AnswersEvent.putCustomAttribute(AnswersEvent.java:56) at com.crashlytics.android.answers.shim.KitEvent.toCustomEvent(KitEvent.java:31) at com.crashlytics.android.answers.shim.AnswersKitEventLogger.logKitEvent(AnswersKitEventLogger.java:34) at io.branch.referral.ExtendedAnswerProvider.provideData(ExtendedAnswerProvider.java:47) at io.branch.referral.ServerRequestInitSession.onRequestSucceeded(ServerRequestInitSession.java:124) at io.branch.referral.ServerRequestRegisterInstall.onRequestSucceeded(ServerRequestRegisterInstall.java:70) at io.branch.referral.Branch$BranchPostTask.onPostExecute(Branch.java:3229) at io.branch.referral.Branch$BranchPostTask.onPostExecute(Branch.java:3091) at android.os.AsyncTask.finish(AsyncTask.java:695) at android.os.AsyncTask.access$600(AsyncTask.java:180) at android.os.AsyncTask$InternalHandler.handleMessage(AsyncTask.java:712) at android.os.Handler.dispatchMessage(Handler.java:106) at android.os.Looper.loop(Looper.java:214) at android.app.ActivityThread.main(ActivityThread.java:6990) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1445)

[apeterson-branch]

The callback not being called doesn't appear to be related to the log message. The line in question (ExtendedAnswerProvider::provideData line #47) is protected by a try/catch that should have caught any exceptions. Do you have the ability to turn Branch debugging on, and provide a full log?

Reference: https://github.com/BranchMetrics/android-branch-deep-linking-attribution/blob/ae312895ba9c724f23bae47792b97d706acb6715/Branch-SDK/src/io/branch/referral/ExtendedAnswerProvider.java#L47

[Danyaga]

Thx. I am working to provide more log I can.

Anyway, you should make the call of that callback more reliable, because every too often i read about this problem. Even with an Error object, if it is the case, but the call back has to be called.

EDIT x1

2019-10-15 16:25:36.034 19093-19093/? I/BranchSDK: ReferrerClientWrapper Exception: Failed resolution of: Lcom/and 2019-10-15 16:25:36.363 19093-19093/? I/BranchSDK: Strong match request https://app.link/_strong_match?os=Android& 2019-10-15 16:25:36.558 19093-19135/? I/BranchSDK: posting to https://api2.branch.io/v1/install 2019-10-15 16:25:36.558 19093-19135/? I/BranchSDK: Post value = {"hardware_id":"b783b1e888364c88","is_hardware_id_ 2019-10-15 16:25:36.810 19093-19135/? I/BranchSDK: returned {"session_id":"712674787462083568","identity_id":"7126

Here the text well formatted. Here a 2nd run.

It seems you have all the data to match my session and call-back my code, but the Callback object is not called.

[apeterson-branch]

I need more information to proceed.

• Crashlytics may not be the root of the problem?
• Your callback is never called? For any event?

[Danyaga]

No, it is called all events (second launch with/without deep-links, etc...) but not right after the first launch after the installation.

EDIT x1

I found this. I am trying to add it as dependency.

EDIT x2

Here the log after the addition of installreferrer as dependency. I think now is better but still no call back called even if you got all the data from your backend.

EDIT x3

Here the second launch after the first which is perfect and the callback is called properly.

EDIT x4

May it be the finish the activity? Maybe you need more time to match the information from referrer API of the PlayStore right after the installation and I, finishing the Activity after a my timeout, am preventing your code to work. Do you suggest to call the finish() of the (splash) Activity from your callback? Is your callback reliable enough?

[apeterson-branch]

Is your callback in an activity, such as a Splash Activity, that finishes before the callback completes?

[Danyaga]

Is your callback in an activity, such as a Splash Activity, that finishes before the callback completes?

Yes, It is. I collect in async in a my Singleton the properties you provide me. In the meantime, but detached on main thread, a timeout is calling finish() and handling the routing of the app to other activities.

EDIT x1

Unfortunately, even keeping the activity alive until you init your code doesn't help me, your callback is not called at the first launch after installation. This even if you collected the data from your backend as your log above shows.

EDIT x2

What i don't get from your SDK is when I have to wait for the Callback called and when not.

Is there a flag i can check in Branch object? All my app routing is waiting for your response, via the Callback call, at this point, but not always it is called.

EDIT x3

I am using .reInitSession(), because the handling of deep link has to work also when the app is in background and the returning of a true is misleading here, if i may, https://github.com/BranchMetrics/android-branch-deep-linking-attribution/blob/ae312895ba9c724f23bae47792b97d706acb6715/Branch-SDK/src/io/branch/referral/Branch.java#L1436 because you should return the actual result of initSession() not a fake result hardcoded.

EDIT x4

This is the .prepare() of my singleton that collects stuff from you when the Callback works.

EDIT x5

I found here you use another method to init the session on your singleton. Can you please explain better the difference with the (re-)init method i am using? Which one has to be used? TBH I think you are not proving us enough documentation to choose one of them and what are the downside of those different implementations and feature of your SDK.

[apeterson-branch]

The main issue I see here is that your callback is in an activity that is no longer on the stack when it finally fires. With poor network conditions, you might be many seconds (let's pretend it is 15 seconds just for example) before the callback returns. Obviously that is not a great user experience to wait that long.

Some options might be:

1. You can defer initializing Branch until after your Splash Activity (in your MainActivity) but make sure to forward any Intent data to your MainActivity.
2. You can put the Branch Listener in the Application class and never worry about it going out of scope. This would require some additional work to pass Branch messages to the current activity.

[apeterson-branch]

Re-Init is not what you want for this scenario. This is a recent addition to handle the specific case where you already have an activity in the foreground, and you receive a push notification and need to handle onNewIntent() to process new URI data.

[Danyaga]

The main issue I see here is that your callback is in an activity that is no longer on the stack when it finally fires. With poor network conditions, you might be many seconds (let's pretend it is 15 seconds just for example) before the callback returns. Obviously that is not a great user experience to wait that long.

Some options might be:

1. You can defer initializing Branch until after your Splash Activity (in your MainActivity) but make sure to forward any Intent data to your MainActivity.
2. You can put the Branch Listener in the Application class and never worry about it going out of scope. This would require some additional work to pass Branch messages to the current activity.

Thx for the answer.

I fixed that issue by waiting for the callback (and, for sure, setting a good network time).

[Danyaga]

Re-Init is not what you want for this scenario. This is a recent addition to handle the specific case where you already have an activity in the foreground, and you receive a push notification and need to handle onNewIntent() to process new URI data.

Nice. At this point the only issue i have is you defined 2 types of init session methods:

1. With a BranchUniversalReferralInitListener object as input
2. With a BranchReferralInitListener object as input

I found out that only for the methods of 1. kind, the Callback object is called every time. So, is it right to user the 1.? I think this is the major misleading information provided by your documentation, which tells to use the 2. kind of methods, and I assume those are intended to be used in other situations.

[Danyaga]

@apeterson-branch Hello, is there a chance to have an answer about my last question?

[apeterson-branch]

There are several forms of initialization available, and all should work in a similar fashion. If you are having issues with form(1) I haven't heard of this from anyone else. Are you saying that -- if you use the BranchUniversalReferralInitListener in your activity that it never responds with a callback?

[Danyaga]

There are several forms of initialization available, and all should work in a similar fashion. If you are having issues with form(1) I haven't heard of this from anyone else. Are you saying that -- if you use the BranchUniversalReferralInitListener in your activity that it never responds with a callback?

As I told you I tried with one of init methods that take a BranchReferralInitListener callback object as input, but, unfortunately, it is not called always (only for launches that are not the first after installation).

Re-Init is not what you want for this scenario. This is a recent addition to handle the specific case where you already have an activity in the foreground, and you receive a push notification and need to handle onNewIntent() to process new URI data.

Nice. At this point the only issue i have is you defined 2 types of init session methods:

1. With a BranchUniversalReferralInitListener object as input
2. With a BranchReferralInitListener object as input

I found out that only for the methods of 1. kind, the Callback object is called every time. So, is it right to user the 1.? I think this is the major misleading information provided by your documentation, which tells to use the 2. kind of methods, and I assume those are intended to be used in other situations.

As I told here I found by my-self this new set of init methods (which is different from the one you suggest to use in your documentation on the site), that is called always.

[apeterson-branch]

I opened a Jira ticket to investigate this. Reference: SDK-602

[ben-j69]

@Danyaga I had the same problem on 4.0.2 and 4.1.0 "Invalid user input detected java.lang.IllegalArgumentException: String is too long, truncating to 100 characters"

By upgrading to 4.1.2 the crash does not occur anymore.

[Danyaga]

@ben-j69 Thx mate. I'll check for sure.

I saw they did a couple of changes also about the other topics, so I definitely should update the dependency, see the results and update this ticket to help them.