Develop Reference

Activities overlapping

I am new to writing Android apps, I have been using the internet and Android Studio to create an app for my club as a bit of fun and learn along the way. I have been watching videos, using tutorials and walkthroughs and I am getting to learn the basics.
However, I have got stuck. I used a drawer template from Android Studio and added the activities I needed and buttons on the main screen to the activities and they all worked fine, no overlapping. When I tried to link the drawer icons to the activities, rather than use the buttons on the main screen, they work, but the app (visually) puts the next activities content on top of the one before.
I cant find anything on the internet except something called backstacking, but that is described when the back arrow is used, my problem is to do with selecting an activity from the drawer menu. I have attached a picture to show what I mean. It gets worse the more menu items that are selected.
If anyone could help, it would be great!

If you are using XML root layout as a constraint layout maybe your constraints are missing. If you are using constraint layout set both top/bottom and left/right constraint.
If your constraints only top for example it is look good on desing but in device that dont know where to positioning left or right and automatically positioning 0 point to top.

When you click one any one menu item put the visibility of other images as gone like
visibility(View.GONE);
and the one selected to be visible

Deep hierarchy of fragments in android

Is it possible to build up an architecture like this with fragments:
Navigation drawer showing the main menu and then when clicking one of the menu items an ordinary combo of list/detail is shown (so far so good, all tutorials explain this). But what if I want a button on the detailed fragment to show a second combo of list/detail fragments, which should not be reached through the Navigation Drawer?
As I have implemented it now, one fragment instatiates the next, which is wrong according to the guides (fragments should always communicate through an activity). But it works fine as long as the user is clicking deeper into the app. The issue comes when he starts to use navigate back, because all the UIs then start to be laid on top of each other.

I wouldn't. Fragments aren't 100 percent consistent across all versions of Android, unless you're using the support library. Even then- nested fragments have always been a bit broken. They weren't even supported at first. The more levels of nesting you add, the less likely it is to work as expected. I wouldn't add more than 2 levels of fragments, and I'd try hard to keep it to 0-1.

Android activity and fragments, best practice

I'm about to make my first Android application and I am currently reading about activities and fragments. I intend to use the Lollipop navigation drawer feature to load different screens in my application for different features. Like settings, About, Add new x, browse x, etc. Should my nav drawer be loading different activities for each item click or loading a new fragment?
All my screens will have the same style associated with them, but will have obviously much different content.
If I load a new activity, do I "lose" the nav drawer to the side? or is it always present as I want it to be accessible from any screen in the application.
I am quite unfamiliar with the Android system so far, but no matter what I choose do I need to use an intent to launch either of these. A real lay mans explanation would be greatly appreciated.
Thanks
EDIT: Within one of my screens I hope to use a tab system and have it change.
This is a mockup I have designed, as you can see I would like the nav drawer to be used from this screen but also allow the switching of 3 different tabs, within the Add new timetable screen.
How would I go about having a tab at the top and then 3 different (linked) screens under it. This would be the deepest level I would go. Every other screen would just be one screen, no tabs.

Activity typically takes the whole screen, so yes, if you launch an Activity, you will temporarily "lose" everything that's placed in other activities.
Fragments, on the other hand, can be stuffed to smaller areas, and you can have several fragments on the screen at once.

How do you implement a fixed left pane for an Android tablet layout?

I'm porting an iPhone+iPad app to Android. It uses a Split View Controller for tablets which in Android lingo allows you to present two Activities side by side simultaneously (Edit: Android only allows one Activity on screen as mentioned by #commonsware below. The next best thing is to use fragments, but the Action Bar can only exist at the Activity level, meaning it will have to expand the entire width of the screen. It wonder if a Split Activity Controller will be coming to the Android Platform.)
The tablet landscape layout has a fixed left pane for statistics that never changes. The right hand pane functions just like the phone version of the app. Transitions occur exclusively on the right hand pane. i.e. the whole screen doesn't slide when changing activities, only the right pane. How would you recommend implementing this in Android?
Should I use a single activity and manually perform transitions between fragments in the right panel? This app has 25 screens and will have an alternate layout for phones, so I'm trying to plan ahead and do this right the first time :) Thanks for your help!

It uses a Split View Controller for tablets which in Android lingo allows you to present two Activities side by side simultaneously.
No. In "Android lingo", you cannot "present two Activities side by side simultaneously". You can present two fragments side by side simultaneously.
How would you recommend implementing this in Android?
Use fragments. Use a FragmentTransaction to replace the right-hand fragment as needed based on user input. Your overall activity layout could have a horizontal LinearLayout (with android:layout_weight to control the sizes for the left and right sides), with a <fragment> element for the left and a FrameLayout for the right.
Should I use a single activity and manually perform transitions between fragments in the right panel?
Yes, to achieve what you ask for.

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.