I'm developing a small social networking app that makes use of something like profile pictures. Images are stored on a server and I have scripts set up that will send the image for each user to the app, which then displays it in an image view for each user, and then saves the image to external storage. The way I have it implemented now is that anytime the app needs the image after it downloads it from the server, the app will get the image from external storage unless a user has uploaded a new image (I thought this would be faster than redownloading it from the server every time). However, it seems to be taking longer to get the file from external storage than it does to get it from my server (and the server is pretty slow, running on wifi from 3 floors away...budget constrains :) ).
My question is what is the fastest way to get these images if the user hasn't uploaded a new one. Should I just downlaod it from the server everytime (I'm assuming not) or is there a better place in the filesystem to store the images that makes for faster retrieval?
Loading images from the SD card should be very fast. Some strategies:
Do it only once - Load the images into memory asynchronously when your activity or application starts. You don't want to be hitting the SD card every time your view updates.
Make them small - If you're having performance problems displaying thumbnails in a list, try saving your thumbnails as smaller images using inSampleSize to put less pressure on the decoder.
Use internal memory - I think that internal memory is faster, but it tends to be in short supply. You could certainly store some number of thumbnails in your cache directory to help speed up step 1.
Responsiveness over performance - The golden rule is to remember that absolute performance does not always correlate with responsiveness. Even if the images take a long time to load, choosing cleverly when to load the images can have a great impact on the user's perception of speed.
Related
In android many image loading libraries (like Picasso -- which uses 2% of the storage for disk cache, Glide) use disk cache in addition to in memory lru cache. I can understand why this might be useful for images downloaded from the network -- if the in memory cache is full, read it from disk rather than fetching them remotely -- thus avoiding network latency etc. However, if we are just reading local images on the android device itself -- do we gain anything by using a separate disk cache with the serialized bitmap data -- since the data will have to be read from the disk anyways ? Probably makes sense if your app needs a thumbnail and subsample the original image once and store it in cache ? Are there any studies showing perf gains. I have seen use of disk cache in googles samples and other bitmap cache libraries.
so here are some refs I found in the AOSP docs:
A memory cache is useful in speeding up access to recently viewed
bitmaps, however you cannot rely on images being available in this
cache. Components like GridView with larger datasets can easily fill
up a memory cache. Your application could be interrupted by another
task like a phone call, and while in the background it might be killed
and the memory cache destroyed. Once the user resumes, your
application has to process each image again.
A disk cache can be used in these cases to persist processed bitmaps
and help decrease loading times where images are no longer available
in a memory cache. Of course, fetching images from disk is slower than
loading from memory and should be done in a background thread, as disk
read times can be unpredictable.
When I upload an image from a mobile device you have two options:
reduce the size on the device and upload the result
upload the full image and reduce the size on the server
Which one is better?
For the user experience, it is better to do all the work you can server-side, minimising the processing time and the transfer time.
I would recommend doing all the work on image on the server if you want the application to be fast, and if the transformation make the image heavier.
Now you may have problem in the future if you have mutliple upload in the same time with a low performance server. If it is the case, choose to do the work on device to devide the work on each device.
I think The "1" is best,because This way of consuming less flow;this option is very important for android app
I always use the 1st approach. You never know how fast your user's internet is, so I prefer doing it locally and save time on the upload.
That is specially true in 3d world countries where 3G speeds are generally very slow and unreliable.
I have an Android application with which user can share posts with images on the server.
Images are taken by the camera - therefore I change the size to a smaller one and compress it.
I also need the image to be in 2 formats - regular and thumbnail.
I guess better to create 2 versions on the device and U/L both?
I also do it in BG, so user will not be blocked for long time...
Is it a good behaviour?
Should I block the user for 10-20-30 seconds (depending on the network speed?)
What is the common use?
Recommnedations?
No ... it would be a better experience if you just upload the large image, and have the server take care of thumbnail generation. That way, you can minimize the user's data usage, and also the time it takes to upload an image.
Also, definitely don't block the user ... do the upload in the background, and let the user continue using the app.
Sending your images using the multipart content type.
If you have an additional step where the user start typing additional information (like a title, description etc.) you can start uploading your image so that the user won't notice the delay (do it asynchronously). That's what Instagram does.
Speaking of the size of your BitmapI think you should consider sending only one normal version of it and let the thumbnailing be done by the server. However you have to compress it (JPEG/PNG) and you can also scale it down by a factor of 2 otherwise you might experience memory errors.
On a side note (not really related to your question) be careful of how much memory is left for your app to use when displaying a large amount of Bitmap. Before Honeycomb, Bitmapwere allocated on the native heap but accounted on the VM Heap (if I'm not wrong) so don't count simply on how much memory is left on the VM heap. This talk is worth a watch if you haven't yet.
I am generating a set of images on server. I need to encode and stream these real time to a android mobile, what is the best way possible, best encoder server side to do this?
Well, you can just have picutres stored in any format and just download them into device one by one. Only matters are how fast connection do you have, how many pictures do you want to send and how fast whole operation has to be finished.
Images downloaded from server in that way are stored in inputstream, which can be saved into file or used to create Bitmap with BitmapFactory and displayed within application. Be aware of OutOfMemoryError, which occurs while creating big resolution Bitmaps with BitmapFactory, as heap is shared amog all applications and is limited to 16 MB.
As for downloading process you can do that with HttpClient library available in Android.
I have to create one application which has use of lots of videos & images. Total size of all the videos & images which are used in application is approximately 500 Mb. Whole application is depend on this videos & images.
I know that android market supports only 50 Mb max. size of apk. I have no Idea that how can I use videos & images in my application. If I put it into drawable then the apk size increase to 500 MB and I know that it is not possible to install 500 MB apk file to mobile device.
If I put this videos & images to the server then It takes so much time to load every time.
Anybody have solution for this problem that How can I manage this size of video and images in my application.
The only way to solve this is to put the data on a server and download it to the SD-Card after startup of the App. Explain it to the user in the market listing that he needs the videos to use the App and be sure to check what kind of data connection your user is using. You can then warn the user if she tries to download the 500MB through a mobile connection.
As of 3/5/2012, Android Market (aka Google Play) is supporting the attachment of up to two "expansion files" of up to 2 Gigabytes each. Your APK must still be under 50 MB, but the attached files can total an additional 4GB.
Whether the resulting SD card storage requirements are acceptable is now between you and your users; Google is stepping out of the way and letting the other "market" decide!
Google's announcement of this policy update appears here:
http://android-developers.blogspot.in/2012/03/android-apps-break-50mb-barrier.html
Prompt the user the first time they run it that they need to download the items and store on the SD card. Then references them because you know where you put them on the card.