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.
Related
I have an application that work on internet access only and I want to impliment it to work also in offline. And when there is internet access should sychronize data to the server
Go through Priority Job Queue. While offline Store your API calls In Job Queue. And fire them When The internet is Available.
You have two solution :
You can create your own synchronisation service ( can be complexe )
You can use couchbase it's a nosql database with a "sync gateway" which allow you to easilly sync between device
I have constructed a background service in which, every particular interval, a request to the server is made which - in successful cases - a JSON response is parsed.
I am using Retrofit API to handle this situation, but I have come to a point where I wonder if this is the most efficient solution.
Should I use sockets or some other kind of API? Is this memory efficient?
Yes, Socket is the best way for continues connection or network calling, And also faster calling if you are using socket,
Also throw socket you can make like live connection, But for continues connection in background you need to create service and manage properly.
Push mechanism is the most efficient way than Polling(network request to server in intervals), provided the server supports push mechanism.
You can refer this for GCM.
https://developers.google.com/cloud-messaging/gcm
But in case if polling is the only way, you case use any of these
Service
Handler
AlarmManager
https://developer.android.com/training/scheduling/alarms.html
https://developer.android.com/training/best-background.html
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'm a beginner in android development and I'm trying to implement an android udp client, which connects to a java server and sends/receives some packets from it.In this process it collects some data (like round-trip delay etc), which is used to measure the QoS of that particular network. I have tried implementing the connection and sending/receiving data using Java Threads, but the application crashes, and hangs if i try to use more than 2 threads. So I'm looking for alternatives. While going through this site as well as some other links I found that in android multiple threads can be implemented using AsyncTask, Handler etc. Also I found that the Service class also helps to run a background service in an app. Please suggest which approach among these would be the best to achieve my purpose.
Thanks in advance.
You can use AasyncTask to do this and as you mentioned service may be useful too, where u can let your application do whatever it wants in background , if user needs to use application by its interface then AsyncTask must be used to avoid Crashing
There is not one right answer that can be applied as a broad stroke to how to do Android multi-threading. There are a few different ways to approach it based on what your specific needs are.
Any long running, blocking call, in Android will result in the application crashing.
The most common solution is to use an AsyncTask though. For example, when I want to make a call out to a web API endpoint for some XML data within an Activity I would in this case use an AsyncTask and kick off the calls from within doInBackground.
This is not an appropriate solution though if the wait time is longer, or possibly an unknown wait time. Or in a situation where there will always be waiting such as a message queuing service. In this type of situation it may be best to write a separate app based on extending the Service class. Then you can send/receive notifications to/from the service from your primary application in a similar manner to how you would communicate with a web service.
I have a service which is is responsible to send requests and take responses over network. I am planning to use it also as an API . So other applications on device can bind to it, send requests and take responses.
1-Is this a proper way to provide an API to other apps?
2-Should I use a Messenger or AIDL ? Messenger seems simpler, but network operation can block a request, so using a single queue for requests can be problematic !
3-Is it a good idea to use same service for both network operations and as an API for other apps ? I can create a separate service for API which binds to network service, but this will bring extra message overhead and code complexity !
According to me you need to create a service separately that can be used by both of your applications. And you need to use BroadcastReceiver to start your service as and when android system boots. So that any of your application can use that service.
Creating a simple service is the best idea. You need AIDL for that so that you can transfer the data between service and application with ease.