Estoy trabajando en una aplicación de Android para mi investigación, y estoy trabajando con OAuth (biblioteca de señalización) para obtener acceso a los datos de usuario de un servicio web que es también una parte del proceso de desarrollo. Puedo pasar por los pasos comunes de OAuth, y uso un Uri (para devolver la llamada a la aplicación), y puedo llegar al paso donde invoco el navegador de los dispositivos, elegir verificar mi aplicación, y el siguiente paso es SUPUESTO para redirigir el navegador de nuevo a la aplicación ....Android Dev - La URL de devolución de llamada no funciona ... (0_o)
en vez me sale un error que dice algo así como "usted no tiene permiso para abrir:
appSchema: // appName authorizationSensitiveInfo ... " los apéndices después del '?' son oauth_token y oauth_verifier desde el servicio (podemos asumir todos los pasos hasta que la redirección sea "correcta").
Los posibles problemas se encuentran en la parte appSchema://appName
. según tengo entendido, esta es la URL de redirección que le dice al Uri que use el navegador del teléfono para localizar mi aplicación e invocar el método onResume(). ¿De dónde vienen los valores para appSchema://appName
(definidos en el manifiesto? Si es así ¿dónde?).
¿Por qué el problema con el permiso? ¿Debo configurar los permisos para que mi Uri acceda a mi aplicación? Estoy perdido ... si necesitas fragmentos de código para ayudarme, por favor responde, no incluí ningún código porque esto es más como un concepto que me perdí ... No estoy en mi máquina ahora pero puedo suministrar código si eso haría las cosas más fáciles de entender. Realmente golpear la cabeza de aquí ...
EN Respone A UN GRAN respuesta aquí es cómo manejo mi hoja de vida EN
protected void onResume() {
super.onResume();
Uri uri = this.getIntent().getData();
if (uri != null && uri.toString().startsWith(CALLBACK_URL)) {
Log.d("StepGreenM", uri.toString());
String verifier = uri.getQueryParameter(OAuth.OAUTH_VERIFIER);
Log.d("StepGreenM", verifier);
try {
provider.retrieveAccessToken(consumer, verifier);
TOKEN = consumer.getToken();
REQUEST_SECRET = consumer.getTokenSecret();
Log.d("StepGreenM", TOKEN);
Log.d("StepGreenM", REQUEST_SECRET);
} catch (OAuthMessageSignerException e) {
e.printStackTrace();
} catch (OAuthNotAuthorizedException e) {
e.printStackTrace();
} catch (OAuthExpectationFailedException e) {
e.printStackTrace();
} catch (OAuthCommunicationException e) {
e.printStackTrace();
}
}
uri = getIntent().getData();
if (uri != null && CALLBACK_URI.getScheme().equals(uri.getScheme())) {
String token = settings.getString(HomeScreen.REQUEST_TOKEN, null);
String secret = settings.getString(HomeScreen.REQUEST_SECRET, null);
Intent i = new Intent(Intent.ACTION_VIEW); // Intent to go to the action view
try {
if(!(token == null || secret == null)) {
consumer.setTokenWithSecret(token, secret);
}
String otoken = uri.getQueryParameter(OAuth.OAUTH_TOKEN);
String verifier = uri.getQueryParameter(OAuth.OAUTH_VERIFIER);
// We send out and save the request token, but the secret is not the same as the verifier
// Apparently, the verifier is decoded to get the secret, which is then compared - crafty
// This is a sanity check which should never fail - hence the assertion
Assert.assertEquals(otoken, consumer.getToken());
// This is the moment of truth - we could throw here
provider.retrieveAccessToken(consumer, verifier);
// Now we can retrieve the goodies
token = consumer.getToken();
secret = consumer.getTokenSecret();
//Save it to a settings file
HomeScreen.saveAuthInformation(settings, token, secret);
// Clear the request stuff, now that we have the real thing
HomeScreen.saveRequestInformation(settings, null, null);
i.putExtra(USER_TOKEN, token);
i.putExtra(CONSUMER_SECRET, secret);
//GO TO APPLICATION
} catch (OAuthMessageSignerException e) {
e.printStackTrace();
} catch (OAuthNotAuthorizedException e) {
e.printStackTrace();
} catch (OAuthExpectationFailedException e) {
e.printStackTrace();
} catch (OAuthCommunicationException e) {
e.printStackTrace();
} finally {
startActivity(i); // we either authenticated and have the extras or not, but are going to the action view
this.setContentView(R.layout.indivaction);
finish();
}
}
}
No está seguro de lo que realmente hace que este otoño aparte ... pero como he dijo que la fuerza se cierra cuando se invoca este método. Sé que pasa la redirección porque uso un httpSniffer para verificar los mensajes hacia y desde el servidor ...
Haré esto una prueba y le dejaré saber si eso funciona. Tenía esa intención manifiesta de filtro de jazz en mi actividad principal, la moveré a la actividad que usa Oauth y anexaré el '?' a mi URL de devolución de llamada. ¡Gracias! –
¿Está iniciando el navegador a través de un intento de tipo ACTION_VIEW? Una posible molestia que puede encontrarse aquí es que aunque el navegador redirigirá a su aplicación, no se cerrará automáticamente. No estoy seguro de si eso obstaculizaría lo que está tratando de lograr. – ootinii
Estoy usando ACTION_VIEW, y una pregunta que tengo es cómo puedo determinar si estoy usando singleinstance/singleTop, es tan simple como si no veo esas palabras (seguro que nunca invoco manualmente) entonces puedo usar onResume en comparación con onNewIntent(). Incluí el filtro de intención en la actividad en el manifiesto, pero ahora mi fuerza de aplicación se cierra. Lo que intento hacer al resumir es guardar la información automática de la devolución de llamada a un archivo SharedPreferences para que otras actividades de mi aplicación puedan usar eso. pero en lugar del mensaje de permiso, simplemente cierra a la fuerza :( –