Develop Reference

Sense to have a Single fragment in MainActivity?

I am making a weather app. In MainActivty (extends AppCompatActivity) it shows the current weather. On this screen there are two buttons: 1 button that opens the SettingsActivity (new screen) and 1 button that opens ListviewActivity(new screen which shows short weatherconditions of all capitals in Europe in a listview)
I haven't used any fragments, but I'm not sure if this is right... I thought fragments aren't needed, because every Activity just has 1 screen. But I read on internet it is good practise to always use fragments, even when an activity only has 1 screen.
Also, is it easy to convert my screen in MainActivity to a fragment?
Could you please give an example of this?

I haven't used any fragments, but I'm not sure if this is right... I
thought fragments aren't needed, because every Activity just has 1
screen. But I read on internet it is good practise to always use
fragments, even when an activity only has 1 screen.
Yes, Its always a good practice to use Fragments event though as of now you are having 1 screen for each of your activity. The main reason is directly related to future phases or features your application may have, so that it would be easier to make your application scalable and also to make your activity clean and do complex individual things in Fragments.
Also, is it easy to convert my screen in MainActivity to a fragment?
For this, you need to make certain changes for both Activity and Fragments. But its upto you(particularly in your current app) how you are presuming the future updates. I would strongly recommend you to use Fragments even in current situation of the app.
Hope it helps.

Yes, the fragments make the app to load much faster as the load on the main thread will be reduced and you can even apply animations to the fragments when it opens, that makes it look even cool and attracts attention.
Coming to your question, the answer is "yes" you can easily convert your MainActivity into a fragment if you haven't done much work in the MainActivity.
Firstly, know what are fragments and how to use them by clicking here.
After knowing what fragments are, all you need to do is create a blank fragment and do all the work that you are doing in MainActivity inside a fragment that you've created and create a newInstance of this fragment in the onCreate method of your MainActivity and replace the MainActivity's layout with fragment by using the FragmentManager's replace function.
Hope, this helps you.

Would it be better practice to use Fragments?

I am currently writing an Android app for my Masters final project. The app has two Activities and both have layouts corresponding to each activity. I also have a settings activity with settings fragment but I am not concerned about this one.
Activity A currently has a Spinner and a button which when pressed will do some stuff and then launch a Activity B. Activity B displays a chart, contains a couple of actions and a button to go back to Activity A.
Neither of these activities have Fragments currently but I am curious if it would be better to include Fragments. As far as I can tell using a Fragment wouldn't hinder performance so at this point it would be a cosmetic change.

Fragments are usually needed if you need to re-use some specific layout.
E.g--> If you have an app which displays movies, you can click and get movie details.
Here it would be better to use fragments as the layout would be the same for each movie and only the content would change inside.
In your case however, since there is not need for such frequent scenarios, you really do not need fragments.

If you want to change the content without changing your activity due to some actions of user, implementing UIs inside Fragments can be useful. Just set the the desired fragment inside Activity by using its FragmentManager. However, otherwise don't think about such change (shifting lots of code/layout from activities to fragments) in the code.

Determine fragment change while espresso testing

I'm testing my application in android composed of 1 main activity and multiple fragments inside in which we navigate.
For my tests I use espresso, and after a click on a particular button, I want to check if the current fragment has changed or not (the part with the button is ok).
So, how can I do in espresso to check if the fragment is still the same than before the click on the button?

If you really want to do this, you can do
FragmentManager fragmentManager = getActivity().getFragmentManager()
and get information about the backstack from fragmentManager. If your fragment has a tag, you could assert that findFragmentByTag(tag) returns something non-null.
But it's normally better to make assertions about the view hierarchy. It's what Espresso was designed for, and it's more in the spirit of black-box testing.
So I would suggest finding some distinguishing feature of the new fragment, such as the page title if there is one, and asserting that that view is present using the usual Espresso methods, e.g.
onView(withText("Page Two Title")).check(matches(isDisplayed()));

When to use fragment backstack vs. individual activities?

I've been developing for Android for a couple of years now, and I still find myself going back and forth on this issue: when should I be using fragments on a backstack versus putting each fragment into its own activity?
In the Android Fragment documentation, they show this diagram:
I understand the tablet use case perfectly, but for the Handset use case, I don't get why you would put each fragment into its own activity. I typically create one activity and add the fragments to the backstack (via FragmentManager). Is either one of these approaches considered the 'right' way to do it? If both are okay, what is a good rule of thumb to use for picking which approach to use?
This question is closely related, but I'm not totally satisfied with it. If you're supposed to use separate activities, what's the point of having a fragment backstack in the first place?

I doubt there is a right way to do it. There are likely some ways that are better than others in some circumstances, but for the most part, the answer will be "it depends."
I have noticed in the latest version (22.x) of the SDK with Eclipse that every Activity that is generated is nothing more than a placeholder for a Fragment. The Fragment is auto generated and contains the view logic. It seems like they want to make Activities nothing more than a placeholder/controller for Fragments. I don't think I agree with that. While I definitely see the use case for Tablets, I feel like this pattern should be used more on an as needed basis than as a general rule. This is just my opinion, but I think moving ALL of the logic into the Fragment sacrifices some of the benefits you get from using an Activity, so it is only a useful pattern if you need to re-use that fragment specifically.
If you're supposed to use separate activities, what's the point of having a fragment backstack in the first place?
Good question. I personally prefer to use many Activities and only use Fragments where I need to re-use the logic/views in multiple places. I think the flow of using startActivity and startActivityForResult and allowing the system to manage your activity stack is just a little easier than trying to manage a huge Fragment back stack and one Activity (again, just my opinion).
So when would I ever use the Fragment back stack? There was actually a very good situation for me to use it recently. I had an Activity that needed to build a very complex object. The Object needed many fields input to the user, so I created a Workflow that walked the user through this process one step at a time. I created a single Activity to handle the creation of this logic. Each step of the UI was a Fragment that took input from the user, reported back to the Activity, then the Activity loaded the next Fragment. The Fragments were added to the back stack so the user could go back to previous steps in the workflow.
Object1CreationActivity
FragmentA --> FragmentB --> FragmentC --> FragmentD
Communication between the Fragments and the Activity should be done with interfaces. This is important if we want to re-use these anywhere else. Because of this, I could re-use much of this code to create another Object.
Object2CreationActivity
FragmentB --> FragmentD --> FragmentE
To summarize, Fragments, Activities, the back stack, these are all powerful tools you can use to make Android applications. There may not be a great rule of thumb for when and how to use them, but as long as you are well versed in how they work together, you can use them as appropriate for your application.

fragments are light weight alternatives to activities....that is one way to look at it. e.g. i have my our app which has about 10-13 screens. Either
I create a new activity for each one of them. OR
I create only a few activities that are logically distinct in functional aspects ad swap view screens in them OR
I create 1 activity and delegate actual screen functional to fragments.
I find the third way much better and manageable. Its kinda saying that fragments allow reuse of view using the framelayout options. Further more you can devise an easy way to share data between fragments as against the heavy weight way of using a Parceable to share stuff between activities.
Also Android API folks are going to focus more on fragment based designs instead of activities so its better to stick with standards. Using fragments i a just a tad more complicated than using activities but is well worth the effort to learn them. Helps create scalable and quiet reusable screen views IMHO.

Android floating view across activities

Requirement
I have an application with 2 activities, say A and B, with navigations like A->B and B->A (on back press). My requirement is
I want a view/layout floating on screen, irrespective of which
activity is currently visible. I inflate this view on app
start(onCreate of activity A), it remains static on screen during the
transition from A->B and when B is onscreen.
So naturally this view should be inflated only once (when app starts,
onCreate of A).
What I found out
I did some searching, and from what I could find, there are 2 methods to reuse layout in android
using <include>
It just seems like a tool to write xml code of commonly used UI elements. It gets inflated every time it is used in a parent layout.
using ViewStub
I did some research on using ViewStub and It also seems a way to reuse code segment in many layouts. It also need to be inflated every time we use it in a layout except it gets inflated only when we make them visible at run time.
Another hint of my requirement
For people familiar with iPhone development you can add view's to UIWindow, which stays there irrespective of which UIViewController is currently active. I want exact behavior in my application.
My original setup
I am targeting android 2.1 and above. It seems Fragment is available from API level 11 (android 3.0) and above. One option is to use android compatibility library that enables usage of Fragment in older versions. I am currently researching on that now. But I also would like to know if there is any other methods available to fulfill my requirement, rather than change my entire project and use fragments.
I have around 30 odd activities in my application and I want this layout floating over all of them. I just made out a test case with 2 activities to make the question simple and easy.

Solution 1: FrameLayout
I think what you want to use is the FrameLayout. FrameLayout is designed to block out an area on the screen to display a single item. Child views are drawn in a stack, with the most recently added child on top.
http://developer.android.com/reference/android/widget/FrameLayout.html
Then read here about the back stack that you could use in your activity to flip back and forth between the activities using the back button:
http://developer.android.com/guide/topics/fundamentals/tasks-and-back-stack.html
Solution 2: Fragment Transactions
Rather than code two separate Activities, code a single Activity with two Fragments. Here is a blurb from the Fragments documentation:
"A fragment must always be embedded in an activity and the fragment's lifecycle is directly affected by the host activity's lifecycle. For example, when the activity is paused, so are all fragments in it, and when the activity is destroyed, so are all fragments. However, while an activity is running (it is in the resumed lifecycle state), you can manipulate each fragment independently, such as add or remove them. When you perform such a fragment transaction, you can also add it to a back stack that's managed by the activity—each back stack entry in the activity is a record of the fragment transaction that occurred. The back stack allows the user to reverse a fragment transaction (navigate backwards), by pressing the Back button."