I'm trying to add a slidingUpPanel(Sliding up panel) across all activities. This panel consists of a viewpager which in turn consists of two fragments. One of these fragments has a recyclerView (more than 1000 items) and the other fragment has some data that changes dynamically depending on the users' choice. This panel is very similar to that of google play music and soundcloud. Now to display this panel I tested two approaches:
1) I created a base activity and added the sliding up panel to it and then extended rest of the activities to base activity. So this way I have to create only one panel and viewpager.
2) I included the sliding up panel in all activities. But this approach is quite unmanageable as I have create viewpagers for all activities and if data changes in one activity I have to write the code to reflect that change across all activities.
Now the problem with both the methods is that each time I open a new activity, a new instance of the viewpager and fragments is created. So, suppose if I have 1000+ items in the recyclerview fragment, switching activities takes more than 2-3 seconds, because each time new instance of fragment is created and the data is loaded all again. This will definitely result in bad user experience.
Is there any way by which the viewpager and the fragments are created only once(when the app starts) and are destroyed only when user closes the app? And data should not load each time user switches activities. I just want to reduce the activity switching time. Any ideas?
Thank you.
Well, for such ui elements as your sliding panel, which stays the same for many items it is preferable to have a single activity.
So if you have 1 activity, you can have a viewpager inside sliding panel, and that part stays untouched. Next, inside your activity you can have FrameLayout wich can be used to host fragments. Doing this you can achieve single instance of sliding panel and navigation between content with fragments.
Having some heavy data collections makes you wishing minimum recreation of that items.
Two approaches for this are (assuming you're using SlidingUpPanelLayout by sothree)
With bottom navigation view
Easy way to do it is creating a bottom navigation view and keeping it in MainActivity and attaching the sliding up panel layout to the bottom navigation view ( layout_above = bottomnavbar_id ) since bottom navigation stays throughout the app so sliding up panel will also have to stay with it
Without bottom navigation view
Create a frame layout inside MainActivity give attributes width and height as match_parent and create slidinguppanelayout and give attributes gravity="bottom"
make the frame layout stay above that slidinguppanellayout , use that frame_layout to show content your want to show from fragments
that's all
Related
I have a Tablayout kind of a bottom navigation, and I want that when the user clicks in a cardview that I have it sends him to another Tablayout but when that happens the bottom navigation does not appear anymore. That is only possible with activities right?
A TabLayout is just a view like any other. It can be inflated as a part of another view, or as the content view for a Fragment or an Activity. So, you're not restricted to using just an Activity with a TabLayout.
Now, if you want it so that when you click on a CardView you're taking to another screen without a TabLayout, you have a couple of options:
Open a new activity
Since this second Activity is going to have a different content view, it's not going to have the TabLayout from the first activity.
Hide the TabLayout and change the content surrounding the CardView
Since we're sticking with the first Activity, we're going to need to make all of our content changes to the views in the Activity. This means setting the visibility on the TabLayout to View.GONE and potentially lots of changes to the rest of the views depending upon what your layout contains.
I noticed that you didn't mention a ViewPager at all. Typically, this is what will be used with a TabLayout to swap between Fragments when you click on each tab. You could have all of your tabs' content in separate Fragments and then when you click on a CardView, just swap that tab's Fragment out for a different one and hide the TabLayout.
So, to answer your question, it is easier to just open a new activity, but it is possible to not use a second activity if you want to put in the work to modify your first one in runtime.
im developing an application with multiple screens using activities and fragments. The principle behind my decisions to use one or the other are based on the interaction in the application.
I have come to the conclusion that you should use an activity whenever major UI elements remain present after an event has occurred that forces the views inside the UI to change (An example of this can be a tabhost nested in the toolbar styled as the Google Play store android App with multiple fragments as childs. Another example is fragments representing the different rows or clickable elements on a navigation drawer).
So right now im presented with the dilemma of choosing once again between the two (fragment or activity) for a UI element that is going to be present across my whole application. Its triggered by a floating action button that launches a creation tool for an element inside my application and i needed to be accesible across all of my apps screens.
So to sum things up, what i need to know if its better to use a fragment or an activity for an element that is ever present across my whole application.
Thanks in advance
Use Fragments or a compound Views. But both in the right way.
Fragments are thought for reusable combinations of views. Compound Views are Layouts containing views. They are the right way if you want to create views from more primitive views, for example a View containing TextView and a increment- and decrement-button.
Fragments are more Activity-like. They have a real lifecycle. Your description looks like you want to create acitivity-parts. And thats exactly what fragments do.
A Fragment represents a behavior or a portion of user interface in an
Activity. You can combine multiple fragments in a single activity to
build a multi-pane UI and reuse a fragment in multiple activities.
Taken from Android SDK Documentation: Fragments.
I'm currently designing an android app and tried several kinds of general setups, each seeming to have it's downsides.
The app generally consists of three screens (A, B, C), each of those has a list. On list selection it should change to a detail view (A1, A2, A3).
I want each detail view to be swipeable back to it's list.
All I'm sure about is that I have three buttons in the action bar which let the user switch between A, B and C.
Beyond that I tried those setups:
The whole layout is one ViewPager with six fragments. Downside: I have to implement the logic "when and where to swiping is allowed" myself - seemed wrong to me
The layout consists of three fragments, each containing a Viewpager with two fragments. The Viewpager-Fragments are replaced on Actionbutton-Clicks
Downside: I have to forward all State changes to the inner fragments
The layout consists of one Viewpager that gets its Adapter replaced whenever an actionButton is clicked and thus always only has two Fragments at a time
Downside: Fragments are often destroyed and recreated
I hope I made my problem clear.
What general design would you recommend?
I would recommend having fragment with viewpager that would show three fragments with lists. Now, on list item select, I would replace this fragment with item details. When user want to swipe back, i would add custom gesture handling that would call onBack. I would argue if such gesture handling is good design but I'm guessing that you simply need to mimic IOS behaviour (which probably most of us have to do too damn often)
I've got a problem that I'm having problems solving. My app has 2 types of fragments. When the app starts, a fragment with main menu is added to a FrameLayout that I use as a fragment container. This fragment takes up the entire screen. Then, when I choose one of the items in the menu, a corresponding fragment should be loaded into the container, replacing the menu. However, this fragment must only take 1/4 of the screen from the left, and the space outside is to be used by some other fragment.
I was thinking about making 3 FrameLayouts, one for the left side, one for the right and one for the entire screen, but this is going to have problems with fragment transactions, since I would have to keep tabs on which fragments are where and remove them by hand.
Basically what I need is some way to change whether my fragments are loaded into a container that takes up full screen, or a container that takes up only some part of the screen. I probably could do it with tons of trail and error and some code, but I bet there is a really easy way to do this in android that I missed.
Instead of trying to dynamically load these fragments into the various containers, I would suggest having two different Activities.
It sounds like the main menu fragment will only ever appear on its own in full screen. So, make that a full Activity (let's call it MainMenuActivity).
The second activity will have two FrameLayouts as it's contents, with one taking up 1/4 of the screen and the other taking up the remaining 3/4. Load this second activity upon choosing a main menu option and populate the fragments in onCreate() of the second activity.
Hitting the back button from the second activity will return the user to MainMenuActivity.
I've just started converting my apps to use fragments. I have a ListView activity and a "Details" activity, which the user goes to after selecting an item in the Listview. I've converted them to fragments successfully, however, I have a header in the layout of each activity. The ListView has a "reload" icon in the header, but the header in the details does not.
Everything works fine when I'm viewing the app in portrait, but I have a layout in the "layout-land" folder which contains both fragments, so, when viewing in landscape, you see both the ListView and the "Details" view. The problem is the header layout is shown in both fragments.
My question is what is the best practice for covering my layouts to the new fragment setup? I'm thinking, instead of having the header in each fragment's layout, I just add it to the layout that contains both fragments?
Sorry if this is just obvious question, I'm still trying to wrap my head around the whole fragments paradigm.
That's why the use of ActionBar is recommended. If you include an action bar in your app with a refresh button , users will know (and learn) to use that button. The onClick implementation is all yours and you could refresh the list adapters accordingly. There is no need to then build these UI elements in all your controls.