What is the purpose of foreground dispatch and how does it differ from adding intent-filters in the AndroidManifest? Currently I can read from and write to NFC tags and I haven't written any foreground dispatch code.
It mostly depends on your requirements. When you register an IntentFilter in the manifest, you specify an Activity that will be started and given the detected tag data in the Intent. This means that your app can be started at any time to handle the tag. For instance, the user can be on the launcher and hold a tag to their phone, and have your app as an option to handle the NFC detection event.
However, assume you have a scenario where it only makes sense to detect the tag while your application is in the foreground. For instance, maybe your app requires the user to be logged in in order to do something with the tag data. In that case, you can use the foreground dispatch mechanism, and start it from any of your Activity classes to receive a result only when your app is active.
It's quite similar to BroadcastReceivers, which can also either be something dynamically registered, or specified in the manifest. In the former case, the lifecycle of the receiver is under your control. In the latter case, you're saying that your app may be started at any time.
Related
I understand the basic difference between the two types of intent registering.
But i want to know is there any difference in terms of speed??
Registering broadcast from code and through manifest doesn't have much difference except these points mentioned in the documentation:
1)When you use registerReceiver(BroadcastReceiver, IntentFilter), any application may send broadcasts to that registered receiver. You can control who can send broadcasts to it through permissions described below.
2)When you publish a receiver in your application's manifest and specify intent-filters for it, any other application can send broadcasts to it regardless of the filters you specify. To prevent others from sending to it, make it unavailable to them with android:exported="false".
Read more in developer documentations: http://developer.android.com/reference/android/content/BroadcastReceiver.html
You can use them based on your requirement.
The BroadcastReceiver class (when launched as a component through a manifest's tag) is an important part of an application's overall lifecycle.
If you registerRecevier in onResume method in activity and unregisterReceiver in onPause() method. Your receiver life time is this activity life time.
I read the documentation and I don't quite understand what either do. Considering Android made the puzzling decision that we now need to use Android Beam to send data from 1 one phone to another and there is no way to simultaneously send data from both to both, I don't see the use.
Can't I just call setNdefPushMessage on one phone, and have an onNewIntent callback in the other phone which does something if NfcAdapter.ACTION_NDEF_DISCOVERED.equals(intent.getAction()) is true?
What is the point of enableForegroundDispatch and disableForegroundDispatch?
enableForegroundDispatch gives your current foreground activity priority in receiving NFC events over all other actvities.
For instance, consider the following example:
Your activity and another activity (either from the same app or from another app) registered an intent filter for the same NDEF record type in the manifest.
Your device receives an NDEF message containing that record type as its first record.
If the current foreground activity did not register with the foreground dispatch system, an activity chooser will be shown and the user can choose between the two activites.
If the current foreground activity, however, did register with the foreground dispatch system (to receive that type of record), it will get priority over all manifest-registered intent filters and will receive the NDEF message without any additional user interaction.
Some more things:
The Android Application Record (AAR), if appended to an NDEF message, will have a similar effect as it will force the NDEF message to be delivered only to a particular app.
If an NDEF message contains an AAR for a different app, you could still use the foreground dispatch system to force delivery of the NDEF message to your app. So the foreground dispatch has priority over the AAR.
Note that the foreground dispatch system is not only used for peer-to-peer mode data exchange, but also for reading NFC tags. In that case, there exist tags that do not contain NDEF messages and are, therefore, significantly more likely to result into multiple activities being registered for the same tag type. Thus, in that case its again useful to give your activity priority over any other activities that are registered for the same tag type.
Suppose I want to develop an application that extends in some way (let me say "cooperate with") a very popular application I obviously don't have control over. Let us also suppose, for sake of simplicity, that the very famous application author won't release an update to block my application.
I studied the application's functionality and identified that it widely uses BroadcastReceivers. I also know, from manifest, the com.famousvendor.intent.INTENT_NAME constants I might use.
The question is straightforward: if I create an application, namely org.zighinetto.tinyapp with a broadcast receiver set for intent com.famousvendor.intent.INTENT_NAME will the tiny app catch the broadcast? Or can those broadcast be received only by the process that fires them?
will the tiny app catch the broadcast? Or can those broadcast be received only by the process that fires them?
There are a number of things that control this.
If the broadcast is secured with a permission, you will not be able to receive that broadcast unless you also hold that permission. It may not be possible for you to hold that permission, depending on the type of permission that it is.
Also, if the broadcast is an ordered broadcast, higher priority apps will receive that broadcast and can abort it (consuming the event, so lower-priority receivers do not get the broadcast). The priority is set via the <intent-filter> (or IntentFilter), and it may not be possible for you to have one that is higher priority than is their own app, depending upon the priority value the original developer held.
There are also other local-only scenarios (e.g., LocalBroadcastManager), though you would not see those in the manifest, and so we can assume that they are not what is being used here... today.
Let us also suppose, for sake of simplicity, that the very famous application author won't release an update to block my application.
They do not need to specifically block your application. They just need to decide whether or not they really want to have the API you are trying to exploit, and they may choose to lock it down if this was more of an accidental API. They might do so in response to a blog post by a balding guy, for example.
I've registered the Intent.action_screen_off/on in my oncreate method of my application, and i can receive the events when my application is running. But when my application exits i get an broadcast intent leaked exception (off the top of my head i think thats what its called, either way its caused by not unregistering my receiver when my app exits)
How can i receive these events when my application is not running? i'd prefer not to use a service or something like that, i've seen other apps do it without services or background processes.
i've seen other apps do it without services or background processes.
That's not possible. The only way to register a BroadcastReceiver other than in running code is to declare it in the AndroidManifest.xml with the relevant <intent-filter>. As it's not possible to do that for either Intent.ACTION_SCREEN_OFF or Intent.ACTION_SCREEN_ON, the apps you've seen MUST have some running component(s) in order to receive the broadcasts.
In short, use a Service - I'm not quite sure why you say you'd prefer not to.
I am making a project and I want that my application comes foreground when it detects an ACTION_TAG_DISCOVERED tag. I can do bringing foreground process via a service, but I want that, my applications can listen NFC even it is in the background, and if it is in the background comes foreground by itself.
Any helps will be appreciated.
Take a look here: http://developer.android.com/guide/topics/connectivity/nfc/nfc.html
Youre interested in filtering for NFC intents. Its a mechanism that allows you to launch your app when a tag is detected. Also, check out disabling/enanbling foreground dispatch.