2016-04-08 2 views
0

Ich benutze branch.io SDK in einer iOS-App. Wir verwenden es als eine Möglichkeit, Nutzer zu unserer App einzuladen und sie zu einem benutzerdefinierten Onboarding-Bildschirm umzuleiten, wenn der Zweiglink vorhanden ist. Eine Sache, die wir bemerkt haben, ist, dass es eine leichte Verzögerung zwischen dem Öffnen der App und dem Aufruf des Branch-Handlers gibt.branch.io Bypass von App-Anmeldebildschirm, wie Verzögerung zu behandeln, bevor url behandelt

Das bedeutet, dass meine App den üblichen Startbildschirm lädt und dann etwa eine halbe Sekunde später der Code der Filiale ausgeführt wird und meine App auf die richtige Ansicht umleitet. Ich sehe den LaunchScreen, meinen Login-Bildschirm für eine halbe Sekunde und dann meine Branch.io-Handler-Ansicht. All das ist richtig, aber ich frage mich, wie ich das besser strukturieren soll, damit es nicht die anfängliche Login Screen View gibt?

Es gibt auch die Möglichkeit einer Race Condition mit dem Verzweigungsblock und den Startblöcken der normalen App, die beide asynchron sind. Im Moment dauert der Zweigblock immer länger, also keine große Sache.

Einige Ideen, die ich hatte:

1) ähnlich eine anfängliche Ansicht erstellen, um die LaunchScreen, dass der App landet auf bis branch.io zurückkehrt, den Splash-Screen anstatt zu zeigen, einen Login-Bildschirm künstlich erstreckt. Das Problem hierbei ist, dass Branch.io außerdem die Fortsetzung nonbranch.io auslösen muss und eine Verzögerung von einer halben Sekunde für alle Einträge bedeutet. Nicht gut. Wenn ich zusätzlich einen Netzwerkanruf benötige, könnte die Verzögerung länger sein, ein Spinner hilft diesem Prozess nicht.

2) Integrieren Sie den AuthManager-Login-Statuscode in den Branch.io-Handler, sodass der normale App-Prozess seriell zum Zweig ausgeführt wird; anstatt dass beide async laufen. Dies schafft wiederum eine Verzögerung, die behandelt werden muss, sonst gibt es nur eine halbe Sekunde lang einen weißen Bildschirm. Es bindet auch den Ladevorgang meiner gesamten App an das SDK von branch.io, das wie erwartet funktioniert, und nicht das, worauf ich mich bei einem SDK verlassen möchte.

Gibt es eine bessere Möglichkeit, diesen Workflow zu erstellen?

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { 
    //... 

    // initialize branch.io 
    Branch *branch = [Branch getInstance]; 
    [branch initSessionWithLaunchOptions:launchOptions andRegisterDeepLinkHandler:^(NSDictionary *params, NSError *error) { 
     // do stuff with branch, such as redirect to a custom View. 
     // run every load and handled if branch.io link present  

     // possible network call(s) involved if branch link present.  
    }]; 

    // ... 

    [[AuthManager sharedInstance] isLoggedInCompletionHandler:^{ 
     // load HomeViewController (logged in) 
    } notLoggedInCompletionHandler:^{ 
     // load LoginViewController (not logged in) 
    }]; 
} 

Antwort

0

Alex mit Branch.io hier:

Diese leichte Verzögerung ist eine unvermeidbare Begrenzung für Daten von einem Server Rückruf warten. Branch tut alles, um das Warten so kurz wie möglich zu machen, und wenn wir versuchen, diese Situation zu lösen, haben unsere Partner oft einen ähnlichen Ansatz wie Ihre zweite Idee gewählt.

Der Branch Callback ist garantiert zu 100% der Zeit (auch wenn das Netzwerk aus ist), so die beste Option ist, einen Begrüßungsbildschirm zu erstellen, der alle Routing bis der Rückruf ankommt. Wenn Branch nichts gibt, können Sie regelmäßig routen. Wenn Branch etwas anbietet, können Sie zu den tief verlinkten Inhalten weiterleiten.

Verwandte Themen