Currently working on an Android application that enables people to alert other people in the same network that have said app installed on their android device. It uses Java's Network Service Discovery classes to accomplish this.
There's a background android service that advertises a network service to the network, so the device can be seen and communicated with by other devices in the network. It calls
mNsdManager.registerService(serviceInfo, NsdManager.PROTOCOL_DNS_SD, mRegistrationListener);
to register the service on the network.
This background service runs at all times when the device is connected to a WiFi-network to ensure availability.
All the functionalities that have been implemented work fine, until the phone gets put to sleep.
When that happens the network service, which is supposed to be broadcasted at all times, stops showing up.
I assume this is not a bug, but normal behaviour since the Android background service is stopped(?) and as such stops sending packets to the network when the phone is put to sleep.
How can I solve this issue? Do I need to take a different approach entirely?
Related
First of all I don't know what type of code to put for my problem.
I'm developing an Android mobile game, with two ways to earn ruby, via mini transactions or via the OfferWall IronSource.
Regarding the OfferWall, those are tasks to complete to then receive Ruby in exchange.
Now my problem that I would very much like to solve
When a user completes a task and the app is not running, how can I send a notification?
zigg, my suggestion would be to call firebase notification while running background service or you can use push notification as Blundell suggested in background service.
The background service will run even if the app is not running. I use foreground services and call push notification in the service when the app is closed or in background.
Hope this helps.
I'm new in Android BLE so my question may be uncorrect or naive in some way. If this is the case please explain me where I'm wrong and kindly show me the correct way to manage this scenario.
Scenario is the following: my Android app communicates with a BLE device sending commands and getting answers from device using BLE characteristics.
Sequence is:
Device wakes up the app (the onConnectionStateChange method is called)
My app writes a command in a characteristic (I call writeCharacteristic putting the command in value parameter).
Device sends back the answer to command to my app (the onCharacteristicChanged method is triggered and value parameter contains the answer)
After waking up the app, the device doesn't do anything until a command is sent via writeCharacteristic. The device accepts different commands.
All good so far, but recently I developed a second different app to communicate with same device.
When I run both apps on same Android phone, one app sends a command to the device and the response is received by both apps! Of course the app that didn't sent the command receives an unexpected answer and goes to an unexpected status.
Ok, knowing the problem I can modify both my apps to handle this situation, but the question is: Is this behavior normal when two apps in same device communicate with same BLE device?
Is there a way for an app to establish a communication channel with a BLE device to avoid sending answer to specific commands to any other app except the one that sent the request?
My guess is that writeCharacteristic and onNotificationChanged aren't the right functions for such kind of communication, but in this case which are the alternatives?
The Bluetooth standard itself doesn't define anything how multiple apps would behave if both have a GATT connection to the same device. In the standard there is just one "GATT client".
Now both iOS and Android have taken one step further in a way that might seem unintuitive. Instead of only allowing one app at a time to communicate, multiple apps can be connected over the same GATT client to a device. The OS "multiplexes" the communication from/to the apps. The behaviour is that responses to read and write requests can only be seen by the app that made the request. So if you do readCharacteristic only that app will get the onCharacteristicRead callback. Notifications however will be delivered to both apps to the onCharacteristicChanged callback, since it wouldn't make any sense to send the notification to only one.
When you say that the "response" to a write request is the notification, that's not correct in terms of GATT terminology. The response to a write request is always empty per specification (or an error). If your peripheral emits a notification, then in your case that might be the "answer" according to your own logic, but it's not a response or any way related to your write request per the GATT specification. That's why Android can't (and shouldn't) send the notification to only one device.
I suggest that you simply ignore notifications you are not expecting. If you want to associate an "answer" to a write request, you can change your protocol to include a transaction id in both packets so they can be matched.
When I write "app" above, I really mean BluetoothGatt objects. You can call connectGatt twice with the same remote device in the same app, which will behave the same as if you connected from two different apps.
I have a Java web application which needs to send manual and automatic notifications to the user.
This notification should go to the user's browser as well as the mobile devices (both iOS & Android).
I found out there is no way to send notifications to mobile devices directly if there is no native application running on the mobile device. So my only option seems to be web push notifications. I went through a few articles and I found it very confusing. I don't know where to start.
Can I send the notifications directly from Java Code? Or do I have to use FCM(Firebse)? If so can I call FCM directly from Java code, such as by calling it using Apache http client libraries?
How does the FCM, client's browser and my application connect?
I also found out that a service worker should run in the background to receive the notifications. How do I integrate it with the Java code?
You can send them directly without using FCM and there are several libraries available, including a Java one.
Unfortunately iOS currently has no support for Web Push. Subscriptions to your service are on a device level rather than by user, so if I sign up on my desktop you cannot send notifications to my mobile unless I sign up again in my mobile browser.
Notifications pushed to Android will be displayed if an instance of the browser is running, in the real world (for me anyway) Chrome always seems to be running in the background somewhere so I get notifications through in pretty much real time. The downside is web push notifications go straight into the notification shade, they do not pop up on screen first.
The rough workflow goes like this:
User visits your page, you load service worker and check for web push
capability, if satisfied you can request permission to send
notifications.
If user grants permission you pass your public key to your service
worker to create a subscription for that user, this returns an
endpoint and two keys which you need to push a notification to them.
Your webpush library runs as a server instance and takes care of all
the encryption and token handling, you configure it however you like
to dispatch messages, usually in response to HTTP POST requests but
it's up to you.
Within your service worker you define an event handler for receipt of
a push message. This is where you create and display the notification
to the user, again how you do this is up to you.
You can pass parameters in the payload of the notification and use them as variables within the notification you display or you can hard code values, you can specify different behaviours depending upon whether the user has your page in focus or not, you can add buttons and set different actions for them, trigger events upon dismissal, customise the vibrate pattern, replace or stack the notifications, access the data in existing notifications etc etc. All this is handled by your service worker, receiving the notification alone does nothing at all.
Your service worker is just a script written in javascript which you link from your page. It is loaded and installed by the browser the first time a user visits and then runs independently when invoked.
Service workers are very powerful. You can also use them to implement complex caching rules, serve content while offline, push data between different browser windows etc. A service worker can spawn more service workers and as they run outside of the main thread of your browser they are ideal for offloading cpu intensive tasks to without delaying the rendering of your page.
Final point to note, your site must be served over SSL to be able to deploy a service worker.
1) It depends a bit on where the Java code that sends a message runs.
If it runs in an Android device, then there is no way to securely send messages from that code. See my answer here for more details: How to send one to one message using Firebase Messaging
If the code runs in an environment you control (such as a server you control, or Cloud Functions), you can call the FCM HTTP end points documented here. The Java Admin SDK doesn't support sending messages yet, although it seems to be under consideration.
I'm building a simple motivational quote app that generates a random quote from a MySQL database. The app works fine on mobile and I want to sync the quote message to a Wear device. I'm using MessageApi to do so and used this tutorial to set it up: http://android-wear-docs.readthedocs.org/en/latest/sync.html.
However, the message functionality only works when the app is running on the host device. I need to launch the app on Wear alone and still be able to receive the message from the mobile device. I thought of running the same application on the Wear device where it will run an httpconnection on it's own but from what I understand this is not possible with Android Wear.
So my question is, is there a way to open an app on a Wear device that will trigger the mobile app to open in the background and hence receive the message that way?
Your mobile app can implement WearableListenerService. In that service implementation, you can listen to messages that are sent to your phone from your companion app on a wear device (when such message is sent to your phone, the framework on your phone starts up your service and passes the message to it). You can then implement the logic you need in that service (fetch a quote, etc) and respond back to your wear's message; when its work is done, that service will go away on its own. For this to work, your wear app needs to send such message to your phone app upon start up (or whenever you see appropriate in your app). This approach should work and probably is the most appropriate approach for your use case.
I have two access point broadcasting same SSID across a wide open area. Usually the mobile device switches to strongest AP by default if the currently AP is not strong enough without haviong disconnecting and reconnecting to WiFi. But over a long period we have observed that the WiFi switching does not happen sometimes.
For such cases we were planning to handle that switching at android application level itself.
But after doing lots of research over web. We could only find methods which involve disconnecting the Wifi and reconnecting again which is not desirable in our case. As our application accepts payments over web . Disconnecting and reconnecting again based on signal strength would result in payments getting declined.
Is is possible to replicate the WiFi switching which mobile device does automatically at android application level.(I know the question is absurd but i am desperately looking for a workaround)