Facebook Connect para iOS: la diferenciación respuesta dialogDidComplete

Question

Me preguntaba cómo diferenciar entre el usuario tocando someter o saltar en el FBDialog línea post-a-corriente. ¿Alguien sabe qué probar?

estoy usando la última iOS Facebook Connect en un entorno 4.2 iOS.

/** 
* Called when a UIServer Dialog successfully return. 
*/ 
- (void)dialogDidComplete:(FBDialog *)dialog { 
    if user tapped submit and post was successful 
     alert user of successful post 

    if user tapped "skip" (cancel equivalent) 
     do not display alert 
} 

Answer 1

Como dijo Fede y kennbrodhagen, esto se parece a la forma más fácil (hasta Facebook corrige este error):

 

- (void) dialogCompleteWithUrl:(NSURL*) url 
{ 
    if ([url.absoluteString rangeOfString:@"post_id="].location != NSNotFound) { 
     //alert user of successful post 
    } else { 
     //user pressed "cancel" 
    } 
} 
 

Answer 2

Mi entendimiento es que

- (void)dialogDidNotComplete:(FBDialog *)dialog; 

serían llamados para el salto.

No he probado esta teoría sin embargo.

Editar: he comprobado ahora, y mi teoría es errónea. El código parece que el diálogo debe llamar

- (void)dialogDidNotCompleteWithUrl:(NSURL *)url 

de su delegado, pero la práctica parece no hacerlo, ya que la página web está volviendo fbconnect: // éxito para una pulsación del botón "skip". Esto me suena a un error.

Answer 3

lo hice un poco de experimentación y parece que cuando se envía el mensaje obtendrá dos devoluciones de llamada: dialogCompleteWithUrl y luego dialogDidComplete. Cuando se omite la publicación, solo recibirá el diálogo de devolución de llamada completa.

Se podría desencadenar la alerta éxito en la devolución de llamada dialogCompleteWithUrl. Si desea esperar hasta que reciba el diálogo de devolución de llamada completa, puede guardar un estado durante el diálogo Completar con devolución de llamada y luego, basándose en ese estado, activar su alerta en el cuadro de diálogo Completar.

Durante mi prueba de la url que recibí durante dialogCompleteWithUrl era de la forma "fbconnect: // éxito/post_id = 1627754863_182914058401072"

Así que si es necesario se podría incluso echar un vistazo a este valor para confirmar aún más su éxito, aunque espero que si la publicación realmente falla (a diferencia de un salto) obtendrá una de las devoluciones de llamada fallidas en su lugar.

Answer 4

Recientemente descubrí la siguiente solución a este problema.

Consulte la respuesta de braceta.

https://github.com/ideashower/ShareKit/issues#issue/8

Answer 5

Hola acabo de seguir el enlace por @Oh Danny Boy y me encontré con esta solución

de este hilo: http://forum.developers.facebook.net/viewtopic.php?pid=303257#p303257 fijo esto añadiendo lo siguiente a webViewDidFinishLoad: en FBDialog.m

[_webView stringByEvaluatingJavaScriptFromString:@"document.getElementsByName('cancel')[0].onclick = function onclick(event) { window.location.href = 'fbconnect://cancel'; return false;}"]; 

Esto hace que el botón cancelar llame correctamente a "fbconnect: // cancel" en lugar de "fbconnect: // success".

- (void)webViewDidFinishLoad:(UIWebView *)webView { 
    [_webView stringByEvaluatingJavaScriptFromString:@"document.getElementsByName('cancel')[0].onclick = function onclick(event) { window.location.href = 'fbconnect://cancel'; return false;}"]; 

    [_spinner stopAnimating]; 
    _spinner.hidden = YES; 

    self.title = [_webView stringByEvaluatingJavaScriptFromString:@"document.title"]; 
    [self updateWebOrientation]; 
} 

Su funciona bien:

Pero hay una cuestión más Si Facebook Cambio html entonces este código ya no funcionará. Mi solución a este problema es que:

En lugar de poner JavaScript estáticamente acaba de obtener desde el servidor a intervalos regulares o mecanismo similer

[_webView stringByEvaluatingJavaScriptFromString://We need to control this javascript from server//]; 

por lo que en el futuro podemos cambiar esta javascript en lugar de actualizar toda la aplicación.

espero que en el futuro este error se resolverá http://bugs.developers.facebook.net/show_bug.cgi?id=5958