Asynctask alternative without limited amount of tasks - android

I want to download some thumbnails async in background and load them into an ImageView after download finished. For this purpose I used AsyncTask, but it's not properly working for more then 5 download at the same time. It seems like there is an internal limit of Asynctask running at the same time.
What is the right alternative to have an ulimited amount of background processes which can update the UI after finishing download?

You shouldn't be using AsyncTask anymore as it's deprecated.
I would recommend you to use a suitable library for that use case, such as Picasso or Fresco, just to mention. Not only they download images but they also handle other tasks like caching or download cancellation.

Related

How to load one image at a time?

I have a form with 10 images which need to be downloaded from my server. The problem I have is that when the form is displayed, the library I'm using will start downloading all 10 images at the same time causing some of the image download requests to time out. (I don't know why it does)
So I think I could fix this by changing my code to download one image at a time.
Is my understanding correct in that I should treat each of the image download request as an Async task and chain them together so that only one image download request will be processed at a time?
Any libraries I should look into to save time in implementing this? Or any other techniques I should be aware of?
This answer is from the comments I had to this question.
You can use an AsyncTask.
You can update the ui when each has finished in the functions:
onPostExecute()
onPreExecute()
onProgressUpdate()
you can try Image loading lib Glide. You can set priorities for image loading so this can be achieved using Glide.
Here is link

Does asynchronous execution means that data is not getting loaded using main thread in Android?

I am currently doing the following:
I have a RecyclerView to display in a fragment.I load the data along with the images from the server. I am using Ion library to load the server data and the images.I have googled and found out that Volley excutes asynchronously. I refered here. I have a doubt:
Ion/Volley runs asynchronously. So does that mean they don't run on the main UI thread? Or do they run asyncronously on seperate thread?
Someone told me that my recyclerview was jerky because I was loading data on the main thread using Ion.I have read that using Picasso to load images will prevent the jerky effect. So can any one clear me on this too?
running [something] asynchronously means that [something] will not running in the same thread you started it from.
Pictures or data loading, a network call or a long processing call all should be run asynchronously in order not to block main execution.
Volley and Picasso by default run asynchronously.
For example when you add a Volley request to the queue it processing it using cache and network dispatchers on different threads. However the callback you get back is received on the main thread so you can work with the UI as you wish without any extra line of code.
Volley can be used also to load remote pictures.
To load local and remote pictures in a list or RecyclerView you can try also glide it works very good for me.
For network data in general other good option is jus. its like volley but with more options and more flexible.
Ion/Volley runs asynchronously. So does that mean they don't run on the main UI thread? Or do they run asyncronously on seperate thread?
yup exactly if something your executing asynchronously it will be independent from the main tread. There will be parallel execution.
Someone told me that my recyclerview was jerky because I was loading
data on the main thread using Ion.I have read that using Picasso to
load images will prevent the jerky effect. So can any one clear me on
this too?
For that you need to use Image loader library for loading images. You can use :
Universal Image loader
Picasso
Glide
I haven't used Ion but if your app is not throwing NetworkOnMainThreadException, then Ion too fetches the network image off the UI thread. So to that respect it should be the same as Volley, Picasso or Glide.
Now if you UI janks, and assuming it is because of Ion, it might be because once the image is fetched from the network Ion will perform some decoding, scaling etc. And that might done in the UI thread. That may be causing the issue.
Picasso, Volley, Glide and (I guess) Ion, use different approaches, techniques when it comes to decoding, fitting, etc. images in order to be as fast and efficient as possible. Maybe Ion is not shining at it.
My advise, if you have problems with Ion, change to Picasso or Glide.

Any way to speed up mass image download on Android? [duplicate]

I am loading multiple photos from Dropbox using the Core API in Android and when making requests they are serialized.
I am getting the thumbnails to show in a grid view and when the user clicks on one of them it goes to another activity it fetches the full res version from the server.
It does this fine, but the high res version only starts to be downloaded when all the others async tasks fetching the thumbnails are finished.
So what I want to know is, is this a limitation of the Dropbox Core API? Or is there a way to make the high res async task have priority over others so it is immediately downloaded and then the others can resume.
This is due to how async tasks actually work. They don't run in parallel on 3.0+ (they used to until 3.0), because too many newbie developers weren't able to program in parallel without errors, so Google decided to change it. Instead, async tasks run on a single thread in FIFO order.
You can override this however. Instead of calling asynctask.execute(), call asynctask.executeOnExecutor() and use a THREAD_POOL_EXECUTOR. This will execute it in parallel on its own thread. I believe there's a thread cap, but it will at least make several run in parallel.
If the thread cap becomes an issue, you can always drop down to using threads instead of using async tasks. You need to do some work yourself to do an onPostExecute, but it isn't that hard. And if you're creeating your own threads you can make up to the OS limit.

Android image downloading and caching using Picasso

In my project a background service downloads contents from remote database using asynctask. I would like to download all images from urls (saved in database) using Picasso in background service. These images will be used later in my app.
Is there any better solution to do this? or just use the one line code of Picasso in asynctask?
Is there any better solution to do this? or just use the one line code
of Picasso in asynctask?
What do you mean by better? Is it about performance?
If you will have to download a lot of images, you might want to download them on the service. With this, your download will not stopped if the activity is destroyed.
For the library, i never use Picasso. I always use Universal Image Loader but i dont know which one is better. I think the most important feature of those libraries is their capability to cache the images.
UPDATE
For performance, you may want to combine the Picasso/UIL library with PullToRefresh library, especially when your listview/gridview want to load a lot of images.

Upload Bulk Image in MultipuleThread android

right now i am uploading image in single thread using asynctask. but it is not efficient and it's takes lot of time to upload. so i am refering this link to download image using ThreadPoolExecuter. can i use this strategy while uploading image also ?
is this good practice to upload image?
is this good practice to upload image?
YES that could be an option if you don't worry about tracking of each execution (i.e when thread completed its task ).
See what google doc says
they usually provide improved performance when executing large numbers
of asynchronous tasks, due to reduced per-task invocation overhead,
and they provide a means of bounding and managing the resources,
including threads, consumed when executing a collection of tasks.
You can down- as well as up-load an image in a separate thread, that's perfectly fine.
If you want to use several threads for that, it would make no sense due to limited bandwidth (several threads would not speed-up the process) and partitioning issues (on the server).

Categories

Resources