Edit: I've noticed that StackExchange has prefaced this question with Android but it applies for both iOS and Android.
We have a client side iOS/Android application that we expect to run (in remote Australia) with very limited internet connectivity. However, the application can expect to have very good connectivity to its local network, which is not on the net.
I've been looking into ways of waking a phone up with a notification of some sort whenever an event happens on the local server.
From what I've researched:
Web push is no good as even the newer VAPID based protocol still wants to route some data through the browser vendor's notifications server.
iOS Apple Notifications essentially have the same requirements as Web Push.
A background task which periodically polls the server/wakes up a Websockets connection can work, but could end up with pretty long delays between polls.
SMS is an option, as although 3G is limited, basic phone connectivity is sometimes available.
Are there any other ways of being able to wake up a locked mobile device with a server-sent event that I haven't listed? Given the operational situation having App Store compliance is not necessarily a requirement.
Cheers
After doing a fair bit of research, the answer (as of early 2018) is a pretty solid no, at least for a cross platform usecase.
iOS requires that an external notification that can wake the device come from a recognised internet-based source (APNS, and maybe in future the standardised VAPID based Push), from the mobile interface if available, or from the device itself which is limited by background execution restrictions.
Related
I've always used GCM for push notifications in android apps, but for security constraint i'm obliged to avoid GCM and use local push server, i've found a lot of answers for this question but none of them is well structured, i hope to get a clear answer for step by step process to use some XMPP server and client libraries for this topic
You may not fully understand what is GCM and what GCM was designed for.
Traditionally, each desktop applications establish its own TCP connection to its own server, just like you can connect to your Openfire instance and send/receive messages when you want without any third-party services.
This approach have many issues in mobile environment:
mobile devices are resource limited: when you have many TCP connections open it will drain your battery fast
mobile devices are not have persistent network connection: you should care about cellular and/or wifi network changes (and it also have battery impact) and you should not lose any messages in these unstable environment.
To solve these problems, Apple, Google (and also their minor competitors) provide "notification services". They are consists of:
System-wide background application ("service") which keeps connection to Apple/Google "notifications" infrastructure servers.
API for developers, to "register" their applications both on server and client side: your server-side application send all events to Apple/Google, and you client app receive "pushes" from that system service, you no need to care about network outages and battery impacts - all issues are handled by OS manufacturer.
But when you are trying to "avoid GCM" you getting all things to be cared by you, plus:
Your "handmade" persistent network service will interfere with Google's one, and will at least double network and battery usage (or even more, just because your implementation will have errors/other corner cases which are already where solved by Apple/Google big engineering teams)
Your application will dramatically more complex, and you will have much more security issues (as security issues are now handled by you, too) and poor user experience (applications with "own" networking are often have bad UX design, prompting and boring end user with network error messages, for example).
So, to sum up:
Yes, technically, you can take smack library and connect to Openfire server. Basically it the same as GCM works.
No, in 99.9999% of cases you should not go this way. Unless you are a big company which develops competing mobile platform.
I implemented push notification system and I noticed that push messages do not ever come when I am on 3G or 4G (mobile Internet).
When I connect to wifi, they come regularly.
Is this behavior bound to Android OS or we can write a code to change it?
I implemented Parse.com 3rd party library. Regardless of myself, I noticed that push messages from other apps do not come unless I am connected to wifi.
If you see the same behavior with stuff from Google (Gmail, Google Play app updates, etc.), then the problem lies with your phone or carrier. If the Google stuff works (they use what amounts to GCM), then your problem lies with Parse.com and whatever the other apps are using for push.
GCM (and the C2DM precursor) work over mobile data or WiFi. It is a bit tricky to implement a push system as a third-party library, which is why I recommend firmware solutions (GCM, Amazon's just-announced Kindle Fire equivalent, etc.). In particular, maintaining a mobile data connection to the push server, with enough heartbeats to keep the connection alive without really draining the battery, is difficult to get right, particularly given subtle mobile carrier or device variations. Google has more experience with this than do most firms, and Amazon only has to worry about a handful of Kindle Fire models.
I am a little stumped. I've been trying to find a way for a wireless device (i.e. Android/ios/Windows mobile devices) to receive a message from a central server and then launch the device web browser.
The Scenario: a server on a WLAN network monitors a certain system. when something on the system goes wrong, the system stops what it is doing and sends an error message to the server and wait for the user to enter a response on the server before it resumes what it was doing.
Now, I want to send a message from the server(when the system it is monitoring crashes) to the wireless devices, so the user does not have to go to the server all the time to continue the system but can just do it over the wireless device (in the web browser).
Just to clarify, I know how to send a message out from the server to everybody connected to the wireless network, i just don't know what to do with that message on the devices...
Any ideas or solutions would be HIGHLY appreciated...
Thanks in advance
You can do this a few different ways:
1) Using commercially available Push Notifications (Google & Apple for example). The advantage is your application will work outside of your wireless LAN, but the disadvantage is you're using their platform, which is restricted in its ability and functionality (having designed and built a couple of these platforms myself I can attest to their limitations - they were going for "least common denominator" when they designed and implemented theirs).
2) If your app is only going to run on a LAN (you control the network) you can put your own system together. The advantage here is there is almost nothing that cannot be done (except on iOS which has several limitations related to the topic). The disadvantage, though, is this is a lot of work.
3) Leveraging an existing platform that might have been designed for a different purpose but can easily be used with minimal changes for your own purposes, and offers a nice compromise between options #1 and #2 (this will require some additional backend/middleware servers to add to your mix). Look at XMPP and Jabber as an example.
Once you have this piece of your architecture in place - receiving pushed data - the only missing item is invoking the handset's browser (or browser type component in your own native application) in response to the received payload.
** As possible alternatives it's worth noting that most mobile platforms allow your native application to directly interact with the handset's IMs or e-mails. For example, you can write code that intercepts a specifically formatted IM, with a small payload, and use that as a "poor man's push engine." I have put together little POCs (proof of concepts) for clients using this technique on Windows Mobile, BlackBerry, and Android (not sure what's possible with iOS in this regard) as it's quick and easy.
The hard part is the pushed data (but several available options on how to handle this requirement), the easy part is invoking the browser.
can anybody confirm what are the currently allowed methods for peer-to-peer communications within the Android framework? I need to transfer json strings and I'm currently using SMS which works ok but the problem is that the data also ends up as lots of text messages. I've read Reto Meier's first edition of Professional Android Application Development where he says that the data transfer options were not implemented due to security concerns.
Has this changed at all and how would you do peer-to-peer transfer of data?
Have you looked at Qualcomm's AllJoyn library? It is designed to work over Bluetooth or wifi, so may fit, though if you're connecting over 3G or wider range networks it won't work.
Given the variation and reliability of networks between two remote devices not on the same network, I'd question whether peer-to-peer is the best solution, and would venture to suggest considering using an application server in between, so you could then use Cloud to Device Messaging [deprecated] (perhaps in tandem with Google App Engine). i.e. to send a message the sender passes it to the server, and the server then passes it on to the recipient.
In theory all devices on the net have a unique IP address and can talk to each other, but it's rarely that simple as routers/firewalls are configured differently so you'd need to pay great attention to the ports you use, especially considering many inbound ports are blocked by default for security reasons.
You can simply use UDP/TCP sockets. In a separate thread you set up the server-side listener socket and that's it. Of course your application has to be started first (or should run in the background all the time). Here's an example:
http://thinkandroid.wordpress.com/2010/03/27/incorporating-socket-programming-into-your-applications/
If you also need peer discovery that will make the thing more difficult.
You should also take a look at peerdroid, an open source project available here. I've been looking in to peer communication options from the point of view of having a collection of federated devices (pre-paired, if you like, similar to Bluetooth pairing); this library looks like it may give you the foundation for what you are trying to do.
If you are on your own network (for example a home or office WiFi) then you should be able to query for other connected devices. If the network you are on is not under your control (the mobile network or a public wifi) then the network will have been configured to isolate each device from everything else. In this case you will have no choice but to put a server up to act as the man in the middle. That brings its own architectural compromises - every device has to regularly poll the server or keep a connection open - unless you use Google App Engine which supports push notifications over Google's own infrastructure.
Thanks for your answer ldx but I would need peer discovery as you indicated. Some further research appears to indicate XMPP as a suitable technology and there are now some services on offer, although these appear to be aimed at 'server' to client notifications. There is a good discussion here on XMPP and some more here although it would appear that there are still some issues to deal with such as polling v push, long-running open http connections and battery life. Xtify looks promising, especially their web service. I hope this provides suitable information to others looking at the topic of peer-to-peer data communication.
I installed today from Market, the Yahoo Mail application and I was reading it offers push message notification technique. Indeed it works, as I got exactly the same moment the alert on my desktop computer and my mobile mail client.
How is it accomplished?
There already is another question discussing how to implement push notification without the cloud to device messaging in older system.
There are several frameworks that give you push abillity. They all require a running a small background thread that is polling a server at a very short interval(Bad for data rate and battery) or keep an open connection to a server that is kept alive somehow and the client is notified every time a new message is waiting on the server.
Have a look at the question and maybe choose on of the mentioned frameworks, the frameworks will reuse the same service for all applications that are installed on the phone using the same framework and therefore save battery and general system usage.
Soon, you will be able to use the Cloud-to-Device Messaging (C2DM) system, though it will require Android 2.2 or higher. You might also want to watch the Google I|O 2010 conference presentation on it, which gives a few clues as to how they implemented it.
Without installing the app, setting up my router to capture packets, and doing some packet inspection I can't tell you exactly how they do it. At the lowest level it's as simple as keeping an open TCP connect to a remote server and having the server sending the client a packet when it needs to do something. My educated guess on the specific way they are doing it is either with IMAP IDLE, or XMPP.