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.
Related
I am developing an android app which needs to load a big image quickly. Using Instagram on Android I have noticed a feature they have that I cannot figure out how it works. Instagram users have a feed which displays usually a scroll list with a bunch of small thumbnails:
When you click an thumbnail image you get sent to another page(assuming fragment) that shows a bigger version of the image which appears instantly (to the human eye it looks instant)
You can scroll through all these thumbnails which means a lot of thumbnails display very quickly which I can understand because the images are small and sending over the network would be relatively quick. The problem I am understanding is how the larger images appear so quickly!? When the app downloaded the thumbnails are the larger images downloaded at the same time (I do not think this is the case because it would be such a waste of network traffic since most users on't click on every thumbnail? What technique is being used to have such fast response times for large images? I thought it maybe because of cache, but it happens when I click a picture I have never seen before.I is so fast it looks like it even is not hitting the network.
How clicking on a thumbnail image produces a a larger image so quickly?
Uses faster CDN networks to fetch images
Uses Fresco for image loading which implements progressive image loading
Uses RecyclerView, image loading is triggered when ever you stop scrolling.
Probably uses webp and jpg image formats
Images are cached for later use
I have a webview which opens a page that shows different images like a gallery.
The image is saved locally on an sdcard and is loaded through css with background-image: url(file://...).
This issue seems (not sure though) to be connected to Android's request for resources for some reason. The longer the OS needs resources the bigger the white (or black) band is.
This doesn't happen always in one test session and affects images randomly (in a cycle a certain image displays ok, in the next it doesn't). Also it seems to affect only images, displaying an iframe is always loaded normally.
I wouldn't have a problem if this happened for one second and then it would display normally, the problem is that the image stays like that until the next refresh of the webview.
android's version is 4.4.2. It is a mk808b plus device if any of this helps...
Any ideas on how to solve or somehow decrease the times this happens... anything really... except using imageview, I want to keep all in the webview. Any directions to follow for further debugging are also greatly appreciated.
Thank you for any help you can provide.
If it is possible I would try converting background images to a vectorial format (like SVG). Rendering should be easier and less memory hungry.
WHAT IM DOING
I'm using the picasso library to display a bunch of images intended to be wallpapers in a gridview.
THE PROBLEM
Selecting an image shows it full screen in a new fragment, this works most of the time but sometimes throws an OOM exception.
In the new fragment with the full sized image I have used .fit() to make the image full screen which makes the app hang for some time but eventually shows the image, most of the time, but selecting one, pressing back, and selecting another stops it working it just shows my other .load() image,
WHAT IVE DONE
ive used .skipmemorycache() which is deprecated and ive allowed for large heap in my manifest, the images are in the app not URLs and they are pretty big, but is there a way to show the images full screen without the lag and to maybe clear it from memory onbackpressed? if i use .resize() the whole thing works fine everytime
THE GOAL
I want to use the full size image it just looks much better and gives a good example of how it would look as a wallpaper. Any suggestions welcome I know this a hard topic and i know the picasso library is amazing so if its not possible just let me know
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’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.