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.
Related
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.
I just finished my android app that have 1 activity, wherein it displays the data on the nfc tag, my problem is that whenever I tap nfc tag, the app opens/launch even if it is not open or running in the background. How can I prevent this from happening?
I want my app to react when it is open, thanks
If you don't want your activity to automatically start upon scanning a tag, simply don't register NFC related intent filters in your app's manifest.
But what if...
... you did not register any NFC related intent filters in the manifest but instead stored an Android Application Record (AAR) on the NFC tag. In this case your only option is to not use AARs.
... you now can't display the tag's data in your activity, because you do not receive any intent upon scanning an NFC tag. In this case, you should have registered for the NFC foreground dispatch system instead of registering an NFC intent filter in your app's manifest.
I'm coming up to speed on Android development and the distinction between an implicit intent and a broadcast receiver is unclear. I was hoping for help in distinguishing these concepts and when to use the two.
Both receive intents, both react to system messages, so why is a broadcast receiver even needed and when is it used as opposed to an implicit intent and intent filter to accept the implicit intent?
Broadcasts are just that -- messages broadcast to anyone listening. They are inherently insecure, and delivery to the intended recipient isn't guaranteed, because there really isn't an intended recipient. For example, the CONNECTIVITY_CHANGE broadcast makes this quite clear: When connectivity changes in an Android device, many apps might be interested. Rather than the ConnectivityManager having to notify each app via specific Intent, it sends a broadcast. Any app that has registered interest in this event will be notified. Any app that isn't running or doesn't care... won't.
An Intent is "sent" when one app or Activity wants to launch another to do something very specific. For example, a file-manager might want to launch an image viewer or video player. Your app might want to launch a very specific Activity within another one of your apps, etc. The communication by specific intents (i.e. including package name and component name) can not easily be intercepted, so it's somewhat more secure. Most importantly, there's only and exactly one "receiver" -- if none can be found, the Intent will fail.
Further, a BroacastReceiver will be active within an Activity or Service and received broadcasts will generally only change state and/or do minor UI updates... for example, you might disable a few actions if your internet connectivity is dropped. By comparison, a specific Intent will usually launch a new Activity or bring an existing one to the foreground.
I am going to compile a list here of all the differences between Implicit Intents (sent via startActivity()) and Broadcasts (sent via sendBroadcast())
Broadcasts, by default, can affect multiple applications at once (Ordered Broadcasts have the potential to be disrupted). In contrast, Implicit Intents will only affect one application. Please note that there may be multiple possibilities of applications that could be affected, but eventually only one will be.
Implicit Intents are handled via Intent-Filters, and Broadcasts are handled via Broadcast Receivers (albeit the intent-filters play a role here too). I have seen in many instances over the web that Broadcasts are compared to Intent-filters and that does not make sense to me.
An Implicit Intent launches an Activity, or a Service. By contrast, a Broadcast launches a Broadcast Receiver. (This, if you think about it, is the core difference between Intents and Broadcasts. It is because of this reason that Broadcasts aren't meant to do too much heavy work, and especially not UI work!)
From the Developers Website:
There is no way for a BroadcastReceiver to see or capture Intents used
with startActivity(); likewise, when you broadcast an Intent, you will
never find or start an Activity. These two operations are semantically
very different: starting an Activity with an Intent is a foreground
operation that modifies what the user is currently interacting with;
broadcasting an Intent is a background operation that the user is not
normally aware of.
I'll add more if I find anything else.
I am new in Android Development. I want to create an application which would add a prefix to a calling number and this decision will depend on some parameters.
I want an user to be aware of it but doesn't have to do anything about it, meaning once the application is installed and an user wants to call, they'll just see that a prefix is going to be added to a number they are calling.
The question is not how to do adding a prefix to calling number (although, that's also what I want to know, but I have found an article about it), but rather:
1) is it going to be a service?
2) is it possible to change a calling number by adding a prefix to it and show a changed number to an user so that they don't have to do anything about it (like pressing "yes","no" to accept this)?
You should register for Intent.ACTION_NEW_OUTGOING_CALL
Broadcast Action: An outgoing call is about to be placed.
The Intent will have the following extra value:
EXTRA_PHONE_NUMBER - the phone number originally intended to be
dialed. Once the broadcast is finished, the resultData is used as the
actual number to call. If null, no call will be placed.
It is perfectly acceptable for multiple receivers to process the
outgoing call in turn: for example, a parental control application
might verify that the user is authorized to place the call at that
time, then a number-rewriting application might add an area code if
one was not specified.
For consistency, any receiver whose purpose is to prohibit phone calls
should have a priority of 0, to ensure it will see the final phone
number to be dialed. Any receiver whose purpose is to rewrite phone
numbers to be called should have a positive priority. Negative
priorities are reserved for the system for this broadcast; using them
may cause problems.
Any BroadcastReceiver receiving this Intent must not abort the
broadcast.
Emergency calls cannot be intercepted using this mechanism, and other
calls cannot be modified to call emergency numbers using this
mechanism.
Some apps (such as VoIP apps) may want to redirect the outgoing call
to use their own service instead. Those apps should first prevent the
call from being placed by setting resultData to null and then start
their own app to make the call.
You must hold the PROCESS_OUTGOING_CALLS permission to receive this
Intent.
This is a protected intent that can only be sent by the system.
Constant Value: "android.intent.action.NEW_OUTGOING_CALL"
I created a BroadcastReceiver and configured it with an android.provider.Telephony.SMS_RECEIVED action filter so it is called everytime the phone receives a text.
Is there some event/action or other way for my application to be notified whenever the phone sends a text (preferably independent of the application that sends it)?
So far the only option I see is to poll the content provider for content://sms/sent which doesn't even give me all sent texts because applications can choose not to put it there.
Unfortunately there is (currently) no way to implement a BroadcastReceiver because the standard sms application uses a SmsManger to send the messages but specifies concrete internal classes for the sent and delivered intents (SmsReceiver.class and MessageStatusReceiver.class respectively). Not that it is any consolation but you can find the following comment in the Sms application's source:
// TODO: Fix: It should not be necessary to
// specify the class in this intent. Doing that
// unnecessarily limits customizability.
The best alternative seems to be polling content://sms/sent, potentially using a ContentObserver.