I have a nanoHTTPD server running on my app in background, when i have like more than 30 http get requests to the server, from then server getting stopped, image loading fails.
is there a limit for number of http request in server, or is the android cannot handle those many request at once ? any help is appreciated.
How is your Android application structured? Is the server started by an activity as part of its normal lifecycle? If so, Android might simply be stopping & garbage collecting your activity once it's in the background.
To avoid that happening you will want to start an Android service and start/stop your NanoHttpd server in the service rather than the application.
There are no limits on the number of pages, or bytes, that the NanoHttpd server can serve. I'd point the finger at the Android lifecycle (without knowing any more that is).
Related
I've been reading that we dont need to use AsyncTask when working with volley. I had a question though, one of the button click in my activity triggers a HTTP request. Now in case my app is closed, will volley still be able to process that request.
When I launch my app again, is it possible to figure if my previous HTTP request was sent or not.
What would happen to the response? Will I be able to catch the response and maybe make some db updates (local to app)?
What is the right design to do these kind of http requests?
Also, in case I want to make some HTTP requests while the app is not launched, can I not use a background task to do all this with volley?
You don't need to use an AsyncTask or Thread for Volley because Volley does that for you. So that's correct.
When you say your app is closed- do you mean the app is in the background, or the app is terminated? In the first case, the request will continue. In the second, it will not, and any response coming in would be ignored at the OS layer because there's no listening app on the socket. Also remember that apps not in the foreground can be killed by the OS at any time.
You can't send an HTTP request when your app isn't launched. You can do so in a JobScheduler or WorkManager item, but then your app is launched, you just aren't showing a UI.
I am using the cordova background geolocation plugin in order to dispatch position when app is on the background. It seems that the plugins functions properly but it fails when the app is more than 3-5 minutes on background to deliver the GPS data using HTTP requests.
Note I am not using the plugin's HTTP request, but Axios (just another HTTP request implementation for react).
In the first 4-5 minutes everything works and HTTP requests are getting send. But after that nothing is happens - no HTTP request are getting send.
Probably the OS shuts this down. I am using Galaxy S7 Android device for these tests.
Not tested on something else.
Should I use socket.io for this kind of task or keep using HTTP request but with some fix?
If you are targeting Android 26+ the system places restrictions on background processing. You will need to use a foreground service and show an appropriate notification.
I have an Android client app that sends some data to a server in Python, where the Python server is supposed to run a long time-consuming operation/computation and return the results to the client.
To do so, I initially started using Flask with Python on the server side, and an asynchronous android http library on the client side to send the data via http POST. However, I quickly noticed that this is not the way to go, because the computation on the server takes time which causes problems such as the client getting timeout errors ... etc.
Then, I started using Tornado's Websockets on the server side, and an android library for websockets on the client side. However, the first main problem is that when the server is running the time-consuming operation for a given client, the other potential clients need to wait ... and it seems a bit of a pain to make tornado work in a multi-threaded setting (as it is originally planned to be single-threaded). Another minor problem, is if the client goes off-line while the server is processing his request, then the client might never get the result when he connects back.
Therefore, I would like to ask if you have any solutions or recommendation on what to use if I want to have such a setting with an asynchronous multi-threaded Python server who is supposed to do heavy-cpu computations with data from a client without making the other potential clients wait for their turn; and potentially making the client able to get the result from the server when he connects back.
FIrst of all, if you're going to do cpu-heavy operations in your backend, you [most probably] need to run it in separate process. Not in thread/coro/etc. The reason is that python is limited to single thread at time (you may read more about GIL). Doing cpu-heavy operation in multithreading gives your backend some availability, but hits performance overall.
Simple/old solution for this — run your backend in multiple process (and threads, preferably). I.e. deploy your flask with gunicorn, give it multiple worker processes. This way, you'll have system that capable of doing number_of_processes - 1 heavy computations and still be available for handling requests. Limit for processes is usually up to cpu_cores * 2, depending on cpu arch.
Slightly more complicated:
accept data
run heavy function in different process
gather result, return
Great interface for this would be ProcessPoolExecutor. The drawback is — it's harder to handle failures/process hanging over
Another way around is task queue + workers. One of most used is celery. Idea is to
open WS connection
put task in queue
worker (in different process or even different physical node) eventually picks up task, compute it, put result in some DB
main process gets callback/result of long polling over result DB
main process sends result over WS
This is more suited for really heavy and not real-time tasks, but gives you out-of-the-box handling for failures/restarts/etc.
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.
I've an application which receives and sends data (JSON) from/to a HTTP server via HTTP POST requests.
There is not really any payload except of a few strings, so I'm wondering if it would make sense to build this whole HTTP communication as an Android Service or just to create a separate thread within my application?
A thread should be fine unless you need to download data when your application won't be on screen.