I’m having a little problem with an app I’m working on. The app shows a gallery that shows between 1 and 70+ pictures (one at a time), all downloaded from the web.
At first I save a low resolution picture and after I finish downloading all low res pictures, I start downloading the high resolution ones and replacing them.
The problem comes when I start downloading the high dpi ones. After some are downloaded I get a memoryOutOfBoundsException (which can be expected).
To solve that kind of problem in android I’ve seen four options:
1.- Using androids Cache Manager.
This is limited to Web Views (So I can’t use them).
2.- Loading the hi res picture every time the user passes thru a picture.
That will make the bad resolution picture appear every time the user changes the picture until the high resolution one (which is loading on the background) gets downloaded and switched. Making the application look bad.
3.- Creating some kind of RAM cache that can hold like 5 pictures and use something like the second method.
In this case, I’ll try to have, in the ram, the 5 hi res pictures nearest to the one that is being showed (either downloaded or being downloaded) so that the app can show hi res pictures for the ones that are near the selected one without having to download them after the user gets to see the low res picture.
4.- Creating a personal Cache Manager
In this case I’ll create a personal cache manager that saves the pictures on the SD card and uses those pictures on the gallery. This also brings one problem, I’ll depend on the user having an SD card on the device. For solving the problem of the files staying on the device after the app is deleted (If the app gets deleted), I’ll just delete all the files on the onDestroy() method of the app (I don’t mind loading them again).
In my opinion, the best option is the fourth. Method, which forces me to depend on the user having an SD card.
Now my questions.
Is there any other way of solving my problem?
Is there another kind of memory on the device than can be used to evade the dependency of the SD card?. Following the question. Is it recommended to use that kind of memory or does using it bring other problems?. (Also, a tutorial about it wold be apreciated.)
Do users usually have SD cards or is the fourth option the worst one?
Thank you in advance.
I would write my own cache manager. If the user can only load pictures to the left and right in the list, I'd keep those three in memory if possible and shift every time the user navigates to a new picture. I'm not sure if that's how your app works, but that's one way of doing it. If you can't predict your user's next choice, maybe have a revolving cache and experiment with how many you can hold in memory at once (not knowing the best, worst and average case of your file sizes, I can't really speak much on that).
You may know this already, but it's always worth mentioning. When you're working with Bitmaps, any time you're done with one...really done with it (such as flushing it from your cache), call it's recycle method. That seems to be the quickest and most widely accepted way of reclaiming that memory for the system.
Related
I am developing an Android app using Android Studio. The app will have the user take photographs and then display those photos as low-resolution thumbnails in a listview along with some other information. I am using a sqlite database with a field for the file name of the image to be called whenever the listview is loaded. There will potentially be several hundred pictures stored on the SD card. Each time a listview is loaded, there may be 50 or more thumbnails displayed.
The debate is whether to render the lo-res thumbnail from the original file each and every time the listview is generated and destroy it afterwards verses whether to create a permanent thumbnail version of the image at the time the picture is taken and call the thumbnail in an effort to save the rendering time. Will there be a noticeable difference in performance (how quickly the listview loads) in one method over the other?
Since I'm storing all the images on an SD card, storage space is not really an issue.
Also, the app will only ever work on the particular device its installed on. It won't be sending information to other devices. The thumbnail that would be generated would be optimized for the particular device's screen at the time it's created.
In this case caching makes sense; it's not only about performance, but also about CPU time, which effectively means the battery. You might still need to provide a fallback to live-scaling, in case the user refuses to grant access to external storage (where the original images are located matters).
We are trying to build a photo app for a client where large photos are required to be fetched using a web service. These photos will be high resolution JPGs ranging in size (between roughly 5 - 7 mb).
The issue we're facing is how to fetch a batch of photos (say 10-15), store them locally on the app, and allow the user to perform editing tasks on them. What I understood from my team is if we edit the high resolution photos it will crash the app due to memory. This means we will have to reduce the resolution and size of the photo, which is reasonable, but could take a while. What is the best practice to download and reduce the photos so a good user experience is maintained?
To give some background, we are build the app for both Android and IOS. The features expected are typical swipe, pinch, editing with basic editing and advance editing like frames, text overlay, etc.
Not sure this is a UX question so much as about app architecture.
Maybe better suited to StackOverflow or another stack exchange site instead, but I'll try to approach it from a UX angle...
USER EXPECTATIONS
Do your users expect to edit high-res & have control over maintaining maximum quality? Or are they casual users just interested in making funny pix & won't care about loss of quality?
If they expect to have control, you could check disc space or device capability before downloading & offer them a choice of smaller size vs. slower response time.
For example, if they're on an older non-retina/low-pixel-density device, display an alert that editing high-res images might be difficult & offer a smaller version as an alternative.
How will saving/uploading edited versions work? Users might be upset if they overwrite originals w/lower quality versions & weren't given an option to "save as" or set quality level.
USE CASES & DEVICE SPECIFICS
Assumption: A user on a mobile device will only work on 1 image (maybe 2) at a time.
No mobile device is large enough to show multiple high-res images on screen at once anyway. Keep current image in memory; only show thumbnails of others (saved on disc) until requested for editing & then swap; release/reload resources as necessary.
If your users are using older hardware (pre-retina iPhone 3GS or iPad 2 for example), then a 5-7MB image (anything >3000px per side) might be a bit slow, but newer devices take/handle 8-12MP pictures themselves. Should be well within the device's capability to open/edit one at a time.
Are you saying this is not the case?? Can't even open 1 image? Is it being saved to disc first, or opened in-app directly from web service?
Verify adequate storage space either for the whole batch beforehand, or as each image is saved
If device storage is full, cancel remaining downloads & alert user which images are missing
USABILITY & RESPONSIVENESS
Download the images asynchronously to avoid blocking the UI
Create much smaller low-res thumbnails to act as a placeholder for the high-res versions. Download & show thumbnails first to give a sense of progress, but differentiate between an image that's still loading & one that's available for editing (with a progress bar, transparency, etc).
Download in the background (as you might an "in-app purchase") and save to disc.
Download individually & save to shared location. This keeps them organized as a batch of 10-15, but lets the user start working as soon a the 1st image is available. Don't make them wait for all of them.
Could use a separate "downloads" view w/progress bars & let user continue work in another tab/view
Only once the user selects a thumbnail do you need to worry about loading/displaying the large version from disc. You can release thumbnail/loading view from memory & free up resources if necessary while the large image is being edited. Reload only as necessary.
Auto-save to disc in background to prevent loss of work & take opportunity to clean up caches & whatnot.
If working memory is already a concern, you won't have many options for undo/redo. Most image-editing apps manage this ok though, so there's a way.
We are making an app that will be basically the home for some Android devices.
Based on that, the idea is to have different partitions, for example, one for videos, one for apps and one for photos. What we want to achieve here is to prevent someone uses the entire storage capacity in recording a video, so with these partitions you can make videos until the videos partition gets full, and if this get full you still can install apps and take pictures.
So, here is the question. Is this doable? I know we have the option to make this via "logic", using folders and maintaining the used space count and make some validations. But the partitions approach seems to be more "clean and clear".
Can we make multiple partitions (external or internal storage)?
Can we save files to specific partitions? (I know that Android 4.4 provide some way of doing something similar but we are using Android 4.0/4.1)
Thanks in advance.
i should create app for tablets, which will be shows magazines, every magazine will be have about 60-70 pages, every page has cover as image ( weight about 400kB - 1mb, height over 1200px and width = screen size ), and every page has small cover ( about 20kB ), some pages have mp3, mov and other files, which I must show on this page. When i start first time app, i must download about 200mb, now but in future will be more files, magazines, and pages ;(
When I open magazine, i must load about 70 pages and when i slide screen, pages will be move right - left. When I click on screen, I must show gallery view with small images cover.
Im wondering, that it will be waste of time to create this app, any ideas how i could show images and other files whithout overload memory ? Have You any experience in app like this ?
Think about it: will any user of your app ever see more than one page at once?
To put it even further, when was the last time you did actually read 70 pages simultaneously?
The key to implementing such an app is clever loading and unloading data as it is needed. There are quite some strategies to achieve this, one very simple would be to keep only a few pages (the last, the current and maybe the next two) in memory at a time. This makes switching pages seamless and keeps your memory footprint low. It can be quite hard to figure out the right balance between memory use and responsiveness, but well, thats what it takes. Good luck.
Your application can contain any number of information within itself, but to display correctly you shouldn't immediately load all media files. Currently displayed in only the informations you need. Many standard controls initially work as well (table with reused cells, for example). Small pictures can be cached in memory, when switching between pages removes all old information and upload a new one.
Just start it and success won't keep waiting.
I have a simple app that displays a series of images and infomation about those images. I've set it up so that when a user touches an image, a new activity is launched and they see more pictures and a longer text description about that image. On that screen, I've also implemented the basic gallery widget that they have here in the Hello Gallery Tutorial.
My problem is that even though I'm drawing on images from the res directory (I've thrown everything in drawable-mdpi thinking that there shouldn't be a huge deal), not all of the images on the gallery portion will load. And I haven't been able to reproduce it 100%, but it seems like the more I play with my phone with this app running (lock screen, unlock screen, go to one image, go back, go to another one, hit home, etc), the more likely any picture that I've got loaded up locally display blank image placeholders, gallery or not (the text comes up fine though).
I'm using a series of imagebuttons, imageviews, and gallery widgets. Play with it enough and eventually they all come as blank, but killing everything through AdvancedTaskKiller brings it back.
Sometimes pictures in my image galleries will also be blank when I first launch my app. That's really weird. I have it set so that the layoutparams are 300 by 200 and I've pulled pictures all over the place to populate my gallery. They should just all scale differently, not fail to load entirely though.
Anybody have any ideas on these?
Try Slow Adapter for the Gallery.
I recommend adopting 1,2,3
It is always hard to work with images. You have to be very careful with recycling memory that your images already used otherwise you could get into different kind of troubles.
Always try to use a good Image loading library that commonly being used by Android developers.
Most commonly used library is https://github.com/nostra13/Android-Universal-Image-Loader
It will optimise your loading.