I have something like this :
SplashPage -> MainPage -> Settings -> About
SplashPage is only page with my logo and animation for about 1 second, and then I redirect my user to MainPage. First problem was that when I press back button on MainPage, I'm back to splashpage and that wasn't good. I solved that by this piece of code :
private bool navigateBack;
public SplashPage()
{
InitializeComponent();
navigateBack = false;
}
protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)
{
if (navigateBack)
{
this.NavigationService.GoBack();
}
else
{
navigateBack = true;
base.OnNavigatedTo(e);
}
}
This way on back button press, user never see splashpage again, but I have weird problem. Application is throwing Navigation Exception that CanGoBack property is false and application exit. It's true, that I want to exit from app, but not using exception, because I will fail certification in marketplace.
My question is how to navigate back from MainPage and exit application, but with no exception thrown. Thank you in advance!
Introducing a separate page for your splash screen introduces more problems than it solves (as you're finding out), so I'd reccomend using an overlay on your main page instead. I [posted about using splash screens and this very situation a while back.
Read the following for background on this scenario and how to approach it:
http://blogs.msdn.com/b/ptorr/archive/2010/08/28/introducing-the-concept-of-places.aspx
and
http://blogs.msdn.com/b/ptorr/archive/2010/08/28/redirecting-an-initial-navigation.aspx
in Mango you can use
NavigationService.RemoveBackEntry()
to remove a page from your page stack, i.e your splashpage as soon as you hit your MainPage
so if you have your splashpage to mainpage you would call the function twice
the first time to remove MainPage from the page stack and the second time to remove SplashPage from the page stack, you will notice that when you press the back key now you will close the app
Related
[Question]
On Windows Phone 8.1, what exactly happens in between the time when the user leaves the app and the OnSuspended event fires? I'm having trouble with the ability to manage objects in that span, in particular MediaCpture object.
To better explain the problem, here is the scenario:
The user is on a page with a video preview being pumped to a CaptureElement
The user taps the Start button
The user taps Back button and returns to the page with a broken MediaCapture
With WinRT there isn't an ObscuredEvent and OnNavigatingFrom doesn’t fire unless you’re going to another page in the same Frame. After some investigation, I've found that the only event that fires is Window.Current.VisibilityChanged
I've gone ahead and hook it when the page is NavigatedTo and unhooked in OnNavigatedFrom (see ex2 below). Inside the event, I check for parameter that tells if the app is hiding or showing and dispose/initialize accordingly(see ex.1 below).
[Problem]
However, this only works with the debugger attached. If I do this without the debugger attached, it doesn't reinitialize and frequently crashes the camera and I have to literally reboot the device.
Code Example 1 (note: e.Visible == false is leaving the app and true when returning)
async void Current_VisibilityChanged(object sender, VisibilityChangedEventArgs e)
{
if (!e.Visible) //means leaving the app
{
await DisposeAll(); //cleans the MediaCapture and CaptureElement
}
else
{
if(mediaCaptureManager != null) await DisposeAll();
await Initialization(); //set up camera again
}
}
Example 2 (hooking into the event)
protected override void OnNavigatedTo(NavigationEventArgs e)
{
Window.Current.VisibilityChanged += Current_VisibilityChanged;
this.navigationHelper.OnNavigatedTo(e);
}
protected async override void OnNavigatedFrom(NavigationEventArgs e)
{
Window.Current.VisibilityChanged -= Current_VisibilityChanged;
this.navigationHelper.OnNavigatedFrom(e);
}
[Update: Resolution]
Instead of using VisibilityChanged, hook into Window.Current.Activated on the page's constructor. With the debugger completely detached, the Activated event will provide the WindowActivationState parameter in the WindowActivatedEventArgs. Like this:
private async void CurrentOnActivated(object sender, WindowActivatedEventArgs e)
{
if(e.WindowActivationState == CoreWindowActivationState.Deactivated)
{
//dispose MediaCapture here
}
else if(e.WindowActivationState == CoreWindowActivationState.CodeActivated || e.WindowActivationState == CoreWindowActivationState.PointerActivated)
{
//initialize MediaCapture here
}
}
See my answer in https://stackoverflow.com/a/28592882/3998132. Using Window.VisibilityChanged in conjunction with your Page\UserControl Loaded\Unloaded handler should solve your issue I believe.
Using Window.Activated is less desirable than Window.VisibilityChanged because Activated relates to being visible AND having focus where as VisibilityChanged only pertains to visibility. For showing a preview having focus is not applicable. Since Windows Store apps on Windows Phone can only have one Window showing there is no difference in using either however if your app becomes universal and runs on let's say on Windows 8+ Modern shell (which can show multiple Store apps with the Snap window feature) or Windows 10 desktop (which can support multiple Store apps showing at the same time) you will not want to stop preview when a user changes focus from your app but your app is still showing.
I'm not sure if it wouldn't be more suitable to use Suspending/Resuming events. Note only that in this case, you will have to debug it properly - it behaves little different while being run with/without debugger attached.
As for the code - hooking your event in OnNavigatedTo/OnNavigatedFrom is not a good idea - when the OS suspends the app and you are using SuspensionManager then OnNavigatedFrom will be called, but when you go back to your app (resume it), then OnNavigatedTo will not be called.
Using Window events may also work here, but why not subscribe it once, somewhere in constructor? - it's window-wide and hence in phone there is only one window, which stands for app, then subscribe once. In this case, you may add a line that recognizes the current page in window and if that page contains mediacapture then dispose (create similar). Then you can also dispose/initialize in navigation events in case user doesn't leave your app and just navigate.
I have a page in a WP8 application, that every time I navigate to it, the constructor is called.
From what I know, the constructor of a page called only once at the first time the page loaded. my page is very heavy, and every construction takes wasted time..
this my navigation code, usual one:
NavigationService.Navigate(new Uri("/Views/Pages/ContentControlNew.xaml", UriKind.Relative));
and this is the constructor of the page:
public ContentControlNew()
{
InitializeComponent();
}
Not special.. is it normal that the constructor is called every time? Please tell me if you need more details because I don't know what else to say about this subject.
Yes this is normal because whenever you use NavigationService.Navigate it always creates a new page object and adds that (pushes it) to the navigation stack. For example when you use GoBack() it pops it out of the stack and destroys it, but when it gets back to the previous page it doesn't call the constructor since that one was already in the stack and does not have to be recreated.
If you don't want to create a page every time you navigate to it, you should look into Navigation Models for Windows Phone for some ideas on how you can tackle this.
When i set ActivationPolicy="Resume" in WMAppManifest.xml page tile navigation(navigation URL) is not working in Tombstone state, it reloads the last back stack page(URL). It works fine with Dormant state with out reloading the page. If don't set this property (ActivationPolicy="Resume") it reloads the page in both states [Dormant state and Tombstone state].
But how can we achieve the navigation to secondary url's, when we set that property.
Please help me .
Adding ActivationPolicy="Resume" is not the only step needed to have your app support Fast App Resume. I believe the behavior you are describing is normal when you only set that one property. I think there are a few ways to implement "Fast App Resume", but I found this to be the easiest way.
Set the activation policy like you just described and then do the following:
Go into App.xaml.cs in the "App" class add:
private bool reset
You should then have a method for InitializePhoneApplication that initializes the RootFrame. Add this:
RootFrame.Navigating += RootFrame_Navigating;
RootFrame.Navigated += RootFrame_Navigated;
Then you can go and add those methods:
void RootFrame_Navigating(object sender, NavigatingCancelEventArgs e)
{
if (reset && e.IsCancelable && e.Uri.OriginalString == "/MainPage.xaml")
{
e.Cancel = true;
reset = false;
}
}
void RootFrame_Navigated(object sender, NavigationEventArgs e)
{
reset = e.NavigationMode == NavigationMode.Reset;
}
If you implement this properly, your app should resume from the last page you were on.
Same problem here. I got WP8 application with Fast App Resume enabled. I can pin tiles pointing to specific pages in my apps. It works fine when app is just Suspended, but when the app is Tombstoned, then clicking secondary tile has the same effect as clicking the main tile.
I receive only one RootFrameNavigating event with NavigationMode == Back and Uri == /MainPage.xaml. The app then shows the previous page that was there before I suspended the app.
I guess this is actual bug in the platform for this specific scenario - Fast App Resume + tombstoned app + navigation from pinned tile, that we as developers cannot solve.
My Swing application prints lines of text to a JTextPane inside of a JScrollPane when a JButton is pressed. For quick operations there is no issue. However, some JButtons invoke operations that may take a few minutes. The button remains greyed out during this time.
What currently happens is that the text is "batched up" and then I get hundreds of lines all at once at the end of the operation at the same moment the button becomes un-greyed. The problem is that I would like the text being appended to the document displayed in the JTextPane to appear sooner (at the moment it is appended) rather than at the time the entire operation completes. This would create a better user experience.
What am I doing wrong?
Use a SwingWorker for performing your background operation.
// Your button handler
public void actionPerformed(ActionEvent e) {
(new SwingWorker<Void, String>() {
public Void doInBackground() {
// perform your operation
// invoke publish("your string");
}
protected void process(List<String> chunks) {
// append your string to the scroll pane
}
}).execute();
}
You are invoking code directly from within the AWT-Thread which blocks every event. The solution is to put your long-running code in a separate Thread. As your code is executed and obtains results, you notifiy your view (using the observer/observable pattern).As your view is notified, you update the scrollpane content.
You must also verify if you are running in the AWT-Thread or not (SwingUtilities.isEventDispatchThread()). If you are not, then you need to dispatch the update of the view in the AWT-Thread using SwingUtilities.invokeLater() because Swing is not Thread-safe.
We are using LTSP with Thin-Clients. We are using it, to run a Java-Swing-Application. The users should not be able to do anything else, so instead of a Gnome-Session we use a shell-script to start our application.
Nearly everything works perfect but one thing: When the Thin-Client starts, the application starts too but doesn't receive the focus. We have to click once with the mouse inside the application, which is not that good, because the application is designed to be used without a mouse.
I didn't found anything useful, a toFront() on my Main Frame wasn't successful.
Has anyone any better suggestions??
You can use method java.awt.Window#setAlwaysOnTop(boolean) to grab the focus and after the first user interaction reset the alwayOnTop property.
You could try to call requestFocus on your JFrame as soon as it becomes visible:
JFrame frame = new JFrame();
frame.addComponentListener(new ComponentAdapter() {
public void componentShown(ComponentEvent e) {
((JFrame) e.getSource()).requestFocus();
}
});
frame.setVisible(true);