I have a general multiplier question. When we look at games such as clash of clans or any mutliplayer game that involves many players at the same time. Are all the information exchanges to determine the game movements/changes based on push notifications, or is it polling or is P2P/mesh connection?
I just always thought of push notifications as for important messages and I am not sure if using it realtime is valid
Have a look to the Parse service.
https://parse.com/tutorials/android-push-notifications
There is an API to send notifications and track all phones
On a task completition you can call the api (with the gameserver) to send notification to your phone.
No need the app to be open.
Related
I am developing a VoIP application with SIP as the signaling protocol. I have implemented the messaging and calling functions and they work when the app is in the foreground. To make the app listen to the call and message receiving when it is closed, I created a foreground notification so that the app would always be in the foreground.
The problem is that the above method consumes a lot of power which is unacceptable. I have also noted that famous VoIP applications like WhatsApp and Signal are not using foreground notifications but, they manage to inform us about incoming calls/messages no matter the app is closed. I wonder how to achieve the same functionality. Could anybody please point me in the right direction?
This kind of App should use Push Notifications (reference: https://firebase.google.com/docs/cloud-messaging) that use ONE SINGLE socket connection for the whole system: each App should register itself for receiving Push, then when the Server triggers (many languages are supported by FCM with examples/tutorials) the Calling Event then a special "message" is sent to the App (providing some information about IP or whatever you want) that gets those information and acts in the proper way.
Unfortunately FCM, after few thousand notification per month, requires payment.
There are other similar online service, but those services requires a fee because they should handle many users connected at the same time and it requires hardwar and bandwidth.
I am writing a mobile application in Flutter, which is Google's SDK for developing mobile apps.
Basically, I was researching into how to mobile push notifications and every source I could find would point me in the direction of Firebase, which is Google's mobile and web application platform. Firebase is extremely nice and makes it really easy to send push notifications from user to user,
but I would like to learn how to do it myself and I can not find documentation to do that.
All I could find was creating a Dart Isolate in the background of my application to solely listen for incoming notifications. The Firebase plugin for Dart, from what I can gather, does just that; creates an Isolate to listen for notifications, even when the app is closed/user has killed the app.
So my main question is, is it possible to create an Isolate in the background to keep a WebSocket connection alive at all times that would listen for data from a server, and then push that data to the screen in the form of a notification without the use of Firebase? (I have created a server in Node.js, and it would be cool if I could just handle all notifications from my Node server). Thanks!
Of course you can implement push notifications without Firebase. Do a web search for “list of push notification services” and you’ll see lists of a variety of services out there. And, on the iOS side, you can have your web service interact directly with the APNs, and have no third party service (such as Firebase’s FCM) involved at all. On the Android side, though, FCM is probably still the logical choice. It’s easy, scalable, and is free.
I would not suggest trying to keep a socket connection alive at all times, though (if that’s what you’re contemplating). First, you won’t even be able to do that on the iOS side when the app is not active. Second, these push notification services are designed to solve the problem that web sockets introduce, namely the user device resource drain and the cost of maintaining a scalable server to maintain all of those connections.
Sure, use sockets where you need them (e.g. near-instantaneous communication while the app is active, etc.), but it’s not the right solution when the app is no longer active.
For iOS side, I would love to point you to Send Push Notification Through APNs Using Node.js. I tried it with my own node server and found it super easy.
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
I want to create an Android application that shows ongoing events to users (missile launches in different regions, based on the user's location. This isn't a game, it's one of the perks of living close to Gaza).
I can use GCM for push notifications, but I have to do this on a device-by-device basis. I would like instead to offer a few subscription channels based on the client's location, and send data from the server to all clients listening to that channel.
Is there a Google API for this, or do I have to implement it myself (maybe by using XMPP), reducing battery life quite a bit?
Is it possible to send push notifications to an android application without using Google server: C2DM?
So, I would like to have my own server which sends notifications directly to the app, but I'm not sure how are the notifications perceived by the device, because the device needs to receive notifications even if the app is not running and the notifications should appear in the notification center.
I think that the guys from www.airpush.com have managed to this, but I'm not sure how.
Can anyone help me with this please?
UPDATE:
Also I would like to know how to display the notifications in the notification center if I don't use C2DM? And if it is possible to configure the notification center to receive notifications from my server even if the user deletes the application developed by us, application which registered that device to receive notifications.
I want to send 3-4 notifications a day, but these notifications need to appear in the notification center and they should go only through our server. How can I configure the notification center within the app to make requests on my server for push notifications.
Thank You!
There is a solution from UrbanAirship called Helium push. According documentation Helium:
Works on Android 1.6 and higher
Does not require a Google Account
No default pushes per day limit
No default pushes per minute limit
Works on Amazon devices (e.g., Kindle Fire)
End to end Urban Airship support (i.e., API to to device)
Best throughput
The problem is that you need development app key for using this one.
Take a look at MQTT:
MQTT stands for MQ Telemetry Transport. It is a publish/subscribe, extremely simple and lightweight messaging protocol, designed for constrained devices and low-bandwidth, high-latency or unreliable networks.
It can be used (and was used in some applications) to implement custom server push solutions. One of the most well known applications using MQTT is Facebook Messanger.
You can easily find more information on MQTT in the Internet, e.g. in this SO question or in this blog post.
According to the FAQ on airpush.com, they're not using real push notifications but rather polling the server a few times per day. One reason I think this is a viable solution for you as well is that Android's C2DM apparently makes use of the Google Play Store, so it won't work on devices distributed outside of the Google eco-system. With over 5 Million Kindle Fires having sold already, that is worth thinking about.
From Airpush FAQ:
When executed once from the main activity of an Android™ application, the Airpush client utilizes Android™ OS's AlarmManager framework to schedule ongoing server polling events a few times per day. If an ad is polled from the server it is cached until optimal display time, which is algorithmically determined by the server.
Without using C2DM there's not option for a "real push notification". Because (afaik, correct me if I'm wrong) an android device registers at google (they can still deinstall malware from your phone via remote) and with this ip they are able to do a push notification. All other solutions could tend to be a "register at a server, keep the connection alive and wait for requests" or something and tend to be more battery-inefficient.
Parse has an excellent push notification service for Android, very easy to setup. More info here: Parse Android Notification Doc
If you want the user to only receive 3-4 messages per day and your messages are not bound to specific arrival times, you don't need pushing mechanisms.
Just create a service in your app that checks your own web service 5-10 times a day. If there is new data, make your app display it in the notification center.
If you don't want to have a service running all the time (like many messaging apps do), you can set up alarms (using the Android AlarmManager framework) that wake your app up regularily to check for new messages to display.
And if it is possible to configure the notification center to receive
notifications from my server even if the user deletes the application
developed by us, application which registered that device to receive
notifications.
That sounds like you want to write a virus or root kit ;-) You could use e-mails for your messages instead.
UPDATE 2013-12-30:
As just noted in my comment, rebuilding what GCM does is not a nice approach. It's enough when Google Services already load the device with this functionality. If your goal is just that Google does not see what messages you send to your users, you might aswell encrypt them. For Google not being able to actually read your messages, the client app should generate a key and send it to your server. All messages you send via GCM can then be encrypted using that key.
If you just want to circumvent Google's restriction on the amount of messages sent to users, you could pack multiple messages into one GCM notification and show them one after the other. But then again, we are back at some kind of polling solution as described before, with the exception that the user does not need to have internet access when you want to show the messages as they are cached on the device.