I use NFC to send text records from my app on device Nr.1 to my app on device Nr.2. Then the device is in touch, on both devices popup "touch to beam" UI. If I touch and beam message on device Nr.1 (sending part ot the pair) - message sent, everything working is just fine. But if I touch "touch to beam" UI on device Nr.2 (which should receive message) - then my app on device Nr. 1 is reloaded. Logcat is show nothing wrong, no errors. Seems, is that case app get some kind of empty NFC message? But why it's just do nothing on that? Why reload? I'm using ForegroundDispatch, create "text/plain" filters programatically, without manifest.
How I can handle this situation, then the users press wrong side of "touch to beam" UI??
If you do not set up Android Beam in your app, Android's default behavior upon beaming is to instruct the other device to either open that same app (first activity that filters for MAIN/LAUNCHER intents of an app with the same package name as the app on the source device), or if your app is not installed, open the Play Store listing. This is done by sending an AAR (+ a Play Store link?) over Beam.
So in your case, clicking the Beam UI on device 2 causes the AAR to be sent to device 1. As a result, your app will be (re-)opened on device 1. In order to overcome this, you can do the following:
Enable foreground dispatch for the activity on device 1, so that the received NDEF message is immediately processed by your app. I'm not sure if this collides with the Beam UI though.
Change the NDEF message sent by device 2 to something that does not contain an AAR using the Beam API.
Related
I'm coding an app with Mit App Inventor2, which is expected to record number and text message of received sms using the Texting component but I can't figure out how to access to number and text of a sms received when the app isn't visible.
With ReceivingEnabled properties set to always in the panel, the app can only:
receive number and text if it is running visible in the screen during the reception of the sms (and correctly past them to other variables);
notify the reception of a sms if the app is closed but I think running in the background (anyway not visible between the opened app);
correctly do nothing if I stop it from the application setting of the phone.
I tried this actions by texting myself with the built apk installed in the phone.
I searched and found 1 asking quite the same thing, and 2 where Taifun states that "This feature however is available only in the United States."
Here there is the block I should improve.
The same question posted in mitappinventor google group.
I have integrated the latest cast SDK within my Android application. It does play media correctly and I'm able to control the playback via on-screen controls as well as via the status bar notification and lock-screen.
I have received, though, reports from some users saying that after a while listening to the media via cast, when their devices went to sleep/got locked, they were not in sync with the receiver anymore as well as losing the possibility of controlling the playback.
I was not able to consistently reproduce the issue (since forcefully locking the device keeps the connection for a while), but I could see it happening a number of times and was able to catch logs for one of them.
At first, I was suspecting that the receiver's messages were not arriving to the sender (android app), but the Google Home application works flawlessly and updates the metadata and playback controls correctly. So, the pain point must be in my application.
I did notice that, while in that "inconsistent state", I am still able to read logs after a track finishes (so, change of state) as follows:
02-05 00:02:08.958 16642-27384/? W/CastDeviceController: [controller-0335 API] Ignoring message. Namespace 'urn:x-cast:com.google.cast.media' has not been registered.
Do I need to register that protocol within my application? (I do use a custom protocol to send messages - and if I'm not mistaken, the "unregistered protocol" is the default one - shouldn't it be automatically registered?). If so, how can I perform that registration?
Any help will be appreciated.
Sorry if this sounds like a lazy question, but I've Googled and couldn't find an answer: I suspect this is because it can't be done as I describe below.
I have an app which runs on the phone for remote controlling power devices. At the moment, users can create a home screen icon on the phone, which fires an intent on the phone which launches my app in the background to execute various macros.
I want to extend this functionality to Android Wear devices, i.e.
1) on the phone, the user would press a button which would programmatically create an icon on the Android Wear device (e.g. in Wear Mini Launcher), which would have an intent associated with it.
2) when the icon was pressed on the Wear device, it would fire the intent on the phone to launch the main app on the phone in the background which would then execute on the phone.
Is this even possible? I would like to avoid having to write a specific app for the Wear device if possible.
Any suggestions welcome, or code snippets would be even better! Thanks.
Andrew
You can do some of what you want, I'll break it down into your separate questions.
1) You would create a mobile and wear app, when the mobile app is installed it will install the wear app as well. There's no way to install them otherwise.
2) On the mobile app you could create a wearable listener service that would respond to messages from the wear app. On the wear app when you do your initial launch of your activity you could send a message to the listener service via the wear messaging api and the finish. Within the mobile wearable listener service upon receiving the message you would launch your intent.
Here's a pretty good example of how to do this -
Wear Messaging API example
ICS introduces the possibility to share an application via Android Beam using NFC, and as far as I understood if an app is opened on deviceA it will automatically be started on deviceB (if it's already installed on it, otherwise the Market app will open) when the devices are close enough and a user "touches to beam" it. Is there a way, inside the launcher Activity, to detect if it has been started because of a NFC message or because of a user interaction?
Only NFC Intents are started when a beam occurs. These are ACTION_NDEF_DISCOVERED, ACTION_TECH_DISCOVERED, or ACTION_TAG_DISCOVERED. Check out the beaming section of the dev guide for how to handle beams: http://developer.android.com/guide/topics/nfc/nfc.html#p2p
In case the Android Beam (or NDEF) message contains an Android Application Record, http://developer.android.com/guide/topics/nfc/nfc.html#aar, the resulting Intent to start the app will not be of the action ACTION_NDEF_DISCOVERED, but ACTION_MAIN. This method can be used to launch any app, including apps that do not filter for NFC intents.
Thank you for taking the time to help me out. I don't know if this is even possible but I though it would be worth asking seeing as it is vital for my app :/ In simple terms, what I want is for a function in my application (e.g. a Toast text to show or something) to be fired when another application is doing something -- like if I send a text message in the messaging application. (example - I send a text in the text msg app and (my app is running in background as a service or something) a Toast (created by my app) displays "You sent a text!".
Thank you for your feedback!
Sincerely,
Jackson Smith
You can't do it in general for every action, and I don't know if you can do it specifically for texting.
However, for some actions (like screen lock/unlock, wifi up/down etc.) either the android system or the application causing the action will broadcast an intent that you can catch with a BroadcastReceiver (if you have the right permissions to do it). You need to know what intent you want to respond to and what permissions you need to be able to receive it.