been looking for the answer over a few days but no luck so I think I better ask SO. Here is my scenario: I'm trying to create a Flutter WebRTC video call app which is similar to WhatsApp or Viber. I use a simple web socket to do signalling so that I can display caller name when there is an incoming call from the other end and depends on callee's action like Accept and Reject the call they can either engage or just simply hang up the call. All working well so far. The problem however I'm facing is when either parties not using the app, the other party can't make a call because they can't send the signal. I think when the app is not running its not connecting to the web socket. How can I make the app keep listening efficiently to call signal events even its not running? Thanks
You need something that notifies the application that there's some incoming call/data even when the application is not running.
I'll recommend to use Firebase Notification Service. Although you can also use Pushy or Pusher Beam for this task.
Upon receiving the notification, you can perform desired task based on the data payload received through the notification.
I want to create an app with Flutter for which it is necessary to receive (and send) mails. Clients share information with eachother in a decentral way using i.e. Googlemail without using an own server.
During my research I found several ways to send mails but no way to receive them since this seems to be not implemented yet in any package.
Flutter offers the option to use platform-specific code with platform channels (flutter plattform-channels) which might be a solution.
However I haven't tested this yet because I write the app for both iOS and Android which means that I'd have to do this for each java and Swift/Objective C.
Maybe someone here knows a better solution.
I have a simple app in Android, that uses some features like Services and Broadcast Receivers. It is a simple project, that uses SignalR to make a chat. A basic chat, where the service has the signalR connection and staying listening for any new messages or contact's status's updates.
Then, I have some broadcast receivers:
to start the service,
when receive a new message to add in the chatList
when receive a new contact online to update the contactList.
So it connects to a server that uses SignalR implementation, and do all the server job that is expected from a chatWebServer.
So, I'd like to re-write this app, using MvvmCross, so i could have a WindowsPhone, iOS and Android versions. I know the broadcast receiver could be changed for the Messages Services in MvvmCross, but the Android Services/ iOS Long Tasks/ WindowsBackgroundsTasks would be implemented as what in MvvmCross? Would be possible to have it implementation in Core project, so I can reuse it in all platforms? Can anyone help how would be it archtiecture?
Thanks in regard,
Gabriel Bastos
You will still need to rely on what the platform has available for you. So on Android you would still need to have a BroadcastReceiver or at least a Service which has the SignalR connection, otherwise it will not survive if the application is closed.
iOS and Windows is a bit of a different story, there you are not allowed to have stuff running in the background. So here you would probably need to use push notifications to notify of new messages. Although on Windows Phone you can have Scheduled Tasks or also called Background Agents here I think you can do something every 60 seconds at most.
On iOS you are out of luck you simply can't do stuff in the background unless you are using the built in Location Services or something like that.
MvvmCross does not do anything magically, nor does it allow to create a service which does something the platform does not provide.
I'm working on a messaging app and I have a dilemma about how to send data from server to client.
I'm using a centralized server design, where clients uses NSURLConnection to send messages to the server, the server doesn't keep and manage open sockets and can't send a message for one of the clients. So clients use a timer and query the server every 2 seconds to see if new data is waiting for them.
The problem with this approach is that polling the server every 2 second seem to kill the battery very fast, so I thought maybe instead of clients polling the server, to use APNS* so when the server has some new information ** for the client, the server will send a push notification *** to the client, then the client will fetch the data from the server.
* use APNS - if client allows it, client can of course disable this option. So I will check if push allowed every time the app enter foreground and if not I'll return to the polling approach.
** New information can be anything from text messages to server admin messages. (and there are a lot of admin messages...)
For example, in my app users can see their friends status (online/offline), so if user1 and user2 are friends, and user2 just change his status from online to offline, then server needs to send this new info (admin message = user2_offline) to user1.
*** The push notifications server sends are empty (with no data/sound), it's just a trigger for the client to fetch the new info, so if a push was sent to the client and the client app was close, he will not notice anything. (if the app is running, then it will fetched the new info from server)
Will this approach work with a massive messaging app requiring massive push notification uses?
To be clearer my main concerns are:
1. Is APNS reliable enough that I can use it as my core server-to-client messaging mechanism?
2. Will apple approve potentially thousands or hundreds of thousands push notifications a day from my server?
Is APNS reliable enough that I can use it as my core server-to-client messaging mechanism?
NO. Just for the sake of being complete let me iterate over the reasons.
Apple itself disclaims the reliability read the Programming Guide
Also, APNS, has a QoS component which may increase the reliability at the cost of being realtime (For Eg. I can ask APNS to deliver the notification anytime within 4 weeks and retry if devices are not reachable) which is not useful in your case.
As per your requirement, if you send a silent push (a push with no user visible message), it can not be sent as a HIGH priority push which decreases the reliability even further. Here is a relevant quote
"Silent notifications are not meant as a way to keep your app awake in
the background, nor are they meant for high priority updates. APNs
treats silent notifications as low priority and may throttle their
delivery altogether if the total number becomes excessive. The actual
limits are dynamic and can change based on conditions, but try not to
send more than a few notifications per hour."
Will apple approve potentially thousands or hundreds of thousands push notifications a day from my server?
Generally, APNS will not have any issues with this in terms of load, but it has throttling in place and they might throttle your notifications, see point 3 above
IMHO, you should look at XMPP as this protocol is designed just use-cases like yours and they have wide community support on all platforms. I will suggest you look at something like https://github.com/robbiehanson/XMPPFramework and setup an XMPP server at your backend which will handle the messaging and presence messages as well as admin messages.
If you have already evaluated XMPP and do not want to go with it, I would suggest you need to put together an intelligent system in iOS App which employs different strategies based on App State, something like following, you can have following strategies
A Realtime Socket based approach -> Establish a permanant socket connection and keep the data in sync as much as possible (This is when your app is running into foreground or background)
The Polling System You talked about in question, which can be utilised when your app is invoked for background fetch/location updates etc.
Use APNS with user visible messaging + custom data, when your server detects that the device does not have active socket and also have not polled for a very long time
I have worked in this area for a while and from my modest experience I think your approach to solve your problems will reach you nowhere. Allow me first to highlight some important facts on the APN characteristics:
APNs are not reliable, they are not 100% guaranteed to reach the client.
As of Apple's documentation, APNs are best effort, so many times they might not reach.
APNs don't hold data inside them, so even if they reach your client app they hold nothing inside them for the app.
APNs are just notifications for the user that something related to your app has occurred, while there message (the text that appears in the Alert Box of the APN) is handled by the iOS and not your app. This is why devices with iOS 4 will display the APN in a different way than devices with iOS 5, it is OS job not your app.
The badge value that appears on your app icon when notifications come is the responsibility of your server, and not the device OS. Put differently, when an APN reaches the device it should come having the new notification count value for your app. The OS won't do anything for this.
Having said that I would like to explain a bit how usually such applications are designed. First, it is not done by URL Connections and the clients don't check the server every period of time. Usually you have a client/server architecture where your client is the app on the device and the server is a real server program that resides on a server machine. The server could be Microsoft (using C# for example) or MAC (using Objective C). The server has a database that it stores information inside it. Some important information (related to your question) is the APN Count Value, the Message that you want to deliver, the state of the client if online or offline.
When a client likes to send something to another client, or when the server wants to send something to a client (or all the client), a check is made to the recipient client to see if he is online or offline. If he is online the message is sent directly, and usually the communications are done on TCP Sockets. If the user is offline then the server will store the message that needs to be sent to the client, increase the APN Count value, send an APN to that recipient. When that recipient becomes online, the server will notice that (because there is establish connection and handshaking) and therefore will fetch all undelivered messages from the database and send them to him...
It is a long process, I hope I was able to explain things a bit to you. In all cases I don't think your way is practical or enables you to reach real work.
I need to implement a message service into my app that works exactly like this:
users register with a nickname within the app
they can add contacts (just nicknames) and send them a message by just specifying their nickname
they can send a message whenever they want, and the message is stored on a server until when the receiver connects to internet.
when a message is received, a push notification is triggered.
So, the messages work pretty much like emails, however instead of using email addresses, we only use usernames. I'm also going to build my own back-end for it.
Which APIs should I use or which 3rd party framework can I use ?
And any tip ?
N.B. I need to make it work with iOS 3.0 as well.
and in the future I will develop an Android app, so the nicknames should be unique and I should be able to send messages from iPhone to Android devices within the same app.
thanks
I've successfully used the Three20 library and would recommend giving it a try. It's an open source spin-off originated by the author of the Facebook app. It features a bunch of additional GUI components that might be useful to your project, like a message composer that resembles the one used by Apple's email app.
Also, Three20 features a nice framework for handling navigation within your app. Currently, the biggest drawback seems to be that certain features don't play well with the iPad API.
The answer seems to be Push Notifications