I have looked at this topic to dynamically add views when needed: Add and Remove Views in Android Dynamically?
However, I have a few questions.
1) Will there be a visible stutter or lag when creating these views on the go? For example, I use a panel system where each panel holds a separate view. However, these panels could reach a high number in quantity (40 odd panels?) when the program is complete. In order to preserve resources, I want only the view that is currently visible to actually be created, and the others views to not be instantiated until they are brought into the visible region. I have been told to use a ViewFlipper, but due to animation and user interaction requirements of my program, I cannot use a ViewFlipper, but have something along the same lines that I have created.
For example:
Imagine one of my "panels" to be pretty much like a screen in the Android Home launcher. The thing with the Home Launcher is that all it's views can be kept alive at any given time, because there's only really 7 of them. However, seeing as there are closer to 40 in mine (not all left and right, some above and below as well), I cannot have them all instantiated at the same time, or else the phone will begin to lag.
2) What is the code to destroy the views once they aren't in the visible region?
My program will determine when the panels are in the visible region or not, hence I will only need the code to destroy the views on the go.
Thanks.
Why don't you use a ListView or a GridView?
If you are not willing to use some of those, you will need to do something similar to what they do with the Adapter and how they recicle views.
Related
I am creating layouts at run time using heavy data, and adding these layouts to a scroll view. After the view get created, its working fine. The problem here is, the data is very heavy and it takes more than a minute to create the screen, which is not so good user experience. I want to create layouts only for the part of screen that are visible, and rest I can create on scrolling the scroll view. Pls suggest how is that possible? Also, If someone has a better approach, Pls suggest.
You can start by creating only a set number of views each time[1], but always add a dummy 'loading' view at the end of the list if there are more views 'pending'. As soon as the user scrolls the ScrollView at the end of the list, start loading the next part of views on a background thread, and as soon as they are built, remove the dummy loading view, and add the new views into your container.
An other approach would be to start loading the next group of views, as soon as the previous group is done finish, but that might be a waste of resources.
An even better approach, is to combine those two methods described, and always have the next group of views being created, if the user is halfway done scrolling to the end
You can check how to know when the scrollview scrolls to the bottom here: Android: Detecting When ScrollView Hits Bottom
[1] Since you care about UX I would suggest that the number of rows should depending on the row's height and device max height. I.e. 4 views on a small device, 6 on a medium, 10 on a large.
In my app, for instance, when a user creates a new post, he or she can select a type of media (photo, video, text, place, etc.) and then review it in the following activity.
The way I have been doing it is to have all of the views (i.e. ImageView, VideoView, WebView, etc.) there, but set their visibility to invisible, unless the user chooses that type of media.
For instance, all of the views are invisible until the user takes a photo and then only the ImageView is visible. This seems wasteful though. Before I start the activity, I know which type of media the user chooses, but still have the invisible, unused views.
Would it be smarter to have separate layouts for each type of media with the repeated elements (the create post button, the privacy and venue buttons, etc.)? But this would violate the DRY principle...
How costly are invisible views? What is the correct way of doing this?
Depends on the complexity of the Layouts, I had this issue in previous app, in first iteration I did like you, but in 2nd iteration I found its hard to optimise single layout with bunch of invisible views; much less the if else cases to toggle views visibility.
and about layout performance, also it depends on layout/design complexity, I don't think unused view will consume that much of memory or cpu.
so if your layout is simple, its okay for now, if not I recommend to use separate layout for each design/type.
and as #ashishduh said, the best is to set visibility to GONE instead of INVISIBLE, since the parent layout will not measure GONE views, but this doesn't prevent view usage of memory or cpu (mostly in custom views)
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.
I Build a Custom Launcher.
The launcher is made of views (each view will contain applications, images etc..)
The user can switch between those views in the home screen (almost like in every other laucncher)
the big difference is that in the launcher i build, when the user is in a specific view, he should be able to see the edges of the prev and/or the next view (if those are exist)
I tried to implement it by having a Horizontal Linear layout that holds the views.
It performs pretty nice, but not smooth enough.
I Concidered using viewflipper, but the problem with it, is that i can't see the prev and the next view.. (am i right?)
How should i implement this system?
thanks
Try to use ViewPager (android.support.v4.view.ViewPager). You need to download this .jar file to use it. http://developer.android.com/sdk/compatibility-library.html
Gallery already does this. It has issues with the smoothness and predictability of the left/right scrolling, but it will easily show your central view and the edges of the two neighboring views.
I am newbie to android so this might be one of the dumbest question you face.
I am developing UI in Eclipse through drag-drop.I have added many elements in one screen now
the window where you drag-drop UI elements is not growing/scrolling beyond a capacity.
So I am not able to see newly added elements.
Please check image for more details..
You can observe elements after Storage Position are not visible.
How to check other elements or cant we add elements beyond a certain number/size ?
~Ajinkya.
You can add as many elements as you want. I can see a bunch of LinerLayouts for each of your items, but each linear layout is one row and has a horizontal orientation, correct? I'm not sure what you have as your overlying view, but make sure that all of those items are inside of a LinearLayout with vertical orientation. You can wrap that in a <ScrollView> to add a scrollbar to it. Here is a Scrollview example
Side note: Also, the drag and drop is nice to look at, but I've always had a better experience directly editing the xml, even if I started creating the layout with the GUI. It's easier to tell what is going on with each element and make changes. It's best to check the way everything looks in the emulator too, sometimes it can look different than in the GUI editor, especially if items are put into your interface programmatically.