Develop Reference

Fragment vs. Custom View in Android

The Fragment and Custom View can achieve the similar function, I know that fragment is more re-usable comparing with custom view, any other benefits/enhancements for using Fragment? Is fragment supposed to replace Custom View, or just a enhancement for some specific purpose?
For instance, the code below is fragment:
public class TestFragment extends Fragment {
private TextView tv_name;
private Button btn_play;
private Button btn_delete;
#Override
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
return inflater.inflate(R.layout.testfragment, container, false);
}
#Override
public void onStart() {
super.onStart();
tv_name = (TextView)getView().findViewById(R.id.tv_name);
btn_play = (Button)getView().findViewById(R.id.btn_play);
btn_delete = (Button)getView().findViewById(R.id.btn_delete);
}
}
The code for custom view:
public class TestCustomView extends LinearLayout {
private TextView tv_name;
private Button btn_play;
private Button btn_delete;
public TestCustomView(Context context, AttributeSet attrs){
super(context, attrs);
setOrientation(LinearLayout.HORIZONTAL);
setLayoutParams(new LayoutParams(LayoutParams.MATCH_PARENT, LayoutParams.MATCH_PARENT));
tv_name = new TextView(context);
addView(tv_name);
btn_play = new Button(context);
addView(btn_play);
btn_delete = new Button(context);
addView(btn_delete);
}
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
return inflater.inflate(R.layout.testfragment, container, false);
}
}
Both TestFragment and TestCustomView can create a view consisting of TextView and Buttons, and use tags of Framelayout/fragment and com.packagename.TestCustomView to declare in the activity's xml layout file, but what's the advantages to use Fragment?

Fragment can be used in different scenarios but most used are:
wrapper around a view
headless fragment - i.e. no view => not very helpful in general but can be used
retainable fragment - can be any of above. By using Fragment.setRetainInstance(true) you can bypass Fragment.onDestroy(), i.e. can keep fragment data on configuration changes but fragment view structure is still destroyed/recreated
can be added to activity back stack, i.e. easy Back button previous state restore
There are cases where fragment are complete pain in the neck, then there are cases where they can achieve results quicker.
For some custom and more flexible situations fragments can get cluttered and managing them would be difficult. So dealing with views directly can be really handy and more helpful for some cases. But everything is based on requirements.
Note View has its own life cycle too and can store/recreate saved instance state. A little bit more work but it has the option too.

Custom Views have the advantage of simplicity and their primary purpose is to display a piece of data on the screen. They must rely on other components in order to do more.
Think of Fragments as a functional unit, a way to display a portion of UI that has a specific purpose, using one or more Views. Fragments are connected to the Activity lifecycle and they can include and control Loaders to populate the Views with data. They can also include sub-fragments. Finally, they can also be added to a synthetic back stack. They can do many things and are somewhat complex to learn.
As you can see, Fragments have much more in common with Activities than they have with custom views.
As a side note, Fragments can also be headless (with no UI). Headless fragments provide a way to encapsulate non-visual functionality relying on the Activity lifecycle in a separate component.

Fragments come with their own lifecycle, which can be a hinderance or a bonus, depending on what you need.
Fragments get lifecycle methods like onResume or onSavedInstanceState, which can help you deal with state transitions in your application. If you're using custom views, you need to handle that kind of things on your own.
There are people who advocate against using fragments, I suggest reading https://developer.squareup.com/blog/advocating-against-android-fragments/

The most useful functionality of using Fragments over Custom Views is that they have their own Lifecycle Callbacks, i.e. we can register our own FragmentLifecycleCallbacks to do some operations before/after Fragment creation/destruction.
We can create our own FragmentLifecycleCallbacks and register it with Activity to inject dependencies in Fragment through Dagger.
There are some workarounds to inject dependencies in Custom Views too, but doing it through FragmentLifecycleCallbacks is much cleaner and easier to do.

Problems with views when reloading fragment

this is bit when i'm creating view,
public static int a=0;
#Override
public View onCreateView(LayoutInflater inflater, ViewGroup container,Bundle savedInstanceState) {
a++;
View view = inflater.inflate(R.layout.fragment_layout, container, false);
editText = (EditText) view.findViewById(R.id.amount);
TextView tv = (TextView) view.findViewById(R.id.textView1);
Button button = (Button) view.findViewById(R.id.addTransaction);
button.setOnClickListener(this); ///fragments implements OnClickListener
editText.setText(""+a);
tv.setText(""+a);
return view;
}
when i load this fragment first time, my editText is empty, but when i load fragment again, value in the editText is same like in previous execution.
Is anyone has idea what i'm doing wrong? And how i can fix it?
** EDIT
i modified little bit my code, now each time when i'm loading fragment a is incremented. and io noticed weird behaviour. tv has has actual value of a, while editText still has old value

You need to move the settext ( and probably some other stuff) into a later method in the fragment life cycle e.g. onActivityCreated.

Before adding the fragment try to get the fragment by calling FindFragmentByTag("tag"), i think you are adding new fragments on top of each other. Also add your fragment transaction to back state and then to check if more than one fragments are added, press back button. I had similar problem, and the reason was i kept adding new fragments in activity

Fragments are tied to activities, so my guess is that the activity is not being destroyed, which means your fragment is not being destroyed and instead "resumed". Perhaps you want that code in the onResume callback? Take a look at the Fragment lifecycle: Android Fragments

Is it possible to create multiple screens, with only one Activity in an Android application?

Normally I would use a separate activity for each "screen" I wish to display, using different XML files.
However I'm working with Dynamically loading jar files into an android application, so therefore at runtime, I am not aware of how many activities there will be, or how many screens there will be.
At the moment, using java reflection, I am able to return a list of strings from the dynamically loaded java file, and draw each list item, as a separate button onto the screen. If one of these buttons is clicked, i want to be able to load a different "screen" on the stack. So when I press back from this new screen, it goes to the previous screen that called it.
Is it possible to do this without creating a new activity and passing a new intent to it and of course making relevant changes to the android manifest file?
To use blackberry functionality as an example - Is there an equivalent in android to blackberry's push and pop screens? Where the screen ur pushing/popping, would simply extent MainScreen?
If anyone has questions, or If I've been vague, please comment and I will try my best to explain myself, any help is very much appreciated.

The Android equivalent to BB's push/pop screen is startActivity()/finish(). However, you can manage your own views in a single activity by either using a container view (such as ViewSwitcher, as #hasanghaforian suggests) or by simply calling setContentView() with a new view hierarchy whenever you want to change the screen. Be aware that when you call setContentView, any view references that you obtained by calling findViewById will be stale.

In my opinion you should use Fragment. I assume that you have some piece of code where you iterate over the strings:
for(String def : definitions) {
Fragment f = new CustomFragment();
Bundle b = new Bundle();
b.putString("STRING_DEF",def);
f.setArguments(b);
fragments.add(f);
}
in above piece of code a collection of Framents is just created. Let's look at the CustomFragment implementation:
CustomFragment extends Fragment {
#Override
public View onCreateView(LayoutInflater inflater, ViewGroup container,
Bundle savedInstanceState) {
String def = getArguments.getString("STRING_DEF");
//write code to create view
return view;
}
}
Now in your ListActivity you have to implement on click listener more or less like this like this
public void onListItemClick(ListView l, View v, int position, long id) {
FragmentManager fragMgr = getFragmentManager();
FragmentTransaction t = fragMgr.beginTransaction();
t.replace(R.id.id_of_view_place_holder_for_fragment,
fragments.get(position),"FRAGMENT_TAG");
t.commit();
}

you can use ViewSwitcher. ViewSwitcher is a ViewAnimator that switches between two views, and has a factory from which these views are created. You can either use the factory to create the views, or add them yourself. A ViewSwitcher can only have two child views, of which only one is shown at a time.Or you can use fragments.

If you refer to if it is possible to have different layouts in the same activity, the answer is yes.
Activities are independent of layouts, you don't assign the layout for an activity in the manifest, you define what layout to use in the activity calling setContentView() method from Activity class to set a layout.
So if you want to have some layouts (screens) the only thing you have to do is define various layouts and use them when you want calling setContentView(R.layout.the layout), after this call, the layout chosen will be displayed.
If you can't create the layout statically by xml, you can create it dinamically by code as needed by demand each time you want.
In addition you can have a stack of layouts, each time you need a new screen, build it, push it to the stack and call setContentView() method, when you don't need it more, pop off the stack and call setContentView() with the new layout in the top of the stack.
Hope it help you

Fragments - Do you have to use an Activity Wrapper around a fragment which comprises the whole Activity?

Consider the sample app from developers.android.com
This describes using Fragments like so:
On a Phone you can use Fragment 1 on Activity A and fragment 2 on Activity B.
On a tablet you have more real estate so you use Fragment 1 and Fragment 2 on Activity A.
Great! ... But... On the first example (the one with a phone) you create an Activity with an xml file containing a single <fragment> and that's all, in the activity you only call setContentView() on that xml? That seems like a lot of redundant code (Activity, XML & Fragment to display a Fragment): Can you set a Fragment as an Activity or is a Wrapper with XML always required?

Ah, found it here
public class MainMenuHolder extends FragmentActivity {
#Override
protected void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
// If not already added to the Fragment manager add it. If you don't do this a new Fragment will be added every time this method is called (Such as on orientation change)
if(savedInstanceState == null)
getSupportFragmentManager().beginTransaction().add(android.R.id.content, new MainMenuFragment()).commit();
}
}
FragmentActivity allow's you to set the Fragment as the content of android.R.id.content which I assume is the android internal ID of the trunk view.
With this method you still end up with an mostly redundant activity (If all you want is the Fragment acting as the Activity). But still, half as much fluff as having an activity and an XML file acting as a container.
Any other answers would be appreciated!

The online example doesn't fill in all the blanks. I'll try to answer your questions directly:
"On the first example (the one with a phone) should you create an Activity with an xml file containing a single and an activity which only calls setContentView() on that xml and that's all?"
You've started in the right place. But there's more to it than that. There's always more than one way to solve a problem in Android but a recommended way of generating the effect of having a dynamic number of fragments based on avail. real-estate is:
Create layout XML files in /layout for the primary (default) targeted orientation/device/form-factor/SDK
Create layout XML files for the smallest-width baseline for other targeted devices. You may also want to target other orientations, SDKs, etc.
Each layout XML file will have it's own set of defined fragments
In the Activity, check to see which fragments are present.
Clearly an analogous strategy can be adopted for programmatic layouts.
In your example in the original question (from Google's docs) you could have:
layout/main.xml :: this layout would only have Fragment 1
layout-sw600dp/main.xml :: this layout would have Fragments 1, 2
Then in MainActivity.java you would check for the existence of each fragment. To do that you could use FragmentManager#findFragmentById() to have a check like: if findFragmentById() returns null for Fragment-2 then MainActivity knows the device has loaded layout/main.xml and only supports one fragment.
Stepping 'back' from the example somewhat reveals that: prior to using Fragments you might have called Activity B from Activity A with startAcitityForResult(int). In the Fragment paradigm you probably only need to have a result from Fragment 2 cause something to happen in Fragment 1, so it's reasonable to have MainActivity be the gatekeeper for that. As you expand on the example you may see that in other apps, MainActivity may need to call other activities - for whatever reason. Perhaps you're targeting a large tablet with enough real estate for 3 fragments but on a handset that needs to be 3 activites. Things can get interesting but the Fragment API is fairly powerful.
"Can you set a Fragment as an Activity or is a Wrapper always required when using fragments?"
A Fragment is not an Activity. Indeed Fragments are loaded by Activities, so yes one might say a wrapper is always required. You're touching on aother subtle aspect of Fragments. Whereas Activities behave like MVC Controllers, Fragments could be called "mini-controllers" due to their lifecycle which both resembles and executes alongside an Activity. Again, the Fragment's lifecycle is contained inside ("wrapped by") the lifecycle of the Activity managing the Fragment. I recommend becoming familiar with the Fragment lifecycle documented at http://developer.android.com/guide/topics/fundamentals/fragments.html#Lifecycle.

More generically you could create a fragment container class:
public class SingleFragmentActivity extends Activity {
public static final String FRAGMENT_NAME = "fragmentName";
public static final String FRAGMENT_ARGUMENTS = "fragmentArguments";
#Override
protected void onCreate(#Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
String fragmentName = getIntent().getStringExtra(FRAGMENT_NAME);
Fragment fragment = Fragment.instantiate(this, fragmentName);
Bundle fragmentArguments = getIntent().getBundleExtra(FRAGMENT_ARGUMENTS);
fragment.setArguments(fragmentArguments);
getSupportFragmentManager().beginTransaction().replace(android.R.id.content,fragment, "tag").commit();
}
}
now you use this class to instantiate any fragment as a standalone activity:
public void showFragmentAsActivity() {
Intent intent = new Intent(this, SingleFragmentActivity.class);
intent.putExtra(SingleFragmentActivity.FRAGMENT_NAME, MyFragment.class.getName());
intent.putExtra(SingleFragmentActivity.FRAGMENT_ARGUMENTS,MyFragment.getArgumentsBundle("a string argument"));
startActivity(intent);
}

Android Inline Activity

In Android, the TabHost object renders activities in a type of inline way. I'm wondering if there's any way I can do a similar type of thing, without using the tab-host. Suppose, i want to have a toolbar or sliding drawer that allows me to switch between the activities in the same way that the TabHost does this. In other words, I'd like to render an activity inline inside of another activity, sort of like an iframe for activities...

Basically you need to play with LocalActivityManager and the ActvityGroup class:
Suppose you have your DashBoard class:
public class Dashboard extends ActivityGroup implements View.OnClickListener {
super.onCreate(savedInstanceState);
//Your view with the activity launcher buttons on the bottom for instance
setContentView(R.layout.frame);
#Override
public void onClick(View v) {
Intent intent = new Intent().setClassName(context,YourActivity.class);
intent.setAction(Intent.ACTION_VIEW);
LocalActivityManager localActivityManager = getLocalActivityManager();
final Window w = localActivityManager.startActivity("uniqueID", intent);
final View wd = w != null ? w.getDecorView() : null;
//the content of your activity goes here
FrameLayout frameLayout = (FrameLayout) findViewById(R.id.tabcontent);
frameLayout.removeAllViews();
frameLayout.addView(wd);
}
}

This may not be exactly loading separate Activities, but...
Instead of Activities, you could achieve that functionality from a user's perspective by by dynamically loading layouts inside a single Activity. That way you could have a slider and update the layout(s) on screen as needed.

No and even use of activities in tabs is discouraged in favor of views. You can do other searches here or on the android google groups to read why.
If you must have separate activities you should start them the proper way with Intents and let Android manage their lifecycle or do tabs with a view per tab.