I have a DialogDragment which I can show one of two ways:
1) By tapping on a ListView item from its OnItemClickListener
2) By activating a the ListView's context menu and selecting a menu item
Doing #1 works fine under all lifecycle events, but if I invoke it via #2 and I pause the activity (by going Home) and the resuming it via the task switcher, the dialog is no longer displayed. The fragment is there, and I can rotate the device and show the dialog.
I experimented, and if I put the showing of the DialogFragment into a Handler with a delay of at least 1/2 seconds, it works.
The following snippet fails -- it shows the dialog, but then pause/resume hides it:
public boolean onContextItemSelected(android.view.MenuItem item) {
boolean consumed = false;
switch (item.getItemId()) {
case R.id.menu_item:
showMyDialogFragment();
consumed = true;
break;
}
return consumed;
}
So the following snippet works. Pause/resume display the dialog again correctly:
public boolean onContextItemSelected(android.view.MenuItem item) {
boolean consumed = false;
switch (item.getItemId()) {
case R.id.menu_item:
new Handler().postDelayed(new Runnable() {
public void run() {
showMyDialogFragment();
}
}, 300);
consumed = true;
break;
}
return consumed;
}
Replacing the 300ms second delay with a 0ms or 250ms delay causes it to be broken again. This repeatable 100% of the time.
This is a terrible hack obviously, made worse by the constant that's probably depends on the speed of the device.
Anybody know why this is going on and/or offer a better solution? I spent hours on this issue and this is the best I could come up with.
I can reproduce this on Android 4.2 (ARM emulator and Galaxy Nexus). I am unable to reproduce your findings on an x86 4.1 emulator, a Nexus S (4.1), and a Motorola RAZR i (4.0). I can also reproduce the problem by modifying one of my own book samples. I filed an issue on it, using your sample: http://code.google.com/p/android/issues/detail?id=41901 Please add any other information you think would help them diagnose the problem.
With respect to a workaround, if 300ms works, then we have one of those lovely "timing issues", and I haven't the foggiest idea how you'd work around it, short of not using a menu to display it. For example, with your sample app, simply switching to SHOW_AS_ACTION_ALWAYS (and therefore having it be an item on the action bar rather than in an overflow menu) is sufficient to have the DialogFragment behave properly. Hopefully, you'll have a way of adjusting your UI to compensate for this bug, or perhaps somebody will cook up another workaround and post it here or on the issue.
I would recommend destroying the dialog on all pauses and recreate in onResume depending on state regardless of how the dialog is invoked. To do otherwise risks a memory leak if the app is killed by the OS in while paused.
To explicitly answer your question, don't rely on the OS to maintain your app state.
Related
I've followed the example pattern for handling the android back button in the react-native docs and it works well. I can use the hardware back button to pop my navigation stack.
At the point that there's only 1 view in the stack though I don't pop it (just like the example), and I return false from my hardwareBackPress event listener. At this point it I see the componentWillUnmount method being called in my final view, at which point my app shuts down.
If I return true then nothing happens at all obviously.
What I want to happen is that the app merely gets "backgrounded" instead of exiting completely.
Answered my own question. The trick is to override the default back button behaviour in the MainActiviy:
public class MainActivity extends ReactActivity {
#Override
protected String getMainComponentName() {
return "foo";
}
#Override
public void invokeDefaultOnBackPressed() {
// do not call super. invokeDefaultOnBackPressed() as it will close the app. Instead lets just put it in the background.
moveTaskToBack(true);
}
}
Though I may be very late in giving the answer it may help other facing the issue.
Recently I came across the same requirement where I have to move the app to the background. I tried the solution provided by #pomo. Though it worked I faced problems. Sometimes on multiple clicking of the back button, the app misbehaves in android though it worked perfectly fine in iOS.
And then I came across the following issues in GitHub where it mentions the reason for the misbehaviour.
The following solution works perfectly fine now.
// android/app/.../MainActivity.java
#Override
public void invokeDefaultOnBackPressed() {
moveTaskToBack(true);
}
<!-- AndroidManifest.xml -->
<activity
...
android:launchMode="singleTop">
Link from where I get the solution
I hope I'm able to help guys with the same requirement.
I am trying to work out how to show the "up" arrow in Xamarin.Forms without a pushing a page onto the stack. I.E. I just want to perform an action when the back button is pressed. I am completely stuck on this so any help would be appreciated.
I have tried creating a custom renderer which handles a view property called DisplayHomeAsBack. Which in the renderer calls the following:
FormsAppCompatActivity context = ((FormsAppCompatActivity)Forms.Context);
Android.Support.V7.App.ActionBar actionBar = context.SupportActionBar;
if (actionBar != null)
{
actionBar.SetDisplayHomeAsUpEnabled(element.DisplayHomeAsBack);
}
Unfortunately it seems this does absolutely nothing, even though all online tutorials and stackoverflow question for android suggest this method.
The plan is that I can then use the "OnBackButtonPressed" override in MasterDetailPage, which should allow me to perform this action. Unfortunately displaying the back button has been the larger hurdle so far!
Any idea of a better way to do this or how I can get the current mechanism to work?
EDIT
I have created a project and uploaded it to this question on the Xamarin support forums, if it helps.
http://forums.xamarin.com/discussion/comment/186330#Comment_186330
Sorry to keep you waiting so long!
Warning that I did not actually run this code and changed it from my own so I would be surprised if it worked perfectly without some changes.
So below should add a back button where there was not one before (so like when there is not really a page to go back to) and then we will add a custom action to perform when it gets pressed.
I would suggest you push a new page onto the stack without using animation so it is transparent to the user and also makes all of this much simpler, but if you absolutely do not want to do that, the below method should work.
MainActivity:
//Use this to subscribe to the event which will create the back button
public override bool OnCreateOptionsMenu(IMenu menu) {
if(menu != null && App.AppMasterPage != null) { //You will need this to make sure you are on your MasterDetailPage, just store a global reference to it in the App class or where ever
Xamarin.Forms.MessagingCenter.Unsubscribe<string>(this, "CreateBackButton");
Xamarin.Forms.MessagingCenter.Subscribe<string>(this, "CreateBackButton", stringWeWillNotUse => { //Use this to subscribe to the event that creates the back button, then when you want the back button to show you just run Xamarin.Forms.MessagingCenter.Send<string>(this, "CreateBackButton")
ActionBar.DisplayOptions = ActionBarDisplayOptions.ShowTitle | ActionBarDisplayOptions.ShowHome | ActionBarDisplayOptions.UseLogo | ActionBarDisplayOptions.HomeAsUp; //You may need to play with these options to get it working but the important one is 'HomeAsUp' which should add the back button
});
} else {
Xamarin.Forms.MessagingCenter.Unsubscribe<string>(this, "CreateBackButton");
}
return base.OnCreateOptionsMenu(menu);
}
Now the next step is do do a custom action when it is pressed. I think you can either override OnBackPressed() or OnOptionsItemSelected() in MainActivity or maybe you can override the MasterDetailPage method. I am not sure.
Which ever one works for you, inside of that override, I would simply check to see if you are on your App.AppMasterPage like we did above, and if so, send a MessagingCenter message which your App.AppMasterPage has already subscribed to in order for it to handle the custom action.
If you get stuck let me know!
I know it sounds like a bit of a hack, but the best "solution" I have found so far is to add a page behind the current page (behind the root) so it is not visible. Then when the user presses the back button, handle it by removing that page.
I have an activity which have multiple piece of UI panel(you can think them as view in android), these panels will be invisible by default.
Now when user trigger action1, PanelA will display, when trigger action2, PanelB will display(at different location of the screen).
Both PanelA and PanelB is visible at the moment, now when user hit the back menu, the PanelB should disappear, and PanelA should disappear when hit the back menu again.
At first, I use View to hold different panels, however I found it is difficult to keep the state consist, for example, the activity will be a little different between PanelA and PanelB.
Then I found the fragment, however after I tried and tested, I found that the addTobackStack() can not apply to my us-case, since the PanelA and PanelB are at different location, android can not save their state by default.
So I wonder if there is any other solution for my requirement?
You need to manually handle this scenario inside onBackPressed() method of an Activity.
For instance -
#Override
public void onBackPressed() {
if (panelB.isOpened()) {
panelB.close()
} else if (panelA.isOpened()) {
panelA.close()
} else {
super.onBackPressed();
}
}
When panelB is opened, it will close only panelB and wont do anything else. Same goes for panelA, if its opened and when both the panel are closed then it will exit the app like normal.
I highly recommend to use DialogFragments here as you can call show() and dismiss() any point of time on that and they can handle custom views pretty well.
Hope it helps.
I use some custom ActionModes in my application. When an action mode is closed, I do some housekeeping, like closing related views, updating changes, etc.. I detect the action mode has been closed in OnDestroyActionMode.
My problem is, when inside of some of my ActionModes, the user may trigger another system actionmode (The text copy/paste/select). In that case, onDestroyActionMode is called and I erroneously asume the user is done with the first actionmode, rather than implement a "stack" functionality, so can I ignore this onDestroyActionMode, let the user edit / cut / etc the text, then reopen the former actionmode when done.
How can I achieve this?
Shedding further light on your situation: prior to honeycomb, longPress on a TextView will yield a popup window with options (like 'Select word', 'Select all', and 'Add "someword" to dictionary') while NOT affecting any existing ActionMode both when shown and when dismissed (by pressing back). So this isn't really a problem pre-honeycomb.
More light regarding HTC Sense: Sense does NOT honour TextView.setCustomSelectionActionModeCallback() because Sense doesn't use an ActionMode for the Text selection feature (and clearly don't care if the rest of the world do!). So this problem has a different smell in that situation (I haven't tested the following solution under Sense, so not sure how it'll behave).
A solution is to create your own custom ActionMode.Callback to replace the OS's one and apply it in setCustomSelectionActionModeCallback() of any TextView and/or EditText you desire (though only if device is running honeycomb or greater). Pass a custom onTextSelectionCABDestroyed callback interface to your custom ActionMode.Callback, call it in the onDestroyActionMode method.
Firstly create an interface and implement it where you want to handle the recreation of your original ActionMode (alternatively you may want to use a bus event with something like Otto):
public interface YourCallbackInterface {
public void onTextSelectionCABDestroyed();
}
and create a new class:
public final class CustomTextSelectionActionModeCallback implements ActionMode.Callback {
WeakReference<YourCallbackinterface> mYourCallbackinterface;
public CustomTextSelectionActionModeCallback(YourCallbackinterface yourCallbackInterface) {
mYourCallbackinterface = new WeakReference<YourCallbackinterface>(yourCallbackInterface);
}
#Override
public boolean onActionItemClicked(ActionMode mode, MenuItem item) {
return false;
}
#Override
public boolean onCreateActionMode(ActionMode mode, Menu menu) {
return true; //returning true will create the ActionMode
}
#Override
public void onDestroyActionMode(ActionMode mode) {
//this is the magic where we actually capture the destroy event for TextSelectionCAB and can subsequently do things like recreate the ActionMore that TextSelectionCAB greedily destroyed!
mYourCallbackinterface.get().onTextSelectionCABDestroyed();
}
#Override
public boolean onPrepareActionMode(ActionMode mode, Menu menu) {
return false;
}
}
And remember to avoid StackOverflowException when recreating an ActionMode from the onDestroyActionMode of an ActionMode, postDelayed a Runnable to a Handler like this I explain here: Reopen ActionMode (or CAB) after onDestroyActionMode is called
Lastly, if you're using ActionBarSherlock, make sure that your CustomTextSelectionActionModeCallback implements android.view.ActionMode.Callback rather than com.actionbarsherlock.view.ActionMode.Callback.
Note: I haven't played with ActionBarCompat so not sure how all this applies there. If someone knows, please post as comment!
I need help figuring out how to check if a device is equipped with the search hardware button or not. Is this possible?
EDIT: I'm talking about finding out if the device has the search hardware button or not. Simple question. Each android device has a set of hardware buttons; menu, home button, back button, and search button. But some devices is only equipped with some of them, not all.
EDIT 2: The reason why I ask is because I want to have a software button showing in my UI if the device is not equipped with a hardware button. I am using the searchable interface in my activity. I am not following the EditText / TextField approach.
I don't think you need to detect if it actually has a search hardware button. The framework will help you out here (though, I'm sure this process will be simplified once Ice Cream Sandwich is released)
Currently, the only devices that won't have hardware search are Honeycomb tablets. So, by using android:targetSdkVersion="11" (or higher), adding implements OnQueryTextListener to your Fragment or Activity, and then adding something like:
#Override
public void onCreateOptionsMenu(Menu menu, MenuInflater inflater) {
inflater.inflate(R.menu.notebooks_menu, menu);
final SearchView sv = new SearchView(getActivity());
sv.setOnQueryTextListener(this);
menu.findItem(R.id.search_notebooks).setActionView(sv);
}
You will essentially solve the problem. Now, to get it working on pre-Honeycomb devices, you may need to use the compatibility library, or use reflection or some other guards in your code.
EDIT
The Samsung Galaxy S II does not have a dedicated hardware search button, but if you hold the menu button down for a couple of seconds, it will begin acting as a hardware search button.
Better way you can do usign two ways
put the search button and call to onSearchRequested();
Second way on click the editText put android:imeOptions="actionSearch" so you need to
check for key
searchBox.setOnEditorActionListener(new OnEditorActionListener()
{
public boolean onEditorAction(TextView textView, int id,KeyEvent event)
{
if (id == EditorInfo.IME_ACTION_SEARCH)
{
//do what ever you want
}
return true;
}
});
Hope this will help you.