Search manager in android

Working With WorkManager in Android Like A Pro

How can we schedule our application tasks at a particular time or periodically? How can we add constraints to our scheduled task like network availability(only Wifi some times) or if the device is charging? We see such tasks occurring in our day to day applications like WhatsApp and PlayStore App updates. Can we chain up such tasks together? We have a solution for all these questions and many more in Android Development.

Work Manager

Welcome to the Android-Work Manager blog.

So let’s discuss Work Manager and its use in background processing in this blog.

We have a lot of ways to do background processing in Android, like AsyncTasks, Loaders, Alarm Managers, etc., Which one to use when? How can we come to a decision on the same?

For more information, please refer to background processing guide

As an Android Developer, we should have an idea of the latest optimizations Android is coming up with its newer versions of OS being released for better performance. Also, we cannot guarantee every android device being used in the market contains the latest version of the Android OS installed. So, we should think about backward compatibility to reach the maximum number of devices that are present in the market(at least a min SDK of KitKat).

So how do we categorize our work that needs to be scheduled based on its importance?

Let’s say our work is to open a contacts screen by clicking on the Contacts button. This is something that is only related to the UI part. Hence the main thread or the UI thread is enough to perform this piece of work. We don’t need this to be done when our device is in doze state. This is an example of a Foreground Service. It’s a guaranteed execution and it needs to be done immediately.

Now, let’s say we have to perform a task but it need not be immediate. Like you want to set a reminder for the day after tomorrow at 8 pm. Now, this reminder will occur nearly after 48 hrs. So the device can be in a doze mode or alive during this period. We have a handful of APIs to perform these tasks. Like Job Schedulers, Firebase Job dispatchers, or Alarm manager with Broadcast receivers in the previous versions.

Now, what if we have a functionality that needs all the properties of these APIs. We tend to come with a combination of all the APIs discussed. That’s a lot of APIs to be used for in a single application. This is where WorkManager comes into the picture.

BackWard Compatible

WorkManager is Backward compatible up to API 14 -Uses JobScheduler on devices with API 23+, Uses a combination of BroadcastReceiver + AlarmManager on devices with API 14–22

WorkManager is intended for tasks that are deferrable — that is, not required to run immediately — and required to run reliably even if the app exits or the device restarts. For example:

• Sending logs or analytics to backend services
• Backing up user data with Server on a Periodic basis (Eg: WhatsApp, Google, etc.,)

Constraint Aware

WorkManager is constraint aware. In our day to day usage, we see our phone getting the latest software updates and we are requested to keep our devices in charging mode for these updates to happen as it may take time and insufficient charge can lead to improper installation of software. Sometimes, we see our apps getting updated as soon as we connect our phones to our power adapters. These kinds of tasks are constraint aware.

Accepts Queries

WorkManager is Queryable. A work that is handed off to the system by the WorkManager can be in a Blocked State, Running State or a Cancelled State. We can get the state of the work by passing the id of the Work like below:

By doing this, we can improve the UX by displaying a progress bar while the task is being executed by the work manager.

Chainable

WorkManager is Chainable. Let’s say we have a series of works that are dependent on each other, we can chain them up with Work Manager. You can also specify the order in which the works that are chained should be done.

Let’s say we want to upload photos to the server. For this task to be done, let’s say we want to compress the images first and then upload it. These tasks need to be done on a background thread as they are time taking tasks and it is evident in this case that they are dependent on each other. We can chain up these tasks by using the Work Manager.

In the above code snippet, work 1, work 2 and work 3 can be referred to as three different images that are extracted in parallel since they are a part of beginWith(). work 4 can be referred for compress and then work 5 can be upload. This way we can chain up our tasks.

WorkManager can be used to perform a unique task(OneTimeWorkRequest) or a recurring task(PeriodicWorkRequest) based on the requirement.

In order to execute a OneTimeWorkRequest or the PeriodicWorkRequest, we have to pass the work to these requests which are our Worker class. This is where our business logic is written in the doWork() method:

The doWork() method runs on the background thread. We can see here a success result is returned once the uploadImages is successful. The other two enum values for the return type are a failure and retry. Return types success and failure are fairly obvious, but what does retry do here? Let’s say we are performing a task with a Work Manager with a constraint that is network connected. If the network get’s disconnected in the midst of the work being done, we can retry the task.

Inputs and Outputs

Not just this, we can create data as inputs and get outputs as data with respect to WorkManager requests. The inputs and outputs are stored as key-value pairs in the Data object.

So, how do we create a data object? Let’s create a simple map in kotlin and convert it into a workData so that it gives a Data object

Now, where can we retrieve this data? It can be done in the overridden doWork method in our Worker class

Now, we see that the compressImages is returning a map of images mapped to their respective sizes. Let’s say we need this data. We can set the output from our worker thread as a Data object.

If we are using a chain of work requests here, the key observation is that the output of a worker will become input for its child workRequests.

Let’s say we use a UploadWorker after the CompressWorker, the compressedImages that is executed in the CompressWorker can be an input to the UploadWorker. It can be retrieved similarly in the doWork method of the UploadWorker class.

This works fine if we have only one worker request chained with another work request. What if we have multiple work requests(running parallel) chained with another work request that needs input from all these parallelly running work requests like

What if the input for work 4 should be the combined output of work 1, work 2 and work 3? InputMerger to the rescue.

InputMerger

InputMerger is a class that combines data from multiple sources into one Data object. There are two different types of InputMergers provided by WorkManager:

OverwritingInputMerger (default) attempts to add all keys from all inputs to the output. In case of conflicts, it overwrites the previously-set keys.

ArrayCreatingInputMerger attempts to merge the inputs, creating arrays when necessary.

Important note:

There might be instances where we get outputs containing similar keys. So, we must be cautious in choosing our Inputmergers. If we want to override the key values, we can go for OverwritingInputMerger. If we want to save all the instances of the respective Key, we have to use ArrayCreatingInputMerger. It creates an array of values(if the values for a key are more than one) for the respective key.

Exception-Example case study for ArrayCreatingInputMerger:

Let’s say we have a key, “age”. One work request has value 30(Int) in it for this key. Another work request has value “three days”(String) in it for the same key. Can the ArrayCreatingInputManager merger these values and create an array for the key “age”? No. It gives an exception. So, it is expected that the datatypes of the values for similar keys should be the same.

How to use InputMerger

Work Manager can cancel the unwanted tasks or tasks that are scheduled by mistake. All that we need to do is to send the task id to cancelWorkById() method :

The Tag Support

The ids that we are referring to here are auto-generated and generally large numbers that are not easily readable by humans. Let’s say we have to log them we are unsure whether we are logging the correct workRequest Id. To overcome this issue, each work request can have zero or more tags. We can query or delete our work requests by using these tags.

Now, if we want to see the status of all the works that are associated with a given tag, we can just use

The above statement returns a LiveData
> as more than one work request can be associated with a single tag. We can use this result to get the statuses like

Similarly, we can use the tags to cancel the work like:

Existing Work-Keep it unique or Add Operations with Keep, Replace and Append

Keep, Replace and Append

These three properties add advantage to using Work Manager.

Let’s say we have a work request with tag “image_1” that is already enqueued with the WorkManager.

Let’s say we define this work request to upload a particular image. And if by mistake, we click on upload the same image, this property helps us in not repeating the task.

So, if there is work already with “upload” ongoing, it will keep that request. If there isn’t one, it will enqueue this particular request.

Replace

This will replace any ongoing work with the name “upload” and replaces it by enqueuing this particular work.

Append

This helps in appending the respective work request to an already existing unique work request with the name “upload”(if it exists)

Note: Please be careful when you add the constraints to the work requests in a chain of work requests. Each and every work request that is being chained may not need the same constraints. For example, if our work request contains image upload and we are chaining compress image and upload image work requests together, compressing an image may have constraints related to storage and uploading image can have a constraint with respect to the network connection. So, add the constraints accordingly.

References

Work Manager from the Android Developers Youtube Channel from Google i/o 18.- This video link also describes how the Work Manager operates under the hood. A snapshot of the same is being give here:

That’s all about WorkManager! Hope this article has been of use to you and has given you a basic idea of how Work Manager is useful for us.

Источник

Использование Android Search Dialog. Часть 3 — Custom Suggestions

Это заключительная статья по использованию Android Search Dialog (предыдущие находятся здесь и здесь). В ней я расскажу, как добавить в диалог динамические подсказки к поиску, а также, как интегрировать поиск по вашему приложению в системный Quick Search Box (QSB). Преимущество QSB в том, что с его помощью можно получать информацию из практически любого места в OS.

Теория

Подсказки к поиску создаются при помощи данных вашего приложения, по которым осуществляется поиск. Когда пользователь выбирает одну из них, то Search Manager посылает Intent к Activity, которое отвечает за поиск. Обычно, когда пользователь нажимает иконку поиска в диалоге, то отправляется Intent типа Search, однако, при выборе подсказки в данном случае можно определить другой тип Intent, так чтобы мы могли его перехватить и совершить соответствующие действия, например, создание нового диалога, или вызов Activity для отображения информации и т.д.
Данные поискового запроса переносятся через Intent как и раньше, однако теперь мы будем использовать URI, чтобы определять тип запроса через контент-провайдер.

Снова, нам не нужно производить никаких действий по отрисовке диалога, этим занимается Search Manager, всё, что от нас требуется — представить конфигурационный xml файл.

Итак, когда Search Manager определяет наше Activity как отвечающее за поиск и обеспечивающее подсказки к поиску, то происходит следующая последовательность действий:

1. Когда Search Manager получает текст поискового запроса, то он отправляет свой запрос к контент-провайдеру, обеспечивающему подсказки.
2. Контент-провайдер возвращает курсор, указывающий на подсказки, которые совпадают с текстом поискового запроса.
3. Search Manager отображает подсказки, используя курсор

После того как список подсказок был отображен, может случиться следующее:

• Если пользователь изменяет текст запроса, то все вышеперечисленные шаги повторятся.
• Если пользователь запускает поиск, то подсказки игнорируются, и к Activity отправляется Intent типа Search.
• Если пользователь выбирает подсказку, то к Activity доставляется Intent другого типа (тип определяется в конфигурационном файле), переносящий URI в качестве данных. URI будет использоваться для поиска записи в таблице, соответствующей выбранной подсказке.

Итак, мы модифицируем наше приложение (то которое рассматривалось в части 1) так, чтобы добавлялись динамические подсказки, причем, для отработки механизма, при выборе подсказки будем вызывать новое Activity, которое будет отображать информацию по запросу. Для реализации потребуется:

• Изменить конфигурационный файл диалога, добавив к нему информацию о контент-провайдере и типе Intent, используемом для подсказок
• Создать таблицу в БД SQLite, которая будет предоставлять столбцы, требуемые Search Manager’ом для подсказок
• Создать новый контент-провайдер, имеющий доступ к таблице подсказок, и определить его в манифесте
• Добавить Activity, которое будет отображать информацию при выборе подсказок

Изменяем конфигурационный файл

Напоминаю, что конфигурационный файл (res/xml/searchable.xml) требуется для отображения диалога и его изменения, например, для использования голосового поиска. Чтобы использовать динамические подсказки, необходимо добавить в файл параметр: android:searchSuggestAuthority. Он будет совпадать со строкой авторизации контент-провайдера. Кроме этого добавим параметр android:searchMode=«queryRewriteFromText», его значение указывает на то, что строка поиска в диалоге будет перезаписываться при навигации по подсказкам, например с помощью трекбола. Также добавим параметры, задающие оператор выборки, тип Intent отправляемого при выборе подсказки, и минимальное количество напечатанных символов в диалоге, необходимое для запроса к контент-провайдеру.

Создаем контент-провайдер

По сути наш контент-провайдер ничем не отличается от других. Но нужно сделать так, чтобы для каждой строки из таблицы подсказок выбирались нужные столбцы, те которые требует Search Manager. Мы будем запрашивать данные по подсказкам с помощью метода контент-провайдера query(). Причем вызываться он будет каждый раз, когда пользователь печатает новый символ в диалоге. Таким образом, метод query() должен возвращать курсор на записи в таблице, совпадающие с запросом, и тогда Search Manager сможет отобразить подсказки. Смотрите описание метода в комментариях к коду.
Сам текст запроса будет дописываться к URI, так что с его получением проблем не будет, нужно просто использовать стандартный метод getLastPathSegment().

Создание таблицы подсказок

Когда Search Manager получает курсор, указывающий на записи, то он ожидает определенный набор столбцов для каждой записи. Обязательными являются два: _ID — уникальный идентификатор каждой подсказки, и SUGGEST_COLUMN_TEXT_1 — текст подсказки.
Необязательных столбцов существует много, например используя SUGGEST_COLUMN_ICON_1, вы можете определить для каждой записи иконку, отображаемую с левой стороны подсказки (очень удобно, например, для поиска по контактам).

Определение типа данных для Intent

Так как мы передаем данные по запросу через URI, то нам нужен механизм для определения того, какая подсказка была выбрана. Тут есть два пути. Первый, заключается в том, чтобы определить отдельный столбец SUGGEST_COLUMN_INTENT_DATA, в котором будут уникальные данные для каждой записи, тогда можно получать данные из Intent через getData() или getDataString(). Второй вариант — определить тип данных для всех Intent в конфигурационном файле (res/xml/searchable.xml) а потом дописывать к URI уникальные данные для каждого Intent, используя столбец SUGGEST_COLUMN_INTENT_DATA_ID.
Мы будем использовать второй вариант, причем отдельных столбцов в таблице я не создавал, так как можно просто создать отображение из SUGGEST_COLUMN_INTENT_DATA_ID в rowId таблицы. Добавлю еще, что ради спортивного интереса в SQLite для поиска использовался FTS3, то есть пришлось создавать виртуальную таблицу, для которой нельзя накладывать ограничения на столбцы (constraints), такие как PRIMARY KEY или NULL/NOT NULL. Зато у виртуальных таблиц есть уникальный идентификатор строки, на него и установим отображение. То есть data для Intent будет иметь следующий вид: к URI будет дописываться «/» и rowId строки в таблице.

Создание Activity для отображения информации

Интерфейс находится в res/layout/record_activity.xml. Всё чем занимается Activity — получение данных из Intent, запрос курсора через контент-провайдер и отображение записи в текстовом поле.

Теперь внесем информацию о контент-провайдере и новом Activity в манифест, также, так как у нас теперь два Activity, то укажем то, которое по умолчанию отвечает за поиск.

Перехват Intent в Activity, отвечающем за поиск

После всех вышеперечисленных шагов нужно обработать Intent в главном Activity, которое отвечает за поиск. Так как мы определили тип Intent для подсказок как View, то нужно просто добавить проверку на него. В случае если условие выполнится, то запускается RecordActivity, используя Intent, в данные которого записывается URI + «/» + id подсказки в таблице.

Источник