I am creating a tabbed application using a FragmentPagerAdapter and android.support.v4.view.ViewPager. In order to follow best practices and separation of concerns I have separated my app into several different fragments. Each of the fragments has an interaction listener that requires an Activity to subscribe to. Since I only have one activity in the entire app do I have to make the parent (tabbed navigation) activity implement all the listeners in the entire app? This seems like it would be bad practice and create one large monolithic Activity class that controls the flow of everything.
I have three fragments inside of another fragment that I use as a home page tab. The home page fragment implements the interfaces of the three sub fragments. The problem is that the home page fragment is not an Activity so the sub fragments throw an exception on onAttach.
What am I missing? How can I implement fragment listeners in a tabbed application without making one large and messy Activity class
After researching further with different keywords I found a good answer here: https://stackoverflow.com/a/23144683/2435006
They key was to make an onAttachFragment(Fragment f) method rather than using the onAttach(Activity a) and calling it in the onCreate method.
Here is the example from the answer above:
public void onAttachFragment(Fragment fragment)
{
try
{
mListener = (OnInteractionListener) fragment;
} catch (ClassCastException e)
{
throw new ClassCastException(fragment.toString() + " must implement OnInteractionListener");
}
}
#Override
public void onCreate(Bundle savedInstanceState)
{
Log.i(TAG, "onCreate");
super.onCreate(savedInstanceState);
this.mContext = getActivity().getApplicationContext();
onAttachFragment(getParentFragment());
....
}
I think you need a good sample related to Fragments. Here is a sample with detailed explanations # ViewPager with FragmentPagerAdapter. The listeners are at onCreateView method at the Fragment. You don't want to set a bunch of listeners in the Activity.
Related
I have a two problems and struggle for a few days. I am not sure what the right way is.
I want to combine a tab layout with a view pager containing three fragments (the tab layout and the view pager are the home screen) and a navigation drawer.
And I think that everything you can navigate to from the drawer should be a fragment accept settings or something similar.
So should I let the tab layout in the layout of the main activities layout or should I put the this layout also in a fragment (so view pager with fragments inside a so calling home fragment)?
When starting the app I check if the user is logged in and if he is download data from Firebase. I do this in another fragment (data fragment) there I setretaininstance to true.
So currently one of the tab fragments needs the data from Firebase but soon all of them will need it.
How do I pass the data (Lists) from the data fragment to the tab fragments or the so called home fragment and then to the tabs.
I already tried interfaces but I don't know how to handle confirmation changes.
Considering the two problems or the combination of both how would you solve this / which design approach is better only use fragments or let the home screen inside the main activity and change the view when the user navigates from the drawer to fragment?
PS. I will add some code as soon as possible.
Thanks.
TabLayout and the ViewPager should be in the Activity layout since it makes more sense, as the Activity manages the Fragments. Also, navigation drawer should navigates through Activities, and Activities between Fragments. Again, that's the logical thing for a decent code organization, and it prevents repetitions in layout (AKA more than one button to navigate to the same fragment).
For the Firebase issue, I suggest you start the call in the Activity, and then call a function in all fragments with the retrieved information. Something like this:
new ValueEventListener() {
#Override
public void onDataChange(DataSnapshot dataSnapshot) {
for(MyFragment f : mFragmentList)
f.addData(dataSnapshot);
}
}
If you really want the Fragment to make the call to Firebase, then you can create you own Event and Listener set.
public class SnapshotRetrievedEvent {
private static List<SnapshotRetrievedListener> listeners = new ArrayList<>();
public static void addListener(SnapshotRetrievedListener listener){
listeners.add(listener);
}
public static void notify(DataSnapshot snapshot) {
for(SnapshotRetrievedListener listener : listeners)
listener.onSnapshotRetrived( snapshot );
}
}
public interface SnapshotRetrievedListene {
void onSnapshotRetrieved(DataSnapshot snapshot);
}
Then in your Fragment waiting for the snapshot, you add the listener like this:
SnapshotRetrievedEvent.addListener(
new SnapshotRetrievedListener(){
#Override
public void onSnapshotRetrieved(DataSnapshot snapshot){
// Do stuff
}
}
);
onSnapshotRetrieved will be called when you call SnapshotRetrievedEvent.notify(snapshot) in your other Fragment.
Hope this helps
I have seen a few versions of this question before, but the reasons for this exception were different than my own it seems.
What I am trying to do:
-Main Activity class has a toolbar at the bottom, clicking the buttons will display a series of fragments, one after another.
- A class EditItemFragmentManager, which is instatiated on a button click, and has methods that display specific fragments based on the toolbar button clicked.
I would like to use this manager class I created because it cleans my code up significantly and will make adding more features later helpful.
Here is my EditItemFragmentManager class, I am not sure if extending Activity is a good idea or not, I think that it will put my MainActivity on pause
public class EditItemFragmentManager extends Activity{
//instance variables
public EditItemFragmentManager(){
// initialization of some variables
}
public void editItem(){
editItemSequence();
}
private void editItemSequence(){
EditNameFragment enf = new EditNameFragment();
FragmentTransaction fragmentTransaction = getSupportFragmentManager().beginTransaction();
fragmentTransaction.add(editNameFragment, EDIT_FRAG_TAG);
fragmentTransaction.addToBackStack(EDIT_FRAG_TAG);
fragmentTransaction.commit();
}
}
So it blows up when commit(); is called, giving me
java.lang.IllegalStateException: Activity has been destroyed
This is how I am trying to get this fragment from my MainActivity,
#Override
public void onClick(View view) {
EditIteFragmetManager manager = new EditIteFragmetManager();
manager.editItem();
}
I am still learning about the Acvtivity lifecycle in Android. I think my problem is something due to this class extending Activity, which puts my Main on pause, and the FragmentTransaction has nothing to commit to? If so, I need to get the existing instance of my main activity and call it on that? This is where I'm a bit lost, if anyone who understands the lifecycle of Activities/Fragments explain how I could go about implementing this while still having a helper class such as this?
If you're using the SupportFragmentManager, then you need to extend from FragmentActivity, and not just Activity. Also make sure that you imported the Fragment from the v4 support library, and not android.app.
Other than that, you seem to be instantiating a subclass of Activity with "new", which is terrible. Create activities only using Intents.
I solved this issue by moving my manager class to become a private inner class of my main, since they are so tightly coupled. No fragment issues now.
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.
In my app there are two fragments (MenuFragment, BasketFragment) and they are located in actionbar tab in navigation mode.
In MenuFragment i hold objects of Product class (Parcelable) in ArrayList in a listview. What i want to do is to carry product to BasketFragment in runtime when i click the item.
I have tried to do that with callback interface and bundle approaches so far and i have always faced with NullPointerException.
Please help me with that. If you would give code example, will be very appreciated.
Using a callback interface is the right way to do this. Without seeing the stack trace for the NullPointerException you were getting I'm going to assume it was because the callback wasn't correctly set. I think if you do it in onAttach() it should work correctly:
#Override
public void onAttach(Activity activity) {
super.onAttach(activity);
try{
mCallback = (BasketCallback)activity;
}catch(ClassCastException ex){
throw new ClassCastException(activity.getLocalClassName() + " must implement BasketCallback");
}
}
Then, you can call your callback method from your fragment, and have the activity pass the object on to the second fragment using getSupportFragmentManager().findFragmentById(R.id.basket_fragment);
I'm wondering why are the Fragments communicating through the container Activity are called reusable.
From: http://developer.android.com/guide/components/fragments.html I know that:
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.
Let's take an example; I have a DateSetFragment which contains two buttons; first button fires TimePickerDialog (FragmentDialog) which allows user to pick an hour and the second one DatePickerDialog (FragmentDialog) which allows user to pick a day. At the end gathered data should be sent back to the DateSetFragment.
According the: http://developer.android.com/training/basics/fragments/communicating.html:
All Fragment-to-Fragment communication is done through the associated
Activity. Two Fragments should never communicate directly.
communication between fragments should be done via interfaces through the container activity. Given that I should send my collected data from both Fragment Dialogs to the container activity and then from the Activity back to the DateSetFragment. I don't see how this make my DateSetFragment reusable and modular in any way. Doing so I have to implement fragment interfaces and some crucial logic in my container Activity which makes it connected with it.
The question is; Is it wrong in this situation if Fragment Dialogs will communicate directly with the DateSetFragment ?
It is "modular" because those interfaces are well defined and explicitly implemented by the hosting activity.
Anywhere you drop that fragment in, if the activity implements the callback interface defined by the fragment events the activity can choose what to do depending on what environment the fragment is attached in.
Example,
DatePickerFragment extends Fragment {
public interface DatePickerFragmentEventListener {
public void onDateSelected(DateTime dt);
}
}
Activity1 extends Activity implements DatePickerFragmentEventListener {
DatePickerFragment mDatePickerFragment;
OtherFragment mFragment2;
#Override
public void onDateSelected(DateTime dt) {
mFragment2.setSomeViewsText(dt.toString());
}
}
Activity2 extends Activity implements DatePickerFragmentEventListener {
DatePickerFragment mDatePickerFragment;
#Override
public void onDateSelected(DateTime dt) {
SharedPrefClient c = SharedPrefClient.getInstance();
c.setExpirationDateTime(dt);
}
}
I have a dateTimePickerFragment (or whatever), in one activity I have 2 fragments, when you change the date on the picker I want to update the other fragment's text view to display that date. In another activity I might use that exact same callback to write the chosen date to SharedPreferences.
The point is that the Fragment is a contained piece of UI interaction, and certain events it will notify the enclosing Activity of what just happened to it, so that the activity dictates that the result of an action on the fragment does to either other fragment or the application itself. There is no reason to implement a custom fragment for each and every situation.