Develop Reference

Android Migrating from phone app to tablet

I've developed an android phone app in which the navigation is mostly activities and starting activities for results. I've read that in order to make the tablet layout look like 2 screens of my phone app one next to the other I should have made it with fragments. Is there another way to migrate my functionality to the tablet app? Meaning to keep the start activity for result but just concatenate two activities on screen? (it may sound stupid, I know). Thanks

In order to keep the software design simple and modular, fragments come in really handy. You can use the same fragment's UI design + working code in multiple places without changing much functionality.
Since you have the code built and running in terms of activities, it won't take much time to migrate/port it to a Fragment since the life cycle methods are pretty similar. All you need to do is study the life cycle of a Fragment and move code chunks from the Activity to the Fragment class.
You can study all about Fragments here - http://developer.android.com/guide/components/fragments.html
or maybe a training session here will help you more -
http://developer.android.com/training/basics/fragments/index.html
You will learn a lot and once you have tried it you will be able to comprehend the advantages in a much better way. In future always make it a point to design in terms of Fragments to have a much modular design.
Along with that I think you will also need to learn to design layout for multiple screen sizes. This link over here will help you understand how to support multiple screen sizes -
http://developer.android.com/guide/practices/screens_support.html
If a tutorial to do this very quickly is what you seek then this should help -
http://www.101apps.co.za/index.php/articles/converting-android-activities-to-fragments.html
All the best :)

It very depends on your app GUI structure. Sometimes, you even not need to adapt your GUI for tablet (if you build interface dynamically basing on screen dimension). As rule, if you have two screens where one screen is advanced or logical extension of other then you can union it into one screen on tablets for better informativeness. Secondary way, as rule, based on fragments.

You can achieve it with help of Activity group but it is deprecated in Api level 13, for more details please visit http://developer.android.com/reference/android/app/ActivityGroup.html, but I will suggest to go with Fragment as Fragment having nearly similar life cycle like as Activity with extra methods and features. Please refer link for more details http://developer.android.com/guide/components/fragments.html

Is there any point of an Activity with one fragment?

All the reasons I can find for using Fragments in Android activities have to do with having the ability to display multiple classes/view in the same screen, encapsulating multiple logical components, etc.
Considering all this, it seems, fragments are only actually useful when you employ the use of many of them.
Is that so? Is there ever a point of using just one fragment in an activity?
I ask now because I saw an option on Android Studio to do just that, and I am wondering what the point is.

Out of my personal opinion, I would say yes.
For the following reasons:
Assuming you are familiar with Fragments, creating a Fragment is hardly any extra work plus has the following benefits
Fragments can easily be reused somewhere else (possibly another Activity that has more Fragments, furthermore, Fragments do not necessarily need to use up the full screen).
Activity transitions are more expensive, Fragment transitions are more sophisticated.
The Fragment animation framework is better (in terms of usability and performance).
I always like to keep the number of Activities to a minimum which keeps the AndroidManifest.xml short and clean.
UI separated into Fragments leads to cleaner code structure and easier code maintenance.
According to google coding guidelines, it is best practice to create as few Activities as possible, and create multiple Fragments instead that are switched inside an Activity.

Well it depends, if you are going to use that fragment in another activity yea, you have a "point" and maybe in a future you can reuse it on another activity, but in the case for example of a splash screen well, it don't have a point. All depend in the uses you want to give to your application.

Pros:
-> reusable piece of code
easy to utilize it again in any module
easy to debug
-> handles orientation changes better than activity using setRetainInstance(true)
-> great help when scale the app in future for multipane layouts or multi-screen support
Cons:
-> little overhead and time consuming if you are not familiar with fragments

Two activities or two fragments?

In an Android app, I have two screens* the user sees, one for preparing a query and the other for displaying the results. The right UI here is to have the query preparation in one screen, and then see the result on the second screen. Since this app is aimed at phone users, there's no need to display the two at once.
The traditional Android way is to use two activities, a QueryPreparationActivity and a DisplayResultActivity, and switch between the two. However, I've been hearing more and more about how the Android UI is switching to fragments. I can implement the two screens as two fragments and have the activity switch them, but is it worth the trouble? I will essentially be reproducing the Activity management code Android already has.
Is there a reason to use two fragments here?
*I'm using the term screen, because it isn't necessarily an activity...

Personally, I always develop using Fragments.
But the best reason I can give you for using Fragments is when you develop for handset and tablet devices you get a lot of reusability.
I know you already mentioned that there is no need to show both screens at once. But say later you were to develop the same "screen" for a tablet device and realize that the preparation screen is too barren and want to have both queryprep and display result show at the same time, you would have to write a totally new 3rd activity.
If you used fragments, you would reuse your 1 activity and 2 fragments, and that activity should be coded smart enough to determine the size of the screen and show the proper layout.
Code Reusability & Flexibility are the buzz words here.
If you have any questions please leave a comment and I will expand my answer. If you like my answer, please upvote and accept.

Fragments were introduced encapsulate UI elements and related behaviour into a single, reusable module. Before fragments you had to re-write the much of the same code that 2 or more activities had in common especially if you couldn't find a good approach to abstract the UI/control code into a super class. This was further complicated by the limitations that activities only call setContentView once. So sharing some code between activities wasn't all that nice.
Now, to answer your question, it all depends on you. If you think that further down the road you could use the QueryPreparation or DisplayResult ui as a module (layout and logic behind it) then go for the fragment implementation. It could be a different layout for landscape view on phone or if you decide to support smaller tablets like the nexus 7. If you are sure that it will never happen then stick with activities. Personally, I use fragments everywhere and they are a sure way to "future proof" your implementation for reuse down the road.

In short Fragments were introduced to accommodate the emergence of tablet/large screen devices and allow developers to create applications that will run across a wide range of screen sizes with very little change to code.
More can be read here at the Android Blog. That blog also details some of the finer technical details for the reasons for the move toward Fragments. Also introduced at Goolge IO 2012 were DialogFragments which you should consider using instead of Dialogs. Another blog post here describes them.
You're better off getting used to using Fragments and DialogFragments from the get go as this is the way Android is moving. Only use individual Activities if you really really need to do a quick-and-dirty app for say testing purposes. Fragments, in my opinion, do require a bit more code-work to incorporate and to initially get your head round but it's worth the effort.

Confused about using Fragments in the app

I have a full-fledged app which is NOT developed using Fragments. My confusion is that should I change it to have Fragments instead of Activities. The thing that I would like to tell is that I'm using only portrait orientation in my application and it is built, keeping in mind only phones, not tablets. So my question is, will it do any good if I change the whole structure of app and use Fragments.
As far as I know, Fragments should be used only If we want to reuse something. Any suggestion is appreciated.

Fragments can be used to create a dynamic and multi-pane user interface, and as such are ideally suited for tablets which have a lot more screen real estate to use up. Of course, on a phone the situation is a little different, you have a much smaller space to play with and sometimes it can be a struggle just to get one Activity fitting onto the screen without worrying about including multiple Fragments.
Fragments are very good for dynamic interfaces, and for helping with compatibility between Tablet and Phone. They are also able to communicate with each other much better than Activities can, so there are certainly advantages to using them even on a phone-only setup. (See FragmentsManager for some functionality they can be used for)
One example of use is illustrated in the diagram below (taken from Android Developer site)
This illustrates the flexibility of the Fragments, which on tablet can occupy the same screen, switching to a more Activity-like format on a phone. It is this kind of power that gives the Fragment such an advantage over an Activity.
So clearly there are advantages to switching to a Fragment orientated solution in terms of flexibility, but your original question states that you are targeting phones only, and only in portrait orientation.
Having an application that is already in existence with Activities, providing that it is a solution that you are happy with, and has good usability I would say there was no reason to switch to Fragments (unless you are looking for a challenge or have some spare time and fancy a tinker). While advantages exist, a drastic change such as adding Fragments could introduce bugs into your application and impact the user experience (at least for the short term).
Long term, if you are ever considering bringing tablet support into the fold or would like to use the landscape orientation, then it might be a good idea to start looking at what you can do with Fragments to improve the experience, and integrate this with the current flow of your phone application.
Otherwise, the current solution you have created will more than suffice, and as long as it is well received by your customer base I see no reason to change.
Of course, there is no harm familiarising yourself with the Fragment APIs for future projects, or in the event that it is time for a refresh of your current project's UI.
It is worth pointing out that Fragments are only supported natively from Android 3.0 (API level 11), and to support earlier devices you will require the Android Support package found in your installation. As such, if your current application targets 2.x devices, I would stick with an Activity based approach, for simplicity and .apk size, unless moving to a native API Level (like Android 3.0+). This is personal preference though and ultimately the answer to your original question will boil down to your personal preference.

Think of fragments as a way to modularize your code into manageable pieces. Each fragment represents a small piece of functionality and UI. This allows your to easily adjust your code to fit different scenarios.
Sure you don't plan on supporting tablets now (regardless of how you feel tablet users will install the app), think of larger size 5-6" devices and the potential of extending your app over to them. It is best to provide your app to as many devices as possible and the best apps will tailor the experience to the device.
The transition to Fragments doesn't have to be difficult. Take a small piece of functionality and move it over to a Fragment. Then you will see how easy and flexible the new pattern is. You don't need to rewrite the entire application as Activities and Fragments can work together.
I believe by skipping out on Fragments you are really making your development tasks much more difficult in the long run.

If you don't plan to support tablets in the future than leave it as it is. You won't gain anything when you convert your app to fragments.
The situation is different if you start a new application. I would use fragments from the beginning in order to be more flexible should the need arise to support other form factors in the future. Note that the functionality is available in the support library so you can use it also on older devices.

It is easier to set interaction between fragments than between activities.
In case of activities:
You need to use startActivityForResult()/onActivityResult();
Your custom types must implement Parcelable interface in order to be passed between activities;
You have to free all resources when your activity is paused/stopped.
In case of fragments:
Passing data is as easy as getting an instance of fragment from FragmentManager and calling a method on it;
No need to implement Parcelable;
You can hold references to "heavy" resources in activity which contains all of your fragments and initialise/release them only once (no need for initialisation/release for each fragment).
Also, an instance of Fragment is more lightweight than instance of Activity and takes less time and resources to be initialised/resumed.
In general, interaction between the components of your UI is cleaner, more elegant, easier to implement when you use fragments.

As far as your application or any of the application is concerned , it's better to use fragments and it causes no harm to your application and it also ease your burden while further extending your application for tablets also.So, better to start with the use of fragments in your application.

I've just finished converting my application to use fragments, because:
Wanted a tablet version
Wanted to use ViewPageIndicator and ViewPager with advanced views
Those are the most compelling reasons to use fragments.
It might be a little more work, but with significantly more tablets appearing on the market and fast adoption rate, perhaps it's worth considering supporting tablets with a nicer UI?
If you really don't want to do this and have no requirement for view paging using advanced views then there is no point over-engineering your project to make it use fragments for using fragments sake. You could argue you might learn about them, but when you come to use them in your next project, you can learn then (that is what I did and it worked out fine).

Android fragments when to introduce them into the application

I'm making an project that needs to run on tablets as well as phones.
I was thinking to use fragments for this. but i dont have any history in using them.
Should I implement them right away or is it easy to implement them later on?
( i could first make the working phone app and later on make it an tablet app)
someone with an history in implementing fragments for the first time?

I recommend to use fragments from the beginning for UI components which may be used in a master-detail like fashon on tablets but as single activity on the smaller phone. You will get a light overhead for the smaller phone (e.g. using an activity container exactly one fragment) but you will profit from that overhead when switching to the tablet. It will also improve a consistent UI design between smaller phones and tablets.
If you target pre-fragment (e.g. Android 2.x) devices use the support library. I also recomment to mark the classes depending on the support library using comments. This way you will find them easier when switching from the support library to the "native" implementation sometimes in the future (at least you have modify the import statements, because the support library uses different packages. In rare instance you will have to modify methods (e.g. change getSupportFragmentManager() to getFragmentManager()).

I have been working for two weeks to update an android application and make it using fragment, so it will be easier for you to use directly Fragment. But i think that the question that you must ask your self is did i need fragments in my app???
Essentially, Fragments allow you to show the user multiple 'activities' at one time. Did you need this?? if no it will be easier that you use resource qualifiers to point to another layout with more/less Fragments (ex. layout-land-large). You will be able to update the size of elements in your file.xml.
if you need to show two activities (when using tablet) , the best solution is using fragment. and here you say: Are the Fragments working together to provide the user a streamlined experience? If yes it will be perfect that you work directly with fragments because fragments send arguments between each other to communicate (not the same as activity).
In activity: intent.putExtra()
In fragment: you can use bundle for example. So if you need to update your application after you will waste your time searching for sender extras and sending it other wise.