I have an Activity class that have a DrawerLayout. That layout shows a list in Drawer and let user to switch between fragments. In these Fragments, there are some URLs and when user clicsk on that, a WebviewFragment would be shown. However, I don't want to show the DrawerLayout in the WebViewFragment. Instead, I would prefer user would being redirected to previous Fragment.
Is there any way for me to show/hide the DrawerLayout depends on what the current Fragment is?
I try to call mDrawerLayout.setVisibility(View.GONE), but it seems that it is not complete. At least the ActionBar icon is still the drawer icon.
You can use this method to lock or unlock the drawer: DrawerLayout.setDrawerLockMode(...). (There are also two other versions of this method to specify a lock mode for specific drawers.) To lock, use DrawerLayout.LOCK_MODE_LOCKED_CLOSED; to unlock, use DrawerLayout.LOCK_MODE_UNLOCKED.
If you are using the ActionBarDrawerToggle, you need to add some extra code to prevent the drawer from opening when they click the ActionBarDrawerToggle if you've locked the drawer.
#Override
public boolean onOptionsItemSelected(MenuItem item) {
// check lock mode before passing to ActionBarDrawerToggle
// I assume your drawer is on the left; if not, use Gravity.RIGHT
int lockMode = mDrawer.getDrawerLockMode(Gravity.LEFT);
if (lockMode == DrawerLayout.LOCK_MODE_UNLOCKED &&
mDrawerToggle.onOptionsItemSelected(item)) {
return true;
}
// Handle your other action bar items...
return super.onOptionsItemSelected(item);
}
Why not open a new Activity that has only a WebView as its content instead? Then the user will have to press the back button to go back to the Activity with the DrawerLayout, and then there will be no problems.
Alternatively, you don't have to have such an activity yourself, you can let Android find a browser for them to open instead using this code:
Intent intent = new Intent(Intent.ACTION_VIEW, Uri.parse("HTTP_URL_GOES_HERE"));
startActivity(intent);
Related
When I use Material Drawer, as soon as a new activity starts, drawer is being displayed automatically, but I want that it starts hidden, so I have to use function drawer.closeDrawer() in the method onResume of activity, as described below:
#Override
protected void onResume() {
super.onResume();
drawer.closeDrawer();
}
Is this the correct way to hidden the drawer when activity starts or restarts, or there is a property to be set for this purpose in the drawer?
Thank you,
Alexandre Bianchi
There are different cases why the drawer may opens after the application starts.
Either you define withShowDrawerOnFirstLaunch, this should be removed or set to false, if you don't want this behavior.
https://github.com/mikepenz/MaterialDrawer/blob/develop/library/src/main/java/com/mikepenz/materialdrawer/DrawerBuilder.java#L1188
It could also be that you open the drawer via the Drawer's API. So make sure you don't call openDrawer programtically
https://github.com/mikepenz/MaterialDrawer/blob/develop/library/src/main/java/com/mikepenz/materialdrawer/Drawer.java#L125
The Drawer comes also with a method to close the drawer. Just call closeDrawer
https://github.com/mikepenz/MaterialDrawer/blob/develop/library/src/main/java/com/mikepenz/materialdrawer/Drawer.java#L134
Put this code in oncreate and it will check the drawer is open or not...if its open it will close the drawer
DrawerLayout layout = (DrawerLayout) findViewById(R.id.drawer_layout);
if (layout.isDrawerOpen(GravityCompat.START)) {
layout.closeDrawer(GravityCompat.START);
}
In my application I created a Navigation Drawer which has 5 items, once an item is clicked in the Navigation Drawer, I can correctly check the item and show the new fragment using the fragment manager.
But currently I have three problems:
My application has floating action buttons, that of course perform actions and open new fragments, so I need to handle that "Fragment changing" in the navigation drawer too, setting as checked the current item which corresponds to the fragment showed.
I SORT OF solved this problem, but using a single method that
performs the fragment transaction in the MainActivity and meanwhile
checks the new item. So everytime a Fragment want to call another
Fragment, it uses this function passing the nav_drawer_item_id as a
parameter. I think that this solutions sucks, so if you have a better idea, it would be really welcome!
My biggest problem is that when the user press the Android Back Button, the fragment pops back to previous one (or sometimes I call popback() programmatically because I am done with that specific fragment )
I really don't know how to solve this problem because I can't check the correct item in the navigation drawer once a fragment is popped back, I need to know which fragment it is.
I need to show the new fragment once the navigation drawer is closed in order to respect "Android Rules" ( And because it's nice ).
I sort of solved this problem too, by setting a "nextFragment" inside the navigation drawer onNavigationItemSelectedListener and by showing the new fragment inside the drawer onDrawerClosed. Is it the only solution?
I'm not posting any code because it really doesn't deserve to be seen, so here is some extra info:
I have a single activity which contains the Navigation Drawer and currently handles the fragment transactions.
I have 6 fragments, 5 called from the Navigation Drawer and 1 called only from others UI components, but this one doesn't need to be checked on the drawer of course.
I tought about a solution and it was like "Setting the checked item FROM the fragment that is showed", but I didn't find any way to get the Navigation Drawer from the Fragment in order to set the proper item checked.
Implement FragmentManager.OnBackStackChangedListener in your activity to get notified whenever something is popped off the back stack and sync the navigation drawer from the callback. That should get rid of the problem caused when the back button is pressed.
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
.....
getSupportFragmentManager().addOnBackStackChangedListener(this);
}
#Override
public void onBackStackChanged() {
// Get the currently active fragment
Fragment fragment =
getSupportFragmentManager().findFragmentById(R.id.fragments_frame);
// Check which fragment is active, check the
// correct selection and set the title accordingly
if (fragment instanceof FragmentAtPosition0) {
setCheckedAndTitle(0);
} else if (fragment instanceof FragmentAtPosition1) {
setCheckedAndTitle(1);
}
}
private void setCheckedAndTitle(int position) {
MenuItem item = navView.getMenu().getItem(position);
item.setChecked(true);
setTitle(item.getTitle());
}
As for the other two cases that you mentioned, I think the solutions you have mentioned are the preferred ways.
I'm implementing an Android application with a Navigation Drawer and I have a problem with it.
I started from the template (Android app with navigation drawer) in Android studio and added a new section to it - Settings. When clicking the settings button the user is taken to a new Activity and the user can go BACK either by pressing the "up" button in the action bar (Which works perfectly) or by pressing the physical back button. That part doesn't work so good.
When pressing the "up" button and then opening the navigation bar, my home page is highlighted (selected). But when using the back button and opening the navigation drawer, the Settings item is selected, as if the user is viewing that page and not the home page.
So this is because the Navigation Drawer fragment isn't updated and I havent found any way to solve this problem. What I would like is for the Navigation Drawer to be recreated (Which is what I think happens when pressing the "up" button). Do you know how I can make this happen?
I started working on a solution based on this:
getSupportFragmentManager().addOnBackStackChangedListener(
new FragmentManager.OnBackStackChangedListener() {
public void onBackStackChanged() {
// Update your UI here.
}
});
But I don't know what to write there that will update the whole UI. (experimented with calling onCreate() but it's too ugly and can't be the right way).
Any suggestions?
UPDATE:
The onBackStackChanged event isn't sent when pressing BACK from another activity. Only for fragments in the current actvity.
You have to override the actionbar back button like this :
#Override
public boolean onOptionsItemSelected(MenuItem item) {
// TODO Auto-generated method stub
switch (item.getItemId()) {
case android.R.id.home:
this.finish();
//or
super.onBackPressed();
break;
}
return true;
}
I had the same problem.I used notifyDataSetChanged() in the ListView Adapter.
In getView() i used,
if(mListView.isItemChecked(position)) {
convertView.setBackgroundColor(getResources().getColor(R.color.md_black_1000_12));
}else{
convertView.setBackgroundColor(getResources().getColor(android.R.color.transparent));
}
notifyDataSetChanged();
I have a Navigation Drawer (appcompat v7) in my app which is working perfectly fine.
Now I want to disable it, until the user buys an in-app-purchase to unlock additional functionality. So in my Activity.onCreate(), after initializing the drawer and populating it, I am calling this function:
mDrawerLayout.setDrawerLockMode(DrawerLayout.LOCK_MODE_LOCKED_CLOSED);
This function is not doing anything. The drawer continues to open and close as normal after tapping the drawer carat in the actionbar. I tried calling this function in Activity.onResume() without any difference.
What is the correct way to use this function?
(I tried looking online for answers, but couldn't find anything which addresses my issue). Any help is appreciated, as I am stuck on this issue for quite sometime now.
mDrawerLayout.setDrawerLockMode(DrawerLayout.LOCK_MODE_LOCKED_CLOSED);
is only disabling the opening drawer layout by swiping till you click navigation drawer icon
keep a boolean variable
write mDrawerLayout.setDrawerLockMode(DrawerLayout.LOCK_MODE_LOCKED_CLOSED); in onStart() and also write below lines of code
#Override
public boolean onOptionsItemSelected(android.view.MenuItem item) {
if(!disabled)
{
if (item.getItemId() == android.R.id.home) {
if (mDrawerLayout.isDrawerOpen(mDrawerLinearLayout)) {
mDrawerLayout.closeDrawer(mDrawerLinearLayout);
} else {
mDrawerLayout.openDrawer(mDrawerLinearLayout);
}
}
}
return super.onOptionsItemSelected(item);
}
this will work for sure
When you call setDrawerLockMode(DrawerLayout.LOCK_MODE_LOCKED_CLOSED) it locks opening and closing drawer only by swipes.
The drawer continues to open and close as normal after tapping the drawer carat in the action bar because your drawer will still respond to calls to openDrawer(int), closeDrawer(int) although a drawer is locked.
You need to add some logic in your action bar menu button listener and not to call openDrawer(int) when you don't want it to open.
Btw, it is okay to call setDrawerLockMode(int) in onŠ”reate
There is a bug with DrawerLayout and used gravity. I have reported it here:
https://issuetracker.google.com/issues/136738274
I have an app with master/detail layout (1 activity, 1 ListView fragment and 1 detail fragment). When the user clicks an item in the ListView, a fragment transaction instantiates a detail fragment on the right-pane that includes the information corresponding to that item. When the detail fragment is shown I hide the initial action bar buttons/items and show 3 new AB items (done/delete/cancel). The user can clean the right-pane and return to the initial UI state by either pressing the back button or by pressing one of the 3 AB items.
The issue I'm experiencing is that when the user selects the app's home icon (i.e. "up navigation") the activity gets re-loaded (i.e. the animation that indicates that the activity is starting can be seen as both the action bar and the UI is been redrawn). The issue only happens when the app home icon is pressed. If the user presses the back button or a cancel/done/delete action bar button, the fragment is simply remove from the right-pane and the UI returns to initial state without any "re-loading".
The XML layout for the activity is the following (inside LinearLayout; prettify is hiding that line):
<fragment class="*.*.*.ListFragment"
android:id="#+id/titles" android:layout_weight="1"
android:layout_width="0px"
android:layout_height="match_parent" />
<FrameLayout android:id="#+id/details" android:layout_weight="2"
android:layout_width="0px"
android:layout_height="match_parent" />
The DetailsFragement has the actionBar.setDisplayHomeAsUpEnabled statement in its onCreate method:
#Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setHasOptionsMenu(true);
ActionBar actionBar = getSherlockActivity().getSupportActionBar();
actionBar.setDisplayHomeAsUpEnabled(true);
}
For both the ListView fragment and the Detail fragments the onCreateOptionsMenu() and onOptionsItemSelected() method are implemented within the fragments. Below the code for the Details fragment:
#Override
public void onCreateOptionsMenu(Menu menu, MenuInflater inflater) {
inflater.inflate(R.menu.edit_menu, menu);
}
#Override
public boolean onOptionsItemSelected(MenuItem item) {
// some variable statements...
switch (item.getItemId()) {
case android.R.id.home:
//Toast.makeText(getSherlockActivity(), "Tapped home", Toast.LENGTH_SHORT).show();
onHomeSelectedListener.onHomeSelected();
return true;
case R.id.menu_edit_item_done:
editedTask.setTitle(editedTaskTitle);
onTaskEditedListener.onTaskEdited(editedTask, UPDATE_TASK, true);
return true;
default:
return super.onOptionsItemSelected(item);
}
}
In the host activity I implement the onHomeSelectedListner to handle the app home icon press (i.e. "up navigation":
public void onHomeSelected(){
FragmentManager manager = getSupportFragmentManager();
FragmentTransaction ft = manager.beginTransaction();
TaskFragment taskFragment = (TaskFragment)getSupportFragmentManager().findFragmentById(R.id.details);
ft.remove(taskFragment);
ft.commit();
manager.popBackStack();
}
The activity's listener in charged of handling all other action bar buttons (i.e. done/delete/cancel) is onTaskEditedListener and, aside of other code that processes some data, it has the same fragment transactions shown above.
Update(1/24)
Based on tyczj and straya feedback I placed log statements inside onCreate(), onResume(), onPause() of the activity to determine the differences between onHomeSelected and onTaskEdited listeners. I'm able to confirm that during the "up navigation" event (i.e. onHomeSelected) onPause(), onCreate() and onResume() are called. Whereas during the onTaskEdited call (i.e. back button or done/delete/cancel press) none of those events are called.
Update (1/25)
Based on a suggestion by Mark Murphy, I commented out the onHomeSelected method call in the "case android.R.id.home" statement just to see what would the Activity do. The thinking was that the app would do nothing since the are no statements. Turns out that is not the case. Even without a call to the listener method (i.e. that removes the fragment), the activity is restarted and the detail fragment is removed from the fragment container.
Update (2/28)
I temporarily workaround the fact that my main activity was getting restarted by disabling the window animations (as highlighted in my own answer). However, through further testing I uncovered a bug. Thanks to Wolfram Rittmeyer's sample code I was able to figure out the real reason(s) why my activity was restarting (in master/detail single layout) during up navigation:
1) Although I was using this "onHomeSelectedListener" to properly remove the fragment from the backstack, I still had some remnant code in the ListView fragment's onOptionsItemSelected that was creating a new intent to start the hosting activity. That's why pressing the app's home icon was re-starting the activity.
2) In my final implementation (shown in my own answer), I got rid of the onHomeSelectedListener in the activity and replace the startActivity intent (i.e. offending code) inside the ListView's onOptionsItemSelected to use the fragment removal + popBackStack code originally in the onHomeSelectedListener.
After much research and poking around, turns out that only reason why my activity was restarting during "up navigation" for master/detail configuration was because I left some code in the ListView Fragment's onOptionsItemSelected that was creating an intent to start the main activity in addition to my full fragment transaction code elsewhere. Below is the final implementation with which I got "up navigation" to work properly on both phone (multiple activities) and tablet (single activity/multi-pane) configurations. Thanks to Wolfram Rittmeyer for a couple of hints in his code (link in the comment section) that help me pinpoint my problem!
Main Activity: Hosts the fragments and performs some other app-specific operations
ListView Fragment: Handles "up navigation in table configuration
#Override
public boolean onOptionsItemSelected(MenuItem item) {
switch (item.getItemId()) {
case android.R.id.home:
if(mDualPane){
FragmentManager manager = getSherlockActivity().getSupportFragmentManager();
FragmentTransaction ft = manager.beginTransaction();
DetailFragment detailFragment = (DetailFragment)manager.findFragmentById(R.id.details);
ft.remove(detailFragment);
ft.commit();
manager.popBackStack();
getSherlockActivity().getSupportActionBar().setDisplayHomeAsUpEnabled(false);
getSherlockActivity().getSupportActionBar().setHomeButtonEnabled(false);
}
return true;
// Other case statements...
default:
return super.onOptionsItemSelected(item);
}
}
Details Fragment: Handles up navigation in phone configuration
#Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setHasOptionsMenu(true);
// Sets "up navigation" for both phone/tablet configurations
ActionBar actionBar = getSherlockActivity().getSupportActionBar();
actionBar.setDisplayHomeAsUpEnabled(true);
}
#Override
public boolean onOptionsItemSelected(MenuItem item) {
switch (item.getItemId()) {
case android.R.id.home:
if(!mDualPane){
Intent parentActivityIntent = new Intent(getSherlockActivity(), MainActivity.class);
parentActivityIntent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP | Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(parentActivityIntent);
getSherlockActivity().finish();
}
return true;
// Other case statements...
default:
return super.onOptionsItemSelected(item);
}
}
If you look at the Navigation Design Pattern you will see that you want to return to the starting activity when the home button is hit.
So say you have 2 Activities call them A1 and A2. Clicking on something in A1 takes you to A2. If the user hits the home button you should return them to A1 clearing the stack of everything up until that activity like this
Intent intent = new Intent(this, A1.class);
intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
startActivity(intent);
this is what the flag Intent.FLAG_ACTIVITY_CLEAR_TOP does
If set, and the activity being launched is already running in the current task, then instead of launching a new instance of that activity, all of the other activities on top of it will be closed and this Intent will be delivered to the (now on top) old activity as a new Intent.
For example, consider a task consisting of the activities: A, B, C, D. If D calls startActivity() with an Intent that resolves to the component of activity B, then C and D will be finished and B receive the given Intent, resulting in the stack now being: A, B.`
The currently running instance of activity B in the above example will either receive the new intent you are starting here in its onNewIntent() method, or be itself finished and restarted with the new intent. If it has declared its launch mode to be "multiple" (the default) and you have not set FLAG_ACTIVITY_SINGLE_TOP in the same intent, then it will be finished and re-created; for all other launch modes or if FLAG_ACTIVITY_SINGLE_TOP is set then this Intent will be delivered to the current instance's onNewIntent().
This launch mode can also be used to good effect in conjunction with FLAG_ACTIVITY_NEW_TASK: if used to start the root activity of a task, it will bring any currently running instance of that task to the foreground, and then clear it to its root state. This is especially useful, for example, when launching an activity from the notification manager.
don't: break and then return super.onOptionsItemSelected(item), rather just: return true;
UPDATE:
So you're saying the Activity is "restarted" based on what you see happen with Views, but can you confirm what may or may not happen to the Activity (and Fragments for that matter) by using logging in the various lifecycle methods? That way you can be sure of what the current (erroneous) behaviour is before moving forward with diagnosis.
UPDATE:
OK, good to be sure about behaviour :)
Now regarding your question "What is the correct way to implement "up navigation" for a master/detail layout (1 activity/2fragments)? ":
The typical way is that the 2 Fragments got added within a single FragmentTransaction and you simply popBackStack to remove them and go back to whatever previous state was. I think you're doubling up by manually removing a Fragment within a FragmentTransaction and then popping backstack. Try just popBackStack. Oh and just to be sure and consistent, since you're using ActionBarSherlock and support.v4 are you using a FragmentActivity (rather than an Activity) and SherlockFragment?
I think you should handle the Up button only inside the activity.
If youre in a phone, the up button will be handled by activity that acts as a wrapper of that fragment, in tablet (master/detail pattern) you dont want it anyways