I develop client-server app. Android client get real-time text data from server.
While app still active(activity on foreground) data show on screen.
Background service connect to server and sending intents, BroadcastReceiver on activity receive it.
When user leave activity(activity comes into background) BroadcastReceiver detach and service only show notifications about new data.
I have 2 ways next:
1) Service will save all new data to container, user after returning to activity open this container and draw data. In this case my question is: What the container should i use? What's thread-safe container use to communication beetween activity and service?
2) Service don't worry about save data just notify, but user after returning to activity should send request to server and get all data. In this case user maybe wait a long time.
Second way more simple than first, but force user wait isn't good.(async don't solve it)
What are you using in your projects? I think this is common case, but google doesn't help me, probably my search was bad.
Related
Let's say I'm making a chat application.
I have an activity FriendListActivity (that shows the list of friends)
this activity also has a Socket that listens to every message that comes from the server.
I also have a ChatActivity that's called whenever I click at a friend within FriendListActivity.
My questions about it:
what happens to FriendListActivity attributes when I call ChatActivity from it? Do they die?
How should I place those activities somehow they work together and the atributes don't die?
I assume that by 'called whenever I click at a friend within FriendListActivity' you mean that you will create an intent and start the new activity, ChatActivity. If this is what you plan on doing, then the answer to your first question is no - FriendListActivity attributes (and any state information) is maintained in that Activity's class (FriendListActivity). What happens is that ChatActivity now becomes the 'top-level' activity and is presented to the user, while the FriendListActivity will run in the background.
See http://developer.android.com/training/basics/firstapp/starting-activity.html for a good description of how to start new activities and communicate information between them.
Generally, for chat applications, you will create a Thread that handles incoming messages (usually by listening on a socket associated with a server). This thread will block on a socket read operation (the exact function name/API will depend on your particular implementation) and wait for the server to send it data. When data is received on the socket, your thread will put that data into some kind of queue (like an 'unread messages' queue) or call a function in the main application to handle the new message. Keep in mind that the UI can only be updated by your application's main thread, so you'll need a way to exchange information from your Socket to the UI handler in order to say, update a TextView object to display the message to the user.
For the Android-way to communicate information between threads, check out https://developer.android.com/training/multiple-threads/communicate-ui.html.
If you have any particular examples/code to share that you're having trouble with, update your question and we can try and provide more specific help.
In Android, i have a socket keeping real-time communication with the server.
This app socket is being controlled by a service, that starts on boot and / or whenever a request is being emitted by the app.
Because I cannot depend on Google PlayStore, I fully control the sending + receving of push-messages manually.
Whenever a new push-message arrives from the server, the socket-service sends a local broadcast message and the listening activities can follow there own action.. If no activities are found, a default android notification is given to the user, saying '[ap] You have {n} new message(s)'...
This has its stability problems (the service can be shut down by the OS when low on memory for example) but its okay.
Now, consider the following:
I have multiple activities that listens-for and shows a count of unread messages.
HomePage
ConversationsOverviewPage
'The' conversation page (chatpage)
Each activity can be on the foreground, but can also be in memory for when the user back-presses and goes back 1 activity. So in Theory, there can be a situation where you want to update different/multiple activities at once.. This prevents having to 're-load' the unread messages from the server when the user gets back to a 'savedInstance'. So the broadcast pattern works best I think.
What is best practise for keeping global track of unread messages, while minimising the server trip on every activity instance:
Very simpel: Make a server request on each and every activity instance, and write update code again for every activity. But this results in the user seeing a delay, as it takes a second before the app receives data from the server and show the 'unread-messages' balloon.
Simpel: Have a global class.. Holding the unread messages for each conversation, But I feel this can give problems with data being incomplete.. Especially when the app is not 'active'
My old vote: Have another service thats keeping track of the unread messages, that starts on boot (just like the socket).. Only when the service starts / boots, it will requests all unread-messages data from the server. Each activity can than 'ask' for the unread-messages data and don't have to worry about it anymore.
But this could be overkill?
My new vote: Keep the socket-service, and add a separate class to this service.. That holds the unread-data.. But this also does not feel to be right.. As the activity would have to ask the service something out-of-scope.. Its not the sockets concern to manage unread messages (separation of concerns), right?
Any thanks from experienced developers is much appreciated!
Third options is ok. Not sure where is overkill exactly. Obviously you shouldn't download all unread messages on every boot or socket reconnection. The most important rule of thumb is to load data when the app really needs it. Few moments about how I've developed about the same app:
there is socket Service which handles connecting, disconnecting, sending data(messages) and receiving data.
there is Notification manager which receives events from SocketService. It saves new data which comes from server and decides which broadcast notification should be sent.
when socket is connected it receives state data from server:
dates(timestamp) of last update for every chat. For instance if local database contains that chat A was updated yesterday but freshly received data from server says that the chat A was updated few seconds ago you need to broadcast event like chat A has been updated since last connection and save update date. If there there is any activity which somehow show the chat A it loads(through http or whatever) new data.
last messages for every chat. The app just compares locally saved last messages and freshly received. If there is new one the app again broadcast event like there is unread message/messages from user x. If there is visible activity which shows updated chat it updates data otherwise the app shows notification.
So the basic flow of handling unread messages is next: connect to the server > check if there is data about unread messages > save new data to the local database > broadcast events about new data.
And I would recommend you to use GCM and socket connection simultaneously. GCM really helps to keep data updated. It wakes up a phone and sometimes delivers data when socket connection just could not be established due to network problems.
I'm very new to Android, this is my first app. I'm just looking for someone to point me in the right direction.
I am building an app that will query a server over tcp/ip every minute. I would like to show the status of this server (up/down) at the top of every activity/screen.
My questions are:
1) What should I use to continuously ping a server in the background across multiple activities? For instance, is there a way to spawn a thread from one activity in such a way that it will continue even if the user goes to a different screen?
2) How can I allow this thread to update a status label on whatever screen the user happens to be viewing?
Use services. Please get familiar with documentation first.
You can use service binding or local broadcast messaging to notify your current/front activity about changes from your service
I'm developing a simple multi-player Android game that communicates with its Game Server using Java Sockets. And to create non-freezing UI, I decided to make Service class in Android app to communicate with server over the Socket connection. Data exchange is done in JSON format.
Now the thing is, during entire game play, a single Socket connection will persist, and data exchange will be done from-and-to the server, but based on events happening on game client running in Android.
Eg; When user taps a button, some data is sent to server and server responds back with some data, until then, client will wait, when data arrives, UI on the activity will be updated, and client will again perform some action, and again that data will sent to server, and so on.
While the client is waiting for data from the server, I'll disable the controls on Activity such that user doesn't perform any actions until data arrives from server, and I'll also show waiting dialog on Activity to let user know that app is not frozen and is waiting.
Now, as Android service primarily works with onCreate(), onStart() and onDestroy() methods, I believe it executes something in background without any user intervention. So in case of my app where I need some input from user (or wait until user provides it) to send it to server, how I'll be using Service class in this case? Also, is there any other option I have apart from using service in such a scenario.
Also, note that I have two activities in my app which will be communicating with the server using single Socket connection.
I am new to Android development and am not sure of the best way to go about handling the following problem.
Background:
I have a TCP client running on android talking to a server. this is up and running just fine however when moving to the next step i am unsure of what to do.
Problem:
I have a UI that draws based on a users touch. I need for the tcp client running on the phone to send the coordinates and some other data to the server. Also there are multiple activities in this process that would be sending data.
What would be the best way to handle this?
Here are some of my thoughts.
1) A class that would have a Runnable client that works on another thread (I think its is an invalid solution because it would not be easy to use the same connection on multiple activities)
2) A local service that can the main activity can start and the rest of the activities can bind to it and send data to it.
If the correct answer is number 2 I am a little confused on how a service like that would work. What I am thinking is that in the OnCreate() method of the service it will launch a tcp connection with the server. Once the socket connection is established I am a bit unsure of how to actually keep in communication with the service and give it the data it needs to send over the client.
You would start the service with startService(). Include in the Intent extras that contain your data to send to the server. The service would retrieve these extras in onStartCommand() and would have a background thread actually send the data.
Be sure to stop the service when you are done with it.