I want to remotely change few SharedPreference settings on my App.
I have been able to achieve this using SMS messages and corresponding broadcast listeners.
Now I want to use my app web server to do the same over the internet.
My question is, is google's C2DM the right choice for this task or it it an overkill or may be even unreliable for this job?
The objective is very simple. Send some kind of notification to the app that triggers a broadcast receiver. Parse the message received and based on the keyword in the message take some action(change SharedPreference settings in this case).
Any pointers?
C2DM does have its quirks, but for this purpose, I personally think c2dm is a good idea.
However you mentioned "unreliable" - one of c2dm's major drawback.
In this introduction, it's clearly mentioned that:
C2DM makes no guarantees about delivery or the order of messages.
Although for the "overkill" part, i can guarantee that using android's c2dm architecture is way more simpler than implementing your own push notification implementation over persistent tcp/ip (check out this article).
C2DM is used for notifying really small messages like new offers,update version released etc. C2DM is loosely based for just updating app from market(now Google play), as far the reliability matters, it will not be the best choice to do it cos you have to sync your app with user's Google account, ultimately what your app server will do is, it will send message first to C2DM server and then C2DM will send the message to you and C2DM is the central for all other apps too like you, So it may happen that your message can not reach to mobile if something goes wrong to C2DM server. So its better not rely on C2DM and find your own way for push notification of your app such as when application starts it searches for any update or anything via service and do needful on based of service's response
Related
I am developing an application that will get some data from the server e.g. live feeds. It will be a multicast message. I just want to know if whether GCM is reliable. I don't want the notification to be on time, if the is a delay of about 1 hour then also it is OK for me. Should I try GCM or go for Web Socket. Does any popular android app use GCM? If yes then please do mention.
Neither GCM none other similar services like iOS Push notifications are 100% reliable, but those messages are usually really fast and they always work, so it depends on the level of trust you need. I'd personally go for them.
I have used GCM before, and in my experience it is very reliable.
If at all i faced any issues, they were in upstream messages (i.e from the device to the server).
I would say that you will get much better performance than 70% delivery with a one hour delay.
Go for it! :-)
I want to implement a chat application. But I have a few questions, which I could not solve by searching the internet.
My requests are:
Of course I can address each device individually from my server (makes sense for a chat app)
I can create a time delay between sending and receiving a message
The application should not require a registration (this is not a MUST, but would be nice)
I wonder if GCM (Google Cloud Messaging) is the appropriate solution for me. I have not yet worked with it, so I would like to have some help. Will I run into troubles with this? And most important: Is a registration required?
You will run into troubles surely, GCM is not for creating chat applications . You will need this XMPP.GCM is kind of thing used for broadcasting messages,which does not even guarantee the delivery of messages instantaneously i.e real time which you will be requiring.
SEE THIS TOO: Android and XMPP: Currently available solutions
I am relatively new to Parse, and am finding that push notifications can take anywhere from being instantaneous, to taking a day or more to deliver. I can see the notifications registered in the admin panel immediately in every case, so issue is not on the send side.
I am developing on Android, but need the cross-platform capability of Parse so I can support iOS.
Well you should prefer to use Google Cloud Messaging GCM for push notifications rather than using 3rd Parties like Parse etc. GCM is super fast and i am using in all my apps which are live.
Here are Good Links to Startoff with GCM
http://developer.android.com/google/gcm/index.html
http://www.androidhive.info/2012/10/android-push-notifications-using-google-cloud-messaging-gcm-php-and-mysql/
I am aware about the parse notification.I am also having same problem,but the problem is because of the Wifi.
It means when you send an parse notification from panel it would take some time to deliver because of wifi is enable on your mobile.
So go with your mobile 3G connection it works within less time.
Turns out, Parse has a GCM handler, and it also needs to be added to the manifest. Otherwise Parse uses its own service, which can be very slow. Enabling GCM, I now have the notifications arriving in under 20 seconds.
I have a few apps which are dependent from server side. From there are getting they data.
The server side needed development anyhow. Server code hosting is done in our side. The client-server communication, structure is already up.
In this state we need to implement a push notification:
If there are new data on the server than it should be visible at user somehow.
The "standard", recommended way now is to use Google Cloud Messaging System.
I have a few concerns about it:
Requires client and server side coding and bind they technology in our code. And not this is the biggest:
Is changing relative often the technology: deprecation, and need to change our code. This is the biggest. Previous of this was something other and before that something other. In 4-5 years 3 changes is to much.
I am thinking to implement like this:
I will write a broadcast receiver listening when the user got internet connection.
On Internet connection it will check the server to see if it has something new or not.
If is does than it will show a notification and job is done. If the user clicks the notification it will start the app and download the playload.
I will use an alarm schedule, to check the server again after 1 or 15 min or 4 hours, whatever. There it will be no service running in background, just receivers!
The register - unregister functionality should be done in app.
Communications to server in plus:
registerMyDevice(IMEI)-or username+password
unregisterMyDevice(IMEI)
isSomethingNewData()
When the client comes to server it will send his IMEI anyhow to identify, so the server will know for who need to send push.
Anybody can take Google proposed solution and prove it is better in this case than our in-house solution?
The main problem with that solution is that you'll add one more background process that shortens the battery life. Imagine what would happen if many app developers choose to implement your solution. A user that installs several such applications will have their battery emptied quickly. With GCM, one connection is maintained with one server, and that connection serves all applications on the device.
I believe integration with GCM is simpler than developing a push solution by yourself. The API changes always come with improvements (original GCM allowed multiple senders while C2DM didn't; the new GCM gives you user notifications and device to cloud messaging), but even if you don't choose to work with them, the old APIs still work (even if they are deprecated).
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.