Closed dustinkerstein closed 5 years ago
@dustinkerstein , sorry for delay.
The default the max wait time is 5.5 sec and we try 3 times with an interval of 1 sec. So ideally it should return (5.5 x 3) + 2 = 18 seconds however , the underlying java implementation applies the timeout for each ip resolved for the DNS and hence the timeout will be long. However the above case the call back should be returned in timeout since there is no network.
So, question is:
Note: Branch API has 3 methods to change timeout values:
No worries on the delay.
I definitely waited longer than 18 seconds, but I can't say how long exactly. I will give it another try today while on the subway (it's a little hard to actually test this).
I haven't had an indefinite stretch of time to test really long periods, but I just went 60 seconds without a callback. As soon as service resumed the callback hits.
@dustinkerstein , I built android native testbed for you and I want to know how native testbed will work. Try please that apk: https://www.dropbox.com/s/zj8b502n6390hxm/Branch-SDK-TestBed-release.apk.zip?dl=0
Note: tap "clear user" before generating of each new link
I just downloaded the app and generated a link, and deep linking with that link works just fine, but I don't believe I can actually test my use case with this app since its lifecycle is different. My Unity app works like this:
Branch.initSession(CallbackWithBranchUniversalObject);
- This scene does nothing except for that.CallbackWithBranchUniversalObject
callback I decide which scene to load depending on the presence of deep link data.I have issues not when I am clicking a link (which wouldn't work since I have no service) but instead just when launching the app directly.
As a temporary workaround, I've added a coroutine after the Branch init that looks like this:
IEnumerator BranchTimeoutCheck(){
yield return new WaitForSeconds (15f);
Debug.Log ("Branch callback didn't return in 15 seconds. Loading next scene.");
SceneManager.LoadScene("ConfigureVR");
}
Which at least allows me to handle the case where the callback never returns.
Should I not be designing my app in a way that depends entirely on the callback? I was just under the impression that it should always return (within a relatively small time-frame) and combined with my app's dependency on deep linking as the primary UX, I felt it was a good approach.
@dustinkerstein , In Unity plugin we use android native jar. I wrote to our android engineers about your issue. When they will fix that, I will update Unity plugin.
I saw several apps that use the same way like you. And that is normal practice. But anyway you should have "default" way, when app doesn't have any info/response from branch.
Some teams made "deferred processing of callbacks". For example:
they made "global" catcher to catch and collect all callbacks from branch (branch universal object and link properties)
each scene, where app decide "which scene should I load?", asks that global object about last callback and decides what to do
global catcher was inited on the first scene and some loading progress was shown
when loading progress is 100%, app switch to scene where you make decision, and that scene ask catcher about "give me last callback"
I think in your case this solution can solve your issue when callback never returns, because after 20 seconds you can force switching to another scene and use "default" logic. Also that solution allow you to do some logic based on callbacks when you minimize your app and then maximize.
Sounds good. Thanks!
Due to this issue being a problem in the native Android SDK, and because of the age, I am closing this issue. If a problem is still occurring, please contact our support team or open a new github issue.
Everything is fine when the phone has a good wifi/cell connection (or airplane mode), but if I have zero bars the callback never seems to get fired.
My app starts with a scene dedicated to the branch init, and this issue causes the app to hang indefinitely in the above case. As soon as a connection is available, the callback does return.
This was tested with Unity 2017.1.0f3 on Android 7.1.2 on a Nexus 6p with the latest Branch SDK as of last Friday.
This isn't supposed to happen, right?