Develop Reference

Trouble understanding Fragment and Activity

I'm a beginner in Android programming, and have trouble understanding the activity - fragment principe.
As far as I understood, fragments are something like "sub-activities", and I can add multiple fragments in one activity, but also I can have an Activity without any Fragments.
Answers to the question "why use fragments at all" can be found all over the net, also there are some stack overflow questions to this topic.
But my question is: If there are advantages in using fragments - why to use activities then?
If fragments are "better" and I should use them everywhere I can, then all my Activity classes will be empty, and the fragments will bring the content to the screen - is this the best practise?
If i want to add a menu for example - I can put it only in the fragment, so what's the point in adding setHasOptionsMenu() in the Activity class?
To be more specific: What should I put in activities, and what in fragments?
I hope you understand my problem.

But my question is: If there are advantages in using fragments - why to use activities then?
Because you don't have a choice. Activities are part of the Android foundation. You cannot have a launcher icon invoke a fragment directly, for example.
so what's the point in adding setHasOptionsMenu() in the Activity class?
In many UIs, there will be action bar items that have nothing to do with any particular fragment: "Settings", "Help", "About", and so on. Those are perfectly fine to define in the activity.
What should I put in activities, and what in fragments?
At the end of the day, you are welcome to do whatever you want, so long as it compiles, runs, and does what you want reliably. You can roughly divide the approaches into three "schools of thought" around fragments.
The simple one is, "fragments are teh evilz and must be destroyed". Adherents will use something else (e.g., Square's Flow and Mortar) as an alternative.
The more complex one is "use fragments where they prove useful". The definition of "useful", like beauty, lies in the eye of the beholder. So, you will see people use fragments for:
master/detail and similar structures for making better use of larger screen sizes while remaining adaptable to smaller screens
pages in a ViewPager
DialogFragment for dealing with configuration changes and dialogs
etc.
Your current position is the third school of thought: "Fragments Über Alles". The difference between this and the "where its useful" scenario is that you would apply fragments even in cases where there is no clearly defined use for them. For example, a HelpActivity, whose sole UI consists of a really big WebView showing your documentation, would not necessarily benefit from having that WebView be managed some subclass of WebViewFragment. The "where its useful" people would skip the fragment until some clear need arose (e.g., you want the help to be side-by-side with other content in an activity on larger screens) The "Fragments Über Alles" adherents would use the WebViewFragment all the time.

What is the best way to build app architecture( activities and fragments)

I am building app right now. I am trying to follow all design patterns and google suggestions for building responsive apps.
Firstly, my app will contain navigation drawer.Of course my app will have several activities. So I have searched the best way to have navigation drawer on all activities, I found that the most correct way is to use some BaseActivity class which will have navigation drawer in its layout and framelaout for storing each activity representation(container for fragment). It can hold fragment, but the problem is that only one fragment.
So I have faced this problem. I am going to design following activity
So as in the picture I wanna to have image slider at the top , and some other layout parts under this slider for example grid layout, list or something other.
I think it would be better to separate image slider and other part, for example when my scree will be in landscape orientation it should be replaced but something other.
Futhermore others activites also gonna to have several independent parts for example list and anything other widget.
But as far as my activities should extend BaseActivity class, they would have only one place(container) for storing fragment.
I have tried to think about ways to solve this problem , and I have only one idea is to create several fram layouts in base activity(equal to max fragments used on child activities) and setting them visible and invisible depending on needs, but this approach pretended to be only way of hidding problem.
I don't know what is the most correct way to implement such type of application, so I need help or advices from more experienced developers to build my app correctly and bring user good experience.
I hope you can help me.
Thanks.

To start with, the container in your BaseActivity does not have to necessarily be a FrameLayout. For example it could easily be a LinearLayout with android:orientation="vertical", so that all fragments you add in it will stack one below the other.
Also each fragment can has other nested fragments in itself (although that's generally not the best practice, as usually it indicates some bad UX decisions).
Both those said, I think you just use the first point I made here. Now if you choose this one, I'd expect the question how to handle tablets and other big screens? Best way to handle them is to create a new landscape layout for your BaseActivity, where the fragments container might be different, for example a RelativeLayout, a LinearLayout with orientation="horizontal" and so on.
Good luck!

Some questions on when to use fragments and activities

Just a disclaimer, I am pretty new to Android and slowly working through tutorials. Most tutorials dont talk about fragments at all in the beginning, but Android-studio by default sets up one for you.
I've read some of the past questions and the dev blog related to fragments and activities and they were helpful in giving me an idea as to the advantages of using fragments.
I am still a bit confused on when one would use a new activity in an app, it seems to me like everything could be accomplished with fragments and a single activity.
Lets say an app has multiple screens, do you implement that as one activity with multiple fragments, or multiple activities with one fragment each to them.
This image makes sense to me and demonstrates the power of fragments, but why on the handsets example is two activities required?
Another add-on question, should everything moving forward be done in a fragment?
Thank you and sorry if these questions didnt really make sense.

An Activity should be the host for a collection of related Fragments. For instance, you might have something like:
Base Activity extends FragmentActivity
LoginActivity extends BaseActivity
-- LoginFragment
-- LoginErrorFragment
-- LoginSignUpFragment
SettingsActivity extends BaseActivity
-- SettingsGeneralFragment
-- SettingsAdvancedFragment
If you try to move all of your logic into a single Activity, it's going to get unmaintainable very quickly. Another good practice is to have a base Activity which all of your Activities extend; since if you suddenly find that there's some functionality you want to provide to all activities, you can just add it to the base class.

Everything said above in both regards are absolutely correct. I would just like to add few points to them.
When thinking about fragments please keep in mind that they are a part of an Activity, which like any other view can be added, modified and replaced dynamically. For example, while using ActionBar's and Navigation Drawers fragments become more handy and flexible. Similar things stands true for ViewPager etc.
Fragments also cater to larger screen sizes in a much better way than the traditional Activity approach. Imagine the users experience then when for every action performed a new screen would replace the Phone/ Tablet against now when all the actions and their performed events lie on the same screen.
One more thing which I like about fragments is, we dont have to declare them in the Manifest. :) Most of the time we forget to do that with Activities until the compiler prompts. :) (At least me)

As you said. In simple application you can use only one Activity and just replace fragments. I did it in my apps and it works perfect. Sometimes you just need to start new Activity if you want to follow android design and architecture patterns.
According to your question about images that you posted you can
obtain the same effects using just one Activity and Fragments.
Yes everything moving forward can be done in a Fragment.

switch to a new activity, instead of switching fragments, when jfeinstein10's slidingmenu list item is clicked

I have seen a few questions raised on this topic (for e.g.: https://github.com/jfeinstein10/SlidingMenu/issues/5) but I am still unclear. I hope somebody can clarify this.
Context:
See https://github.com/jfeinstein10/SlidingMenu
I have an android app that organizes screens by activities and fragments (i.e.) each screen is an activity containing one or more fragments.
The new requirement is to add a sliding menu (similar to what this library provides).
Issue:
It appears from the examples and discussion that the right model would be to have just 1 MAIN ACTIVITY that will then switch in/out fragments belonging to the different screens. In fact the author mentions in the above thread: "If you were to launch Activities based upon the list selection, then you would not have the behavior where you swap the views that you're talking about. " and also "You can't put an Activity into the above view. That doesn't really make sense when you think about what an Activity is. ".
Why doesn't it make sense? Obviously, I am missing the point here.
Question:
Given that my project already contains multiple activities (one corresponding to each screen), is my only option then to re-organize the project to have JUST 1 MAIN ACTIVITY, in order to use this library? Or alternatively, is there any way to launch a new activity when a list item in the sliding menu is clicked, and still observe the sliding menu behavior, [EDIT- added the last part to be more clear] or in other words, on how exactly to use this library within my existing app design.
Thanks in advance

First, you can't have an Activity inside another and activities are completely different from views as stated in the docs:
An activity is a single, focused thing that the user can do.
Now, to answer your question, it all depends on how you want your app to behave. You could have your activities with the sliding menu implement the onClosedListener and switch to the selected activity from there. This will give you the animation of closing the menu before switching activities. It will also give you a weird effect since every time you select something from your menu you'll see the animation of a new activity coming to the front.
I think the best approach would be to have a "common purpose" between all your sliding menu options. For example, in one of my projects I have to allow the users to select between lists of different types of data. When the user selects anything from the menu, I load a new list fragment into the right corner where he may choose the item he wants to view or edit. That's the app entry point and also the only place were I have a sliding menu in my app. It is pretty much the same for every app that implements this UI design pattern. Look at google+, currents and youtube where the side menu lets you choose which feed or content to show. Once a user makes a selection, just open a new activity for the selected item (a g+ post, a video, a news article, a tweet or whatever it is).
Your app doesn't have to have lists of different data or anything like that to use the sliding menu, but keep in mind that the activity with the sliding menu should have a clear, focused goal with respect to its functionality and purpose. Having a sliding menu because many other apps have one is a bad choice, you should use it with a specific objective. Also keep in mind that applying the sliding menu everywhere would interfere with the platform's navigation pattern and lead to an overall bad user experience since it wouldn't behave as the other apps.

It doesn't make sense to place an Activity into the above view because the Activity is the main controller for the view of each screen. The Activity also shows views and keeps track of Fragments (which in turn are mini controllers, with or without their own views). So placing an Activity in the above view would mean that you would place an Activity in an Activity... Wich is impossible.
From what I can derive from your text I think it would be wise to read through the Android developer guide on Activities and Fragment again (http://developer.android.com/guide/components/activities.html) to get a better understanding of how the concept of Android works.
Now to your question:
I am not clear on what you are trying to achieve but if you want your app, with menu to behave like, say, the Google+ app then one way of doing it is to implement a base class that extends the Activity class (or what ever base Activity used in your project) and let the base set the SlidingMenu. Then you would simple extend your base Activity in each of the Activities that are supposed to have a menu.
You could also do it the way you describe it, but then you would end up with a classic example of a God object (http://en.wikipedia.org/wiki/God_object). It's a neat way to practice your Fragment juggling skills and switching between Fragments instead of starting new Activities does have it's use cases, but I still wouldn't recommend it for a project with more then a few views.

Here is the answer that came closest to the issue I had - http://www.verious.com/article/polishing-the-sliding-app-menu/. Scroll down to the bottom of the page to see the last section titled "Using the fly-in app menu between Activities". This is one option if you have a lot of activities in your existing app and want to avoid extensive re-factoring. I haven't tried this out yet but its worth being aware of.

Android: Multiple views, deep navigation, one Activity. What is the best way to handle?

I'm looking for the the best way to reproduce, in an Android app, the behavior of the iPhone UiNavigationController within an UITabBarController.
I'm working on this Android app where I have a TabActivity and 4 tabs. I've already gone through a lot of posts regarding the use of activities and tabs and how it's not a good idea to use activities for everything, which seems fair enough. I decided to use one Activity on each tab anyway, since it makes sense in my application.
However, in one of those activities I have a deep navigation tree with more than one branch and up to 12 different views the user can go through.
The problem is: Android controls the navigation through activities inside an app, if you click the back button it will go to the previous one, but if I'm navigating through views, using one Activity, and I click back, it just finishes it. So how can I have a smooth navigation behavior between views in an Activity?

I had implemented this using a TabActivity with FragmentActivity as each tab. Utilizing Fragments API you can organize the code just like you would be using 12 different activities, still using only 1 for each tab in fact. Fragment's framework will handle back key press for you to show previous fragment instead of closing the entire activity.
There are some problems with such approach, for example, there's no MapFragment, but the workarounds can be found here on SOF.
You will need Android Support Package if your minimum SDK version is lower than 3.0.

Well I know very little about UiNavigationViewController, but I guess you want something to navigate between different Views. As you are using TabActivity, every tab should load into a separate Activity.
But since you want to branch it out, using that many Activities is not a perfect solution, neither the ActivityGroup too. The better solution, as per my opinion(I have run into similar problem once) is to have the main or root tabs loads into separate Activity, but for their branches, use the ViewFlipper, which flips the Views. So the whole Layout(Subclass of View) can be flipped.
You may run into some problem while flipping more than two Views (as what people say, though I never had any problem). So in that case you can use layout.setVisibility(View.GONE) to hide the layout and just change it with View.VISIBLE for next view.
And about the concerns of back button, you need to store the last used View or Activity into a variable, and in the override of onBackPressed(), just need to call them.
There might be better solution than this, not that I can remember, but yeah it's the easiest solution I can come up with.