We're doing an app where Android and Mac send messages between each other. So far we managed to handle Android <-> Android, iOS <-> iOS and MacOS <-> iOS. We used Bonjour (NSD in Android) for discovery. When it comes to Android <-> iOS/Mac, they discover each other fine but the connecting is problematic.
On Android's end, to start we used Google's old nsdChat, converted to Kotlin and added coroutines to free up the main thread. On the Mac, we used Apple's Peer-to-Peer sample project of TicTacToe. Like I said, both apps work fine on their own OS.
Doing Android<->iOS/MacOS, after we register Android's service, Bonjour on Mac recognizes it. Android discovers the Mac too and resolves the service. After connecting, Android says it connected a client socket and manages to send a message before getting a random symbol back from Mac's side although no one sends it, before closing the connection. On the other side, when you click on Android's "Connect", Mac doesnt immediately shows any signs that they connected, but when you send the message from Android it shows some errors. (so there was something between them)
We're inexperienced in the Networking part, but we suspect it has something to do with the protocols, as it mentions SSL and TLS. Not sure if we have to do some extra modifications to it to work. Is it as simple as adding a SSL socket to Android and that that would fix the connection? There are practically no examples online, and literature is pretty scarce (all are mostly decidated to their own OS's, without cross functionality). I can expand more (add our code, explain further etc.) if there is someone who knows what's wrong/missing.
I am building a Hybrid Mobile Application using IONIC Framework. My problem is that my client is septic of using GCM and APN and asks to get a solution for PUSH notification independent of these two. So something inhouse needs to be build. I have two problem and a few questions about the same.
Can web sockets help in giving the same functionlities that APN & GCM provide.
If I use websockets in some fachion can I achieve PUSH Notification on the mobile application even if the app is closed but user's session persists.
Can we build a PUSH server inhouse? If yes where can I find the specs according to OS of the Phone.
I am well aware of Web Sockets, can it help for the above purpose?
Point me to the specs required to Build such a server and how would I go ahead to configure with Ionic if possible.
I would be using NodeJS, Mongo/Redis with web sockets.Thats what I am thinking please let me know if its otherwise and how to achieve.
Thanks
It's a lot of push service system that some of them is free and some of them are not
Also, you can implement by yourself, you need to have the server to support WebSocket then In application layer you need to connect to server (e.g, Service in android) and create your own broadcast to handle data came from WebSocket
Some point you need to remember :
- Your application always needs to connect to your WebSocket link (battery life issue and network listener)
- You must be sure that application always runs (e.g, when the device restarted [use android.permission.RECEIVE_BOOT_COMPLETED])
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.
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.
I recently learned about the ability of iPhone apps to receive nearly instantaneous notifications to apps notifications to apps.
This is provided in the form of push notifications, a bespoke protocol which keeps an always on data connection to the iPhone and messages binary packets to the app, which pops up alerts incredibly quickly, between 0.5 - 5 seconds from server app send to phone app response time. This is sent as data - rather than SMS - in very very small packets charged as part of the data plan not as incoming messages.
I would like to know if, using Android, there is either a similar facility, or whether it's possible to implement something close to this using Android APIs. To clarify, I define similar as:
Not an SMS message, but some data driven solution
As real time as is possible
Is scalable, i.e., as the server part of a mobile app, I could notify thousands of app instances in seconds
I appreciate the app could be pull based, HTTP request/response style, but ideally I don't want to be polling that heavily just to check for notification; besides which it's like drip draining the data plan.
Firebase Cloud Messaging FCM FAQ is the new version of GCM. It inherits GCM’s core infrastructure to deliver messages reliably on Android, iOS and Chrome. However they'll continue to support GCM because lot of developers are using GCM SDKs today to handle notifications, and client app upgrade takes time.
As of June 26, 2012, Google Cloud Messaging is the preferred way of sending messages to applications running on devices.
Previously (and now deprecated), the service was called Cloud To Device Messaging.
XMPP is a good solution. I have used it for a push enabled, realtime, Android application. XMPP is powerful, highly extensible and easy to integrate and use.
There are loads of free XMPP servers (though out of courtesy you shouldn't abuse them) and there are open source servers you can run on one of your own boxes. OpenFire is an excellent choice.
The library you want isn't Smack as noted above, it's aSmack. But note, this is a build environment - you will have to build the library.
This is a calculation I did on battery life impact of an XMPP solution:
The Android client must maintain a persistent TCP connection by waking up periodically
to send a heartbeat to the XMPP server.
This clearly imposes a cost in terms of power usage. An estimate of this cost is
provided below:
Using a 1400mAh battery (as supplied in the Nexus One and HTC Desire)
An idle device, connected to an 3G network, uses approximately 5mA
The wake-up, heartbeat, sleep cycle occurs every 5 minutes, takes three seconds
to complete and uses 300mA
The cost in battery usage per hour is therefore:
36 seconds 300mA = 3mAh sending heartbeat
3600 seconds 5mA = 5mAh at idle
4:95 + 3 = 7:95mAh combined
A 1400mAh battery lasts approximately 11.6 days at idle and 7.3 days when
running the application, which represents an approximate 37% reduction in
battery life.
However, a reduction in battery life of 37% represents the absolute worst case
in practice given that devices are rarely completely idle.
I recently started playing with MQTT http://mqtt.org for Android as a way of doing what you're asking for (i.e. not SMS but data driven, almost immediate message delivery, scalable, not polling, etc.)
I have a blog post with background information on this in case it's helpful http://dalelane.co.uk/blog/?p=938
(Note: MQTT is an IBM technology, and I should point out that I work for IBM.)
Have a look at the Xtify platform. Looks like this is what they are doing,
Google is depreciating C2DM, but in its place their introducing GCM (Google Cloud Messaging) I dont think theirs any quota and its free! It does require Android 2.2+ though! http://developer.android.com/guide/google/gcm/index.html
If you can depend on the Google libraries being there for you target market, then you may want to piggy back on GTalk functionality (registering a resource on the existing username - the intercepting it the messages as they come in with a BroadcastReceiver).
If not, and I expect you can't, then you're into bundling your own versions of XMPP. This is a pain, but may be made easier if XMPP is bundled separately as a standalone library.
You may also consider PubSubHubub, but I have no idea the network usage of it. I believe it is built atop of XMPP.
I have been looking into this and PubSubHubBub recommended by jamesh is not an option. PubSubHubBub is intended for server to server communications
"I'm behind a NAT. Can I subscribe to a Hub? The hub can't connect to me."
/Anonymous
No, PSHB is a server-to-server
protocol. If you're behind NAT, you're
not really a server. While we've
kicked around ideas for optional PSHB
extensions to do hanging gets ("long
polling") and/or messagebox polling
for such clients, it's not in the core
spec. The core spec is
server-to-server only.
/Brad Fitzpatrick, San Francisco, CA
Source: http://moderator.appspot.com/#15/e=43e1a&t=426ac&f=b0c2d (direct link not possible)
I've come to the conclusion that the simplest method is to use Comet HTTP push. This is both a simple and well understood solution but it can also be re-used for web applications.
There is a new open-source effort to develop a Java library for push notifications on Android, using the Meteor comet server as a backend. You can check it out at the Deacon Project Blog. We need developers, so please spread the word!
Google recently(18May2016) announced that Firebase is now it's unified platform for mobile developers including near real time push notifications.It is also multi-platform :
The company now offers all Firebase users free and unlimited
notifications with support for iOS, Android and the Web.
source
I cannot find where I read it at, but I believe gmail utilizes an open TCP connection to do the e-mail push.
As GTalk is gone from the SDK, it might be a good idea to make a 'standard' push messaging system. That way, only one service has to run, only one extra tcp connection needs to be open. Applications should talk to this service using Intents and should first request permission to send and receive notification from the service. The service should then notify the user a new application wants to send and receive messages. The user will then grant or deny permission, so he stays in control. The application will then register an action + category to the service, so the service knows how to deliver the pushed message.
Would the a good idea or not?
Why dont you go with the XMPP implementation. right now there are so many public servers available including gtalk, jabber, citadel etc. For Android there is one SDK is also available named as SMACK. This we cant say a push notification but using the XMPP you can keep a connection open between client and server which will allow a two way communication. Means Android client and server both can communicate to each other. At present this will fulfill the need of Push in android. I have implemented a sample code and it really works great
I have recently developed http://pushdroid.org its a single application that should be installed on the phone just like google has implemented it in 2.2 this works from 1.5 and is broadcasting via intent.
The problem with GCM is that there is a lot of configuration involved in the process:
You have to add a lot of boilerplate to you Android app
You need to configure an external server to comunicate with the GCM server
You will have to write tests
If you like simple things (like me) you should try UrbanAirship. It is (IMHO) the easiest way to use GCM in your app without doing a lot of configuration. It also gives you a pretty GUI to test that your GCM messages are being delivered correctly.
You can find the docs and getting started guide here
You can find a sample application here
Note: I am not afiliated with UrbanAirship in any way
https://github.com/Guti/Google-Cloud-Messaging--Titanium-/blob/master/src/com/google/android/gcm/GCMRegistrar.java
Its reaily good and working solution for push.
Please try it
They have their listeners which has to be used by you by using their library classes in your code. You need not to bother about pushing. You have to send the message to server server will push the message to the device. They use OAuth. Regarding Protocols, there are two methods using CCS and XMPP. CCS just uses XMPP as an authenticated transport layer, so you can use most XMPP libraries to manage the connection. To send notifications to device you can write code in android app to send as well as your server code. the message sending will be done only by your code. Rest will be taken care by Google Server in GCM case. You can check detail at this link
http://developer.android.com/google/gcm/server.html
Also, for security issues
google cloud messaging security https://groups.google.com/forum/#!topic/android-gcm/M-EevBitbhQ
In case your app is not running then also devices can recieve notification because you have to write code for broadcast listeners. In background it will be listening to server and whenever any message packet will be there it will recieve the message as notification. Android has service you need to not to bother about it. You have only to use those resources using the library class that makes your work easier and let them write if your app is not running then also it recieve notification. Obviously, there would be some listener whick make the app to recieve.Check "Recieve the message" section in this link
http://developer.android.com/google/gcm/client.html
It will acccept request from users also. For GCM it will do. Please check "Send a message"
http://developer.android.com/google/gcm/client.html