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).
Related
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.
im currently working on a android app that has to GET over 70 images all from different urls. I am currently using the asynctask to GET all the images. would my app load the images faster if i was to create many threads and divide task of getting 70 images between the threads like 20 on one thread and 50 on another?
I suppose you want to load all 70 images at the same time? It might depend on the speed of the internet connection but basically I guess the time to completely load all images would be the same, whether you load them sequentially or in parallel. Sequentially, each image can be loaded using the full internet bandwidth, while loading the images in parallel could only use a fraction of the bandwidth, so in the end the total amount of time will be roughly the same.
Well, I can imagine that having multiple http connections each managed by different thread may be beneficial for the performance. The best way to determine the number of threads to use (could be > 2) is to benchmark your piece of code for overall download time (i.e. between begin until all images have been loaded).
For downloading multiple images asynchronously I would also recommend using picasso library.
It has very few chances to get faster, because time of loading is due to time of the connection.
The right way to do I think, is to think about designing your application better, to avoid retrieving 70 images in one time, because I don't know your application, but do you really need to display 70 images in same time ? It would be better to load images only when you want to display it. This for 2 main reasons :
Your activity will be displayed faster
Your user may not have an unlimited data plan and is maybe not on wi-fi
I am currently using the asynctask to GET all the images. would my app
load the images faster if i was to create many threads and divide task
of getting 70 images between the threads like 20 on one thread and 50
on another?
If you are using a single task to download all your (70) images that is not a proper way for it. Of course you should use separate tasks while downloading images if you want them to be downloaded faster.(I assume there is no constraint for downloading images sequentially) If you continue using a single task to download 70 images, they are going to be downloaded one by one and it will take long.
Use a library for image downloading. It is a painful job to load remote images. I suggest you to use a library for this. I'm currently using ShutterBug. Try it.
I want to implement queues in one of my app. I've been investigating few options like file based queues and database queues. File based doesn't look like a right choice when data grows really big. I'm more inclined towards SQLite based queues now since it can support the large data set. Wondering if someone has already implemented queues in android and the approaches taken. What is the best way to implement queues in a multithreaded environment in android?
[EDIT]
I want to make a queue for messages, which can grow really big if device is offline for long time and unable to flush queues to server. I feel SQLite could be better solution, but afraid if all the database loads as a first thing into memory when an app starts. I want to support really huge backlogs queues, but don't want to consume too much memory to load them all at once.
Wondering if someone has already implemented queues in android and the approaches taken
Square released Tape, a persistent queue implementation for Android, that they use in their apps.
File based doesn't look like a right choice when data grows really big.
IMHO, a persistent queue should never "grow really big". If the data associated with the queue entry is large, that suggests that some of that data should not be considered part of the queue data model, but part of the app's overall data model, resident elsewhere (e.g., SQLite) and be pointed to from the queue.
For example, suppose the queue is for image uploads. IMHO, those images are not part of the queue. The queue represents commands to upload images. The queue entries should point to where the images are stored, as those images likely serve other roles (e.g., cache entries) beyond simply waiting to be uploaded.
I'm using Jake Wharton's DiskLruCache lib.
I'm curious about app performance, caching strategy, using caching both in a view and across a whole application. Most of the time, the image won't change.
Let's say for example I have a 320x320 photo on my server. I open the stream, save the image.
In my list views, I show bitmaps and in the detail, I show a larger image. Should I save a thumbnail bitmap too? Is that more efficient?
What is your experience with sharing the cache "object" across the entire app (let's say I have multiple views that might leverage the same data. What are the issues with this?
For the sake of performance and currency, what if the image changes on the server. What's the best strategy to know that it's changed? I don't have access to modified date. Only size and yet, I don't really want to query size every time either. Set a flag in the app on the server and then query the flag?
In a traditional application (if there is such a thing), what's the best practice for clearing the cache from time to time? (indent weirded out.)
(I was inspired to write this after seeing all of the performance improvements by Facebook in iOS. I don't have billions to do caching but I would like to at least be smart about it! LOL)
A lot of these answers depend on the type of app you're writing, how important image updates are (and how likely images will change, etc), and total images produced. Aside from disk caching, you should be using memory caching as well, especially in ListViews and other areas where the same images will be scrolled through repeatedly. Look at LruCache and read the Caching Bitmaps entry from Google.
320x320 is probably too big for a listview, you will likely want to create thumbnails (depending on device, and how you're implementing your listviews).
1) You should be using Disk caching fairly aggressively (how you define that is up to the app you're writing). Use the external storage directory, and if they have a few GB left over, it's not an issue if you take 100 mb for your app for instance. It can all be cleared away if it's ever needed anyway.
2) There shouldn't be an issue. Disk IO (even to a flash medium) should never be handled on the main thread. Use AsyncTasks to load the images. There can only be one main foreground activity at once anyway, and while an activity is sleeping, it shouldn't be trying to read from the disk anyway.
3) Again this depends on how you're implementing your app. You should be able to get additional information when retrieving the file (even Apache can tell your app the last modified date).
3.1) You can have a sqllite db that keeps track of how often certain images are used, and most recent read. If the most recent read is a few days old, let that image expire.
Edit: There's a library from Jake Wharton now called Picasso that I would recommend using, which handles the Network/local IO as well as memory and disk caching. Check it ou here: http://square.github.io/picasso/ . A lot of what you will need to do can be accomplished with one line: Picasso.with(this).load(imageFileURL).into(imageView);
After some googling, I selected various sources and started to use a separate thread to download images to make the UI responsive. It actually worked like a charm. But after a few minutes it would freeze the emulator. Initially I had assumed various reasons but finally I figured out that if this threading code is removed it works without freezing the emulator.
The code was adapted from another Stackoverflow question from the answer given by a certain Fedor. For the sake of simplicity I had removed the HashMap part and directly download the image each time a request comes from the list adapter. Also, I assumed that since the image is very small (< 1 KiB) it can actually be downloaded again rather than storing it in memory.
I am not sure if this is the right way to handle asynchronous image download, but any help in preventing the emulator freeze would be much appreciated. I can copy paste the code if needed.
Have a look at this url
about downloading images from remote server using asynchronous task and threadpool.