2015-09-27 3 views
10

Ich benutze Facebook SDK (4. *) auf Android. Nur implementiert programmgesteuert anmelden (ohne Verwendung von "LoginButton") LoginManagerlogInWithReadPermissions(). Damit Callback funktioniert, muss ich FacebookCallbackManager.onActivityResult(requestCode, resultCode, data); aufrufen, was ich in der onActivityResult Methode meiner Aktivität mache.Wo ist der Anfrage-Code konstant (64206) für die Anmeldung in Facebook SDK definiert

Allerdings verarbeitet meine onActivityResult Ergebnisse mehrere wiederkehrende Aktivitäten und überprüft die requestCode, um zu sehen, welche Aktivität zurückgegeben wird. Ich sehe, dass Facebook Login mit 64206 zurückkehrt, aber ich kann nicht finden, wo diese Konstante definiert ist. Ich möchte 64206 nicht fest codieren und ich frage mich: Weiß jemand, wo dieser Ergebniscode im Facebook SDK definiert ist (und ist es öffentlich)?

+0

der Anforderungs-Code '64206' ist einfach' 0xface'. Überprüfen Sie die folgende Antwort. –

+0

In ähnlicher Weise lautet der Anfragecode '64207'' CallbackManagerImpl.RequestCodeOffset.Share.toRequestCode() '. –

Antwort

21

Also nach allem entschied ich mich, mit dem Debugger zu graben und fand es in der Facebook SDK. Anforderungscodes sind in CallbackManagerImpl.RequestCodeOffset definiert.

Sie können den Login-Anfragecode damit erhalten: CallbackManagerImpl.RequestCodeOffset.Login.toRequestCode().

Dort finden Sie auch Codes für Share, Message, Like, GameRequest, AppGroupCreate, AppGroupJoin, AppInvite.

3

Sie sollten sich nicht wirklich um den tatsächlichen Wert des von Facebook intern verwendeten Anfragecodes kümmern, da das Ergebnis von CallbackManager.onActivityResult(requestCode, resultCode, data) Ihnen sagen wird, ob es behandelt wurde oder nicht. Das heißt, zuerst das Ergebnis der CallbackManager anbieten. Wenn es anzeigt, dass es gehandhabt wurde, sind Sie fertig. Wenn es nicht behandelt wurde, ist es einer der Ergebnisse Ihres anderen Anfragecodes, also fahren Sie einfach mit der Logik fort, die Sie bereits haben.

Vom docs on CallbackManager:

/** 
* The method that should be called from the Activity's or Fragment's onActivityResult method. 
* @param requestCode The request code that's received by the Activity or Fragment. 
* @param resultCode The result code that's received by the Activity or Fragment. 
* @param data  The result data that's received by the Activity or Fragment. 
* @return true If the result could be handled. 
*/ 
public boolean onActivityResult(int requestCode, int resultCode, Intent data); 

Notiere die @return Bemerkung.

Also im Grunde Ihr Code sollte etwa so strukturiert sein:

@Override public void onActivityResult(int requestCode, int resultCode, Intent data) { 
    super.onActivityResult(requestCode, resultCode, data); 
    boolean handled = callbackManager.onActivityResult(requestCode, resultCode, data); 
    if (handled) { /* all done */ } 
    else { /* result wasn't handled by the callback manager, so check for other potential request codes */ } 
} 

Wenn Sie wirklich wollen, können Sie die Facebook-SDK Quelle tauchen in den Ursprung des Anforderungscodes zu verfolgen. Siehe insbesondere CallbackManagerImpl, wo die statischen Rückrufe mit einem vordefinierten Anforderungscode-Offset eingerichtet werden.

+2

Bei diesem Ansatz gibt es zwei Probleme: 1. Das größere Problem: Ich möchte keinen externen Code mit dem Ergebnis "Intent-Daten" aufrufen, das (möglicherweise) vertrauliche Informationen enthält. 2. Das kleinere Problem: Es ist nicht effizient (und es ist chaotisch). Was, wenn ich jedes Mal mehrere externe onActivityResult-Handler aufrufen muss, z. wenn ich mehrere externe libs verwende ... – Ognyan

+0

@Ogre_BGR: 1. Dann invertiere einfach das if-else, damit du nicht zum else kommst, wenn es einen 'sensiblen Datenfall' gab (wenn du das wirklich machst.) etwa, sollten Sie * keine * Bibliotheken verwenden, also ein bisschen strittiger Punkt). 2. Bestenfalls subjektiv.Sie sagen chaotisch, jemand anderes könnte das Gegenteil argumentieren, da das Ergebnis dann in dem Kontext behandelt wird, aus dem seine Anfrage gefeuert wurde. Es hängt auch davon ab, wie Sie die Effizienz definieren: Die Verwendung eines dedizierten Handlers ist ein einfacher Ansatz, um Code-Duplizierung zu vermeiden. Wie auch immer, am Ende liegt es an dir. Alles, was ich getan habe, ist eine vernünftige Lösung für Ihr Problem. :) –

+0

Ja, es ist subjektiv, aber ich tendiere dazu, zu expliziten Anfrage Code-Vergleich zu ziehen. Es gibt eine Sache, die mich mit der Lösung stört, die ich in der Antwort auf meine eigene Frage zur Verfügung gestellt habe: 'RequestCodeOffset' ist in' CallbackManagerImpl' verschachtelt und wenn Facebook beschließt, eine neue 'CallbackManager'-Implementierung bereitzustellen, können sie 'CallbackManagerImpl' und meinen Code ablehnen muss geändert werden (aber im Falle von FB haben wir das schon mehrere Male durchgemacht, also keine große Sache :-)). – Ognyan

4

besseren Weg ist FacebookSdk.getCallbackRequestCodeOffset()

+4

Nachdem ich FacebookSdk überprüft habe, fand ich eine Methode boolean isFacebookRequestCode (int requestCode). – dabicho

Verwandte Themen