In my existing app I am porting two activities to fragments. The case is the classic dual panel mode with a list on the left and the content on the right.
The doc says that I should avoid to manipulate fragments within fragments, passing instead through the host activity. Said that I am using callbacks to the activity.
The first doubt (maybe banal) I have is:
How to avoid to duplicate the same code in the activity that hosts the
2 fragments and into the activity that wraps the fragment when not in
dual mode?
I'll try to explain. So I have:
ListFragment and ListFragmentActivity
ContentFragment and ContentFragmentActivity
because both fragments can live independently from each other, then:
HostActivity
that implements a listener invoked from ListFragment for adding/replacing the ContentFragment
My question is: when ListFragment is instead hosted from ListFragmentActivity, how to avoid to duplicate the code present in the HostActivity into ListFragmentActivity.
Guess I am missing something, thanks in advance.
Get rid of ListFragmentActivity. Have HostActivity handle the case where there is either one or both fragments. Then, by definition, there is no code duplication. See: https://github.com/commonsguy/cw-omnibus/tree/master/LargeScreen/EU4You
Related
I need to do a Fragment that works for all activities (like a banner or something).
I have a HomeActivity, IncidentActivity, ScheludeActivity, etc. but I need to do a fragment or something that could be accessed from all those activities but it need to be instantiate once because it will have a, webview that I don't want to be reloading everytime I change of activity.
Can you give me some advise?
You can create a BaseActivity which these three activities extend from this. The instance of fragment should be single. Your fragment should be retainable(setRetainInstance(true)). Do not forget, you should use the same instance of your Fragment! So, you can control fragment instance in your BaseActivity.
I'm currently using the new navigation component and sticking to the one activity principle, I'm communicating between my fragments using viewmodels, I currently have a scenario where to tie the view model to the fragment (don't want it tied to the activity, this data must die with this fragments lifecycle) I'm having to call
getParentFragment().getParentFragment().getParentFragment()
to me this seems wrong but I have tested it and it seems to work fine, for instance logging the hash codes gives me
D/EnvTabFrag: this fragment 62204288
D/EnvTabFrag: parent fragment 264756153
D/EnvTempFrag: this fragment 169781400
D/EnvTempFrag: parent fragment 66865393
D/EnvTempFrag: parents parent fragment 62204288
D/EnvTempFrag: parents parents parent fragment 264756153
can anyone tell me if theres something terrible that I'm doing here that maybe i don't see or understand, the only potential issue I can see are null pointers, is this an ok approach or is there something I'm missing? many thanks
an example snippet
locationPickerViewModel = ViewModelProviders.of(getParentFragment().getParentFragment().getParentFragment())
.get(LocationPickerViewModel.class);
I want to separate logic fragment from activity but the problem is I make api call and save data in fragment. And when user click a item in fragment. I need to send parcelable data to other fragment to show detail info about item.
Is launching fragment in fragment anti pattern for android ?
I would like to hear some opinion about this matter.
Yes, is totally an anti-pattern, remember that you need to see the Activity as a container and fragments as independent sub-screens, so is the Activity responsibility to manage the fragments. I.e.: If you have a Post activity you can have a PostText fragment, a PostImage fragment and all of that is manage by the activity, every fragment is attached to an Activity.
It is not a common practice to have a nested fragment inside a fragment even it can be done. However, it would be better to have an activity as the centric container for all your fragments. You can use EventBus (GreenRobot / Otto) to separate the concerns and do all the API calls in another class and send the results by subscribing to this event.
In the latest versions of eclipse (ADT v22.6.2) the create android application now generates an activity_main.xml and a fragment_main.xml. It generates only a single activity class
but this now has an embedded inner static fragment class that is created by the activity in its onCreate method
#Override
protected void onCreate(Bundle savedInstanceState) {
if (savedInstanceState == null) {
getSupportFragmentManager().beginTransaction()
.add(R.id.container, new PlaceholderFragment()).commit();
}
....
public static class PlaceholderFragment extends Fragment
My confusion is how to port old code/examples where there was only 1 activity and the main application
logic is usually put in the Activity onCreate method i.e. stuff like findViewById. Listeners
etc
The way I have approached it is that I put all my user created views as members of the static PlaceHolderFragment class. Then I call this in the fragment onCreateView. I still have some logic in the activity and it stores a pointer to the fragment. It updates the views members by calling getters on the fragment. Is this correct or should all logic be moved to the fragment now ?
All the tutorials/examples use the old approach where logic is placed in the activity
so there is no reference documentation for how to use the new files that Eclipse generates for an Android application. Any help appreciated ?
Don't worry about the files that Eclipse generate automatically: You can do whatever that you want!!!
Fragment is a element between an Activity and a container.That's mean that you can put the logic of your code inside of one fragment with not problems.
In theory, fragments are used when you want to manage screens using different modules, containers. It's a fragment, a module, part of one screen (but also can be used in a full screen looking as an activity and with the same behaviour than one activity.) For example, imagine that you have for mobile phone screens, one list of news in one screen, and when you click, your app go to the next screen for show the content of the news, right? Ok, so you can use for these 2 screens: 2 activities for each one or one parent activity with 2 fragments...whatever that you want...
Imagine the same case, for a tablet version of your app, now the left part of the screen you should show the list of news and in the right part of the screen, the contain of each news clicked, right? In that case, would be completly necessary to use one activity parent with two fragments...in that case, we could reuse almost the same case for the mobile phones or tablet.
And now, focus in your question: if you don't want complicate the life (not too much, because work with fragment is easy too) I will recomend you to use only activities for your app.
But, like your question, you want to port, there isn't any problem. Now imagine that your activity is going to be only the class where you are going to manage the fragments. The logic for each screen has to be in each fragment. Use the activity only for replace fragments, or share information between fragments, etc. The activity will be like the orchestra director.
From each fragment, you can access to methods or public variables of your activity using ((NameOfActivity)getActivity()).
Is it clear for you?
One more stuff, in fragment, normally the method that we used for initialize stuffs is onCreateView (and not onCreate like activities).
Just a general question about working with Fragments and Activitys for android development: where does the business end of the functional code go for Fragments loaded into an Activity dynamically? (i.e. a fragment's OnClickListeners, OnCheckedChangedListeners, button logic methods...)
Do they go in the Fragment class, or the Activity class?
All the GUI logic for views attached to a fragment should be contained inside the fragment itself.
Thus a fragment should be as self contained as possible.
You can, though, if necessary do callbacks to your activity based on fragment GUI interaction. This can easily be done like this inside the fragment:
#Override
public void onAttach(Activity activity) {
if (!(activity instanceof SherlockFragmentActivity)) {
throw new IllegalStateException(getClass().getSimpleName()
+ " must be attached to a SherlockFragmentActivity.");
}
mActivity = (SherlockFragmentActivity) activity;
super.onAttach(activity);
}
In this specific case the reason for gaining a reference to SherlockFragmentActivity is to gain access to the support menu inflater mActivity.getSupportMenuInflater(), hence the construction can of course also serve to gain information from the underlying activity.
This probably depends on how much the Fragment's functionalities have in common, and how many, let's say Buttons, have to be handled.
I personally (and it's probably most common practice) handle onClick(...) events separately for each Fragment, meaning that I let each Fragment implement it's own OnClickListener.
Furthermore, when handling everything through the Activity, probably not all the components that react to click-events are in memory at all times and can be reached via findViewById(...), depending on which Fragment is currently displayed and how your user-interface is built up in general.
they always in fragment class because fragment is one type of component in android which we can reuse it. if we put onclick and oncheckchanged in activity then what meaning of reusing that component??
for more information about please go through following step:
Link 1 for basic level of information about fragment and how to handle them
Link 2 for dealing with multi pane fragment
Standard site for fragment
It depends:
If fragment can handle logic which is self sufficient(complete) then that code can be handled by fragment. e.g. on click call phone number.
If fragment have UI whose action is activity specific, then you want to add listener in activity.
e.g. master detail view like email client, on tablet user click on title fragment1 which have list of email titles, then handler on click in activity can show detail fragment2 in activity.
In all you want to keep fragment reusable.