I'm trying to create an activity that consists of multiple layouts (imagine newspaper sections like 'News', 'World News', 'Sport'...and so on) that periodically change their content. So every x seconds a different news story is shown.
What's the most efficient way to do this in android?
I started out with my own layout. And just updated the different TextViews and ImageView programatically. That worked fine, except for image loading, as for the lack of view recycling the image was reloaded every time a certain story was displayed. This caused a noticeable lag (even when using Picassos image caching) as all the layouts were updating their news story at the same time.
Than I looked at ViewFlipper. Now I inflate multiple layouts programatically (one for each news story) and add it to the ViewFlipper (one for each news section). Once that is done everything runs pretty smoothly. But it takes ages until all those layouts are inflated.
So what's the best way to go here? I couldn't find any good examples online but maybe I'm just missing the right term to google for.
Thanks for any help.
Consider using a looping ViewPager. A ViewPager typically will preload the side of the pages when the current page is displayed, so that reduce the lag. There's a library for that. https://github.com/imbryk/LoopingViewPager. Hope this helps.
Related
I have this situation I wanted to discuss:
I have a listview that it's purpose is show 25 stores.
For the design I want I have:
2 layouts, the first one has:
1 big photo of the store (downloaded from a database).
1 icon if the store belongs to the best rated stores list (that icon is on my app)
1 textview (downloaded string)
the second has:
3 textviews.(downloaded string)
Everytextview has a custom typeface.
As you can Imagine, this is a huge task for each item.
My main question is:
Wouldn't I get a much better performance if I downloaded everything and instead of making a listview I populate a scrollview with this data?
It might take a bit more to create the layout but probably it would be smoother scroll or am I wrong?
You can do the same with ListView (download everything and display), but I don't think that "downloading everything" will actually bring any performance improvements (except you're talking about cache).
ScrollView will lead to much worse memory performance as you'll have to create and keep 25 views at once. On contrary, ListView reuse the same views while scrolling which will result in creating approximately as much views as it can fit on the screen.
With ScrollView, if dataset changes, you have to somehow repopulate your 25 views. In worst case recreating all views.
Moreover, going with ScrollView you'll have to deal with 25 big photos in memory at once which will probably give you nightmares for a few days.
From my experience, if the number of elements in the list is less than 50 and the layout is not using too much memory, then you might be better off using a scrollview.
ListView is designed for much bigger dataset, and it's designed to reduce memory usage rather than performance. There are tons of work that Google put into it to optimize its performance. Together with viewholder pattern and modern hardware, and the perceived performance is close to fully populated scrollview.
But again, why need Listview if the dataset is small enough that doesn't affect memory usage? ListView is tricky to use when combined with fancy animation due to the underlying funky optimization done by Google.
What I have learned from a similar problem is that the scrollview is smoother that the listview. My case was to opt one for the navigation drawer, because smooth inflation and scrolling in the drawer has direct impact on user experience.
I first adopted the listview but it was by no means smooth. Then I found that found here that google developers use scrolview instead of listview for the drawer that works smooth for me either.
But if lazy loading of the list items is what you require(not in my case), then you should go for listview.
Currently, I am having a ListView with different list item view for each row (Most cases Different).
I am having 6 different item layout, I will add more in future, and I will have only like 5-15 list items, some time may be less and may be many in other cases.
Some item views contains:
ViewPager
ListViews
ImageViews
Texviews
Gridviews
CAROUSEL
Webviews
As this is dynamically generated depends on data, I am facing following issues :
Scrolling Slowly (Some Times)
List Item height
Performance
Is RecyclerView the best solution in this case?
Without seeing your code to identify specific concerns, it's hard to address specific reasons why you are seeing such performance problems. Such as, are you properly using the ViewHolder paradigm? Or are you inappropriately loading stuff on the UI thread when it should be loaded on a background thread? Android has a small section talking about scrolling smoothly with a ListView you should check out. That aside,based on what you have mentioned so far...I think you major problem is design.
Problems
If your ViewPager is using a FragmentPagerAdapter...then that will definitely be causing a lot of overhead and performance drag.
ListView: You should never ever place a ListView within another ListView. This will cause all sorts of problems. Android does not like embedding two scrollable widgets that scroll the same direction. Even if this worked, it'll cause some major performance problems.
GridView: Same goes with the GridView. You should never ever place a GridView within another ListView. Even if this worked, it'll cause some major performance problems.
If you're ImageView is loading some large graphics, it should be on a background thread and not the UI thread. Else you'll get some slow performance
Carousel - I have no idea what API this is but if it scrolls vertically, then it's a no go.
WebViews are a very heavy weight object. I can definitely see this guy slowing things down, especially if it's loading a lot of content.
To build off what #Joffrey has said. There are some major concerns in your choice of UI. Based on what you are placing in this ListView tells me that you need to seriously rethink how to display your content to the user. Eg, try using a TableLayout or GridLayout instead of a GridView.
Apology if this has been asked before, but I've tried googling the topic without any good result. Basically I'm trying to find a replacement for Gallery widget which Google has decided to deprecate. So far I have the following candidates:
ViewPager. Unfortunately (as far as I know), you can only display one View at a time. I know someone has posted a workaround for this here: https://gist.github.com/devunwired/8cbe094bb7a783e37ad1. But I'm having problem with this approach. On my phone, three images are shown (horizontally). The most left & the most right are static, while the middle one is scrollable (like what ViewPager should do). i.e. the most left & most right image doesnt scroll as I scroll the ViewPager. So I have to turn down this solution.
GridView. Seems good, but it seems like GridView is designed to be scrollable horizontally & vertically. I just want one row, and scroll horizontally. As far as I know, Gallery is not designed with this in mind.
HorizontalScrollView. Another one that Google has suggested in the Javadocs (apart from ViewPager). Seems like a good one to use, but... if i understand it correctly, using this approach all the contents are going to be instantiated up front. There is no lazy loading..
So I'm puzzled right here. Seems like the best solution is to either use ViewPager with only one View at a time (undesirable for what I want), or stick with Gallery.
What do people think??
Thanks in advance!
android.support.v4.view.ViewPager is the definitive answer.
You can display any number of pages (Views), it all depends on the PagerAdapter. It has a method .getPageWidth(position), which gets called for each page. If it returns 0.5, for example, the page will only be half the width of the ViewPager.
Don't stick with Gallery, as it has memory leak issues.
So, lets say I've got my activity all set up, and it loads facebook names and users as well as some other things in a layout, and I just add a layout for each facebook user.
So I have a giant scrollview with a row for each user. Essentially a listview.
This can get up to 250 users, which causes a pretty huge loading time.
Now, the issue is, there is a lot to change if I want to convert this into a listview for the built in lazy loading. Is there any way to implement lazyloading into a scrollview?
Using a ListView and Adapter is lazy-loading in a scrollable view. It's the right solution, and it's pretty easy to set up. Doing anything else will just cause you more problems down the road. Take what the SDK gives you instead of trying to implement it yourself.
Maybe you can cache the result from your last loading, and display those first. Then you can slowly refresh each frame.
I have implemented a ViewPager in my app, and aside from the swipe paging, I have buttons for "Next" and "Back", with a simple onClick method with the only line being a setCurrentItem for the ViewPager.
While the paging animation is completely smooth during swiping, it is more or less instantaneous (just flips instead of scrolling) when I click Next or Back. There is no visible "scrolling" motion, or sometimes barely visible, however not even close to smooth. It does not hurt the usability of the app in any way, since the transition still happens immediately, but visually it looks a lot less appealing, and the user experience suffers.
Now, I suspect it has something to do with the app drawing the next View and therefore "skipping" the animation. My instantiateItem uses LayoutInflater and a simple switch statement to inflate each view (4 pages at most), and I am loading custom ListViews inside each case in the switch statement. The custom ListViews are at most 3 items long, with a TextView and an ImageView in each row (ImageView resource is 5kb in size). To me it seems this amount of objects should not be reason enough to slow down the paging animation.
Aside from that, I also have a custom background assigned to my app in styles.xml, and this is the background used through every activity (160kb in size).
Those are the only things that I think could be slowing down the app, since the onClick method contains only one line (setCurrentItem), so nothing aside from going to the next view is happening in the app, and the instantiateItem is the simplest implementation of the method possible that I know of.
Things I've tried:
Setting the ViewPager's setOffScreenPageLimit to 4, which I thought would pre-load the views and eliminate any loading in between paging, but in the end setting it to 0 seemed to make the thing slightly more likely to show at least a frame of animation
Optimizing the custom ListViews by using convertView to reuse old views, while it did result in more of the animation being shown, it still wasn't completely smooth, varying from "almost perfect animation" to "instant flip"
Removing the custom background, which together with the above two fixes lead to an almost good enough solution, but still resulted in flips every few steps.
The tinkering described above leads me to believe it has something to do with the views being loaded, but I've not found a good solution for pre-loading these to the desirable effect.
Knowing my newbie programming skills, I know there is a sure fire way to solve this without resorting to gimping the design of the app itself, but reading through the documentation, Stack Overflow questions, Googling for advice, I've just ran out of places to look to.
To sum up this probably too verbally descriptive post my main questions are:
Is there a way to ensure the animation of the ViewPager is executed smoothly? A separate thread perhaps? As I understand though, UI stuff should only be on the main thread, where it already is, and nothing else aside from the view loading is executed anywhere in the code when paging.
Should I be using a different way to load the pages? Would Fragments help?
Thank you for any advice.
ps. The lack of code is due to the methods in question being the most basic implementations possible, but I will provide the code if necessary.