I can use the SettingsFlyout afterhide event to know when one of my settings pages closes, but how can I detect when the overall Settings page closes. i.e. the user goes back to the app.
It depends on how the user returns to the app. If they click outside of the settings UI while your settings page is displayed, then the afterhide event will fire. But if the user is displaying the main settings page, that's UI that is controlled by the OS, and isn't really part of your app, per se. For example, the user could open the settings UI to change the system volume, or make changes to network settings. In those circumstances, it wouldn't really be appropriate for your app to receive notifications.
So I don't think there is an event to subscribe to for the main settings pane closing. As such, you should subscribe to afterhide on each of your settings pages to ensure that you can capture any changes appropriately.
Hope that helps.
For more info on Windows Store app development, register for Generation App.
Related
Issue: appears to be that banno framework is "remembering" the urls. This is happening in a mobile browser when the user does not close the tab or browser. When the user opens the page, banno is remembering the url from last time and trying to load the same url.
What needs to happen is that banno needs to fully reload the page so that we can go retrieve a new url and log the user in again.
Could it be how they treat plugins when a browser is left open. A url that is loaded is not good forever.
Odds are good that the situation you're encountering is described in https://stackoverflow.com/a/71267143/6680761
Essential info from that link is:
Part of keeping state of the page is keeping authentication data. The OAuth flow used to initially authenticate the user is not intended to be used on every page refresh. It's expected that the embedded web application will keep its own authentication state. How this is done is usually very specific to the language and platform used for the embedded web application. However all strategies almost exclusively use a cookie which is destroyed when the application closes.
The Oauth callback URL with an authentication code should be redirected away from once the code is exchanged for an access token. From that point forward your app should be using its own authentication mechanism.
When the user resumes an app that was tombstoned, does it start on the main app page and you have to handle with saved states to check where was the user and send him there again, or does it open directly the page where the user was and all you have to do is to restore your variables and date from the saved state?
Tombstoned
A tombstoned app has been terminated, but the operating system preserves information about its navigation state and also preserves the state dictionaries the app populated during Deactivated. The device will maintain tombstoning information for up to five apps at a time. If an app is tombstoned and the user navigates back to the application, it will be relaunched and the application can use the preserved data to restore state.
More info in the official documentation.
So, the navigation is kept, but you need to restore the state. You can always test this - in project properties, go to debug and select
Tombstone upon deactivation while debugging
So when you deactivate the app while debugging, it will actually go to tombstoned state and you can test it properly.
My app is embed into a page with other related infomation, so I want to, if the user denies the access, to go back some steps (in Flash) and asks again if he can allow access, but once you deny (or allow), Flash don't show this window again.
Today I'm calling a external JS to reload the SWF element, but it's not elegant.
you can open the SecurityPanel in the privacy tab:
Security.showSettings(SecurityPanel.PRIVACY);
In Windows Phone, the reminder is usually used for scheduled notifications. The reminder when popped up, requires user to click the reminder pop up in order to navigate to specific page and do certain action.
Can we simulate or suppress this reminder programatically when occured and instead perform the action it was supposed to execute when actually clicked. This would be of great use to user.
Any help, suggestions or ideas on the same?.
Thanks In Advance.
It isn't possible. A Windows Phone application has very limited interaction with the system when it isn't running in the foreground.
If you're trying to bypass the reminder to display something (for instance, a page of your application) without user interaction, then you have no way of doing that.
If it's just about updating some data or calling a webservice without displaying anything, you should use a background agent instead of a reminder.
Windows Phone was built around the idea of letting the user in control at all time. That's why there is no way of forcing the user to navigate to a page of your application if it wasn't running in first place.
Firstly any news on the V2 SDKs for iOS and Android?
The normal flow is:
In app: click authorize button.
browser opens box.com/api/oauth2/authorize?....
User inputs their details.
User is taken to an allow/deny page.
User taps allow or deny.
User is taken back to app via the redirect_uri scheme.
My problem is once the user has put their details (3) in once and arrived at the allow/deny page, any future attempts to authorize full on skip the allow/deny page and go straight to the box home page without ever calling the redirect_uri along with the auth codes.
This can be 'fixed' if the user clears their browsing history/cookies before trying again, which is a long way from ideal. Any ideas?
For a potential short term fix until the v2 sdk is released, a web view can be used which will give you full control over things like the cache (we are using one in the sdk).