In an Android app, I am using one static instance of org.apache.http.impl.client.DefaultHttpClient and sharing that instance in all activities and services of the app, so that this client may be used to log in once to a remote server and all subsequent user requests to that remote server will remain authenticated.
Every activity or Service that makes a GET or POST to this remote server calls the same method : MyUtilityClass.gettHttpClient()
Do I need to worry about synchronization of this httpclient? If so, what is the best way to handle this?
Use ThreadSafeConnectionManager, but be sure to call httpResponse.getEntity().consumeContent() after processing the response in order to ensure that connections are released back to the pool.
Use a ThreadSafeConnectionManager, then you do not need to synchronize.
You can use AndroidHttpClient1. It is properly configured and already uses ThreadSafeClientConnManager
Related
I need to implement some async client in android app for communication with external device. I need this client to start connection with specified socket on different thread and then implement some methods which will be sending data to external device, all this methods need to be asynchronous. What is more I need to have guarentee that Android won't kill my process.
This client needs to be working w Dependency Injection. I would like to create single instance of this client being injected and used across many activities.
What I took into consideration is:
AsyncTask - heard that it is for only short tasks
Thread - I am struggling with implementing other methods despite run which will be asnychronous and able to be called
Service - I can't make it asynchronous
ServiceIntent - I am not sure if it is the best pick for implemeneting async methods.
I need your suggestions which way would be best with simple explanation why.
I am developing an app that is designed to allow emergency calls using Twilio - my code is derived from https://github.com/twilio/twilio-client-quickstart-android.
All I've done which is different to the GitHub code is create a separate AlertManager class that does the Twilio initialisation outside of an Activity.
At any moment a user must be able to open the app and tap a button which will (as quickly as possible) make an emergency call using Twilio.
My issue is that Twilio requires the creation of a clientDevice by requesting a "capabilityToken" from my server. That is fine, but the token expires after an hour.
Assuming there is always an external internet connection, how can I make it so my application always has a clientDevice (with a valid token) object available in memory somewhere, such that when the user enters the Activity to make an emergency call, they are able to do it immediately without the app having to request a new token nor create a new clientDevice?
From a quick test using Airplane mode and hard coding a valid token it appears the Twilio SDK can create a clientDevice as long as it has a token, i.e. only one network request is required to retrieve the token, rather than two if another is required to create the clientDevice.
I know I could use some kind of Service to fetch tokens, but I'm not entirely sure where I can store my clientDevice. It can't reside inside an Activity since the app will not always be running. I did wonder about creating my own Application class but as I understand it Android can and will create new instances of that class when it needs to which would then result in my clientDevice being removed from memory. Or is it possible to store it in the Service and then send some kind of broadcast to the Service to make the call?
I hope that makes some kind of sense and if anyone has any ideas it would be much appreciated.
Twilio developer evangelist here.
I have a couple of ideas about the token expiry.
First up, you can set the token expiry time up to 24 hours.
Second, you could use Twilio's AccessManager library that takes an access token and lets you listen to events for when a token is close to expiry or when it expires.
I don't know about keeping live objects while your application is in the background though I'm afraid. Hopefully someone else can help you here.
I am currently developing an android application using HTTP/REST requests to communicate with my backend. I am not using any particular library yet since until now the built-in HttpURLConnection works fine for me. However I would like to have some kind of fallback mechanism if my requests fail due connectivity issues. A similiar problem is also described in https://stackoverflow.com/questions/31786486/android-volley-internet-queue but has not been answered yet and other related posts rather focus on caching older responses to redirect requests to the cache when there is no connection is available.
Up to now I considered using Volley but as far as I understand it it only allows to retry a failed request until it finally connects. I think it would be a cleaner solution to cache the failed request and attempt to resend it after I registered a change in my connectivity state via a BroadcastReceiver. Is there an existing solution which does that for me or do I have to set up an internal database and manage the whole process myself ?
TL;DR
I want to store failed HTTP/REST requests on my android device when my device is offline and resend them when the device can establish a connection again. What am I looking for ?
I had the same situation with a reporting service. What I implemented was a Service that receives requests and queues them. In a separate thread (started when the service starts) it checks the queue and attempts to make the connection. If you use a BlockingQueue you have the 'signalling' between threads for free, so you don't need to idle-poll.
You can use set up a receiver for WifiManager.WIFI_STATE_CHANGED_ACTION and/or ConnectivityManager.CONNECTIVITY_ACTION events, so that you start the service or wake up the thread and attempt to re-send when the connection is up again.
I suggest a Service so you can detach all this from the code in your Activities and have some facilities for starting and stopping it. I personally used an IntentService because that allows me to serialize the requests through Intents, and let the OS handle the Intent management sending for me. You might implement it differently, even without a Service, just with a Singleton object.
If you also need storing them when your app is not running, I would use a SQLite Database.
As #Sebastian wrote you can write queue handler yourself, or perhaps check if existing implementations, like android-priority-jobqueue is not going to be useful for you.
I want to keep a connection alive to my Android application so that when the server wishes to communicate to the device (ie. send new data) to be able to do so. I do not want to use external API's or requests from the mobile; just a connection that stays idle until I send data from my server. What would be the simple way to go with this?
If you only need to keep the connection alive when your app is running, do the following:
If your application makes constant use of the network, it's probably
most efficient to set up a single instance of RequestQueue that will
last the lifetime of your app.
From here: https://developer.android.com/training/volley/requestqueue.html
Otherwise, Google Cloud Messaging is the right approach: https://developer.android.com/google/gcm/index.html
Maybe look into Google Cloud Messaging for Android, see the overview page here
should we use android services for network connection? if yes please provide me a sample.
It depends what kind of network connection you are using. If you just want to fetch some data from the web I would recommend using a AsyncTask. If you are opening a port to a distant server for a longer living connection like a chat application would use you may want to look at a service.
In general you're better of just wraping the communication in an AsyncTask. Then you can easily handle for instance progress updates and canceling of requests etc. Services should be reserved for heavy lifting.