Разница между методом startChooser () и startActivity () - PullRequest
Новая
       35

Разница между методом startChooser () и startActivity ()

0 голосов
/ 05 июля 2018

Я новичок в Android и заметил, что могу поделиться намерением двумя способами.

первый путь:

ShareCompat.IntentBuilder.from(this). setType(mimeType). setChooserTitle(title). setText(text). startChooser();

Второй способ: 

Intent shareIntent =   ShareCompat.IntentBuilder.from(this)
                                                .setChooserTitle(title)
                                                .setType(mimeType)
                                                .setText(text)
                                                .getIntent();
    if (shareIntent.resolveActivity(getPackageManager()) != null){
        startActivity(shareIntent);
    }

У меня вопрос, спасает ли меня использование * 1015 от чека, который я использую вторым способом? ... также есть ли другие различия между этими двумя функциями?

Ответы [ 2 ]

0 голосов
/ 05 июля 2018

Использование startChooser() спасает меня от проверки, которую я использую в второй

номер

IntentBuilder - это, по сути, вспомогательный класс для построения намерений совместного использования (Intent#ACTION_SEND и Intent#ACTION_SEND_MULTIPLE) и запуска действий по обмену контентом.

также есть ли другие различия между этими двумя функциями

Под капотом и startChooser(), и startActivity () выполняют одно и то же действие. startChooser() просто заворачивает startActivity(). Проверьте определение startChooser(): 

    /**
     * Start a chooser activity for the current share intent.
     *
     * <p>Note that under most circumstances you should use
     * {@link ShareCompat#configureMenuItem(MenuItem, IntentBuilder)
     *  ShareCompat.configureMenuItem()} to add a Share item to the menu while
     * presenting a detail view of the content to be shared instead
     * of invoking this directly.</p>
     */
     public void startChooser() {
        mActivity.startActivity(createChooserIntent());
     }

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

0 голосов
/ 05 июля 2018

Первый способ:

Здесь вы передаете свой Намерение платформе, но не знаете, имеется ли какое-либо приложение в устройстве для обработки этого Намерения или нет.

второй способ:

Сначала убедитесь, что в устройстве доступно хотя бы одно приложение, способное обработать Намерение.

Во-вторых, у вас есть способ обработать неожиданный поток, не передавая это намерение фреймворку. Например, вы можете уведомить пользователя о «недоступном приложении для обработки этого действия».

...