I am trying to do the following and am looking into other people's experiences:
I want to have an HTTP server running on Android that receives GET requests from a client. From there, the server must deliver the query parameters to a Service that will do some processing (sometimes quite heavy). When the service is done, it sends back the data to the server that will then return the response.
Of course, the startService(intent) call is asynchronous so I'm wondering how to tell the server to wait for the processing to be done before sending back the response. At the moment, the inter process messaging is done with the Messenger and Message classes.
What sort of design would be able to achieve that?
Use a bound service (one that implements onBind()) and a transact call on the returned IBinder object. Or write your own AIDL to describe the service's synchronous interface.
You want to bind to your service on app startup, before the HTTP requests start coming, since the bind operation itself is async.
By the way, why does the functionality have to be in the service? If the service is in the same app, can you move it directly to the HTTP server class?
Related
I'm working with Android on the front end and I'm using Spring's REST Client libraries to send HTTP Requests to a REST web service. I've read examples online where people use AsyncTask to accomplish this with a RestTemplate in doInBackground method of AsyncTask, but I've also read examples where RestTemplate is used outside of AsyncTask, even in an activity or fragment. Is there any point in using one method over the other?
Secondly, when receiving a response from the server through RestTemplate's exchange or getForAllObject, based on the data received my client should be doing different things. For example, if I want to search for users, I should receive User objects and then my client should then update the users fragment/activity, but if I want to login, I should receive different data and my client should perform different subsequent tasks.
If I create an AsyncTask every time I send an HTTP Request and then receive the response, how can I distinguish what subsequent tasks need to be done client-side? Is the preferred method to use enums? For eg., when I want to get data from a server, I can instantiate an AsyncTask and pass as execute parameters an enum to specify which HTTP request to send and an enum to specify what to do with received data. Then I could just use switch statements which call different functions based on the enum?
If none of this makes sense, is there a more standard way to approach handling responses from the server?
From docs
AsyncTask enables proper and easy use of the UI thread. This class allows you to perform background operations and publish results on the UI thread without having to manipulate threads and/or handlers.
AsyncTask provides a convenient way to do tasks in background and interact with the main UI thread. If you did not use AsyncTasks you have to implement your own methods to synchronize with the main thread to update the UI. If you are calling any back end services or doing long running operations, it is always good to go with async tasks.
It is a bad practice to have your same REST end point to return different objects based on an enum. Have two separate endpoints. One GET call to search users and one POST call to login users. In the client side also have separate implementations on consuming above endpoints. Use them appropriately when needed.
I'm about to write an application that sends data to a server with a post request. These requests can fail and if they do I want them to be sent when the connection is back online.
What is the best way to implement this behavior?
EDIT
I've read some articles and come up with the following idea. I register a BroadcastReceiver in the manifest and tell it to listen for android.net.conn.CONNECTIVITY_CHANGE and android.net.wifi.WIFI_STATE_CHANGED. When the request can't be send I store the request. If the connection becomes alive then I will send the cached requests.
What is the best way to implement this behavior?
Make Volley requests from a bound Service, and send the result back to the Activity if it is still in the foreground.
EDIT:
won't this be a problem if the user decides to close the application?
That's exactly why you need to use a Service. If you do it from an Activity, the request continues even when the Activity is dismissed. If your Volley request is expressed as an anonymous class instance, it continues to hold an implicit reference to the outer Activity class, which leads to a memory leak / exception.
Check your Internet Connection continuously by using Handler or service ,if it is sends the data to the server otherwise dont send it.
I am a web developer and writing services for android. The android developer, whom with I am working, is sending multiple async calls to the server, and asking me to send a service code with in the response of each service, as he will able to decide about a particular response belongs to which service that he sent before.
Is'nt there a way in android to keep track the responses of multiple async calls? Why should the server tell to android that which service is served.
There is no need for the server to send any code . He could send each http request using IntentService with a key. On each response from your server, he puts the key in a bundle, compare it and do what he wants.
See this code : https://github.com/JCERTIFLab/jcertif-android-2013/blob/master/src/com/jcertif/android/fragments/InitialisationFragment.java
I think their is no need of service code to keep track of the response-request pair, because if 5 threads sends the 5 different request, then, all of them receive their responses only.
Order of retrieval of response may vary.
Lets assume a condition,
ThreadA sends requestA.
ThreadB sends requestB.
Then,
ThreadA receives responseA only.
ThreadB receives responseB only.
Order variation:
ThreadB response may come before ThreadA.
I'm developing restful android application, but I'm still newbie to android, and I would like to avoid beginners bed structural design that would cost me troubles latter.
I've read lots of discussions about android services and restful applications, many of them contrary to each other, so I would like to know have I choosen a good approach.
Inspired by this presentation http://www.youtube.com/watch?v=xHXn3Kg2IQE I put my http requests into IntentServices, instead of the Async Task.
I've choose Intent Service because of:
as a services they are not sensitive to foreground/background switching like Activities (won't get killed).
Intent service provides work in separate thread, so the user interface stays responsive.
Since Intent Service cannot run multiple request simultaneously, I've "split" my domain into few groups and for each group I have written my Intent Service. (ends up in: one CRUD set -> one intent service)
This way I got that inside of a group can be only one request running at a time (And this is good for me, since this way it could never be executed for example update and delete at same unit).
And, on the other side, I can run multiple requests at the same time if they are from the other groups, and don't affect each other.
So basically, I have this:
one generic HTTPRequest class that builds requests from name value pairs
UserIntentService - creates user related requests and executes it by using HTTPRequest cass, and proccess request using UserProcessor. Notifies caller by intent with data.
CallIntentService - creates call related requests and executes it by using HTTPRequest cass
and proccess request using CallProcessor. Notifies caller by intent with data.
UserProcessor - parsing response
CallProcessor - parsing response
ServiceHelper - finds and starts right intent service
When using from activity, I use something like this: SeviceHelper.StartService (action, data),
and I get response by local BroadcastReceiver inside of the activity. I register receiver on the OnStart(), and unregister it on the onStop() method of the activity.
Is that a good approach?
Should I have only one IntentService for all calls?
Is it better to have one Service that runs all the time in background, instead of using Intent Service that has to be started for each request?
Is there any other things that can get bad with this approach that I'm missing?
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.