i want to develop an application that will receive PUSH notification from
server. what is the best way to do this so that i dont have to write so much
code to implement this. I am looking for any commercial service that can do
this for me. Can you please suggest me some good api or service
Urban Airship (urbanairship.com) provides an API to do this. However I would recommend C2DM.
Google's c2dm provides nearly this http://code.google.com/android/c2dm/
Even though there is no official push api supported
Yes, here is a good tutorial with all code you need:
http://blog.boxedice.com/2010/10/07/android-push-notifications-tutorial/
http://tokudu.com/2010/how-to-implement-push-notifications-for-android/
Google's C2DM can do this very neatly. Its available from Android 2.2+. Here is a tutorial on how to do it by Vogella. http://www.vogella.de/articles/AndroidCloudToDeviceMessaging/article.html
If you want more control and run the service along side your server, you can try OpenMobster Mobile Cloud platform's push service.
It provides the following functionality
A platform agnostic Push API (works on Android and iOS)
Queuing (If you are not available, it will deliver later when the phone comes online)
Should get you up and running quite fast. (No certificates, device tokens etc etc). Just a secure persistent TCP connection to the OpenMobster server is needed (the framework establishes this when the service is installed on the phone)
For more on the platform you can checkout: http://code.google.com/p/openmobster/wiki/PushFramework
btw: The platform also supports Device-To-Device messaging between other devices in the systsem (applications could be chat, instant messaging etc)
D2D Framework doc: http://code.google.com/p/openmobster/wiki/D2DPushFramework
Related
Layer looks awesome for mobile development, however, in case we need to build a web to mobile chat, the web SDK is not yet available. Can we integrate it with parse to do so? Or maybe some other solution.
The Web SDK is currently in Early Access so it's available to be used. You could potentially use the combination of the Platform API and Parse cloud code to do a partial chat from web to mobile in the meantime, but it depends on your use case.
I do not know Layer but I think(hope) you can send http request (REST api) to parse and trigger the cloud function. So the cloud function can send your message to your mobile client as a push notification. After that, the only thing that you have to do is handling the push notification cases such that when the app is opened, when the app is closed or when the app is on chat screen. Hope this helps.
Regards.
Another good alternative is Hyphenate. Similar to Layer, but Hyphenate supports both Mobile and Web SDK with rich features and very reliable services.
Parse is good, but shutting down soon, an good alternative is Firebase by Google.
https://hyphenate.io/
https://github.com/HyphenateInc/Hyphenate-SDK-Web
I have visited many blogs and questions looking for a way to use android as a client and nodejs as a server for my app. I came up with a solution that is to use PhoneGap like frameworks so that it could act like native but is not in reality. I need to use native android sdk and connect with NodeJS server (using SocketIO) to create my app. Is there any way I could do this?
P.S I want to know that while I set up by GCM can I pass my IP and port that I have created in my socket.io file to the GCM?
Cordova (hence PhoneGap) allows you to use most of the hardware APIs. PhoneGap nowadays is just a build service of some sorts.
The Cordova website and plugin store explain all the details. But t WebSockets are just an upgraded protocol or feature of TCP. Any newer technology supports it without any dependencies, but in dependence of the network you're traveling in.
Without diving deep into the code here at socket.io-website, I reckon that the initial build of your Cordova app is a WebSocket implementation to the server. So you got everything bootstrapped already.
What this tutorial doesn't explain is how to connect to the server. But read it up here.
I have no prior experience but Google Cloud Messaging seems not to be in the scope of the problem of socket.io. Once you have a connection to the socket you can send to the client whatever payload you want and might or might not need GCM anymore. If you need to send stuff via GCM read up on the the GCM node module.
Passing IPs around shouldn't be much of a problem since you're are running a public service anyway. You'd need to secure it anyhow of course.
What is the easiest way to implement a simple app which does two things:
receive push notifications (new messages in user's inbox),
open a page on my website in a webview or web browser.
It would be best if the solution was portable among iOS, Android and possibly other mobile systems like Windows Phone and BlackBerry 10, but I'm happy with separate solutions, if it's the only way to do it.
I suggest that, checking out Parse apis for this task.
There are solutions like http://xtify.com/ or http://urbanairship.com/products/push-notifications/ that provide an all in one package across platforms but I don't know the quality of service or which one would be right for you, some research on your part will be necessary if you choose this path.
Or you could implement it yourself but it will require your own server. The server would notify both Androids C2DM And Apple Push Service at the same time. You will have to implement the client side on each.
For iPhone here's a good tutorial for setting it up http://www.raywenderlich.com/3443/apple-push-notification-services-tutorial-part-12
For Android http://www.vogella.com/articles/AndroidCloudToDeviceMessaging/article.html
You register your app with both services then sends the push keys to your server. With the keys the server can then notify both platforms respective push services to send a notification .
I can't really help with the server setup stuff as its not my area of expertise but this is how we implement push notifications for the apps my company makes.
I'd recommend a Phonegap (Cordova) app and UrbanAirship for the notifications. You can get a free account with that. It's relatively easy to implement too.
As for the browser, I'm not sure exactly what you want it for. Could you elaborate and I'll post a response.
I'm looking for a client version for android to use the appengine channel API on my app. I've seen some other people developed, but none of them seems stable. Some have to use a web view for the JavaScript, etc. I don't want something like that.
Any resource about it, or any wise approach I could use?
By the way, I'm using appengine with python.
There's and official C2DM service to receive updates from the cloud on mobile devices, which works in a way similar to channels, by opening a socket and listening for updates. Is there any reason why you don't want to use C2DM?
I'm currently writing an Android application that should be able to receive push notifications from another application hosted in Google's App Engine.
Since I can't use sockets in GAE, I though maybe using XMPP over GTalk server would solve my problem. But that way the Android Application would be connected to the users Gtalk account and thus showing the user as being online, when in reality the user is not.
Any way of achieving this kind of communication without showing the user as being online, and without asking the user to create a separate account?
Or any free push notification alternatives?
EDIT:
I'm targeting 1.5+ Android devices so C2DM isn't an option.
Thanks!
May be you can use the channel API: Building real-time web apps with App Engine and the Feed API
Not sure about the exact requirement of your app, but.. perhaps C2DM can be an alternative?
http://code.google.com/android/c2dm
I've found the PubNub service (http://www.pubnub.com/).
It enables push notifications through API's on several platforms (PHP, Ruby, JavaScript, Java, ...).
It's a paid service, but provides a free daily quota.
Although it's not the ideal solution to my problem, it'll have to suffice until some Channel API documentation comes out.
Thanks to all of you!
Why are you shying away from HTTP/JSON? Might be useful to know why you discounted the obvious solution...