We all know that as of Android 2.2 a push notification system exists (C2dM). However, I do not see many developers using it.
In my next project I plan (hope so) to use this system. So before I dig into it, I would like to know what are the bad sides of it? Why people do not use it?
It can't be just because of incompatibility with systems older that 2.2.
Nice question. Here is my 2 cents :
C2DM is still in beta
There is a limit on the number of messages you can send. If you need to send a large number of messages, then you need to explain it to Google and get it approved.
The device must have Android market with one google account signed in.
The documentation is a bit flaky [My personal opinion]. e.g. The signup form asks for the app package name and the ROLE account ID on the same page providing wrong impression that once signed up, the package name is bound to the ROLE account ID and can only receive messages from it.
I don't think people are not using it. Rather I find most developers are very much interested in it and are implementing it. My C2DM post has the most visitors of all my posts.
However the problem might be for individual developers who develop stand alone apps. They may be reluctant to use it since they will require to maintain a server side component to push messages.
[Will update my ans. if I find anything else.]
I think a lot don't use it because
They have no real need for it
So far it isn't very straight forward
Stated above, it is in beta still.
With Apple Push, it is pretty straight forward (on the device side), you simply invoke a call and it gives you the device token. With C2DM, you have to (though you can dig for the google account) prompt the user for the google account, then you have to hope they don't have too many Apps already registered for C2DM (100 limit now).
Server side, I'd say C2DM is a lot easier than push, you simply are invoking a service, with APNS you need to setup pipes, use certificates, etc. It isn't easy for most to do. C2DM is just invoking a HTTP call. The server aspect adds a bit of expense as well, hosting application services isn't always cheap.
I don't see a lot of Apps having the need for it, so far Twitter and Facebook seem to be (Though they may be using something else, I am not sure).
And, it is still a beta service. Do developers want to invest a lot of time in a beta service? Not all do, some will take the risks.
I've used it and I like it, I have it coupled with APNS and have had great success so far.
Related
I've probably spent 150 hours the past two weeks reading up and watching tutorials on mobile app security and authentication strategies for REST APIs, and I've perhaps never been more confused and overwhelmed in my life, lol. I've learned a thousand things I shouldn't do, but I still have no real handle on what I should do.
As background, this mobile app won't be dealing with super sensitive information (no financials, no HIPAA content, etc.), but I still want to secure it and its REST API with best practices, preferably while maintaining my sanity. The API will be private to the app, Python-based, and allow email/password login as well as social login (Google/Facebook). Once users initially register and log in, they should never really have to log in again unless they intentionally log out or want to log in on a second device.
I've looked into both Django Rest Framework and Flask for building the API, and even though the nuts-and-bolts style of the latter seems more to my liking, I've homed in more on DRF since it seems to have better documentation out there with respect to authentication. Among the most helpful guides I've walked through to date are this 2018 Medium article on Guide to an OAuth2 API with Django; and this 2020 YouTube video on Social Logins with React and DRF (using drf-social-oauth2).
However, I'm still left with a ton of questions/concerns:
I've yet to find a guide/tutorial that helps me fully understand how to implement PCKE into the OAuth2 workflow (which seems to be the current recommendation). Is PCKE really standard practice these days, or have I just gone too deep down the security rabbit hole?
With libraries like drf-social-oauth2 and django-allauth + dj-rest-auth, I'm struggling to understand how to separate the authorization server from the resource server (and perhaps a third authentication server, in a PCKE workflow?). It sounds logical enough in theory, but for the life of me I just can't find an understandable model for turning that theory into reality. I'm surprised I don't see more people having the same sort of confusion, so I wonder if I'm just missing something completely basic.
The YouTube tutorial I linked above seemed pretty strong, right up until it started embedding the Client Secrets directly into the (React) app, which everyone (including the guy on the video) seems to agree is a huge no-no. I'm guessing those secrets belong instead in the code on the Authorization Server (well, rather, in the environment variables of the server), but, again, it's not clear to me if libraries like drf-social-oauth2 facilitate such a setup.
Have I been right to focus so much on OAuth2, or should I have been learning more above OpenID Connect (OIDC)?
That's just the start of my confusion. Even once I figure out the above and get my API to successfully grant tokens to my mobile app, a whole new set of questions arise:
Since I want my users to stay continuously logged in, what should my token management strategy be? Should I even bother with refresh tokens, or is there a use case for issuing access tokens with no expiration date?
Is there a strong argument to be made for using JWTs instead?
Is it (relatively) okay to store tokens in shared preferences on an Android app?
If I do rely on refresh tokens, is there a general strategy for how long access and refresh tokens should each last? And how/when in the app workflow should tokens be refreshed? (NOTE: This is the question I've done the least research on so far. I mainly include it here to underscore how lost I've gotten in trying to figure all this out.)
And then the more existential questions:
If I implement this all perfectly, how much am I actually accomplishing? Like, even with client secrets hidden away in an authorization server and PCKE in play and all that, someone who roots a phone and decompiles my code and can mimic user registration and get a token and make API requests, right?
In other words, am I even asking the right questions?
Anyway, apologies for the lengthy confusion of this post. I think I'm probably 70% hoping for answers, 20% looking to vent, and 10% hoping for moral support. It'd be great if someone can maybe at least let me know if I'm on the right track; or point me that direction if I'm not. Thanks!
[Disclaimer: I looked around at the other stackexchange websites and couldn't find a perfect place to post this question, so i'll post it here. i'm happy to take it down and place it somewhere else if you know where this is supposed to be. please do not downvote because of that]
Currently we use a 3rd part tool (HockeyApp) for monitoring crash reports on an android app. They have an API that i can use to query for crash reports. I want to be able to have an automated crash report system where if certain conditions are met, i get an email (or maybe a phone call). For example, say i get 9001 crashes within an hour, i would like to receive an alert.
Is there a tool for doing this already? (crash monitoring for android, using hockeyapp is highly preferred)
I looked into rolling out my own Ruby on Rails app for doing this, using ActionMailer apis. has anyone had any experience with this and recommend it? Or what would be a better approach? (If i have to roll out my own tool, dev time is of the essence)
What kind of tools do your/other companies use for this kind of situation (crash alerting/pager duty)?
You can continue to use HockeyApp and set a webhook when a new crash was created. This webhook can point to your own backend or to a service like Zapier, which can then trigger a PagerDuty, email or all kinds of notifications.
You can look at crashlytics. They notify by email and send daily stats on email. For detailed stats you can visit your account. But this service is only for crashreporting.
I don't know if this is even possible, couldn't find anything usefull on the internet.
I wanted to make an app, that me and some of my friends could send a message trough "my app" and that everyone who has that app, receive the message, without using a phone number.
So basically, same as WhatsApp GroupConversation, but then without using a phone number.
Is this even possible?
If it is possible, could you put me on the right track to start with.
Hope I am clear enough, if not, tell me :)
Edit:
This just pops up in my head (didn't look on internet yet), but what I want, is a kind of a shoutbox.
This is possible, in fact WhatsApp does not use your phone number for this at all.
You simply provide your phone number to asure a unique ID and proof that you are indeed in possession of this phone with the validation SMS.
From there on, your phone number isn't even used anymore.
You can go 2 ways with this;
Create a simple webservice with a database on which you just save and request messages. Maybe make a little difference between get all or get latest message. Anyone, hooking into the group, can just fetch the same data. With the use of GCM push notifications, you can make this pretty instant.
Use XMPP, which is a chat protocol kinda all the chats use. Whatsapp, Google talk, FB messenger... This will provide you with instant messaging just like any other chat app or program you know.
Option 2 is by far the best in final functionality, but be warned that XMPP is quite complex and error prone.
You can look into the asmack and asmackx libraries for Android, which will give you the basic functionality with ease. Going a bit deeper, you'll have to dig into the protocol and really get to know it though.
ps. For both you'll need your own server, however with asmack(x) you are also allowed to use Google's Talk servers for free. Communication will go through your Gmail account. Basically with this you just make your own version of Google Talk.
It is possible by implementing server-client architecture. Your app will use a common database for all the users. whenever an user install your app, he will achieve an unique user ID. if anyone uninstall it, his id will be destroyed. You can track the users from those ID in database. You don't need phone numbers.
i am developing app that would receive data from server any time. i have searched some mechanism to do this
C2DM: but i require Google account for each device on which app will be installed
MQTT: but it is a Third party and a person for which i am developing does not trust third party because he says in future may be that third party start charging for their service or even stop their service.
Pooling: which is again not a good idea because it consume lot of battery
Is there any better way of doing this..
i have posted similar question before but did not get a satisfactory answer and i am still confused...
The most straightforward and reliable way to implement this is by using C2DM. Requiring a Google account on each device shouldn't be a big deal, because users need that anyway to access the Android Market. The only major exception to worry about will be Kindle Fire users.
This blog post has a good listing of alternative ways to roll your own push service: http://tokudu.com/2010/how-to-implement-push-notifications-for-android/. However, you need to think if the extra effort (including maintenance) is going to be worthwhile.
I have developed a simple two player chess game in android to be played using Bluetooth. I want to extend it by making it possible to be played through internet. whenever a player makes a move, the move should be transferred to the other player via internet.
How to make this possible?
I have heard of C2DM mechanism.Does that suites the scenario i described and is it reliable?
Thanks:)
Yes, C2DM is ideally suited to this type of game. This is what I am using for my own game (http://www.chesspresso.net) which is a correspondence chess client for android.
Things to consider when using C2DM:
You don't send the info to the devices, you notify the devices that a move has been made. You don't use C2DM to transfer data, you use it to notify that something has changed.
Its available for 2.2+ Android, which is the majority of devices. But if you wanted to support older devices you'd have to consider an alternative. I am using polling for older devices.
You have to request for developer access, then once your app is ready you have to request production status. If you don't do this you'll hit the developer status quota very quickly once its released! They are very generous with production quota, but you have to explain what you're using it for and it also can take a few weeks to get accepted!
Your users will have to have a google account that is authorised, otherswise C2DM won't work. Most users will have an account associated with their device, but some don't so this means that you'll possibly want to validate for the presence of an account to notify the user.
Its reliable, but every now and again a device will have to wait for the message. Sometimes a few minutes. Usually its instant.
Hope that helps!
UPDATE:
C2DM has now been deprecated, and replaced by Google's GCM.
Also, I strongly suggest looking at other options as tying yourself down to a Google specific API means you won't be able to support external marketplaces. For alternatives, I am currently evaluating Amazon SNS and I will also be looking at Urban Airship. There are possibly other alternatives I have not considered evaluating yet.
UPDATE:
Evaluation update of non google based push notifications:
Amazon SNS is just not a project for this task and Urban Airship for the vast majority of apps is too expensive. Unfortunately all the other alternatives are all very expensive also, especially if your app (like mine) relies heavily on push.
A good way of doing that is using a simple direct TCP connection between the peers.
If you're new to socket programming on Java, try this:
All About Sockets
Another option is to use some sort of IM as a communication medium for app. For eg. Use Asmack to connect to XMPP Im like GTalk. Prompt user to create an account there, for your game.
And use it to send and receive commands via IM. This way you won't need to setup your mediating server.
This works if user knows who he is playing with. To collect the user data and let them search for available players, you still need to setup a server. IRC chat room may be an option to avoid this also.
GTalk was just an example. You can use any IM or IRC also.
C2DM it's not design to transfer informations, even if they are small like "horse in b4" or things like this. It's designed to inform the device of something, maybe a newer version of a document or more articles on a website.. Stuff like this.. It's not designed to communicate device to device. And also it may be not fast enough for a real time chess play.
You should look for a more traditional way of communicate via internet or to search for some libraries (I'm pretty sure that something exists..) that will help you.
IMHO, C2DM is exactly the kind of thing you would want for a chess game; to be notified when the oppo has made his turn (which may be minutes /hours / days later ?). I have discussed my game with a few google android devs and they've stated that C2DM is ideal for this. You'll need to go via a centralised server though (well, not essential but very advisable) as there may be issues with resync'ing game state etc. Worried about "hitting the limit" ? Well, for a start my c2dm acct is restricted to "just" 100,000 messages per day. I guess you're buying the drinks if you hit that !!
Chess is often played by email. You could do that.
Of course, any centralized/federated messaging system will work.
What might be better for your use is to add a jabber client to the application and have the program generate an account name that is used for automated messaging. You could host the jabber server or generate the accounts on a free provider.
Google App Engine if you know Python or Java.
Alternatively there are two web app API styles in wide use today: SOAP XML and RESTful web services.
If you know RoR I would recommend using JSON/REST, because you can just use Phusion Passenger with Apache to deploy your app. Free, extremely easy, and makes your server very reliable.
You could, and I only mention this because my friends do this all the time, use twitter as a server between the games.
I also found a lib called mages which looks quite promising.
Good luck.
I did this for my online 2D rpg: http://developingthedream.blogspot.com
Basically, use a middle-man server to co-ordinate data between all your clients.
You simply open a socket and communicate with the middle server and it takes care of passing on the information to any other connected clients.
I wouldn't recommend C2DM because of the message limit, and because the latency is still to big. Using your own server you can optimize it, plus you'll be the only one using the service so your data will be delivered faster.
I think that C2DM is not right way for playing chess because there is no warranty that messages will be delivered. You need more reliable way for data transfer