Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
What is the best way to send requests sequentially in background? I'm having trouble deciding between an AsyncTask, Service or Runnable due to the complexity of my problem. Basically I have a DB, with pending requests, and I want to create a "background job" that doesn't get killed until he finishes his task. This job needs to check if there're any pending request and if yes, send them first. For this I'm planning to have a background task with a queue that consumes the first element and continues the process on success and aborts the operation on failure. It also needs to be a singleton so, if any request arrives while it's still sending pending requests, I can guarantee the sequencial state integrity. Said that what do you guys think is the best android class that will suit my problem? Thanks
I thinking about using this. It looks like a very nice framework to do what I'm looking for https://github.com/path/android-priority-jobqueue
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I'm currently developing an application which should share the location of multiple clients live. It is important that the locations are always up to date. I would like to ask what's the best way of doing so with keeping performance in mind. I currently only have a web services in mind which handles the locations and the client fetches the data every X seconds from the server or live updates with firebase.
I'm strongly recommend to use synchronized DB, such as coutchDB/PouchDB or similar, in that why the DB framework will be responsible to sync all clients without the need to handle each client separately.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Is it a good practice to make long tasks such as server requests in the application class? Let's say these requests are for initialization,is it still fine to place these requests in the oncreate method in the Application class.
It is not. Everything inside the onCreate of Application class will be executed in the main thread, resulting in freezing the UI if your task takes a lot of time.
The best practice, when it comes to operations such as communicating witha server, is to implement a Repository Pattern and execute the time consuming operations in a different thread, then use the results in the UI Thread.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Today i used retrofit library in my project instead of AsyncTask because it is faster than HttpUrlConnection but i am wondering how it is faster and what mechanism they are using. I searched about that but didn't get the accurate or satisfactory answer. Please help me out to understand the concept behind it.
Async task execute serially and are single threaded by default and they will wait for last call to complete before execution of next one and designed in a way so that to avoid common errors due to parallel running threads. Retrofit is not. It sends calls parallely and use ThreadPoolExecutor.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have to repeat a weather API Task after every half an hour to fetch data from the http://api.openweathermap.org for that I have used handler post delay but some one suggests me to use Alarm manager for repeating task as It produces interrupt. but if we use handler it consume more memory and uses more Cpu. I need suggestion which one is best.
The docs for AlarmManager point it out when to use it.
Note: The Alarm Manager is intended for cases where you want to have your application code run at a specific time, even if your application is not currently running. For normal timing operations (ticks, timeouts, etc) it is easier and much more efficient to use Handler.
In your case your app will not be visible all the time since it's a weather app. It makes sense to use AlarmManager here to update the data. For more pro's and con's there are more answers here
It's always case dependent.
Previously SyncAdapters were used for performing long performing operations, Now JobSchedular is the latest background monitoring service which can be used.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have an interesting issues and wanted some input from someone with a similar experience.
I have an Android app that makes a REST call (e.g. accepts an open order). App sends out the request and runs into connectivity issues, meanwhile server gets the request, changes order state and sends back a response (e.g. HTTP 200). But, the app, missing its network connection, does not receive the response and gets an timeout exception. If I try to accept the order again, I get response that it is already taken (in this case by me).
The question would be - what should be the best approach to such situation.
For now, the requirements are to run a loop if I get a timeout exception (in some scenarios it's a loop including another web call to check whether this order did not appear in my "CurrentOrders"). I don't like this design and was wondering what would be better. Maybe the web call could return 200 (success) if the same client tries to accept the same order twice or more? Or how would some of you handle such situation?
I'm not quite clear about the semantic of your "accept" action.
What does it actually do?
On the one hand it seems it updates the order state. It should be then idempotent since further updates should not change anything.
On the other hand you have some kind of external state (order is taken). This can't be done through REST, you have to use some kind of unique id to resolve the conflict. Look at this question for more info.