I just would like to ask if these Layouts can hold fragment/multiple fragments. I base this on google play store.
Sorry for bad logic.
Yes, scroll views can hold multiple fragments.
However, managing the fragment stack gets tricky.
Because fragmentManager/ChildFragmentManager will only maintain stack for one container, if I am not wrong.
As long as you don't add them dynamically in run time,it is easy.
i.e. if the fragments are described in the scroll view from xml layout and you don't perform fragment transactions, you are all good.
I have dealt with the same issue, and cost me a lot of trouble but I did implement it. However, if you end up with such a requirement, you might be doing something wrong give other solutions a go and see if you can avoid this requirement.
NOTE : I don't think Google play uses fragments in Scroll Views.
What I see them do is have RecyclerViews within recycler views, if this is what you are talking about
i.e. There are Horizontal RecyclerViews within Vertical RecyclerViews.
In case you are not aware, RecyclerViews are the new version of listViews, they are more powerful and perform way better.
I suggest you don't use listViews, but use RecyclerViews instead.
Related
I am trying to achive this:
First I tried by putting all my recyclerviews (with WRAP_CONTENT) inside a nestedscrollview. That worked, but the performance was awful. Then I tried to set a height for my recyclerviews, that was a lot better (especially the first gridlayout and the horizontal linearlayout loaded very fast), but still had the problem with the dynamic "category" part.
Now I am trying to put all my recyclerviews inside a single recyclerview with different viewtypes. Since that is a pretty big deal (I need to refactor a lot of code because I have diveded every area from the screenshot inside a single fragment and now I need to put all that code inside an adapter) I wanted to ask if I can actually expect any gain from this, because in the end its again a "nestedscrollview" (made by myself, but...). Or if there is some other "best practice" way to achive this layout.
Thank you
Edit:
As expected this didnt do the trick neither. When just the two first recyclerviews are added as viewtype it scrolls and loads smoothly. But as as soon as I try to add the category items (below the category), I notice a lag and especially when selecting multiple categories and scrolling fast up, there is noticable lag. I guess I will have to change my layout and move the category selection part inside a separate view, just need to come up with a user friendly solution. But its acutally quite dissapointing that, in my opinion such trivial task, laying out multiple tables, is such a pain in the ass on android.
I didn't manage to get it working with standard android stuff.
Now I am using epoxy from airbnb ,and I have converted all my views from nestedscrollview to the epoxy recyclerview. Its a great library, and airbnb use it too for all their views.
Nevertheless it's sad that the android dev team doesn't address this problem and provide a solution besides the info "don't nest multiple scrollviews(recyclerviews) that scroll into the same direction".
You can use Recyclerview in recyclerview.
https://irpdevelop.wordpress.com/2016/02/10/horizontal-recyclerview-inside-a-vertical-recyclerview/
And make sure to use multiple view types.
This is not a design question, I have the item designed. I am confused on how to pull it off.
I am tasked with designing a view for Android that has a view of a user's post and the comments under it. The post contains some extra information and widely different design from the comments, but all of them need to scroll in tandem, like a web page would (Oh, how I am spoiled by my years of web dev...).
My current solution is to nest a LinearLayout (at the top of the view to contain the user's post) and a RecyclerView (below the post to display the comments) inside a vertical ScrollView. The information is actually displayed, but the RecyclerView, of course, scrolls independently of the LinearLayout above it and ruins the functionality of the view.
I wish, if possible, to keep the RecyclerView in use
The best case scenario would be to have the LinearLayout with the post scroll a certain amount, and then the RecyclerView take over. However, I don't want to poison my codebase with 200+ ugly lines of code to achieve this, so if this is a laborious task to complete, I would rather look for alternatives.
The first thing to understand is: do you really need a RecyclerView, or even better, do you really need recycling?
If the answer is yes, the way to go is two different item types in the RecyclerView's Adapter (for more details, see here or here). This concept was already present in the ListView: the main difference is that RecyclerView enforce the use of the View Holder pattern. It is not so complex, and, more importantly, is the way the RecyclerView is supposed to solve that problem. Depending on your UI design, you may also want to have different view types for different types of comments (plain text, images, ...). Remember that, when the RecyclerView is included in a ScrollView, the recycling won't work, because all the items in it will be drawn at once to compute the height of the content of the parent ScrollView.
If the answer is no, then you could just create your views at runtime and add them to a parent LinearLayout in a ScrollView. It is really nothing more than a for loop.
A more fancy approach would be to use an ItemDecoration for the user's post, but I don't see any specific advantage in this case.
Do we get any benefits of implementing a ListView for which every item would have different layout? Would it be a better idea to put those items into ScrollView with LinearLayout instead?
Intuitively, it seems like using a ListView may still give better performance, though it might be negligible depending on the size of your content. Because the ListView inflates the views as it needs them, it seems like you might save some time by not parsing/rendering views that a user might never see. A long ScrollView with a bunch of views inside seems like it would take additional time when first launched, since the view hierarchy is more complex.
I do think Michael is mostly correct though, that the main advantage of a ListView is that views are reused, which saves on memory/processing. Unless you have a ton of content in the ScrollView, I suspect the performance difference is not significant, and will almost definitely be more complex -- in particular, having to create an adapter that knows how to create each view type for each row.
I don't understand why you may use ListView for this. Listview is a list of common data using the same layout if you click on it. Users depend on same/similar GUI patterns.
How about Sliding Tabs or the newer navigation drawer, link NavigationDrawer.
If you like sliding tabs, then I can give you more details.
I am not sure if this is even a question worth asking or I am just bit too much overworked to think through this hence, the community help would surely be great at this stage to resolve this issue.
So, my question is that I have some 20-25 screens in my Android app. The app overall comprises of navigation drawer, tabstrips, fragments and lists in most of those fragments (some fragments only have listviews while some fragments have several other components and listviews as well). Now, few of these listviews have slightly similar row views but, not such that I could use the tag "include" due to placement and size issues.
For example, in rowview_1, I have one imageview (ImageView_1) and three textviews (TextView_1, TextView_2, TextView_3) to its right and finally, an imageview (ImageView_2) on extreme right on whose click an event occurs. Whereas, in rowview_2, I have one imageview (ImageView_1) and three textviews (TextView_1, TextView_2, TextView_3) to its right. On extreme right, two more textviews which convey some extra info and an imageview (ImageView_2) beside ImageView_1 and below TextView_3.
So, what would be a better and optimized approach in such a scenario?
1) Having separate multiple rowview layouts
2) Having one rowview with all the static elements in one place and dynamically adding and removing the extra elements (I believe it could be equally expensive for a rowview in a listview).
I am not sure if there can be any other approach. Any idea/guidance is most welcome.
Thanks in advance!
First of all. I think the differences if there are any are very minimal.
Scenario 1:
1) Cleaner code
2) Easier to make changes to one without affecting the other.
Scenario 2:
1) Complicated layout file
2) Does not necessarily take longer to load if everything's visibility is set to GONE in the layout.
One thing to note is that if you are going to load both layouts in the same Activity, you should surely go with scenario 2. When you load it the first time, the activity caches the layout so the next time, it loads super fast. If they are split over different activity, then the cache is gone anyways. Another thing to consider is how often you make changes to both together. If that is going to be often then scenario 2 is better. Changes will be done in one file. I personally prefer scenario 1. Its easier to show someone else who wants to make changes.
Hope this helps.
I am new to android therefore I got a little bit lost with all those ViewFlipper, ViewSwitcher, ViewAnimator and ViewPager. Moreover, I am not sure what's happening under the hood.
Basically I have an activity which shows some data. With swipe (or button, doesnt matter) I would like to scroll the view and get to another page (as seen in the picture below).
Is it possible to implement something like that without changing to another activity?
I am a little bit confused regarding views and access to the design elements. How those pages are located each to another? e.g. If I am currently seeing Page1, can I modify content of Page3? Or plainly saying, are all page views loaded all together? As if I set setContentView(R.layout.xlayout); then I can access only xlayout elements.
But if I use same activity, then I have a thread there which updates a counter on Page1, if I change view to Page 2, the counter will not find Page1 Counter TextView and will complain.
As I Understand Android 4.0 has ViewPager which is similar to the seen in the picture. I am using GB. Should I use support library or can I just go around and implement something similar without importing any libraries?
(Sorry, my description is a little bit messy)
Yes, you can use ViewSwitcher, ViewFlipper and ImageSwitcher depending on your requirements.
ViewSwitcher may have two childs at max. And these child might be a View or an object of subclass of view.
ViewFlipper: May have as many childs you want. and these child might be a View or an object of subclass of view.
ImageSwitcher might be used to switch images over.
By using view flipper you can display one item at a time, and adding a gesture overlay, you can apply sliding effect. To apply View Flipper, you need to add all the views to ViewFlipper, and showNext and showPrevious methods are used to show next and previous child.
You need to use a ViewPager to have the same behaviour as in Google Play.
it only available on recent version of Android, but you can use the Compatibility Package to make it available for older version.
With a ViewFlipper you can't "scroll" between two pages.