FragmentTransaction in TabListener

[Donn Felker]

In the samples (and in my project for my client) I notice that we have to get the FragmentTransaction from the support fragment manager as such: 

@Override

public void onTabSelected(Tab tab, FragmentTransaction ft) {

getSupportFragmentManager()

.beginTransaction()

.replace(android.R.id.content, FragmentStackSupport.CountingFragment.newInstance(tab.getPosition()))

.commit();

}

You also have to commit it. 

The documentation on the Android site explicitly says to NOT commit the FragmentTransaction here: http://developer.android.com/guide/topics/ui/actionbar.html#Tabs (scroll down after the first example on that anchor) otherwise an exception will be thrown. 

So I have two questions: 

1. Why do we not get a hydrated FragmentTransaction in the listeners (leaving us to have to manually get one). 

2. Why do we have to commit the transaction when the docs say not to? 

I'm sure its something buried in the ABS stack, I'd just like to understand it better. 

[Jake Wharton]

That bug(?) is present in the official compat lib as well and is not an ABS problem specifically (at least as far as I am aware). There was a StackOverflow question I saw a while back that linked to this post by Mark Murphy regarding the very same thing. He links to a GitHub repo of his where it looks like he executes a transaction himself exactly as you do.

I know not the underlying reason behind this. My new philosophy has been to modify as little as possible in the official compat lib classes.

---
Jake Wharton
http://about.me/jakewharton

[Donn Felker]

Thanks for the explanation. 

[Lionel Port]

I'm still new to this api but came across this same problem.

The Android api docs say to implement the tab listener using this
pattern.

public void onTabSelected(Tab tab, FragmentTransaction ft) {

// Check if the fragment is already initialized
if (mFragment == null) {
// If not, instantiate and add it to the activity
mFragment = Fragment.instantiate(mActivity, mClass.getName());
ft.add(android.R.id.content, mFragment, mTag);
} else {
// If it exists, simply attach it in order to show it
ft.attach(mFragment);
}
}

Using ActionBarSherlock it throws NullPointerException as ft is passed
in as null.

From what I can see the two places I'm hitting the problem are not in
the compatibility library,
com.actionbarsherlock.internal.app.ActionBarWrapper passes null to the
onTabSelected method instead of passing through the one provided and
com.actionbarsherlock.internal.widget.ActionBarView passes a null
transaction in the select method. Not sure if the compat library also
has bugs in this area but would be good if the actionbar wrappers pass
the transaction through if its available.

On Dec 9, 8:23 am, Jake Wharton <jakewhar...@gmail.com> wrote:
> That bug(?) is present in the official compat lib as well and is not an ABS
> problem specifically (at least as far as I am aware). There was a
> StackOverflow question I saw a while back that linked to this post by Mark

> Murphy<https://groups.google.com/forum/#!msg/android-developers/pCnSx7sTIZ8/...>regarding

> the very same thing. He links to a GitHub repo of his where it
> looks like he executes a transaction

> himself<https://github.com/commonsguy/cw-advandroid/blob/master/Honeycomb/Fee...>exactly

> as you do.
>
> I know not the underlying reason behind this. My new philosophy has been to
> modify as little as possible in the official compat lib classes.
>
> ---

> Jake Whartonhttp://about.me/jakewharton

[Jake Wharton]

We can't pass the one provided because it uses the native type rather than the compatibility type. That's not to say, however, that we can't just create our own transaction around the tab selection and commit it afterwards which is likely what the underlying implementation does. I'll take a look at it this weekend and see what I can come up with.

[Jonathan Steele]

Is this is what your looking for? https://github.com/JakeWharton/ActionBarSherlock/blob/4.0-wip/library/src/com/actionbarsherlock/internal/app/ActionBarImpl.java#L504

[Jake Wharton]

Well that's 4.0, I no longer depend on the support lib so there is no way to have access to either the native or support fragments. I chose to ignore any fragment transaction, native or support-based, with the implementation of 4.0. Even in adding the support plugin with 4.0 there's no way to conditionally support them.