2015-09-27 6 views
10

Sto usando Facebook SDK (4. *) su Android. È stato appena eseguito l'accesso a livello di codice (senza utilizzare "LoginButton") utilizzando di LoginManager. Affinché la richiamata funzioni, devo chiamare lo FacebookCallbackManager.onActivityResult(requestCode, resultCode, data); che faccio nel metodo onActivityResult della mia attività.Dove è la costante del codice di richiesta (64206) per l'accesso definito in Facebook SDK

Tuttavia, il mio onActivityResult gestisce i risultati di diverse attività di restituzione e controlla lo requestCode per vedere quale attività è stata restituita. Vedo che l'accesso di Facebook ritorna con 64206 ma non riesco a trovare dove è definita tale costante. Non voglio hardcode 64206 e mi chiedevo: qualcuno sa dove è definito questo codice risultato nell'SDK di Facebook (ed è pubblico)?

+0

il codice di richiesta '64206' è semplicemente' 0xface'. Controlla la risposta qui sotto. –

+0

Analogamente, il codice di richiesta '64207' è' CallbackManagerImpl.RequestCodeOffset.Share.toRequestCode() '. –

risposta

21

Quindi, dopo tutto, ho deciso di scavare con il debugger e l'ho trovato nel Facebook SDK. I codici di richiesta sono definiti in CallbackManagerImpl.RequestCodeOffset.

È possibile ottenere il codice di richiesta di accesso con questo: CallbackManagerImpl.RequestCodeOffset.Login.toRequestCode().

Vi si possono trovare anche i codici per Share, Message, Like, GameRequest, AppGroupCreate, AppGroupJoin, AppInvite.

3

Non dovresti davvero preoccuparti del valore effettivo del codice di richiesta utilizzato internamente di Facebook, in quanto il risultato di CallbackManager.onActivityResult(requestCode, resultCode, data) ti comunicherà se è stato gestito o meno. Vale a dire, prima offrire il risultato allo CallbackManager. Se indica che è stato gestito, hai finito. Se non è stato gestito, è uno dei risultati del tuo altro codice di richiesta, quindi continua semplicemente con la logica che hai già in essere.

Dal 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); 

Annotare la @return osservazione.

Quindi, in pratica, il codice dovrebbe essere strutturato un po 'come questo:

@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 */ } 
} 

Se si vuole veramente, è possibile immergersi nella fonte Facebook SDK per rintracciare l'origine del codice di richiesta. In particolare, fare riferimento a CallbackManagerImpl, dove i callback statici sono impostati con un offset di codice di richiesta predefinito.

+2

Ci sono due problemi con questo approccio: 1. Il problema più grande: non voglio chiamare codice esterno con il risultato 'Dati intenzionali' che (può) contiene informazioni sensibili. 2. Il problema più piccolo: non è efficiente (ed è disordinato). Cosa succede se devo chiamare ogni volta più gestori esterni onActivityResult, ad es. se uso diverse librerie esterne ... – Ognyan

+0

@Ogre_BGR: 1. Quindi capovolgi l'if-else, in modo da non arrivare al resto se ci fosse un 'caso dati sensibili' (se è davvero quello che ti preoccupa a proposito, non dovresti usare comunque * qualsiasi * librerie, quindi un po 'un punto controverso). 2. Soggettivo al meglio.Tu dici disordinato, qualcun altro potrebbe argomentare il contrario in quanto il risultato viene quindi gestito nel contesto in cui è stata emessa la sua richiesta. Dipende anche da come si definisce l'efficienza: avere un gestore dedicato è un approccio semplice per evitare la duplicazione del codice. Ad ogni modo, alla fine tocca a te. Tutto ciò che ho fatto è fornire una soluzione ragionevole al tuo problema. :) –

+0

Sì, è soggettivo ma tendo a gravitare verso il confronto esplicito del codice di richiesta. C'è una cosa che mi dà fastidio la soluzione che ho fornito nella risposta alla mia stessa domanda: "RequestCodeOffset" è annidato in "CallbackManagerImpl" e se Facebook decide di fornire una nuova implementazione di "CallbackManager" possono deprecare "CallbackManagerImpl" e il mio codice dovrà essere cambiato (ma nel caso di FB ne abbiamo già sofferto diverse volte, quindi non è un grosso problema :-)). – Ognyan

4

Modo migliore è chiamare FacebookSdk.getCallbackRequestCodeOffset()

+4

Dopo aver controllato FacebookSdk, ho trovato che esiste un metodo booleano isFacebookRequestCode (int requestCode). – dabicho