Как управлять доставкой тегов NFC в несколько приложений

Я хочу создать приложение, которое сохраняет метку времени в базе данных, когда я сканирую свою рабочую партию, содержащую тег NFC. Это будет сделано через IntentService без запуска активности. После второго сканирования еще одна временная метка будет сохранена в базе данных через IntentService. Никакая деятельность не должна быть начата. Уведомления будет достаточно. Активность может быть запущена пользователем вручную для просмотра информации.

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

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

Итак, вопрос в том, как я могу отсканировать тег и направить его в нужное приложение. Таким образом, тег A будет обрабатываться приложением A, а тег B — приложением B, и окно выбора каждый раз не будет отображаться.

Я думал, каким должен быть лучший вариант, или, может быть, у кого-то есть отличная идея, как это решить.

Я рассказал о нескольких различных решениях:

  1. Используйте только доступные для записи теги NDEF и добавьте к ним запись приложения Android (AAR). Таким образом, после сканирования запустится нужное приложение. (Если на переднем плане нет активного приложения NFC), это будет означать, что пользователь ограничен технологией тегов и должен записать ее перед использованием.

  2. Разрешите приложению прослушивать все теги NFC, и если тег не связан с задачей, снова перенаправьте его в систему, чтобы другие приложения могли его обработать. (Не знаю, возможно ли это)

  3. Напишите приложение, которое прослушивает все теги NFC, и пусть пользователь решает, какой тег будет отправлен в какое приложение. Поэтому, когда приложение получает новый тег, оно спрашивает пользователя, какое приложение может обрабатывать тег, и сохраняет значение по умолчанию для этого конкретного тега [по идентификатору или чему-то еще] в базе данных. Поэтому в следующий раз он направит намерение в приложение по умолчанию для этого тега. (Или уже есть что-то подобное?)

Надеюсь, этот вопрос немного ясен. В противном случае я попытаюсь прояснить это немного больше, если хотите ;-)

Мне очень нравится слышать, что вы думаете об этом. Или, может быть, у вас есть хорошие предложения? Пожалуйста, дайте мне знать.

Заранее спасибо.


person kuipers    schedule 05.06.2013    source источник
comment
Ни № 2, ни № 3 невозможны AFAIK.   -  person CommonsWare    schedule 06.06.2013


Ответы (1)


Для этого я успешно использовал схему URL-адресов для конкретного приложения. Предположим, что ваша схема URL — «kuiperstimestamp».

Затем тег должен содержать URL-адрес, например:

kuiperstimestamp://ts/20130506T034536.293

Затем вы создаете фильтр намерений для своего сервиса, который включает элемент data:

<intent-filter>
    <action android:name="android.nfc.action.TAG_DISCOVERED" />
    <category android:name="android.intent.category.DEFAULT" />
    <data android:scheme="kuiperstimestamp" />
</intent-filter>

Поскольку фильтр намерений довольно специфичен, вы не получите диалоговое окно выбора приложения (если только другое приложение или служба не имеют такой же конкретный фильтр намерений, что маловероятно).

Этот подход менее специфичен для Android, чем использование AAR.

person Codo    schedule 06.06.2013
comment
Спасибо за ответ! Вот так. Когда я использую тип mime, как вы объяснили, я не зависел от тегов NDEF и Android. На данный момент это будет приложение для Android, но лучше подумать о будущем. Поэтому лучше позволить пользователю использовать тег, который можно записать. Затем система Android прекрасно справляется с диспетчеризацией. - person kuipers; 07.06.2013