Android Dev – URL-адрес обратного вызова не работает (0_o)

Я работаю над приложением для Android для своих исследований и работаю с OAuth (библиотекой указателей), чтобы получить доступ к пользовательским данным из веб-службы, которая также является частью процесса разработки. Я могу пройти через обычные шаги OAuth, и я использую Uri (для обратного вызова к приложению), и могу перейти к шагу, на котором я вызываю браузер устройств, выбираю проверку моего приложения, и следующий шаг ПРЕДПОЛАГАЕТСЯ чтобы перенаправить браузер НАЗАД в приложение....

Вместо этого я получаю сообщение об ошибке, которое гласит: «У вас нет разрешения на открытие:

appSchema://appName?authorizationSensitiveInfo..." придатки после '?' являются oauth_token и oauth_verifier из службы (мы можем предположить, что все шаги до тех пор, пока перенаправление не будет «правильным»).

Возможные проблемы лежат в части appSchema://appName. насколько я понимаю, это URL-адрес перенаправления, который сообщает Uri использовать браузер телефона, чтобы найти мое приложение и вызвать метод onResume(). Откуда берутся значения для appSchema://appName (определены в манифесте? Если да, то где?).

Почему проблема с разрешением? Должен ли я устанавливать разрешения для моего Uri для доступа к моему приложению? Я потерялся... если вам нужны фрагменты кода, чтобы помочь мне, пожалуйста, ответьте, я не включал никакого кода, потому что это больше похоже на концепцию, которую я только что пропустил... Сейчас я не на своей машине, но я могу предоставить код, если это облегчит понимание. Вот реально ломаю голову...

В ОТВЕТ НА ОТЛИЧНЫЙ ОТВЕТ ВОТ КАК Я РАБОТАЮ С МОИМ РЕЗЮМЕ

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();
        }
    }
}

Не уверен, что на самом деле заставляет это развалиться... но, как я уже сказал, оно принудительно закрывается при вызове этого метода. Я знаю, что это проходит через перенаправление, потому что я использую httpSniffer для проверки сообщений на сервер и с сервера...


person hitsugaya_taichou    schedule 05.04.2011    source источник


Ответы (1)


Чтобы uri обратного вызова работал правильно, вам нужно добавить фильтр намерений, подобный следующему, в ваш манифест в действии, в котором вы хотите его использовать.

   <intent-filter>          
    <action android:name="android.intent.action.VIEW"/>     
    <category android:name="android.intent.category.DEFAULT"/>
    <category android:name="android.intent.category.BROWSABLE"/>
    <data android:scheme="appSchema" android:host="appName"/> 
   </intent-filter>

Теперь, если ваша деятельность использует singleInstance/singleTask, вы должны использовать что-то похожее на следующее:

@Override
public void onNewIntent(Intent intent) {

    super.onNewIntent(intent);
    Uri uri = intent.getData();
    String oauthToken = uri.getQueryParameter("oauth_token");
    String oauthVerifier = uri.getQueryParameter("oauth_verifier");

    //...do what you need with the parameters
}

если вы не используете singleTask или singleInstance, вы можете сделать

@Override
public void onResume() {

    super.onResume();
    Intent intent = getIntent();
    Uri uri = intent.getData();
    String oauthToken = uri.getQueryParameter("oauth_token");
    String oauthVerifier = uri.getQueryParameter("oauth_verifier");

    //...do what you need with the parameters
}

Я считаю, что это должно сработать.

Кроме того, если я не ошибаюсь, URL-адрес обратного вызова, который вы предоставляете, должен включать ?, поэтому «appSchema://appName?»

person ootinii    schedule 05.04.2011
comment
Я попробую и дам вам знать, если это сработает. У меня был этот джазовый фильтр манифестных намерений в моем основном действии, я перенесу его в действие, которое использует Oauth, и добавлю '?' на мой URL-адрес обратного вызова. Спасибо! - person hitsugaya_taichou; 05.04.2011
comment
Вы запускаете браузер через намерение типа ACTION_VIEW? Одна из возможных неприятностей, с которой вы можете столкнуться здесь, заключается в том, что, хотя браузер и перенаправит вас обратно в ваше приложение, он не закроется автоматически. Не уверен, что это помешает тому, что вы пытаетесь выполнить. - person ootinii; 06.04.2011
comment
Я использую ACTION_VIEW, и у меня есть один вопрос: как определить, использую ли я singleinstance/singleTop, так ли просто, как если бы я не видел этих слов (я никогда не вызываю их вручную), тогда я могу использовать onResume в отличие от onNewIntent(). Я включил фильтр намерений в действие в манифесте, но теперь мое приложение закрывается. Что я пытаюсь сделать при возобновлении, так это сохранить информацию oauth из обратного вызова в файл SharedPreferences, чтобы другие действия моего приложения могли использовать это. но вместо сообщения о разрешении оно просто принудительно закрывается :( - person hitsugaya_taichou; 06.04.2011
comment
Ах, мой плохой, я имел в виду singleInstance/singleTask, но если вы не установили android:launchMode для этого действия в своем манифесте, он должен использовать стандарт, что означает, что вы правильно используете onResume, а не onNewIntent. Когда вы закончите работу с браузером, вызовет ли обратный вызов вашу активность повторно? - person ootinii; 06.04.2011
comment
Итак, ваша активность принудительно закрывается после перенаправления обратно из браузера? Если это так, я бы проверил logcat, возможно, виновником является какое-то исключение, которое вы не ловите. - person ootinii; 06.04.2011
comment
Спасибо за всю твою помощь! Я просмотрю список исключений и посмотрю, что выглядит не так. Вы очень помогли!! - person hitsugaya_taichou; 06.04.2011
comment
Спасибо. это было решением моей проблемы с активностью singleTask. - person cucko; 24.05.2013
comment
Не забудьте добавить android:launchMode=singleTop в свою активность в файле манифеста, проверьте этот URL-адрес для получения более подробной информации о launchMode: intridea.com/blog/2011/6/16/ - person ImadT; 16.09.2014
comment
Обязательно ли использовать super.onResume() и super.onNewIntent() соответственно в этих фрагментах? - person Puma; 16.02.2016
comment
Определенно в onResume(), и, вероятно, неплохая идея сделать это и в onNewIntent, хороший звонок, отредактировано. - person ootinii; 16.02.2016