Android activity result api fragment

Introducing the Activity Result APIs

Google has finally released the new Activity Result APIs, which are something I’ve been looking forward to for a very long time. In this post I’ll run through the basics, how you can create your own contracts, and how this allows us to abstract away even more responsibilities from your UI.

The basics

As I’m sure you’re aware, when you want to request data from another activity (say for instance, requesting an image from a camera), you would override onActivityResult . This works absolutely fine but has a couple of downsides:

Repetitive logic

Actually receiving the result requires some slightly tedious code. You need to check the request code to see if it was your activity that requested what’s being returned, then you need to check to see whether or not the request was successful. After that, you pull the data out of the Intent object. It’s become commonplace to see code like this littered around the UI:

Wouldn’t it be nice if we could abstract this away?

Tight coupling

The only place to get these onActivityResult callbacks is in an Activity or Fragment and there’s simply no getting around that.

The Activity Result API

Starting with Activity 1.2.0-alpha02 and Fragment 1.3.0-alpha02 , we now have a nice abstraction which allows us to handle onActivityResult callbacks in a neat and reusable way, and Google were kind enough to add a few commonly used contracts so that we don’t need to manage them ourselves.

This is the new callback which we can register at any point in our Activity . Making the actual request is as simple as invoking takePicture :

So what’s going on here? Let’s break it down slightly. takePicture is just a callback which returns a nullable Bitmap — whether or not it’s null depends on whether or not the onActivityResult process was successful. prepareCall then registers this call into a new feature on ComponentActivity called the ActivityResultRegistry — we’ll come back to this later. ActivityResultContracts.TakePicture() is one of the built-in helpers which Google have created for us, and finally invoking takePicture actually triggers the Intent in the same way that you would previously with Activity.startActivityForResult(intent, REQUEST_CODE) .

The built in ActivityResultContracts

The built-in ActivityResultContracts currently include a few common operations:

• Requesting multiple permissions with RequestPermissions
• Requesting just one permission with RequestPermission
• Making a phone call with Dial
• And taking a picture with TakePicture

So what do these actually do under the hood? Let’s take a closer look at TakePicture :

ActivityResultContract takes two type parameters which correspond to data that’s required to make this request (in this case, nothing or Void but quite often a String such as a URI), and the data type to be returned — a Bitmap . As we can see, the contract has two functions, createIntent and parseResult :

In these built-in contracts, you can see we’ve moved the logic which previously tended to live in our Activity and moved them to pretty trivial helper classes. It’s also incredibly easy for us to write our own reusable contracts: we simply specify the inputs and outputs, and handle the Intent creation and Intent + resultCode parsing ourselves.

For a concrete example: we often launch one of our own Activities to send custom data types back. Here’s a ActivityResultContract which would allow us to handle that:

Lovely. However, this is still coupled to the Activity or Fragment . Is there a way around this?

The ActivityResultRegistry

Happily, there is, and it allows us to do all sorts of clever things. The ActivityResultRegistry is a new feature of the ComponentActivity class, and ultimately it contains a list of callbacks to be invoked when onActivityResult is triggered. All we require is a reference to one to be able to register our listeners from any class:

It’s worth pointing out that the resultLauncher() invocation here is an activity-ktx extension for invoking an ActivityResultLauncher of type Void , which is actually just:

Thanks to Ian Lake for letting me know about this one. The TakePictureHandler class allows our Activities to be more composable, and we can test this functionality fairly easily as a small, single-responsibility class, abstracted away from our view:

One slight downside of this is you have to remember to add the handler to the lifecycle observer in your Activity or Fragment . We can improve this a little so that it manages this task itself:

Here, we pass both an ActivityResultRegistry and a LifecycleOwner to the underlying implementation — this is because otherwise it wouldn’t be possible to test the implementation; we need to be able to pass our own result registry with a dispatching callback AND we need to be able to trigger the onCreate lifecycle callback. By keeping the TakePictureImpl internal , we can test this class thoroughly but expose a simpler API for the caller where we only pass the ComponentActivity . There’s a bit of Kotlin delegation magic here too, and if you’re unsure what this does you can check out one of my previous articles for some more info.

Back to the Activity Result API itself: there’s plenty of situations where this would be useful. We have a class which abstracts away Google’s in-app update API and emits a sealed class of results through a Kotlin Flow type. However the API requires implementing onActivityResult , and we haven’t been able to get around that, so we’ve had to pass the Intent returned through the callback manually to the class. Now we don’t have to do that, the class can be entirely self-contained. It’s a pretty complex example so I haven’t posted it here, but I might put it up separately once I’ve refactored it to use the new registry.

I’m also looking forward to seeing what abstractions people come up with for requesting permissions with this new API.

Gotchas

After some discussion, there does appear to be a small gotcha whilst using this API. Google are pretty explicit in their docs that you must re-register your callback in onCreate :

To clarify, these callbacks are not persisted on a configuration change — but any results returned are in-fact queued, so that when you re-register you’ll instantly receive the awaiting result. Basically to avoid weird behaviour, always make sure these callbacks are registered in onCreate ; don’t do anything weird like registering them ad-hoc in click listeners. Thanks to Gabor Varadi and Vasiliy Zukanov for spotting this and a good discussion on the underlying issue on Twitter. There’s also a great point made here:

The issue isn’t the number of pending requests, it’s that the ID for a result contract is dynamic based on an AtomicInteger.getAndIncrement instead of something stable. So if you misuse the API and call prepareCall each time you want to launch a result request, then you wouldn’t get the result if the camera low-memory-kills you. You only get it if you initialize the ResultCaller once in onCreate and re-use it each time.

So be aware of this behaviour, and that this may change in future. A bug has been filed with Google and this is an Alpha release, so perhaps this post will require updating in a few weeks.

Last thoughts

This is a useful abstraction and I’m super pleased that Google have released this. One minor thing to note is that the the current documentation on the activity result page appears to be incorrect in a couple of places (how to register a contract, how to dispatch a result in a test), but hopefully that’ll get resolved shortly.

Hopefully this has given you some good ideas for some neat abstractions and I’d love to see them, so please share anything you come up with. I’ll likely update this post in a few weeks with some bits and pieces that I come up with too.

Thanks for reading!

Edit: Thanks to Ian Lake for the tips on activity-ktx and pointing me in the direction of the documentation bug tracker.

Источник

AndroidX Activity Result APIs — The new way!

Traditionally, we use startActivityForResult() and onActivityResult() APIs to start another activity and receive a result back that is available on the Activity classes on all API levels.

With JetPack, it’s strongly recommended to get the business done with all-new Activity Result APIs introduced in AndroidX Activity 1.2.0-alpha02 and Fragment 1.3.0-alpha02 roll out.

You now have a nice abstraction which allows you to handle onActivityResult() method in a very clean and reusable structure, You can register a callback for an Activity Result, The Activity Result APIs provide components for registering for a result, launching the result, and handling the result once it is dispatched by the system.

Activity Result APIs —

• registerForActivityResult() — For registering the result callback
• ActivityResultContract — A contract specifying that an activity can be called with an input of type I and produce an output of type O Makes calling an activity for result type-safe.
• ActivityResultCallback — A type-safe callback to be called when an activity result is available. It’s is a single method interface with an onActivityResult() method that takes an object of the output type defined in the ActivityResultContract
• ActivityResultLauncher — A launcher for a previously-prepared call to start the process of executing an ActivityResultContract.

registerForActivityResult() takes an ActivityResultContract and an ActivityResultCallback and returns an ActivityResultLauncher which you’ll use to launch the other activity.

You can either use different contracts or want separate callbacks for multiple activity result call, you can call registerForActivityResult() multiple times to register multiple ActivityResultLauncher instances.

registerForActivityResult() is safe to call before your fragment or activity is created, allowing it to be used directly when declaring member variables for the returned ActivityResultLauncher instances. But you cannot launch the ActivityResultLauncher until the fragment or activity’s CREATED.

Launching an activity for the result —

Calling launch() starts the process of producing the result. When the user is done with the subsequent activity and returns, the onActivityResult() from the ActivityResultCallback is then executed

You can use the prebuilt ActivityResultContract from ActivityResultContracts. Alongside this, you can create custom contracts as well. You can read here to learn more about creating a custom contract.

Generic StartActivityForResult contract —

StartActivityForResult can be used for the generic purposes. This is an ActivityResultContract that doesn’t do any type conversion, taking raw Intent as an input and ActivityResult as an output. Can be registered with ActivityResultCaller.registerForActivityResult(ActivityResultContract, ActivityResultCallback) to avoid having to manage request codes when calling an activity API for which a type-safe contract is not available.

Ready to Use Contracts —

You can find more here

Dependencies —

Package Summary —

We need to be conservative when developing apps that run in the Android ecosystem which is targeted to a vast and wide variety of OEM manufacturers, When starting an activity for a result, it is possible (and, in cases of memory-intensive operations such as camera usage, almost certain) that your process and your activity will be destroyed due to low memory. For this reason, the Activity Result APIs decouple the result callback from the place in your code where you launch the other activity. As the result callback needs to be available when your process and activity are recreated, the callback must be unconditionally registered every time your activity is created.

Droid Log

The ultimate log sheet for Android. Filled with super random but interesting stuffs on Android.

Источник

Получаем результат правильно (Часть 1). Activity Result API

Каждый Android-разработчик сталкивался с необходимостью передать данные из одной Activity в другую. Эта тривиальная задача зачастую вынуждает нас писать не самый элегантный код.

Наконец, в 2020 году Google представила решение старой проблемы — Activity Result API. Это мощный инструмент для обмена данными между активностями и запроса runtime permissions.

В данной статье мы разберёмся, как использовать новый API и какими преимуществами он обладает.

Чем плох onActivityResult()?

Роберт Мартин в книге “Чистый код” отмечает важность переиспользования кода — принцип DRY или Don’t repeat yourself, а также призывает проектировать компактные функции, которые выполняют лишь единственную операцию.

Проблема onActivityResult() в том, что при его использовании соблюдение подобных рекомендаций становится практически невозможным. Убедимся в этом на примере простого экрана, который запрашивает доступ к камере, делает фото и открывает второй экран — SecondActivity . Пусть в SecondActivity мы передаём строку, а назад получаем целое значение.

Очевидно, что метод onActivityResult() нарушает принцип единственной ответственности, ведь он отвечает и за обработку результата фотографирования и за получение данных от второй Activity. Да и выглядит этот метод уже довольно запутанно, хоть мы и рассмотрели простой пример и опустили часть деталей.

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

Используем Activity Result API

Новый API доступен начиная с AndroidX Activity 1.2.0-alpha02 и Fragment 1.3.0-alpha02 , поэтому добавим актуальные версии соответствующих зависимостей в build.gradle:

Применение Activity Result состоит из трех шагов:

Шаг 1. Создание контракта

Контракт — это класс, реализующий интерфейс ActivityResultContract . Где I определяет тип входных данных, необходимых для запуска Activity, а O — тип возвращаемого результата.

Для типовых задач можно воспользоваться реализациями “из коробки”: PickContact , TakePicture , RequestPermission и другими. Полный список доступен тут.

При создании контракта мы обязаны реализовать два его метода:

createIntent() — принимает входные данные и создает интент, который будет в дальнейшем запущен вызовом launch()

parseResult() — отвечает за возврат результата, обработку resultCode и парсинг данных

Ещё один метод — getSynchronousResult() — можно переопределить в случае необходимости. Он позволяет сразу же, без запуска Activity, вернуть результат, например, если получены невалидные входные данные. Если подобное поведение не требуется, метод по умолчанию возвращает null .

Ниже представлен пример контракта, который принимает строку и запускает SecondActivity, ожидая от неё целое число:

Шаг 2. Регистрация контракта

Следующий этап — регистрация контракта в активности или фрагменте с помощью вызова registerForActivityResult() . В параметры необходимо передать ActivityResultContract и ActivityResultCallback . Коллбек сработает при получении результата.

Регистрация контракта не запускает новую Activity , а лишь возвращает специальный объект ActivityResultLauncher , который нам понадобится далее.

Шаг 3. Запуск контракта

Для запуска Activity остаётся вызвать launch() на объекте ActivityResultLauncher , который мы получили на предыдущем этапе.

Важно!

Отметим несколько неочевидных моментов, которые необходимо учитывать:

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

Не рекомендуется вызывать registerForActivityResult() внутри операторов if и when . Дело в том, что во время ожидания результата процесс приложения может быть уничтожен системой (например, при открытии камеры, которая требовательна к оперативной памяти). И если при восстановлении процесса мы не зарегистрируем контракт заново, результат будет утерян.

Если запустить неявный интент, а операционная система не сможет найти подходящую Activity, выбрасывается исключение ActivityNotFoundException: “No Activity found to handle Intent”. Чтобы избежать такой ситуации, необходимо перед вызовом launch() или в методе getSynchronousResult() выполнить проверку resolveActivity() c помощью PackageManager .

Работа с runtime permissions

Другим полезным применением Activity Result API является запрос разрешений. Теперь вместо вызовов checkSelfPermission() , requestPermissions() и onRequestPermissionsResult() , стало доступно лаконичное и удобное решение — контракты RequestPermission и RequestMultiplePermissions .

Первый служит для запроса одного разрешения, а второй — сразу нескольких. В колбеке RequestPermission возвращает true , если доступ получен, и false в противном случае. RequestMultiplePermissions вернёт Map , где ключ — это название запрошенного разрешения, а значение — результат запроса.

В реальной жизни запрос разрешений выглядит несколько сложнее. В гайдлайнах Google мы видим следующую диаграмму:

Зачастую разработчики забывают о следующих нюансах при работе с runtime permissions:

Если пользователь ранее уже отклонял наш запрос, рекомендуется дополнительно объяснить, зачем приложению понадобилось данное разрешение (пункт 5a)

При отклонении запроса на разрешение (пункт 8b), стоит не только ограничить функциональность приложения, но и учесть случай, если пользователь поставил галочку “Don’t ask again”

Обнаружить эти граничные ситуации можно при помощи вызова метода shouldShowRequestPermissionRationale() . Если он возвращает true перед запросом разрешения, то стоит рассказать пользователю, как приложение будет использовать разрешение. Если разрешение не выдано и shouldShowRequestPermissionRationale() возвращает false — была выбрана опция “Don’t ask again”, тогда стоит попросить пользователя зайти в настройки и предоставить разрешение вручную.

Реализуем запрос на доступ к камере согласно рассмотренной схеме:

Подводим итоги

Применим знания о новом API на практике и перепишем с их помощью экран из первого примера. В результате мы получим довольно компактный, легко читаемый и масштабируемый код:

Мы увидели недостатки обмена данными через onActivityResult(), узнали о преимуществах Activity Result API и научились использовать его на практике.

Новый API полностью стабилен, в то время как привычные onRequestPermissionsResult() , onActivityResult() и startActivityForResult() стали Deprecated. Самое время вносить изменения в свои проекты!

Демо-приложение с различными примерами использования Activty Result API, в том числе работу с runtime permissions, можно найти в моем Github репозитории.

Источник