I decided to not use fragments for now, although Android wants developers to now use it.
But I don't find it useful at the beginning. Unfortunately my IDE prepares everything to use fragments, so my question basically is, how to I get rid of everything, thats necessary for fragments? Is there a way to create a project without fragments? Thats what I did:
package com.pthuermer.juraquiz;
import java.io.IOException;
// import com.pthuermer.juraquiz.QuizActivity.PlaceholderFragment; // only necessary for Fragments
import android.support.v7.app.ActionBarActivity;
import android.support.v7.app.ActionBar;
import android.support.v4.app.Fragment;
import android.content.Intent;
import android.media.MediaPlayer;
import android.os.Bundle;
import android.view.LayoutInflater;
import android.view.Menu;
import android.view.MenuItem;
import android.view.View;
import android.view.View.OnClickListener;
import android.view.ViewGroup;
import android.widget.Button;
import android.os.Build;
public class AppLaunch extends ActionBarActivity {
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_app_launch);
/* FRAGMENTS
if (savedInstanceState == null) {
getSupportFragmentManager().beginTransaction()
.add(R.id.container, new PlaceholderFragment()).commit();
}
END FRAGMENTS */
// code goes here...
}
#Override
public boolean onCreateOptionsMenu(Menu menu) {
// Inflate the menu; this adds items to the action bar if it is present.
getMenuInflater().inflate(R.menu.app_launch, menu);
return true;
}
#Override
public boolean onOptionsItemSelected(MenuItem item) {
// Handle action bar item clicks here. The action bar will
// automatically handle clicks on the Home/Up button, so long
// as you specify a parent activity in AndroidManifest.xml.
int id = item.getItemId();
if (id == R.id.action_settings) {
return true;
}
return super.onOptionsItemSelected(item);
}
/**
* A placeholder fragment containing a simple view.
* Useredit: not going to use fragments for now.
public static class PlaceholderFragment extends Fragment {
public PlaceholderFragment() {
}
#Override
public View onCreateView(LayoutInflater inflater, ViewGroup container,
Bundle savedInstanceState) {
View rootView = inflater.inflate(R.layout.fragment_app_launch,
container, false);
return rootView;
}
}
*/
}
I think many people in the Android community will agree that fragments are not easy to handle and even draw new problems, some of them without even a decent proper solution.
Nevertheless, trying to remove all fragments from an app is not an easy task and might require good Android programming skills. You will have to convert your fragments either to views or activities, and that is not so easy to do, especially for activities containing multiple fragments.
The best option so far is to use mortar from Square, but this alternative is not totally ready and mature yet and using it requires, TMHO, advanced Android skills.
So, if I were a relatively new programmer in the Android world, I would keep fragments, get used to them, understand how they can be used to create reusable components and make apps that work on both phones and tablets.
After a while, when you will master them, you will find their drawbacks, and be able to look for alternatives.
I tried to study mortar from Square three times and still I haven't the slightest idea how to use it. So I went ahead and used Kotlin+Anko, switched all Fragments to Views and I'm more than happy - the code base is three times smaller, no dirty Fragment hacks, no NPEs that view has not been created for unknown reason, etc. Just implement views as follows:
class QuestionnaireView(ctx: Context, questions: List<Question>): _LinearLayout {
init {
orientation = LinearLayout.VERTICAL
for (question in questions) {
verticalLayout {
textView {
text = question.title
}.lparams(matchParent, wrapContent)
... etc - generate answer fields as necessary
}.lparams(matchParent, wrapContent)
}
}
}
Advantages:
Pass parameters using constructors like a human being, not via retarded arguments Bundle
No longer worry about the Fragment lifecycle and whether onCreateView() has yet been called or not.
Gets rid of exceptions thrown in Android's moveToState() mammoth method
Get rid of thousands layout.xml files stored in a single directory
Get rid of that styles.xml horrible mess
No need to define multiple layouts just to show a list+details on 720dp devices: just add if(screenWidthDp>=720) { detailView {} } to your init block.
Disadvantages:
No layout previews
Android Studio will become so slow it's almost useless.
You'll need to generate IDs for those views, otherwise their state will be lost on rotate
Related
I have built an app for crypto currencies, to maintain a portfolio. I planned to show the latest news items in the same app.
The whole project is an Android app done in LibGdx.
Question
How to have a webview for the area "Part-B"?
LigGdx have anything like WebView?
Does LibGdx has any extensions to take care of WebView?
Screenshot
Starting with your last two questions; no. LibGDX does currently no extensions, nor native support for webviews or something similar. You can, however, create a custom layout. LibGDX has a initializeForView method, which you can use to grab the View itself. This is inflated in a Fragment, which is added to the layout itself. The WebView is then the other view.
First off, the launcher:
import android.os.Bundle;
import android.support.v4.app.FragmentActivity;
import com.badlogic.gdx.backends.android.AndroidFragmentApplication;
public class AndroidLauncher extends FragmentActivity implements AndroidFragmentApplication.Callbacks {
#Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.gdxwebview);
// Create the fragment
GDXWithWebview fragment = new GDXWithWebview();
getSupportFragmentManager().beginTransaction().
add(R.id.fragmentRoot, fragment).
commit();
}
#Override
public void exit() {}
}
Since fragments are involved, the launcher is different from the generated launcher
For the fragment:
The reason behind using a fragment is to inflate LibGDX into the fragment, which ends up as a sub-unit of the activity. If you set the content view in the activity, you will not get a WebView in there as well.
import android.os.Bundle;
import android.view.LayoutInflater;
import android.view.View;
import android.view.ViewGroup;
import com.badlogic.gdx.backends.android.AndroidFragmentApplication;
public class GDXWithWebview extends AndroidFragmentApplication{
#Override
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState)
{
// return the GLSurfaceView on which libgdx is drawing game stuff
AndroidApplicationConfiguration config = new AndroidApplicationConfiguration();//Configure with whatever you need
return initializeForView(new MyGdxGame(), config);//WARNING!! Replace MyGdxGame with your game class.
}
}
And finally, the layout. It's a basic layout, and the weights (/sizes) may need tweaking for you to get it to look just like you want it to
import android.os.Bundle;
import android.support.v4.app.FragmentActivity;
import com.badlogic.gdx.backends.android.AndroidFragmentApplication;
public class AndroidLauncher extends FragmentActivity implements AndroidFragmentApplication.Callbacks {
#Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.gdxwebview);//The layout; comes later
// Create the fragment
GDXWithWebview fragment = new GDXWithWebview();
getSupportFragmentManager().beginTransaction().
add(R.id.fragmentRoot, fragment).
commit();//Add the fragment
}
#Override
public void exit() {}
}
In addition, if you plan on using the WebView to go online, you need the Internet permission (if you use it to execute JavaScript or other web content locally, without going on the Internet, you shouldn't need it):
import android.os.Bundle;
import android.view.LayoutInflater;
import android.view.View;
import android.view.ViewGroup;
import com.badlogic.gdx.backends.android.AndroidFragmentApplication;
public class GDXWithWebview extends AndroidFragmentApplication{
View root;
#Override
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState)
{
// return the GLSurfaceView on which libgdx is drawing game stuff
AndroidApplicationConfiguration config = new AndroidApplicationConfiguration();//Configure with whatever you need
root = initializeForView(new MyGdxGame(), config);//WARNING!! Replace MyGdxGame with your game class.
//declaredInTheClassWebView = (WebView) root.findViewById(R.id.webView);//For initialization, make sure you call root.findViewById, not findViewById. You have to specify the view in which to find the ID when dealing with Fragments.
return root;
}
}
And per the LibGDX documentation on use with Fragments, you also need the v4 support library. Assuming you use Gradle 4.1 and Android Studio:
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation="vertical"
android:layout_width="match_parent"
android:layout_height="match_parent">
<FrameLayout
android:id="#+id/fragmentRoot"
android:layout_width="match_parent"
android:layout_height="0dp"
android:layout_weight="1">
</FrameLayout>
<WebView android:id="#+id/webView"
android:layout_width="match_parent"
android:layout_height="0dp"
android:layout_weight="9"/>
</LinearLayout>
If you use an earlier version of Gradle and the Gradle plugin:
<uses-permission android:name="android.permission.INTERNET" />
And if you don't use Gradle, find the appropriate call for your build system. If you don't have a build system, grab the jar manually and add it to the classpath.
I am new to programming Android. When I start a new Android Application Project in Eclipse it automatically opens 2 files for me:
MainActivity.java and fragment_main.xml
package com.example.testprogram;
import android.support.v7.app.ActionBarActivity;
import android.support.v7.app.ActionBar;
import android.support.v4.app.Fragment;
import android.os.Bundle;
import android.view.LayoutInflater;
import android.view.Menu;
import android.view.MenuItem;
import android.view.View;
import android.view.ViewGroup;
import android.os.Build;
public class MainActivity extends ActionBarActivity {
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
if (savedInstanceState == null) {
getSupportFragmentManager().beginTransaction()
.add(R.id.container, new PlaceholderFragment()).commit();
}
}
#Override
public boolean onCreateOptionsMenu(Menu menu) {
// Inflate the menu; this adds items to the action bar if it is present.
getMenuInflater().inflate(R.menu.main, menu);
return true;
}
#Override
public boolean onOptionsItemSelected(MenuItem item) {
// Handle action bar item clicks here. The action bar will
// automatically handle clicks on the Home/Up button, so long
// as you specify a parent activity in AndroidManifest.xml.
int id = item.getItemId();
if (id == R.id.action_settings) {
return true;
}
return super.onOptionsItemSelected(item);
}
/**
* A placeholder fragment containing a simple view.
*/
public static class PlaceholderFragment extends Fragment {
public PlaceholderFragment() {
}
#Override
public View onCreateView(LayoutInflater inflater, ViewGroup container,
Bundle savedInstanceState) {
View rootView = inflater.inflate(R.layout.fragment_main, container,
false);
return rootView;
}
}
}
and
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:paddingBottom="#dimen/activity_vertical_margin"
android:paddingLeft="#dimen/activity_horizontal_margin"
android:paddingRight="#dimen/activity_horizontal_margin"
android:paddingTop="#dimen/activity_vertical_margin"
tools:context="com.example.testprogram.MainActivity$PlaceholderFragment" >
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="#string/hello_world" />
</RelativeLayout>
I wonder what all this stuff is. The Tutorials I watch always have a different code when they start a new project. For example the .xml file that Eclipse opens for them is named activity_main.xml (unlike mine which is named fragment_main.xml). Also their MainActivity.java has less methods integrated then mine.
Can Someone tell me wether that makes a huge difference and how i can maybe change that.
You are using latest one so it get like this. Don't worry about it.
public class MainActivity extends ActionBarActivity
instead of
public class MainActivity extends Activity
Remove all code in your MainActivity except OnCreate(). Then you follow your tutorial.
You onCreate should be
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
}
Those are probably old tutorials (on Android platform even after couple of months an tutorial can become old), Android ADT is constantly changing. It now automatically adds an Activity and a Fragment to your project. Instead of just an Activity. You can still use knowledge from those tutorials and fit it into Fragments. Or delete Fragments and use only Activities. But Android is promoting the use of Fragments with Activities, not just mere Activities so you should learn how to use them.
Create New Project Like This:
Start `File->New->Android Application Project->Next->Next->Next->Select-> Empty Activity->Next->Finish
I'm trying to create a small game on Android and have some questions on a specific section of my game. I'm fairly new to android so please excuse if I don't have a full understanding of certain things.
When clicking "play" I'd like to view slide-able menu that makes it able for the user to swipe left and right to choose a level. Overtime I will be adding few more levels but have 2-3 of them now.
What would be the best way to do this? Is it best to implement a fragment for each "level page" or create entirely new activities?
My project is compatible for Android ver. 2.3.3 and above, so it's automatically included the "appcompat_v7" project. (I don't know if that makes a difference).
I've pasted my code below if needed:
package com.example.snake;
import android.support.v4.app.Fragment;
import android.support.v4.app.FragmentActivity;
import android.os.Bundle;
import android.view.LayoutInflater;
import android.view.Menu;
import android.view.MenuItem;
import android.view.View;
import android.view.ViewGroup;
public class SnakeLevelSelectActivity extends FragmentActivity {
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_snake_level_select);
if (savedInstanceState == null) {
getSupportFragmentManager().beginTransaction()
.add(R.id.container, new PlaceholderFragment()).commit();
}
}
#Override
public boolean onCreateOptionsMenu(Menu menu) {
// Inflate the menu; this adds items to the action bar if it is present.
getMenuInflater().inflate(R.menu.snake_level_select, menu);
return true;
}
#Override
public boolean onOptionsItemSelected(MenuItem item) {
// Handle action bar item clicks here. The action bar will
// automatically handle clicks on the Home/Up button, so long
// as you specify a parent activity in AndroidManifest.xml.
int id = item.getItemId();
if (id == R.id.action_settings) {
return true;
}
return super.onOptionsItemSelected(item);
}
/**
* A placeholder fragment containing a simple view.
*/
public static class PlaceholderFragment extends Fragment {
public PlaceholderFragment() {
}
#Override
public View onCreateView(LayoutInflater inflater, ViewGroup container,
Bundle savedInstanceState) {
View rootView = inflater.inflate(R.layout.fragment_snake_level_select, container, false);
return rootView;
}
}
}
What I intended to do was create several fragment classes and animate between the fragments when the user swipes. I also have issues understanding on how to use several fragments with the "PlaceHolderFragment" class, since the solutions I've found on SO have been different. This is an entirely question, but would be appreciated if it was answered as well.
What would be the best way to do this? Is it best to implement a fragment for each "level page" or create entirely new activities?
This is exactly what a Fragment is for. What you are looking for is already there and named ViewPager. Using ADT and Eclipse you can even create an Activity with this already implemented. Use the "Navigation type" combobox for that purpose:
You can also choose "Action Bar Tabs (with ViewPager)", which will enable Tabs in the ActionBar and make sure that you can switch to different Fragments using both the swipe gesture as well as the tabs.
Android now has this built-in in the SDK.
They call it the Navigation Drawer.
Look up the documentation it contains sample project, it is very easy to implement.
this code is about the default code of MainActivity.java
having problem to understand and also there is a another thing that is the fragmentaion_main.xml file which is likely another buden instead of activity_main.xml why it so ?
package com.example.onehello;
import android.support.v7.app.ActionBarActivity;
import android.support.v7.app.ActionBar;
import android.support.v4.app.Fragment;
import android.os.Bundle;
import android.view.LayoutInflater;
import android.view.Menu;
import android.view.MenuItem;
import android.view.View;
import android.view.ViewGroup;
import android.os.Build;
public class MainActivity extends ActionBarActivity {
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
if (savedInstanceState == null) {
getSupportFragmentManager().beginTransaction()
.add(R.id.container, new PlaceholderFragment()).commit();
}
}
#Override
public boolean onCreateOptionsMenu(Menu menu) {
// Inflate the menu; this adds items to the action bar if it is present.
getMenuInflater().inflate(R.menu.main, menu);
return true;
}
#Override
public boolean onOptionsItemSelected(MenuItem item) {
// Handle action bar item clicks here. The action bar will
// automatically handle clicks on the Home/Up button, so long
// as you specify a parent activity in AndroidManifest.xml.
int id = item.getItemId();
if (id == R.id.action_settings) {
return true;
}
return super.onOptionsItemSelected(item);
}
/**
* A placeholder fragment containing a simple view.
*/
public static class PlaceholderFragment extends Fragment {
public PlaceholderFragment() {
}
#Override
public View onCreateView(LayoutInflater inflater, ViewGroup container,
Bundle savedInstanceState) {
View rootView = inflater.inflate(R.layout.fragment_main, container,
false);
return rootView;
}
}
}
What is appcompat_v7?
It is the support library added for backwards compatibility. Android has many versions and each new version brings many changes to the API. So, for the older versions of Android to be compatible with the code written for the newer versions, the appcompat_v7 library is helpful.
Why is it being added every time I create a new project?
I assume that you are using Eclipse IDE for the development. Ideally, it would suffice to create one appcompat_v7 folder and make all the projects link to that folder for support library. But, there seems to be some bug in Eclipse. It creates a new appcompat_v7 folder each time a new project is created.
'fragment_main.xml' is like another burden?
Fragment class was introduced in Android API 11. It is useful in creating different layouts for tablets and phones. It is more of a good support to take advantage of the bigger screens on tablets. If you want to develop your application for a smart phone only, you need not even worry about it. So, it's more of an advantage than a burden.
For more reading on fragments, go to http://developer.android.com/reference/android/app/Fragment.html
This appears after installation "Android Support Library":
https://developer.android.com/tools/support-library/features.html
The scenario I am faced with, is in my application I have a single pane and dual pane style layout. Rather than individually handle every single navigation operation possible between the screens, for every different style of layout, I am using a function which sets up the layout correctly when given the desired screen.
It is basically a switch statement for each screen in the app, with a nested switch statement in each screen to handle each layout style. This is what I'm talking about in code:
protected void setupScreen() {
switch(currentScreen) {
case SCREEN_ONE:
switch(currentLayout) {
case SINGLE_PANE:
// Perform actions to setup the screen
break;
case DUAL_PANE:
// Perform actions to setup the screen
break;
}
break;
case SCREEN_TWO:
switch(currentLayout) {
case SINGLE_PANE:
// Perform actions to setup the screen
break;
case DUAL_PANE:
// Perform actions to setup the screen
break;
}
break
// ... etc ....
}
}
In the section where I want to perform the actions to setup the screen, this consists of the following basic three operations:
// Create the fragments if necessary
if (screenFragment == null) {
screenFragment = new myFragment();
}
// Remove the existing fragments from the layout views
// HOW???
// Add the fragments for this screen to the view
getSupportFragmentManager().beginTransaction().add(pane1.getId(), myFragment, "myFragment").commit();
As you can see, what I am struggling with is how to do the second step. How do you remove all Fragments from a given View without knowing exactly which ones you are wanting to remove? The closest I have found is FragmentTransaction.replace() which does successfully do this for every case but when it turns out you are replacing a Fragment with the same fragment. In this case, it does not remove all, then add (like the documentation suggests), it just seems to remove. Is this an issue with using the compatibility libraries or is it not the way FragmentTransaction.replace() should be used?
In any case, how should I go about doing this? Do I have to code a removeAllFragments() function to go through every fragment and detach it or is there a way to do the first half of what the 'two in one' FragmentTransaction.replace() function claims to do?
None of the other answers were really working for me. Here's what I did:
List<Fragment> al = getSupportFragmentManager().getFragments();
if (al == null) {
// code that handles no existing fragments
return;
}
for (Fragment frag : al)
{
// To save any of the fragments, add this check.
// A tag can be added as a third parameter to the fragment when you commit it
if (frag == null || frag.getTag().equals("<tag-name>")) {
continue;
}
getSupportFragmentManager().beginTransaction().remove(frag).commit();
}
or, if you're forced to use it (but not recommended):
.commitAllowingStateLoss();
Also, if you're removing all fragments from the view multiple times, you might consider checking if the current frag is null or isDetached() or isRemoving() or you might get NullPointerExceptions.
Update: The documentation for getSupportFragmentManger().getFragments() is apparently hidden now, but still works just fine in my code. Here's the screenshot of the documentation:
Having said that, since it is hidden, they no longer want this method used, so see my update below.
Update 8-4-15: If you're not using the support library for fragments, there is unfortunately no getFragments() available, but there are still a couple, more inconvenient, options.
Give each fragment a tag or id upon creation, and iterate through them to process each fragment as desired.
Create a listener using onAttachListener so each time a new fragment is attached to the activity, you can store that fragment, and then iterate through that data structure to process each fragment as desired.
When not using the getSupportFragmentManager(), to process a transaction you will need to use getFragmentManager() instead.
The typical mechanism is to use FragmentManager.findFragmentByTag() . You use this and add tags to your fragments (or the alternative for id's). This way you can determine what fragments are currently being managed. Then, once you have a handle to a present fragment (findFragmentByTag returns non-null), you can use FragmentManager.beginTransaction() to start a FragmentTransaction and remove / add the necessary fragments. Working in this way will allow you to avoid the 're-adding' process for the fragment you want to keep.
What I'd probably do is have code like so: (warning psuedo code)
Fragment pane1 = FragmentManager.findFragmentByTag("myFragmentPane1");
Fragment pane2 = FragmentManager.findFragmentByTag("myFragmentPane2");
setupScreen(pane1, pane2);
You should also consider sub-classes of your class instead of having 'everything in one class'. You have a fairly obvious case of Martin Fowler's Replace Conditional with Subclass. Otherwise, I fear this is going to be incredibly hard to manager when you add another screen.
If you use android.support.v4.app.Fragment you can do this:
List<Fragment> fragments = getSupportFragmentManager().getFragments();
if (fragments != null) {
for (Fragment fragment : fragments) {
getSupportFragmentManager().beginTransaction().remove(fragment).commit();
}
}
Turns out FragmentTransaction.replace() is the correct operation and should work correctly. It only does not work when using ActionBarSherlock and SherlockFragmentActivity so I can only assume it is a bug in this compatibility library.
I have confirmed this through using the code below to implement the desired behaviour through Android on API11+, the android compatibility library, and ActionBarSherlock. It only breaks in the last instance.
package com.test.test;
import com.actionbarsherlock.app.SherlockFragmentActivity;
import android.os.Bundle;
import android.content.Context;
import android.graphics.Color;
import android.support.v4.app.Fragment;
import android.support.v4.app.FragmentActivity;
import android.view.Gravity;
import android.view.LayoutInflater;
import android.view.Menu;
import android.view.View;
import android.view.View.OnClickListener;
import android.view.ViewGroup;
import android.widget.Button;
import android.widget.FrameLayout;
import android.widget.LinearLayout;
import android.widget.LinearLayout.LayoutParams;
import android.widget.TextView;
public class MainActivity extends SherlockFragmentActivity {
// Consistent fragment instance
myFragment myFrag = null;
// Views
FrameLayout fl = null;
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
LinearLayout ll = new LinearLayout(this);
ll.setOrientation(LinearLayout.VERTICAL);
Button b = new Button(this);
b.setText("Repeat");
b.setOnClickListener(new OnClickListener() {
#Override
public void onClick(View v) {
// Reattach the same fragment
getSupportFragmentManager().beginTransaction().replace(fl.getId(), myFrag).commit();
}
});
fl = new FrameLayout(this);
fl.setId(200);
fl.setLayoutParams(new LinearLayout.LayoutParams(LayoutParams.MATCH_PARENT, LayoutParams.MATCH_PARENT));
myFrag = new myFragment();
getSupportFragmentManager().beginTransaction().add(fl.getId(), myFrag).commit();
ll.addView(b);
ll.addView(fl);
setContentView(ll);
}
public static class myFragment extends Fragment {
#Override
public View onCreateView(LayoutInflater inflater, ViewGroup container,
Bundle savedInstanceState) {
TextView tv = new TextView(getActivity());
tv.setText("My fragment");
tv.setGravity(Gravity.CENTER);
tv.setBackgroundColor(Color.RED);
return tv;
}
}
}
This is more or less how I have handled this. Have all your fragments implement an interface something like:
public interface NamedFragment{
public FragmentName getFragmentName();
}
Make an enum corresponding to your fragments:
public enum FragmentName{
SOME_FRAGMENT,
SOME_OTHER_FRAGMENT;
}
Then in your fragment switching activity:
// Get the manager and transaction separately so you can use both:
FragmentManager fragmentManager = getSupportFragmentManager();
FragmentTransaction ft = fragmentManager.beginTransaction();
// Get a reference to the fragment(s) currently in the container(s)
Fragment currentFragment = fragmentManager.findFragmentById(position);
FragmentName cFragmentName =
((NamedFragment) currentFragment).getFragmentName();
Fragment nextFragment =
Fragment.instantiate(this, some_new_fragment_string);
FragmentName nFragmentName =
((NamedFragment) nextFragment).getFragmentName();
// Compare the "names"
if(cFragmentName != nFragmentName){
ft.replace(position, nextFragment);
}
You'll have to change things around a little to fit your particulars.