I want to create a chat application using service, Here service should listen to new messages, notifies user if new message arrives from server and then when user clicks on notification, it shows complete message details. Again if user wants to send a message, it has to send the message back to user.
Here I want to start service only once and run indefinitely, But when activity starts it's starting service each time.
consider server as chat.socket.io
Please tell me how to achieve the solution. Thanks in advance :)
If the service is only loaded already, it won't load it again. The intent will be delivered to the same service. So you don't have to worry about that.
Also, you might want to use Google Cloud Messaging instead of making services for chat like notifications.
Related
I'm working with Firebase Cloud Messaging. I have a couple of question I was not able to understand from the documentation:
Android: Lets suppose the app is closed (not backgrounded: closed). If I send a notification with also the data payload, this data payload is passed to the activity through the Intent Extra
Messages with both notification and data payload, both background and
foreground. In this case, the notification is delivered to the
device’s system tray, and the data payload is delivered in the extras
of the intent of your launcher Activity.
What if the user does not tap on the notification? Is the data payload lost? Is there a way to retrieve it?
iOS/Android. Lets suppose the user disabled the notification and I sent a notification to the client: is there a way to retrieve (pull) the notification at the application start?
Thanks very much
If the app is closed (not in background) the onMessageReceived method is called when the notification is received and there you can retrieve the data payload with remoteMessage.getData().get("key_for_parameter"); where key_for_parameter is the name of the parameter that you send in the notification. This method is called even if the application is closed. However, take into account that the "onMessageReceived" is called only if you omit the "notification" param in the notification (look this post)
So once you have the params in the onMessageReceived you can look for an strategy to use them in your application like storing in the DB and you are not going to lose the data if the user does not click on the notification.
if your app in background, Firebase will not trigger onMessageReceived(). Why.....? I have no idea. In this situation, I do not see any point in implementing FirebaseMessagingService.
According to docs, if you want to process background message arrival, you have to send 'click_action' with your message. But it is not possible if you send message from Firebase console, only via Firebase API. It means you will have to build your own "console" in order to enable marketing people to use it. So, this makes Firebase console also quite useless!
There is really good, promising, idea behind this new tool, but executed badly.
I suppose we will have to wait for new versions and improvements/fixes
I am wondering if I can use parse as a notification service for the backend instead of to notifying the user. I am wondering if sending a push notification can start a background activity to run some code in the background. Would this be possible or should I try a different service. If so, could you recommend any other services and/or solutions to the problem. All of the other services seem to be the same and the only other solution I can think of is scanning the server every little while in the background. I am afraid that will use too much battery life.
Sure, you can do this with a combination of push notifications and their proper handlers.
Send the push as a silent push. As noted in this SO post, silent push reception is the default- you have to add extra code to interact with the user.
When you receive it, process it appropriately to run background code instead of interacting with the user. You can read more about how to receive and process a push in the Parse.com Push Guide for Android.
I looking for a way to read notification message automatically, and displaying it, on receiving a message from the server, when the activity is on the foreground, just like a chat application.
I got GCM working, and i am able to create a notification when the client app receives a message from the server.
anyone guide me how to get this done?
If I understand your question when the server send the device a message and your application on foreground u want to get the message into your application and avoid from create a notification.
when you get a call to your GCM Receiver you should know if your application is on the foreground.
look here for know if the application in background/foreground.
now, if the application on background create notification else don't :)
hope it's help u.
I'm trying to build a GCM notification listener, which will basically use the notification to flag the user that some operation should be made (which involve communicating with my remote App-Server).
I assumed that I should create a UI-less application running on the device's startup and listen to the GCM notifications and issue the internal android notification. When the user opens the notification an activity will be opened which will do the rest of the job with the remote App-Server.
Looking at notification examples it seems to me that I may be missing some basic understanding since all te examples which I had found use a UI application to manipulate the notifications.
What do I miss?
The common use case for handling of GCM messages in Android apps is as follows :
Your app registers to GCM upon startup and sends the registration ID to your server.
Your server sends a GCM message to your app.
You app receives the message in a broadcast receiver, which usually starts an intent service.
The intent service usually displays a notification to the user.
The user taps the notification, which starts an activity of the app.
You can see this use case implemented in the official GCM demo and in many other examples.
The fact that the app you wish to develop has no UI doesn't prevent you from implementing the exact same use case.
(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?