Is it possible to use a certain image for a loading screen when it's the first time the app is ever opened, and then after that use a different image for the loading for all visits after that?
Basically I'm creating about 10 files (not large in size) when the app is first launched and I wanted to display a message to the user so they don't think that the app normally takes more than a second to load up. I know I can display a popup on the home screen, but I have an animation that fires when you go to the home screen and also I need those files created before the user arrives there. Any ideas? Or maybe a different view point that I didn't mention?
You can't change the splash screen. Maybe you should rethink how your initial 10 files are created, and take Paul's suggestion of showing a popup control while you do the work, or better yet, offloading it into the background? I guess it depends if your created files are required for something in the UI
--edit--
Actually, the more I think about it, the more I favour a background thread doing the work while you have a popup control displayed to the user. It would allow you to give the user feedback on what is actually going on. If your popup says something like "Preparing this application for its first run...", and then shows a progress bar that updates when each file is created, the user is getting feedback on exactly why the app is taking so long to load the first time. Otherwise they may think "This app is very slow, I wonder if there is a better one out there"
I'm not sure if this is what you were thinking when you said "Popup", but you could create a full screen Popup (in the System.Windows.Controls.Primitive sense of Popup) that completely covers your main UI so that the user can't see it.
Your temporary loading UI would be defined as a UserControl described in XAML/C# in the same way as a normal PhoneApplicationPage.
When your files are ready and you close the popup you should send a message to the View (i.e. .xaml.cs) of your main page that will cause the animation to be replayed with all contents visible.
Related
I’ve encountered a problem I can’t solve.
I’m working on a project with MFC in Visual Studio. The problem is, sometimes GUI just stop visibly reacting, but technically it keeps doing the functions it was intended to do. It means, when I press a button, the function OnBnXXXPressed is executing, but the button doesn’t look like it was pressed, as if I’ve pressed on a picture of button, not the button itself. And it’s not just this button — every other element of GUI seems to keep working, but doesn’t show that it is working.
Also, in this state dialog windows don’t show up upon their call. If I call AfxMessageBox, the message box won’t show up, and the thread that called this function, will not be blocked; AfxMessageBox will basically be skipped.
I have absolutely no idea what can possibly cause that behavior. The question is: what should be happening in program for it to behave this way? Especially if it’s built with MFC?
The project consists of 50+ files, and every function responsible for GUI makes changes to the elements it is about. I do not know where the error is, and I ask you, to the very least, where should I look for it.
Thank you for attention!
The answer was originally provided in the comment section. My code indeed has a GDI resource leak that was provoking this behavior.
When a button is clicked, are you doing a bunch of processing, or do you return fast? If you don't return, maybe locking the UI thread. After a user presses on the button, how long is it taking before the OnClick for that finishes running?
If that's it, here's some more info: https://learn.microsoft.com/en-us/windows/desktop/Win7AppQual/preventing-hangs-in-windows-applications
The solution I've generally used for long-running logic on a UI click is to run it a background thread.
I am creating an app with Laravel that is supposed to use GoogleMaps API to show certain data in the map.
What I want to achieve is, that when you browse the root of the app, so when the user hits the main website, a new window is opened that will show a map to work with. So I want to have the ability to work with a second screen that only shows the map and all the information that should be displayed on the map.
How can I open a new window with certain content automatically when I browse to the main page.
Best
Sebastian
All modern browsers prevent this from happening, as it's commonly abused to serve popup advertisements. You'll need to make the new window happen via a user action, like a click on a button.
I am a little bit confused if I need to really do anything for fast switching. It seems like if I am not using media element, camera and sockets I get this "fast switching" for free.
I am not sure how to test it though. I see a couple videos where
Hit the Windows Icon(Start Icon)
Hit the back button
or
Hold down the back button till you get the screen view
Go to some other app
Come back to your app.
These both seem to load up fast again but how about if.
Load up app
Hit windows icon
click on tile app
Should fast switching happen at this point or does it load a new instance of your app up killing your old one?
There is different concept involved here:
-the first thing is Fast App resume which is a new feature of windows phone 8 that you can enable so that when you press the application tile it don't restart your app but keep the same instance (by default it will just kill the app and just recreate a new instance exactly as if the app was never opened). You can find more information about that here.
-the second concept is Fast App Switch and Tombstoning. You can find more information about the application life-cycle here. Basically what happen is when you press the windows button or navigate to another app your app will go in dormant state. In this state the application is not running but is still in memory. When you go back since everything is still in memory everything should as it was left off. The main case to handle in case of fast app switch is the fact that when your app is deactivated all the network connection are killed so you should make sure that when you go back you don't display any web error message dialog and that you redo any failed web request.
The second possible state of your application is that after the app is in dormant state you open a couple of app and the device don't have enough memory, then it will choose to tombstone your app. In that state your app is removed from memory so anything you have not saved will be lost. When you go back to your app it will go back to the page where the user previously was and recreate it.
That mean that to handle this case before the app deactivate you should have :
save any context specific data that you might not have been passing by navigation parameter.
maybe save what the user have been currently doing (for example if he is currently entering a long text, it might be better to save it so that the user don't have to reenter it from scratch)
saving the current scroll position or thing like selected items could be a plus
Also when the app resume you have to make sure that you re-query all information that you need. An example of something which would break would be if you load some Data (from a web server for example) in OnNavigatedTo of the main page and then just reuse the data on the detail page without re-querying it. If you are on the detail page press the start button and then do some other and the app tombstonne, when you go back to the app than the data will not be available (since the memory has been "cleared" and onNavigatedTo of the main page is not called since it will navigate back directly to the detail page).
You can use the page state and application state to save whatever information you need to handle properly the tombstoning case. Basically there are dictionary to which you can add some object which will be serialize (so you need to make sure that whatever object you try to save is serialisable) automatically when the app is deactivated.
To test the Tombtonning case easily, what you can do is in the project properties, in the Debug Tab check the check box "Tombstone upon deactivation while debugging". Like this it will always tombstonne the app when you debug and press the windows button or go to another app. To check that it is really tombstonning, when you go back you should see your app showing a resuming screen for a few second (while in the tombstonning case it's almost instantaneous.
So this is a bit confusing. It took me forever to figure out what they really mean by this.
What fast switching references is for more complicated apps. Apps that take advantage of something that requires a saved state.
For example if you are creating a navigation app. You are navigating then you leave the app. When you go back to that app it should show the "Resuming..." indicator and then bring your app back to its previous state.
Here is a Channel 9 video on FAS
http://channel9.msdn.com/events/MIX/MIX11/DVC09
Also here is the MSDN article about it
http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff967547(v=vs.105).aspx
Should fast switching happen at this point or does it load a new instance of your app up killing your old one?
In that case, new instance of your would be launched.
Actually, its a bit confusing, but not that much.
App can be either closed (by Windows key or pressing BAck key for a while) or exited (by pressing Back key in the main menu). Next, app comes to dormant state, it holds everything in memory. ApplicationDeactivated would be risen.
So, if you would just re-activate it (by pressing Back and selecting your app, or by pressing Back only, if you have nothing else in the stack), it would be resumed. ApplicationActivated event would be risen with e.IsApplicationInstancePreserved = true
If you would use lots of other apps (device would run out of memory), your app would go to tombstoned state. Then, you'd be needed to restore all data. e.IsApplicationInstancePreserved would be false.
If you would re-launch your app (by clicking on tile), new instance would be launched, and ApplicationLaunching would be risen.
Fast switching isn't something that really concerns you as a developer. What you need to worry about is "tombstoning" - when someone switches away from your app, you need to save the state: when the user switches back to it, you as the developer have to assume that your app was actually restarted from scratch and needs to reload that saved state. That's the difference between Application_Launching and Application_Activated (user started your app anew from the start screen, vs. app was suspended and is now being resumed, but from scratch).
At some earlier point this was the only way app switching worked. Fast App Switching was added later on and simply changed the contract such that sometimes your app would be resumed where it left off without being tombstoned. It depends on memory, etc, but it is simply a benefit to the user who will, in many cases, no longer need to wait for the app to reload its tombstoned state. You as the developer still have to assume you'll be tombstoned.
I want to check for changes in the aplication state every time interval, and if it has changed, to open a window, and give the user 10 seconds to press on the window, if he does press on the window, then to allow him to navigate freely in the window, and if he doesn't press, to return back to the window before. I thought to implement it with a thread running in the background and waking up every time interval I want. Maybe there is a better way?
This strikes me as a scenario with lots of potential issues.
How do you stop the "window" appearing at an inconvenient time to the user? (e.g. when they were just about to tap on som.ething)
Why not just raise the notification when the state actually changes? This way you wouldn't need to poll.
What is the "Window" you are displaying? How does it differ from the page it is replacing? Is this a popup or are you actually navigating to a different page?
What is the state that's changing? How is it changing without user interaction?
Can't you notify the user of the state change without a potentially intrusive display of a new "window"?
I agree with #matt-lacey, this could be dangerous and might result in a bad user experience.
With that said, this might work
Deployment.Current.Dispatcher.BeginInvoke(() =>
{
//navigation code here
});
I didn't know you could do a pop-up window, could you elaborate?
I've made a thread that is running at the background and making some work, if it decides that a change is necessary, I want to give the user a chance to react to it, or ignore it.
I'm pretty new to this, so if there is a better way than to navigate to a different page i would love to hear it.
Thanks.
It sounds to me like you want to notify the user that something has happened/changed and give them the option to do something about it, which is exactly what "toast" notifcations are all about. They pop up at the top of the screen to inform the user, and then the user can tap that toast to do something, e.g. when WiFi networks are available, you tap the toast to select an available network.
The Silverlight Windows Phone Toolkit includes the ToastRequestTrigger that you use to display toast notifications. The Windows Phone Developer Guide from the patterns & practices team gives examples of using the ToastRequestTrigger. You will need to implement the tap handling yourself in the toast content, but this should be simple enough.
I would like to show the user a splash screen (a picture) while my Cocoa-based application launches. How would this be possible?
First thanks a lot. because my app running for a while time , so I want to show a splash before app running . Now if I show a window inside with a image , after that how to run the app? How to make sure that the app running after the splash showing ? How to do to get the sequence ?
First Thank you very much. And I show the window in applicationWillFinishLaunching method use orderFront,then hide it in applicationDidFinishLaunching: use orderOut,Now I found that the mainWindow not to show and the app terminate ,why ? How to do to resolute this question? Thanks!
Although Peter's answer is ultimately correct (you should rewrite your app to launch faster), sometimes that's not a practical option. For example loading code later in the application may take too long (e.g. a data acquisition application), forcing it to be loaded at startup. If you decide that you want to show a splash screen, the easiest way is to show it in the application delegate's applicationWillFinishLaunching: method. Create a splash window in your applications MainMenu.nib and add an outlet to your app delegate referencing that window. You can then put the window onscreen in applicationWillFinishLaunching: and hide it in applicationDidFinishLaunching:. Note that the main thread's NSRunLoop is not iterating during this time, so if you want to update the splash screen (with status, a progress bar, or such), you'll need to manage those redraw events yourself.
Again, think very hard about whether the long startup is necessary. If it is, showing a splash screen with a progess indicator is the minimum that you owe your users.
Why do you hate your users?
Seriously, don't do this. Don't make your users wait to use your app. Make your app launch quickly instead.
(And just in case you insist on an answer: Show a window with the image in it, then hide the window when you feel the user has waited long enough.)
Just put up a window with the image and close it when you are done with your launch initialization.
Barry's answer above does not seem to work for document-based apps. Showing a splash window within applicationWillFinishLaunching: interferes with the startup sequence of the app such that the document window isn't created. I've uploaded an example project here. In applicationWillFinishLaunching:, comment out [_splashWindow orderFront:self ] and the document window will come up.