I'm building a phonegap application for my blackberry. When I have the application open and I press the back button, the application terminates entirely, instead of just being "minimized" and allowed to sit in memory. So next time I click on the application, I have to login instead of seeing the last page I was on.
Is there a way to cause the blackberry back button to "minimize" instead of complete termination?
For BlackBerry Java applications the 'Hang Up' button is the standard UI request to minimize the application. Try that first. You should only override the function of the back button to minimize instead of exit if the application cannot or should not cleanly exit.
One of the most annoying behaviors for applications is if they don't exit when requested.
There are a few onEvents that are provided by Blackberry's api to essentially background the application when someone tries to pop the screen off the display stack. It's been a while since I've done this but I have done this personally. I believe I used onObscured.. reference: http://www.blackberry.com/developers/docs/4.2api/net/rim/device/api/ui/Screen.html#onObscured()
There are other events on there just carefully read through the api and instead of this.close() the screen do something like UiApplication.getUiApplication().requestBackground();
I have few more observations. Back button exits the application only on 6.0 (OS) phones. But it doesn't exit on 7.0 phones.
In order to avoid issue on 6.0 ,You can over ride the back button functionality in your .js file with below code.
blackberry.system.event.onHardwareKey(blackberry.system.event.KEY_BACK,function() {
//keep your code here
alert("back key pressed");
//For example..
//if you want to navigate to particular page(say previous.html) on back button,you can use
window.location.replace("previous.html");
//you can also use
history.back(); // To navigate to previous page as per page navigation.
return false;
});
To get this event in your .js file you need to add below line in your config.xml
<feature id="blackberry.system.event" required="true" version="1.0.0.0"/>
Related
Currently, I have to create automation ui test with XCUI and I have some action to open external browser by default is Safari.
I need to create some uitest's behavior like this.
Go to external browser when click my button.
Check is open correct url in browser (or just open browser) ?
Go back to our app with resume state.
Is it impossible to do that ?.
Absolutely. Safari is an XCUIApplication just like any other with a bundle identifier of com.apple.mobilesafari.
To check the URL you'll tap() the URL field (it's a button when a page loads) and read the value of the URL field (at this point it's a textField). Once you're done asserting that, activate() your app and you'll be back in it (note: my tests finish after asserting so I don't have to do this, but it's the published method - you could always enter debug and find how to tap the button to return to your application in the top-left of the screen if this doesn't work).
I'm happy to provide exact code if you show me you've tried this and can't get it working, but it's pretty straightforward XCUI automation.
Providing the exact code, that worked for me
enum SafariError: Error {
case appLoadTimeout
}
let safari = XCUIApplication(bundleIdentifier: "com.apple.mobilesafari")
app.buttons["MyButtom"].tap() // MyButton launches Safari
guard safari.wait(for: .runningForeground, timeout: 5) else {
throw SafariError.appLoadTimeout
}
safari.otherElements["Address"].tap()
XCTAssertEqual(safari.textFields["Address"].value as! String, "https://check-url.com")
app.activate() //Back to my app
The previous answers work fine for an external browser. If you app happens to launch inline browsers, they won't work as there is no URL bar. You could detect the inline browser and tap the Safari button to launch it externally before checking the URL, but then you'd have to reactivate your app and close the inline browser. Many more steps.
THERE IS AN EASIER WAY THAT WILL WORK WITH BOTH BROWSER TYPES!
What do these browsers share? A share button! How can we get the URL from there? Copy will place the URL in the pasteboard, which we have access to.
app.buttons["ShareButton"].tap()
_ = copyButton.waitForExistence(timeout: Waits.short.rawValue) // a tiny wait is necessary here for the share page to open fully
app.buttons["Copy"].tap()
let URL = UIPasteboard.general.string!
There are two catches here:
When inline, app is your app. When external, it's com.apple.mobilesafari. You'll have to have logic to handle that.
You want to wait for the page to finish loading. By not doing so, you will run into flakiness. When the page is loading, there is a ReloadButton. When that goes away, you should expect to see a StopButton. If the reload button doesn't disappear, the page isn't loading completely so you may need to hit the stop button, but do so in a safe way as I have seen maybe 1% of the time the page load completes in the milliseconds between giving up on it and performing that tap - I do a quick isHittable check before tapping.
I'm writing a web app for Tizen Smart TV. One of the required features is implementing the Smarthub Public Preview deeplinking.
I have setup the app to open at a specific content when the Public preview tile is clicked. However, I cannot prevent the app to reload. The documentation mentions adding the appcontrol event to the window event listeners, but I don't think this event is being recognized by the app, since the code is not executed.
It only works if I directly add my deeplink() method to the onload property.
According to documentation, this piece of code should prevent the app to reload, but it is not working:
<tizen:app-control>
<tizen:src name='index.html' reload='disable'></tizen:src>
<tizen:operation name='http://samsung.com/appcontrol/operation/eden_resume'></tizen:operation>
</tizen:app-control>
window eventListener is not working wither:
onload="window.addEventListener('appcontrol', deepLink)"
Any help on how to implement this correctly?
Thank you in advance
You are probably modyfing window.location in the app (ie in router).
reload='disable' prevents reloading index.html. When application receives app control request and page is different, application will be reloaded.
You can find more about appcontrol in Tizen documentation (note that Tizen for TV may differ from other devices):
https://docs.tizen.org/application/web/guides/app-management/app-controls/
I've got some information regarding your question.
To do application resume without Page reload,
Set extra data in app-control like below
key: SkipReload
value: Yes
We were surprised we didn't find any mention of this anywhere online, so we're posting here in hopes we find a solution.
Using an iPhone with mobile safari is when we hit this issue running the 2 easy to follow tests below, one works, one doesn't.
Here is the link
https://pwa-react.netlify.com/
Here are the 2 tests we run (both listed in the link), one works when not in PWA mode, and the other fails when in PWA mode.
Test #1: Works Perfectly (Expected Behaviour)
Visit https://pwa-react.netlify.com/ from iPhone in mobile safari
1. Make sure you have google drive on the phone but not logged in.
2. Click "Choose File". It will show you the list of options to choose from.
3. Click "Browse" to look for the photo.
4. Click "Cancel" and you're back here.
5. Click "Choose File" it will still show you the list of options to choose from.
This works perfectly in mobile safari but NOT in PWA mode below.
Test #2: Does NOT Work (Unexpected Behaviour) (PWA)
Visit https://pwa-react.netlify.com/ from iPhone in mobile safari, hit the share
button, then add to home screen. This will add the PWA app on your phone. Open App.
1. Make sure you have google drive on the phone but not logged in.
2. Click "Choose File". It will show you the list of options to choose from.
3. Click "Browse" to look for the photo.
4. When it shows you the Google Drive logo with Sign In, double click the home
button, then go back to the PWA.
5. Click "Choose File" it will NOT show you the list of options to choose from.
This is now 100% broken.
The ONLY way to fix it is to go to Settings>Safari>Clear History and Website Data (all the way down)
How can we fix this so when the user hits "Choose File" it shows the list of
options to choose from in the PWA?
Screenshot #1: These are the options that appear in Test #1 and stop appearing in Test #2
Screenshot #2: This screen allows us to cancel in Test #1 but it disappears in Test #2
Any idea how to get Test #2 to work by allowing us to choose the upload options like in Screenshot #1 without breaking the app and having to go to safari settings to clear history and website data for it to function again?
PS - Here is the repository file pwa-react/src/App.js
We were facing almost exactly the same issue in our PWA, so first, off I want to thank you for helping us narrow down the cause.
After reviewing the iOS PWA lifecycle (article here) and a couple maddening hours of trial and error I was able to figure out a solution that is semi-acceptable.
My guess at what is happening when you leave the app mid-upload (Test #2) is that there is some internal context in how iOS handles PWA's that is not being reset, so when you go back and try to upload a file again it thinks that the upload dialog is already open.
The article mentions that opening external links without target=_blank will cause the PWA context to be deleted, so when the in-app browser closes, the PWA page reloads in the standalone window. I thought that might reset the "detached upload" context, and it ended up working.
So I created a page hosted on another domain, and linked to it below our upload button in the PWA:
// not sure the target={'_self'} is necessary but not risking it
<a href={'https://externalDomain.com/reset'} target={'_self'}>
Having Issues? Reset Upload
</a>
This works decently well, minus one issue. When you click this link it opens the in-app browser, but there is no "Done" button or navigation tools for the user to know how to exit. Linking back to the PWA does not work, because iOS detects that and does not reset the app context. What I did notice was that if I navigated to another page from the first external page (I originally just tested this with google.com), the "Done" button would show up, making it obvious how to exit.
With that knowledge, I guessed that you could probably just do window.history.pushState to achieve the same effect, which works. My final solution is below. It causes the entire app to reload when the user presses Done from the in-app browser, but that's far better than having them re-add to the home screen in my opinion.
const Reset: React.FC = props => {
React.useEffect(() => {
// Redirect any wayward users who find this page from outside the PWA
if (!window.matchMedia('(display-mode: standalone)').matches) {
navigate('/');
}
// push an additional page into history
const newUrl = `${window.location.href}?reset`;
window.history.pushState({ path: newUrl }, '', newUrl);
}, []);
return (
<Grid container>
<ArrowUpIcon />
<Typography variant={'h5'}>Press done above to return to App</Typography>
<Typography variant={'body1'}>Sorry for the inconvenience!</Typography>
</Grid>
);
};
Hope this helps! Would love to hear if it works for you.
Edit After Production Testing:
An additional important note is that your "reset" page must be on a completely different domain for this to work. Ran into this today in production, because our reset page was on a subdomain with the same root as the PWA, iOS was not resetting the entire PWA lifecycle.
SUMMARY
Key Issues:
Leaving an iOS PWA while any of the "file upload" dialogs are open ('Take Photo', 'Photo Library', or 'Browse') breaks the iOS PWA lifecycle.This breakage makes it impossible for the user to open any "file upload" dialogs when clicking on a file input.
In order to fix this issue, the PWA context must be completely reset.
It seems that the only ways to reset the PWA context are to restart the phone, delete the app and re-add it to the home screen, or to open an external link.
When opening an external link, the "Done" button that closes the iOS PWA embedded browser will not show on the initial page. The user must navigate to an additional external page in order for the "Done" button to show.
External links do not trigger a reset of the PWA context reset when they have target="_blank".
Solution:
In order for the user to be able to upload files again, the PWA context must be reset. The easiest way to do this (in my opinion) is to ask them to open an external link.
(In PWA): Present a link to the user to fix the fact that the upload dialog is not showing. The link destination must be a completely unrelated domain (not a subdomain) and must have target="_self" (issue #5).
(External Page): Once the user clicks on the link and the external page opens, there will be no visible way to leave the page (issue #4). To resolve this, you can use history.pushState to simulate navigating to an additional page.
(External Page - Bonus): To make it clear to the user that the issue has been resolved, add an arrow in the top left pointing to the "Done" button (as shown in my screenshot).
We have an App that accepts donations and per Apple's guidelines (item 21.2) we can't do this in-app, it must open a webpage in Safari to perform the donation. We've got that bit working fine, and we can actually automatically invoke the App post donation and put the user right back where they left off. The trouble is that the Tab in Safari persists when the user returns to Safari later.
Is there a way to open an app from a webpage while simultaneously closing said webpage in Safari?
So apparently the way to do it is via Javascript. You can set the window location and then immediately close the window.
e.g.
window.location = "myapp://?stuff";
window.close;
I developed an mobile application using LWUIT and it works fine in devices with J2ME.
I want to run the same application in Blackberry also.
I saw some samples about LWUIT on Blackberry but none of them answered me.
How can I handle the back button on the device to make back movements?
What I mean is that, when I press the back button on the device, I want the application move to the previous screen.
I used regular buttons to handle back movements just for now, but when we think of user side, it is not so friendly.
I dont want to use commands like I did in j2ME app., because it seems not so nice.
Is there anyone who can solve it?
Set a particular back command to the form. For example,
Command backCmd = new Command("Back"){
public void actionPerformed(ActionEvent evt) {
previousForm.show();
}
};
currentForm.setBackCommand(backCmd);