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.
Related
Is there any possibility of general notification for an android-based Webview mobile application?
Hi there. I have built an android based WebView mobile application of Nextcloud. [Nextcloud is a suite of client-server software for creating and using file hosting services. It is enterprise-ready with comprehensive support options. Being free and open-source software, anyone is allowed to install and operate it on their own private server devices.] So the activities in nextcloud will be notified with in the website without any issue.
We wan't the notfication to pop-up, like general Android mobile applications. Can any one help me. First i need an clarification is this possible or not?
While using Chrome, The notifications of any websites will be pop-up in our laptop. Like wise we want the webview to pop-up the notifications in mobile.
As far as I know, your requirement is not possible directly. The web push notification only works for the browser. In that browser will be responsible for showing notifications for the user. For example, let us consider we send web push notifications with FCM. Notification will be sent to Chrome/Mozilla server from firebase and it will be delivering it to devices. The browser is responsible for push notification permission handling.
First, webview cannot handle permission.Webview does not have a push server. So it can not receive the notification sent from FCM server.
Alternatively, you can try with service worker api in webview and handle receiving notifications natively. Web push internally uses manifest.json(To configure notification icon,name,fcm id) and service worker API to achieve push notifications for web apps.
Else you can use try Trusted Web Activity(TWA). It uses Chrome custom
tabs to load the webpage. It required Chrome in the device. Since Chrome custom tabs runs on top of chrome, it can handle push notification delivery.
But not sure whether the notification will be delivered via chrome or the app. If your app is a PWA and it uses TWA, a notification might get delivered to your app. Otherwise, it might get delivered through the Chrome browser
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 little question about an android app with a function "remote" use via internet.
So I have these ideas:
Create a webservice using php on the server, and refresh the client app all x time like 4-5 sec
Or make a java server (so I don't know how I can do that)
I just want make a remote connected via user/password to the server and the other app connect to the server and refresh his status.
Do you know the best way for do that?
Thanks
The question is not very precise, but as far as I understand it, both your ideas implement the 'pull' concept, that is the client app checking the status of the server every now and then.
If you want the app to be instantly notified of the server status change, I would suggest push notifications with GCM (Google Clound Messaging). You can find some basic descriptions and examples at: http://developer.android.com/google/gcm/index.html
Sending a server-to-client notification is simple regardless of the platform you use server side. E.g. for PHP integration with GCM, check out this thread: GCM with PHP (Google Cloud Messaging)
I am using the Google-GCM service for pushing notifications to a mobile device & building this application in Java EE.
I'm perfectly able to push notifications to the mobile device. And from the client-end (mobile) I'm able to receive input(string).
Henceforth my conceptual question starts: When I'm receiving input from a mobile (let's say: "Hello, Server"), I'm trying to build an automated process on the server-side and in reply it will push a notification (let's say: "Hi client, I'm fine; How are you?") automatically.
I want to grab some idea to push the notification automatically whenever the mobile device is registered. How do I do it?
All realistic implementations of GCM include a stage where an app receives a RegID, and communicates the RegID back to the server, typically via an HTTP service, typically along with some other business specific data. The server would store the RegID, associating it with other data, and later use it to send messages.
Have you implemented automated the delivery of the GCM registration ID to the server yet? If so, in the same piece of code, you might as well push a notification back. If not, do put together some. Server-side implementation would depend on your server's platform, naturally.
Is it possible to open my mobile Java program with an SMS?
And I don't want this SMS to be stored in the inbox. I'm looking for the kind of "Control SMS" that banks use for their mobile applications. I want the same in my application: send SMS to the mobile, the mobile device shows a message on screen that will be opened by the program, and this SMS should not be saved in the inbox.
Are you sure that you're not mistaking push notifications/cloud to device messages for SMS's?
Push/C2D messages are similar to SMS's inasmuch as a central server sends a message out to devices and many apps then display a popup based on that message, but the implementation is completely different. If you're not mistaking the two, is there a reason you'd prefer to use SMS's that are handled differently than most instead of push/C2D messages?
Here's the documentation for Apple's Push Notification Service.
Here's Android's Cloud to Device Messaging documentation which serves the same purpose.
Have a look and see if that would serve your needs.
If you are looking for completely client side J2ME based solution for feature phones - then try push registry. It is available above MIDP2. I don't know the exact details but there you can define event and triggers which will be stored by phone OS and invoked automatically when particular type of event occurs.
SMS sending is separate issue but there are tools available for that definitely.