I am having issues with my app returning to the foreground every time the user presses the back button. I believe this may be because there is a sound playing module that restarts the activity although this is just my hypothesis. However whenever I press the home (middle) button the app is sent to the background and everything works accordingly. I would like to emulate this functionality by capturing the back press event and handle it in a similar manner to the home button. While navigating the source, i've found the following handler in
android/reactnativenavigation/layouts/SingleScreenLayout.java
#Override
public boolean onBackPressed() {
if (handleBackInJs()) {
return true;
}
if (stack.canPop()) {
stack.pop(true, System.currentTimeMillis());
EventBus.instance.post(new ScreenChangedEvent(stack.peek().getScreenParams()));
return true;
} else {
return false;
}
}
I can understand at a glance what is being done however I am not very familiar with Java and don't want to introduce any bugs involving the native side of the app, could anyone kindly point out what I would need to modify?
So, you need to capture "the hardware back button" press not the home button right?
check here for the react-native way of doing it
Related
I'm using React-Native-Navigation from Wix (version 2) to setup navigation in my React Native app. I'm using the sideMenu layout with the center section being a stack. When the user selects one of the side menu items the selected view is pushed onto that center stack. If the user presses their back button on Android, then the view is popped from the stack, but I don't always want this to happen, mainly if the view they selected is a WebView.
If the view is a WebView, I want to manually handle the user pressing the hardware back button. If the WebView can "goBack" then the view will go back, but if it can't then the view will be popped from the stack (as it normally would).
I've tried overriding the back button press using the BackHandler class from react-native and this allows me to capture that press and have the WebView go back if able, but the act of popping the view from the stack also fires. Is there a way in React-Native-Navigation v2 to tell it, "Hey I got this, don't pop unless I tell you to."?
My current code for this section is as follows:
componentDidMount() {
BackHandler.addEventListener('hardwareBackPress', this.backHandler);
}
componentWillUnmount() {
BackHandler.removeEventListener('hardwareBackPress', this.backHandler);
}
backHandler = () => {
if (this.state.canGoBack) {
this.webviewRef.current.goBack();
// I thought this might force the back press to be
// ignored by react-native-navigation, but no dice.
return false;
} else {
// WebView can't go back so pop view like normal
Navigation.pop(this.props.componentId);
}
}
I was expecting this to only pop the view from the stack if the WebView can't currently go back and otherwise just have the WebView go back.
What actually occurs is both events fire. I.e. the WebView goes back, but the view is also popped from the stack.
I was able to find the answer to this through some more digging in the React Native Navigation and React Native docs.
The event subscriptions are called in reverse order (i.e. last registered subscription first), and if one subscription returns true then subscriptions registered earlier will not be called.
So the issue was in my backHandler method. Instead of returning false I needed to return true.
backHandler = () => {
if (this.state.canGoBack) {
this.webviewRef.current.goBack();
// We've handled the event so we return true and the
// handler on the view's parent can effectively be ignored. Yay!
return true;
} else {
// WebView can't go back so pop view like normal
Navigation.pop(this.props.componentId);
}
}
My program is fullscreen application. On start I use some checks and if something is wrong, error dialog is shown. I need two windows (main fullscreen, and dialog) were here and all graphics were ok.
When I use this code:
primaryStage.show();
/*..some checks*/
dialogStage.show();
.. there is no fullscreen. It's somehow overlapped by other windows.
This one works better:
stage.setOnShown( new EventHandler<WindowEvent>() {
public void handle(WindowEvent windowEvent) {
/*..some checks*/
dialogStage.show();
}
});
primaryStage.show();
But... I can see task panel from Windows. It becomes hidden when dialog is closed.
And also I can see default java icon there. Although I've set custom icon before.
Looks like setOnShown() is called before all graphical updates are done.
Is there any event or something to know it?
I also tried Timeline from animation to call a small delay. But without success.
The same with calling dialog from additional thread (with Platform.runLater() of course :) ). This way fullscreen hides at all.
Maybe on JavaFX8 things are better?
A very straightforward question....
How do you enter a new line in a CEdit control box without it triggering OK and closing the dialog box altogether? What I mean is when you hit the enter key it automatically selects OK, even if your cursor is still in the CEdit control. Is what I am trying to do possible? Or do i have to use some other control
PS: It is a modal dialog box btw.
There are various solutions for this problem.
Basically what you need is the ES_WANTRETURN style on the edit control.
Another solution is to check the message and key in PreTranslateMessage (since it has been commented upon this is not the recommended way, I'm just mentioning it for possibilities):
BOOL CYouDialog::PreTranslateMessage(MSG* pMsg)
{
if (pMsg->message == WM_KEYDOWN && pMsg->wParam == VK_RETURN &&
GetFocus() == youcontrol)
{
return TRUE;
}
return FALSE;
}
The other solution is to handle WM_GETDLGCODE. You should subclass the edit control and do this:
UINT CYourEdit::OnGetDlgCode()
{
return CEdit::OnGetDlgCode() | DLGC_WANTALLKEYS;
}
UPDATE: FYI, also have a look at Just because you're a control doesn't mean that you're necessarily inside a dialog box.
The default dialog processing, as you've discovered, is to close a dialog box when enter is pressed. MFC actually executes the OnOK processing, but you can override that. Here's and old explanation, but, it's still relevant.
I find myself more and more using the touchpad gesture of 3 fingers to the left or right in order to perform a "back" or "forward" in Google Chrome (on my Asus Zenbook, but I believe there's a similar gesture on Macs)
I found that when browsing, I open a tab to read something (Like a like from Twitter or Facebook) and when I'm done my instinct is to go "back" to get back to the previous tab I was browsing on. (I think I got that instinct from using Android a lot).
I figured that I need a Chrome extension that would close my current tab if I'm attempting to go "back" in a tab that doesn't have a previous page in its history.
I went over the Chrome events and various methods I can invoke and while there's a "forward_back" transition qualifier in the WebNavigation api, the onCommitted event doesn't fire when attempting to go "back" using the touchpad gesture or Alt+left keyboard shortcut.
Also, I couldn't find how I can access a current tab's history to see if the page I'm at doesn't have a previous one in the stack.
Ideas anyone?
function noHistory(tabId) {
// TODO
}
function getCurrentTabId() {
// TODO
}
function userHitBack() {
tabId = getCurrentTabId();
if (noHistory(tabId)) {
chrome.tabs.remove(tabId)
}
}
function attachEvent() {
// TODO attach userHitBack
}
attachEvent();
To catch the "back" event, you need to handle specific key pressed to call your "userHitBack" function. Something like this:
document.onkeydown = function() {
if (keyId == ...)
userHitBack()
}
You can use this to your advantage as you can bind any key to trigger the close of the tab.
To check the tab history length use this:
window.history.length
It is html5 historyAPI
According to the documentation, Display.setCurrent doesn't work if the current displayable is an alert. This is a problem as I would like to pop up another alert when the user selects a command. Does anyone know how to work around this so that we can go from one alert to another? I am using CLDC 1.0 and MIDP 2.0.
Additional Information
The spec does allow us to edit an alert while it is on screen, but some Nokia phones don't handle it well at all. So I am now trying to go from the alert to a blank canvas, then back to the alert. Of course I don't want the user to interact with the previous canvas, so it seems that I am forced to create a new blank canvas. As a sidenote, this has the slight disadvantage of looking worse on phones which still have the previous screen when an alert is shown.
The bigger problem is how to transition from the blank canvas back to an alert once the canvas is loaded. Testing on the Motorola emulator revealed that showNotify is not called after returning from an alert to the previous screen. I guess I could create the next alert in the paint method, but this seems like a ugly hack.
OK, so your problem is that you can't set it up to do:
Display.setCurrent(alert1, alert2);
and
Display.setCurrent(alert2);
is also not possible if the current Displayable is already alert1.
So how about put an intermediate Displayable item that is blank and that immediately changes to the next alert? Assuming the current Displayable is alert1, like this in your alert1's command block:
Display.setCurrent(blankForm);
Display.setCurrent(alert2);
That should work assuming you are not using the default 'Dismiss' command. So basically it goes from alert1->(blankForm->alert2).
I couldn't find a way around this, so I just used the paint hack.
public class AlertPage extends Canvas{
MIDlet midlet;
Alert alert;
private AlertPage(MIDlet midlet){
this.midlet=midlet;
}
protected void paint(Graphics arg0){
//Yep, this is a hack, but showNotify doesn't seem to work well for Motorola
if(alert!=null){
Display d=Display.getDisplay(midlet);
d.setCurrent(alert);
alert=null;
}
}
public static void showAlert(MIDlet m, Alert a){
AlertPage page=new AlertPage(m);
Display d=Display.getDisplay(m);
page.alert=a;
d.setCurrent(page);
}
}