I put two fragments in an activity. What I want to do is to hide a view from say fragment A when I click a button in fragment B. I have the hiding function in fragment A but how do I call it in fragment B?
I tried:
((FragmentA)getActivity().getFragmentManager().findFragmentById(R.id.fragment_a)).hideLivePreview();
but it gives me a null pointer exception...please help
You do not want to do this in general. Fragment A and Fragment B should not directly communicate, since Fragment A and Fragment B may not both be on the screen at the same time all of the time. They might be side-by-side on a large screen but displayed via separate activities on smaller screens. IMHO, activities should mediate all communications between fragments. If you have two fragments that are too tightly coupled for that, they should not be separate fragments in the first place.
All that being said, you are getting a NullPointerException because there is no fragment with that ID in the activity.
Related
As google suggests single activity based application. I have a situation where I need clarification.
I have one activity containing 3 fragments and each fragment is linked to different fragments having other screens.
should I use only one viewmodel for each tabs or should I use one view model having different screens.
As I have only one activity and view Model resides till activity is destroyed. Do all viewModel that I will create for each screen will contain data until activity is destroyed. If this is the case will it make my app heavy.
should I use only one viewmodel for each tabs or should I use one view model having different screens.
You should use the smallest scope for each ViewModel possible. Generally, this means that data associated with only one fragment should use a ViewModel associated with just that one fragment.
As I have only one activity and view Model resides till activity is destroyed. Do all viewModel that I will create for each screen will contain data until activity is destroyed. If this is the case will it make my app heavy.
ViewModels live only as long as the ViewModelStore they're attached to is around. Therefore if you have a ViewModel associated with a fragment, it'll survive only as long as that fragment exists. For example, if that fragment gets popped off the back or you call remove(), then the ViewModel is destroyed. ViewModels only live as long as your activity if you specifically create them using the activity as the ViewModelStoreOwner (for example, by using ViewModelProvider(activity)).
should I use only one viewmodel for each tabs or should I use one view
model having different screens?
In single activity architecture, you can use ViewModel with either Activity Scope or with Fragment scope. As #ianhanniballake suggested in his answer, use ViewModel with Fragment which means that each tab in your case will have its own ViewModel attached to fragment. This will provide separation of concerns for functionality in each tab.
As I have only one activity and view Model resides till activity is
destroyed. Do all viewModel that I will create for each screen will
contain data until activity is destroyed. If this is the case will it
make my app heavy.
Again answer to this question is connected to your first question and explanation provided to it.
While working with single activity architecture narrow down scope as much as possible. Use ViewModel associated with activity (lets call it Global ViewModel) only to keep data which is used across multiple fragments. This way viewmodel will contain data till activity is in backstack and fragments can use it when required.
This will provide you 2 advantages
ViewModel will not contain additional data which you mentioned in your 2nd question
And most importantly there will not be any data discrepancies while accessing fragment multiple times. For e.g. if you open any fragment, fetch data from api and keep it in Global ViewModel and fail to delete it when remove fragment from backstack then your fragment will show old/obsolete data when you will open fragment next time. To avoid this scenario it is better to keep this data in viewmodel with fragment scope.
I hope this will be useful.
Each Fragment usually should have a ViewModel itself but in some cases where you want to share the same ViewModel instance, you can achieve it with having a ViewModel scoped to an activity.
ViewModel objects are scoped to the Lifecycle passed to the ViewModelProvider when getting the ViewModel it is found on the docs and you might have to read other details there but technically you can scope a ViewModel to a Fragment or to an Activity.
I'm struggling to figure out how to create fragments that have their own layout files and take up the whole screen, as opposed to adding them to the activity's layout.
For instance, in my activity there is a button which should call a RecyclerView Fragment that takes up the whole screen, let the user pick an item, and then return to the activity. All the examples I'm finding though use transactions to add or replace on the activity's layout. How do I make fragments that are inflated from their own layout files and call them from the activity?
And sorry, I'm sure there's a better way to ask but I'm just going through docs and vids trying to learn.
A few line difference between Fragment and Activity:
An Activity is an application component that provides a screen, with which users can interact in order to do something. More details: http://developer.android.com/guide/components/activities.html
Whereas a Fragment represents a behavior or a portion of user interface in an Activity. http://developer.android.com/guide/components/fragments.html
I have a Android app that shows lots of real-time data jammed onto one large scrolling activity.
Now i want to split it up into two simpler screens using fragments, where only one fragment may be on the screen at any one time.
I read up a whole lot on fragments and watched several videos, but before i start ripping up my code to convert it to fragments i wanted to know the following.
If i create two fragments A and B, then while showing fragment B, data comes in for fragment A. Can the controlling activity still communicate with fragment A giving it data even though its off screen? OR do i have to save the data somewhere and then when the user switches to fragment A then I give fragment A the data to be shown, while saving incoming data for fragment B which will now be off screen?
The problem is that right now im not saving any data because everything is on one screen, so as data come in i just displayed it, but if i switch to using fragments i dont know if i can do the same thing by passing the data to the fragments even if they are not on screen at the same time.
Thanks.
If you retrieve your data with multiple asynchronous requests in your Activity, you may create a fragment for each of them and move related retrieval operation into that fragment (probably to oncreateView() method). Then, you can use ViewPager (probably with TabLayout) in the parent Activity to be able to use all those fragments. Therefore, your Activity only deals with setting the ViewPager and leave the rest to fragments.
ViewPager shows one page at a time but it can initialize other fragments as well, even before they are shown. You can use ViewPager's setOffscreenPageLimit() method to increase that range.
In case you need a communication channel between fragments and the activity, you may create callback mechanisms, as described here.
I'm implementing a fragment hierarchy similar to the one described in Fragments (Android Developers).
In adition in tablets in portrait the app should behave as in the second case. My problem is to handle the transaction from an orientation to other.
The first idea I considered was:
From landscape-to-portrait:When the activity A goes to portrait: Remove the fragment B to the view. Start activity B for result passing the propper values for recover the original fragment B state
From portrait-to-landscape: When the activity B goes to portrait. finishes (with the fragment 2 status in the result). The activity A with the result restores and adds the fragment B to its layout.
But this solution is pretty complex and I think it provably is not a nice idea. The alternative solution I have considered is only to have an Activity. That activity layout is:
<FrameLayout>
<LinearLayout>
<Fragment A>
<Fragment B>
<Slot>
For small devices:
The app removes the fragment B and when a item is selected add to the backstack the fragment to the "Slot"
For tablets:
Using fragmentTransactions the fragment B is moved from Its position to the "Slot" using the backstack to behave properly to the orientation changes
I think the second option sounds better but, is the correct way of doing this?
Thanks
If you want my advice, I'd say it depends on way too much factors. I think you should stick with what you find manageable enough. It depends too on how complex your app's screen flow is.
Keeping it in one activity is, for me, a good idea if you don't have that much fragments to manage. An advantage of this approach is that you don't need to fiddle around with the life cycle of two different activities.
Anyway, finding the implementation complex is in a way an indicator that what you're planning won't be manageable for you in the future.
Hope that helps!
I dont get why would you want to do it in such a complicated way. Have one activity on tablets, two activites on phone. Have first activity implement a listener that would fire if list fragment's item was clicked. The activity knows if it is inside single or dual pane mode, so inside that onItemSelected callback method, have it either start a new activity in case of a single pane mode, or replace a fragment, in case of a tablet.
You can also see this, using Master/Detail template when creating a new project.
I read quite some articles about fragments, but I am still confused about how to do what.
I have a MainActivity, which displays two fragments side by side. In one of the fragments I have a button and defined in the fragments layout XML for the button
android:onClick="buttonClicked"
Now I want to implement that method
public void buttonClicked(View view)
I would have assumed that this has to be implemented in FragmentA.java and not in MainActivity.java. But it only works if that method is implemented in MainActivity.java. Why is that? To me that doesn't make sense. Pre Honeycomb a method belonging to one activity stayed in that activity, now on a tablet I am merging many activities to one MainActivity and all the different methods are merged? Whatever do you put for example in FragmentA.java then? What if you have to start you an own activity because this app runs on a handheld, then the onClick method has not to be in the MainActivity but in the Activity which needs to be called then. I am pretty confused at the moment...
I'm not sure what the specific problem is, but maybe this will help.
From the Android documentation on Fragments:
You should design each fragment as a modular and reusable activity component. That is, because each fragment defines its own layout and its own behavior with its own lifecycle callbacks, you can include one fragment in multiple activities, so you should design for reuse and avoid directly manipulating one fragment from another fragment.
That is, you should never manipulate a fragment from another fragment; rather, this should be done through the underlying Activity. Read the "Creating event callbacks to the activity" section in this article for more information (it's important stuff!!).
On the other hand, if you want the button to perform an action within the Fragment itself (i.e. if you wanted a Button click to change the text of a TextView within the Fragment), you should implement this in the Fragment, not the Activity (this is because the resulting behavior is contained within the Fragment and has nothing to do with the parent Activity).
Leave a comment and I can clarify if my post is confusing... I only recently began to understand Fragment's myself :).
Well,
I guess it is related to hierarchy of android context structure.
Activity is host of all child views and hence you can say fragment is actually using its host's context.And that's why when you use onClick with fragment system always searches it in Host activity of fragment.
Check it on.
Android developer onClick attribute description
I haven't checked one thing but you could put a test.
By providing implementation in host activity rather than in fragment,but use onClick on layout file of fragment.It should call parent's method.