My team and I are currently working on the implementation on web push notification on android (in pwa and twa context).
The purpose of this dev is to replace sms to notify our users, so we need a certain quality of service.
We implemented a classical solution where the subscription is done through our web interface (angular), the endpoint is sent to our backend and used when some event is triggered to send a notification to the device. All this process is OK. After a subcription, service-workers can be inspected and the push notification endpoint is correctly set.
The http status code returned by the endpoint call (updates.push.services.mozilla.com or fcm.googleapis.com) is 99% of the time 201 but we notice that many notifications are not received by the device. We add some listeners in our service worker to call our backend when the notification is received, clicked or cancelled.
The service works fine on our desktop environment. The notification is received as soon as the browser is launched on both firefox and chrome. It is reliable but this is not our target.
We notice different behaviours among our android testers.
For chrome users, some of them receive all the notifications, some of them lose a few (about 10%), some users lose a lot (about 50%), some of them need the browser to have been launched at least once, and so on.
For firefox users, the service seems to be unusable. It stops working after a couple of days, for no reason : the about:serviceworkers page shows that the endpoint associated with our application is set to null, whereas it has been correctly set just after the suscription.
However, when the notification is received, and clicked, the targetted url is launched but the application or browser stay in background
From that point, we would need several things :
any help or information that could help us having a more consistent behaviour like android or chrome settings requirements or minimal version
a nice way to debug
a way to inspect the running the service workers on an android device (without launching the browser)
more details about the global operating process on android
a way to understand why the successful submitted notification could have not been sent to the device, beyond connectivity problem.
Thanks in advance
Regards
Koj
Related
I have an Android app, instant messaging is one of the key features. For implementing the IM feature, we use our push server based on websocket.
For my app, I have a PushService, in this service, I establish a websocket connection which connects to the push server and receive push message.
The code works well when app in foreground (i.e.: works well while user plays with the app), but when the app doesn't in foreground, it stop receiving push messages after a while (about 1 minute). Same issue when user turns off screen.
I have set a repeat task with AlarmManager, which checks the websocket connection status, if it is not in connected status, then re-try to connect so as to back to normal to receive push messages.
This works well below Android M, for example on the Android 5 phones, it seldom misses push messages. But on Android M / Android N, it doesn't work as good as on Android 5.x. I can confirm the service itself is keep running , check from the 'Running services'.
I've noticed that starts from Android M, Android introduces Doze and Standby mode, not sure if they are related, if yes, how can I make the app continue to work again? On my phone the WeChat and Skype Android App work well, what's the mechanism behind it? I know FCM is the best solution, but I cannot use that for customers in China, so I need a workaround.
Edit: I had proposed to use a foreground service but PM doesn't like the notification tray always being shown in the status bar he wants to keep it clean.
Any advice will be appreciated!
I don't know about WeChat or Skype communication, but i know the WhatsApp using you own service notification with the same tecnology of FCM.
They using the Jaber server with implements the XMPP communication protocols
link
I'm implementing an app with an internal calendar, fetched from a remote web service. I want to send a local notification to the user when an event of interest is scheduled in the calendar, at a specific time chosen by him. Just like the iOS calendar app, when you can create an event and ask to be notified X hours/days before it happens. The main difference is that you can't create events: they are downloaded from a pre-populated remote calendar.
In Android I've solved the problem by using AlarmManager, while in iOS with Swift 3 the closest I've got to porting the same solution was via opportunistic background data fetch. The main difference between the two solutions is that background data fetch doesn't work when the app has been killed.
It would be really important for me that local notifications worked even when the app is killed. I think users expect apps notifications to work even when the app is closed, like it happens with WhatsApp or Facebook. I know that those notifications are triggered by someone writing something and therefore they are Push Notifications, but the average user just expects notifications to keep working even when the app is closed.
What would be the most elegant solution to "emulate" the behaviour of Android's AlarmManager in iOS?
Scheduling a bunch of notifications in advance hoping that the user will eventually open the app before all of them are dequeued looks a badly designed solution.
Also, delegating all the work to the server and push the notifications to the subscribed devices looks quite bad too as it requires much more work on the server side. Plus it requires a server which is able to awake itself to send push notifications, which is something that I don't have. I only have a simple webserver which answers to HTTP requests.
EDIT : The ideal solution I'm looking for isn't any of the previous 2 options, since I find them more like workarounds than actual elegant solutions to what I perceive being a fairly common problem. There has to be a third option...
In iOS there is no way to achieve this. Looking at the documentation of application(_:didReceiveRemoteNotification:fetchCompletionHandler:), it states that
the system does not automatically launch your app if the user has force-quit it. In that situation, the user must relaunch your app or restart the device before the system attempts to launch your app automatically again.
You can receive push notifications, but no code will be executed until the user launches your app. So unless you are sending remote push notifications from a server, you cannot set up new local notifications until the user opens your app.
I am pretty new to the mobile development scene and there is a very basic question to which I cannot seem to find the answer. Here is the scenario.
I have a mobile application. That application is connected to a server that I own. To use the mobile application, users have to login using unique credentials. Now lets say there are certain events on my server, about which I want to notify a particular mobile application user. Can my server proactively send a signal / data to the particular mobile app instance [using sessions data perhaps] so that a notification can be displayed on their screen?
Polling by mobile application towards the server to look for such events is not allowed / feasible.
I can speak to an iOS solution. Android surely has very similar functionality.
There are 2 ways to accomplish this:
Silent push notifications
Background fetch
A silent push notification can be, well uh, pushed to devices without alerting the users. This means that upon reception of the notification, the app can start downloading what it needs from your server. You will need to set up proper backgrounding for this to work properly. Otherwise, the notifications will be queued up and will only take effect when the user opens your app the next time. Start here for push notifications. The payload you send is what controls the notification.
Background fetching is process where your iOS app gets woken up by the operating system (iOS) periodically to allow you to perform a task. This task can be fetch data from a server or anything else you want pretty much. This is probably the best of the 2 solutions given that push notifications are not guaranteed to be received and this puts the onus back onto each device to fetch their own data as opposed to you creating a whole back-end system to perform the push notifications. Start here for background fetches.
You mean something like push notifications? You can read this tutorial (or any other tutorial on google) about how to implement push notifications in your app:
http://www.vogella.com/tutorials/AndroidCloudToDeviceMessaging/article.html
Lookup about push notifications on each of the platforms you're talking about.
Plus look into some live web apps, two that come to mind are meteor.com and nodejs
Can Pusher messages be received on Android/iOS app when the app is closed or the phone is turned off?
What i expect to happen...
When phone is on & app is on, it's pretty straight forward from the Pusher docs on how to react to pusher messages sent to the app.
When phone is on & app is closed, the phone should receive a notification that something has been sent to the app.
When phone is turned off, a notification should be received by the phone when it's turned back on to notify that something has been sent to the app.
Are these even possible? If yes, what are some suggestions to lookout for? If no, what can be some workaround?
When an application using Pusher moves into the background on iOS and Android the connection to Pusher will likely stay active for a few minutes. But eventually that connection will be closed. You can't stop that happening within your application (although there may be a "hack" around stating your app is a Voice app when submitting to the Apps store).
Therefore, you should monitor your application moving to the background and put a fallback in place to delivery messages to the phone when it's not connected.
Please see How get pusher events when the iOS app go to the background? for libPusher (the Pusher iOS library).
Here's an extract from the Android Processes & Threads Lifecycle docs on a "Service Process":
A process that is running a service that has been started with the startService() method and does not fall into either of the two higher categories. Although service processes are not directly tied to anything the user sees, they are generally doing things that the user cares about (such as playing music in the background or downloading data on the network), so the system keeps them running unless there's not enough memory to retain them along with all foreground and visible processes.
So, running a Pusher instance in such a thread is a viable option.
However, there will still be occasions where the user goes offline. In that situation your server you can detect if a user is online by querying the Pusher HTTP API or by using WebHooks where your server can be instantly informed if the user has gone offline or come back online.
Using the mechanisms above you can facilitate smart notifications; if the user is online (the app is in the foreground) then send the message to them by Pusher, if they are offline (the app is in the background) then use an alternative mechanism for delivery (native Push Notification, SMS or email).
I am creating a app in android 4.0.3 i.e ICS version, which connects to the server when client gets login into the app.I am trying to get status of an client when he gets online or offline through server & seen onto the app screen.I am unable to proceed. Can anyone say me:
Is it possible to get the status of an user through server?
1-- How to proceed for first step...?
2-- How should I get a response from the server that the client is connected & viewed to other client example - when we login into skype our status shows available with green radio button, In same way how can I get it.?
It ll be very help full, If anybody guide me.
Many Thanks..
I'm assuming you're trying to develop a chat app ?
If this is the case, try using an XMPP library. XMPP is widely used for chat apps, including Facebook chat (and Google talk I think) and there are plenty of open source libraries available.
Otherwise, if you only want real-time notifications as a part of a bigger picture, try using push notifications. Google supports Cloud to Device Messaging (C2DM) for android. It allows to have push notifications to a specific device without you having to deal with persistent connections, battery and CPU use .etc.
C2DM approach comes down to this. When a client connects to your server, get a list of his friends and their 'C2DM IDs' and fire a C2DM push to their devices. This push is delivered to your app, and you can respond to it by firing a notification, or update UI .etc. (Your app doesn't necessarily have to be running. Push notification is delivered via a specific broadcast, and your app can register a receiver for it to wake up.)
Keep in mind that there is a quota for C2DM messages per device, per app and also a limit for the payload per message. So you're not supposed to send massive files via this. Just a notification to your app, so it can call your server and get an updated list, instead of polling.
You can get more info on C2DM and code samples here. https://developers.google.com/android/c2dm/
Hope this helps.
You may have moved on, but I'm posting for anyone who would run into this one in the future.
Firebase is a good solution to use in this scenario, if the app is always running when you want communication to happen. (It will not wake up your app as C2DM/CDM does, unless you have a service running all the time and still wouldn't wake up if the device is asleep... AFAIK)
It may be useful for some scenarios, but may be not for a chat app as you want the device to wake up when a message arrives.
Note that they have limitations on the free subscription though.