I'll start with the project idea I have in hand:
We are trying to make a simple application that requires the sending of messages between phones. Say there's phone A and phone B, and both have installed the application. Phone A sends a message to B through the application, and B receives it. B can do the same and send messages to phone A.
Since we want to target from Gingerbread and up, Wifip2p from google is not possible since it requires API 14 and up.
I read about GCM , and while I do understand the concept there's something I don't quite get yet. Every instance of the application registers with the server, the server then saves the ID so it can later use it to communicate to the GCM, and the GCM can use the registration ID to deliver the message to the phone.
What I don't understand is how phone A will be able to know the ID that corresponds to phone B, in order to tell the server to deliver the message to phone B.
I'd really appreciate the help, thanks.
EDITTED
Based no the answers, I think I'm not managing to express my question properly.
I understand that this systems bases itself in three factors: a server, GCM, and your device.
The device registers with the server, and the servers saves the device's registration ID which it will, later on, use to send it to the GCM so that the GCM can then send the appropriate message to the device.
What I don't understand is how the following procedure is carried out:
PhoneA wants to send a message to PhoneB, so phoneA would send this message to the Server, and the Server would later pass it on to the GCM who would then pass it on to phone B.
This explanation is nice, in the abstract vision of it all. But, how does phoneA tell the server that it wants the message delivered to phoneB. How does phoneA even know what ID corresponds to phoneB?
Hopefully this clears it up.
Phone A doesn't need to know the ID of phone B. Just make a method in your server that delivers a list of clients you are interested in (phone B, C, D, etc) when you connect.
When you send a message to your server, include the handle of the phone you want to deliver to. This should not be the other phone's GCM registration ID in my opinion, but rather a unique handle generated by the server.
For this to work, you need to either implement a your server -> phone A communication or use GCM to deliver the list of clients as a notification.
Related
I have a Cordova app that receives secure messages from a service provider, through our servers, to an app installed on a phone by the user. However, the app may be rarely used (in the order of 12 months or so). In the event that the provider needs to contact the user we currently send an FCM notification. The problem is that because we don't want to place any drain on the user's battery for a service that they rarely use (although is extremely valuable) then we don't try and run anything in the background - which means that according to the firebase document Lifetime of a message the message will be discarded if the user doesn't open the app for one month.
The referenced doc states:
If the device has not connected to FCM for more than one month, FCM still accepts the message but immediately discards it. If the device connects within four weeks of the last data message you sent to it, your client receives the onDeletedMessages() callback. The app can then handle the situation properly, typically by requesting a full sync from the app server.
How are we supposed to inform the user that there is a message for them?
I understand why such a precaution can make sense, but what options exist to allow us to receive the notification causing minimal impact on the users' device?
We are developing a VoIP app and we want to switch to the Tokbox library.
Ours is like a telephone app just like Viber but for a specific audience. We need the app to behave like a telephone app. The user makes the call, the receiver hears the phone ringing, picks up the call and hangs it up when done talking. I could find a lot of resources on Tokbox online (for Android and iOS) but I couldn't find much info on a telephone with the library. Can anyone point me to the right direction or explain things a little bit.
Thanks in advance.
To implement a mobile telephony app (like Viber) where user A calls user B you need a couple of extra pieces in addition to TokBox platform.
First you need to make use of standard Apple&Google push notifications to initiate the call to B. For example you can use Google's service [1]. Typically A will send a HTTP request to your server to initiate the call to B and your server will use Google API to send the push notification to B.
At the same time your server should generate a TokBox sessionId for this call and send that sessionId and a token back to user A. User A can use them to connect to the TokBox session and start publishing while waiting for B to join it.
When B receives the notification then you can alert the user (ringing tone) and present any UI you want to him. When B accepts the call you can make another HTTP request to your server to get the sessionId and token for the call (that sessionnId and token could also come in the initial push notification) and join it.
At that point you have both users (A and B) connected to the same TokBox session, publishing audio&video and subscribing to the other stream, so you have a bidirectional audio+video call.
[1] https://firebase.google.com/docs/cloud-messaging/
There is a scenario where I have to communicate from one android device to another android device (Far Away). But without using any server or sms service. Although I do have an active internet connection. I found a way through GCM, as GCM service provide data upstream as well as data downstream.
I want to know is there anymore way of doing this ?
You need a notification service, and google has something like that for us...
how does this works??
Take a look at the image below,
you need to register your android app in the google service, and your web interface will need an id, so everytime you want to push something to the android, your web interface instead will push it to the google server with the Id of the app, then google (no matter how) will localize your app, and even if its not running, they will get the notification,
behind the scenes there is a couple of thing that you must do, bu nothing like launching rockets from the NASA.
I will suggest to take a look to some tutorials
in order to start with the registration of your app, get the api key etc etc..
In your case
you will need the id of the other phone, so you can push it data.
I am creating a app in android 4.0.3 i.e ICS version, which connects to the server when client gets login into the app.I am trying to get status of an client when he gets online or offline through server & seen onto the app screen.I am unable to proceed. Can anyone say me:
Is it possible to get the status of an user through server?
1-- How to proceed for first step...?
2-- How should I get a response from the server that the client is connected & viewed to other client example - when we login into skype our status shows available with green radio button, In same way how can I get it.?
It ll be very help full, If anybody guide me.
Many Thanks..
I'm assuming you're trying to develop a chat app ?
If this is the case, try using an XMPP library. XMPP is widely used for chat apps, including Facebook chat (and Google talk I think) and there are plenty of open source libraries available.
Otherwise, if you only want real-time notifications as a part of a bigger picture, try using push notifications. Google supports Cloud to Device Messaging (C2DM) for android. It allows to have push notifications to a specific device without you having to deal with persistent connections, battery and CPU use .etc.
C2DM approach comes down to this. When a client connects to your server, get a list of his friends and their 'C2DM IDs' and fire a C2DM push to their devices. This push is delivered to your app, and you can respond to it by firing a notification, or update UI .etc. (Your app doesn't necessarily have to be running. Push notification is delivered via a specific broadcast, and your app can register a receiver for it to wake up.)
Keep in mind that there is a quota for C2DM messages per device, per app and also a limit for the payload per message. So you're not supposed to send massive files via this. Just a notification to your app, so it can call your server and get an updated list, instead of polling.
You can get more info on C2DM and code samples here. https://developers.google.com/android/c2dm/
Hope this helps.
You may have moved on, but I'm posting for anyone who would run into this one in the future.
Firebase is a good solution to use in this scenario, if the app is always running when you want communication to happen. (It will not wake up your app as C2DM/CDM does, unless you have a service running all the time and still wouldn't wake up if the device is asleep... AFAIK)
It may be useful for some scenarios, but may be not for a chat app as you want the device to wake up when a message arrives.
Note that they have limitations on the free subscription though.
(The following question is for mobile platforms in general (iPhone, Android, Blackberry))
We are integrating chat functionality into our existing application. I designed the system with a .Net web service and Sql Database to keep track of chat messages. Everything's working fine so far, when the chat window is open.
I need a way to notify the user of a new message when he/she is not currently viewing the chat screen (meaning either the app is not in the foreground or they are in another section of the app (not the chat screen).
Obviously, push notifications would be perfect here, but I'm not sure when I should be sending pushes.
How would the client sending the message know whether or not the other guy is viewing the chat screen? Should I just be sending pushed with every single message and have the receiving device decide whether or not it needs to pop up a window or display something in a nofication bar?
It seems like overkill to be pushing every single time a message is sent. How is this normally done?
Any ideas at all would be greatly appreciated.
Thanks.
First and foremost, keep in mind that your server will act as the broker for all messages passed between different chat clients. Here's how this could work:
User A initiates a message for user B
Message gets sent to the server.
Server determines that this message is for user B.
Server initiates a push notification and delivers the message to user B.
Now why would you need to push every single chat message? Because the only other way for your users to get notified would be to poll your server for new messages. Constant polling (at whatever rate you determine) is extremely bad in the mobile realm due to limited resources (battery, networking, etc.)
In a push notification scenario, it is up to your application to handle the logic of whether the user is notified on receiving a new message. What this means is that when user B receives a new message from user A, it's up to you to decide if you wish to notify B (i.e. bring your app to the foreground) or not. In either scenario, you want to use push notifications instead of polling.
On a similar note, user B does not necessarily have to know that user A's application (your app) is in the background which is why you will need to handle that logic (within your app) appropriately.
Push notification normally is applied to the application if it is not in the foreground. It is a way to wake-up the application to handle a new transaction from the server. Basically, a push notification is to be done if the client is running in the background and a new message is ready to be fetched from the server. As long as the new message is not fetched, if other messages arrive on the server, a push notification should be sent to the application.
Push notification is not necessary if the application is still running even if the user is viewing other screens of the application. It is however important that a thread is handling the connection to the server which is "patiently" waiting for transactions from the server.
One question, what protocol are you using for the messaging?.. Is it OMA IMPS protocol?