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.
Related
Users often forget to do a task which must be done before logging out. To help with this I'd like to create a popup on logout with an option to cancel logging off.
I'm open to using any language. AppleScript looks promising, although I have no idea how to go about detecting and canceling a logout.
Since writing the question I've discovered the quit handler fires on logging out. I've created a script showing a dialog in the quit handler, which does the job of cancelling a logout, but I'm left with an ugly icon in the dock.
I'm able to remove the dock icon using the "LSUIElement" property in "info.plist", however it no longer prevents logging out when this is set.
Normally, logout clean-up is handled by individual apps: e.g., a document-based app with unsaved changes might prompt the user to save documents first. That makes sense, because each app knows what does and does not need to be taken care of before it closes, while the system generally doesn't.
As you've discovered, if you create a front-facing app the system will poll it and give the app a chance to delay or abort logout. The system does not notify background apps, services, or accessories (on the assumption that only user input needs to be checked for persistence). If you set LSUIElement to 1, your app becomes a background app, and never gets the chance to interfere with logout. There's no easy or immediate way both to have such an app work and have it be invisible to the dock.
Maybe if you're more specific about what your goal is, there might be a workaround (e.g., if you're only interested in monitoring a specific app, that might be doable).
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.
I'm developing my first Windows Phone 7 app. I don't yet have access to an actual device, so I am relying on the emulator that ships with the SDK.
In my app, I use the EmailComposeTask and SmsComposeTask where required. When debugging my app in the emulator, I click a button which runs one of these tasks, and it works. But when I then push the back button to get out of the task and back to my app, the app state is lost - it's as if I am launching it fresh all over again.
But, where it gets weird, is that on occasion this doesn't happen. I have gone back from one of the Tasks more than once to find my app state exactly how I left it.
And so, my questions:
Is this just a bug with the emulator?
If not, why is not consistent, and how should I be "saving" my app state prior to call the Email or SMS task?
Thanks.
Your page is being tombstoned which is why it seems like your application has restarted. This basically means that your app is still stored on the stack, ready to be called, but pages state and other data information is lost. To fix this, you need to handle the serialization of any data you want to keep.
For transient data, like page state things (e.g. textboxes, checkbox etc..), you can use PhoneApplicationPage.State. I believe the limit is 2mb. If you need to store more, you should store it in Isolated Storage (unlikely, unless you need to save an image). You can read about the process here. To understand the process of Tombstoning, you should read this MSDN page. To save time, you can use Tombstone Helper which handles all the lower level storage details for you, but it's a good idea to understand the process of Tombstoning anyway so you know what's going on.
The reason your app doesn't always get tombstoned is because EmailComposeTask doesn't cause a tombstone straight away. From this MSDN blog post:
Below is the list of native
experiences that, when invoked, do not
trigger an automatic tombstone in the
calling application:
PhotoChooserTask
CameraCaptureTask
MediaPlayerLauncher
EmailAddressChooserTask
PhoneNumberChooserTask
There are three scenarios in which an
application in the background will
immediately be tombstoned:
User forward navigates away from an application [for example, user
presses the Start key]
Application invokes launchers or choosers not listed above
System requires more resources to carry out a foreground activity
As you can see, that's not to say EmailComposeTask will never cause a tombstone, so you should still handle it, but it explains why your page state is sometimes kept automatically.
I am facing some issues in WP7 tombstoning. My issue is application hangs when i try for a sudden tombstone and come back. ie, After loading the page i press device menu button and with in seconds i pressed back button( Pressed Back button before the actual page disappeared) In that time the page loads but the application hangs / its back key press is not working. and if we try for a slow thombstone it is working perfectly. And the pretty interesting thing is that, while tombstoning the loaded and unloaded events of APP working perfectly. Please any one help me to solve this issue.
It sounds like your App has been deactivated, but not tombstoned. This results in neither the App or Page contrusctor being called, causing your app to act in unexpected ways. I highly recommend reading the Windows Phone Silverlight Application Life Cycle document. The relevant extract for said article:
This case can occur if the user
presses the Start and Back buttons on
the phone in quick succession. In this
case, the application received a
Deactivate event and the system was
starting to save the state of the
application to perform an application
tombstone. Before this operation is
completed, the app Activated event is
received. The system knows that the
application was not removed from
memory, so the flow of execution is
different. Specifically:
• The app constructor is not called.
• The page constructor is not called.
The only way for the application to determine
if this condition has occurred is to
set a flag to indicate if the page
constructor has been called. If you
notice in the above section, this flag
was set in the page constructor, and
cleared in the OnNavigateFrom event.
In this case, we will receive the
OnNavigatedTo event, but we will see
that the page constructor was not
called. This tells us that our
application was not tombstoned.
What am I doing wrong here? :(
I open Instruments.app, create a new UI Recorder template, select my application's .app bundle from the Target -> Choose Target menu, hit Record, open a couple of documents, type some stuff on them, close the documents, quit the app.
At this point UI Recorder stops and the Record button changes to "Drive & Record". I hit it, I see my application get launched and Instruments start recording data. Then Instruments gets confused (somehow)... my application loses focus, and suddenly UI Recorder is replaying all of my actions in Instruments!!, which just screws with Instruments in all kinds of messy ways. In this state I'm unable to move the mouse (the system just steals the cursor back), and I'm unable to quit instruments, since when I hit CMD+Q I'm prompted to Save the document, which I can't do because I have no control of the keyboard or mouse.
This is really frustrating. Has anyone got experience with this tool who can tell me where I'm going wrong? I'm scared to run it a third time as it literally hijacks my entire system.
So, you have a memory leak, and it happens when you do a specific series of actions.
The hard way to debug this would be to just have the Allocations and/or Leaks instruments and do the actions yourself every time, and every time you screw up (leave something out, do something wrong), kill the process and start over.
The easy way is the UI Recorder.
The first time you record with it, it records your actions (at the events level, not the target-action level). Mouse movements, clicks, etc.
The way UI Recorder differs from other instruments—which is why it surprised you—is that when you record with it thereafter, it plays them back.
It's not just swinging around your mouse cursor willy nilly; it's doing what you did the first time. Every time after you do things the first time, the UI Recorder does the exact same things for you.
That's what UI Recorder is for: Perfect, mechanically-ensured reproducibility. It's doing what it's meant to do; it's working as it should.
And yeah, aborting that is hard. I haven't looked yet, but there may be a stop-recording global system hotkey you can use. There is one when Instruments is in mini mode.
Also, you can set whether UI Recorder is in “drive” (playback) or “record” mode in the little pop-over that comes up when you click on the (i) button for the instrument. Switch it to record mode to re-record your interaction for different results in future runs. (I don't know whether it preserves the recording(s) in past runs.)