I'm a new android developer and I've noticed that recently the adt bundle has changed in a way that when you open a new android project it sets one main activity and a fragment instead of just creating an activity.
Therefore i'm wondering if that means that I rather be writing my code just with fragments? meaning having just one activity and just jump between fragments?
If not, when would I prefer to open a new activity instead of a new fragment?
Think of an activity as the backbone of the display and the fragments as small sub-pieces of the display.
You change activity when you want to completely change the entire display, and you mingle with your fragments when you want to change only part of your display.
Something along those lines
yeah, you can do like that having one activity and rest of the code in fragments. you know in my application i have 4 activities and nearly (i didn't counted that) more than 50 fragments i have used. Android - I need some clarifications of fragments vs activities and views http://developer.android.com/guide/components/fragments.html refer those two links where you can find enough info about fragments. you can use fragments in tablets to use its screen efficiently and more adventages you can find in above links. hope this helps
I believe it also depends on your personal preference in coding whether you want to use activities or fragments. (Well, there may be some occasions where you want to use activites rather than fragments: e.g. switching your App configuration to landscape when using Camera)
While fragments offer code re-usability and flexible displayed views, they also add more complexity to your application. You could also achieve the same views with activities in maybe a more robust and less complicated way. But if you can keep an overview of your fragments you should be fine either way. I think you should try both and decide for yourself which is best.
From 4 reasons to use Android Fragments, the purpose of fragments is:
Fragments group user interface components and their associated logic.
Also from the same article:
1. Dealing with device form-factor differences
The Activity class is often thought of as the main UI class in Android. It is true that Activities do render the UI for an application but Activities also have a lot of other responsibilities such as lifecycle management, platform interaction, etc. Putting all of this burden within the Activity class creates difficulties in dealing with device form factor differences. Ultimately one of two things happen.
A single Activity has to provide a lot of special case handling for various form factors
A separate Activity is created for each form factor with the non-UI details duplicated or otherwise shared across each Activity
Fragments eliminate this problem by taking on the UI details and leaving the other responsibilities to the Activity. This way a separate Fragment can be created for each form factor with the form factor specific UI details being the only responsibilities of each Fragment. The Activity is then free to delegate the UI responsibility to the appropriate Fragment for the current form factor.
2. Passing information between app screens
Historically each screen in an Android app was implemented as a separate Activity. This creates a challenge in passing information between screens because the Android Intent mechanism does not allow passing a reference type (i.e. object) directly between Activities. Instead the object must be serialized or a globally accessible reference made available. By making each screen a separate Fragment, this data passing headache is completely avoided. Fragments always exist within the context of a given Activity and can always access that Activity. By storing the information of interest within the Activity, the Fragment for each screen can simply access the object reference through the Activity.
3. User interface organization
Two of the most common UI metaphors for organizing application screens are Tabs and Dropdown Lists. Tabs are great when there are just a few screens and Dropdown Lists work well when there are several, as when selecting a folder from the Android email app as shown here.
Fragments make implementing these UI metaphors easy. In both cases you simply put the Android ActionBar into the appropriate navigation mode, implement the appropriate interface, and then use a FragmentTransaction to switch between the currently displayed Fragments.
Tabs use ActionBar.NAVIGATION_MODE_TABS and ActionBar.TabListener
Dropdown Lists use ActionBar.NAVIGATION_MODE_LIST and ActionBar.OnNavigationListener
4. Advanced UI metaphors
As the use of Fragments matures, they are an increasingly important part of rich UI design and are becoming the foundation of some of the more advanced UI metaphors. One of my favorites is swipe-based navigation where you move between screens in an application by drawing your finger from one side of the display to the next.
To add swipe navigation to an app, simply implement a Fragment for each screen, place a ViewPager in the UI layout and connect the ViewPager to a FragmentPagerAdapter.
