I am developing an app for windows phone 7.My app communicates with a server which sends it some data which I display on the UI.And I save the state of my app in ApplicationSettings.
And I have found that sometimes
ApplicationSettings.Save() doesnot save the current state.Rather when I start my app it resumes with the previous state which was stored successfully.
Actually I call save method when my app is closing.
But I just want to know if my app is making some changes on the ui.Then is there a possibility that it could be the reason for not saving the state.
If that is the case then what should i do to save my state properly.
If you are saving ONLY when the app is closing (i.e. Application_Closing), then you are not capturing the state often enough. Depending upon how you have exited the app, there are times when the application is simply deactivated, but not necessarily closed. If the app is subsequently tombstoned after deactivation, you will have needed to save the state appropriately to restore it back.
Here is an article to give you a better idea of the different states.
Windows Phone 7 Tombstoning
Related
I wanted to implement one of my idea where I want to restore or open the saved pages again of the last instance for a window application in case of crashed or sudden shut down.
The current approach, as we have to re-configured all the steps and actions as we have done before crashing.
Background - We have a WPF windows application with C# and legacy code.
Suggest me any suggestion or way to achieve this.
I have developed an app for the Microsoft store. The problem is, that I can not upload this app to the store, because I've used the confirmAppClose capability, to detect when my app gets closed.
Does anybody know another way to detect when my app gets closed?
Does anybody know another way to detect when my app gets closed?
I am afraid there is no way to detect or prevent the app from exiting without using the confirmAppClose restricted capability. That's why it was introduced in the first place.
When it comes to store submission, you'll need to provide additional information on the Submission options page in order to receive approval for an app that uses a restricted capability.
Current scenario stands like this:
User opens my app
Background audio agent starts playing
User goes back to start screen
Audio keeps playing from the background audio agent
User kills the application from the "task bar" (the closing button in upper right corner)
Background audio agent keeps playing.
I need to achieve following:
Close the audio background agent when the user kills the application (I know that I can use the close method on the backgroundaudioplayer but I need to call this when the application is killed/exited).
Questions:
Is there any event besides: Application_Deactivated / Application_Closing when the user truly exits/kills the application?
If there is no event like mentioned above - can I tell from Application_Deactivated / Application_Closing when the user really exits/kills the application?
Thank you
there is no way to detect when an app got closed by the task switcher or system. Usually apps keep tombstoned until they get either reactivated or killed. You have to do all the clean-up work in the Application_Closing and Application_Deactivated events.
This has one simple reason: When an application lies in the background it is freezed and cannot execute code. Whenever the user or the system kills it (to get more memory for example) the app and all its data get completely wiped out of the memory. Without notifying your app and without giving it the chance to gain performance (which would be counterproductive).
So you just have the chance to use the Application_Deactivated event when the user tap the start button or another app is launched or the Application_Closing event when the user closes the app via back button.
Read this if you need additional information about the Windows Phone 8 Application lifecycle.
Beside this a user would expect that the background audio is still running after he closes the application. A podcast for example should also play when I closed the podcast app. What kind of audio are you talking about? Maybe we can find a smart solution...
The only events you can react to are Closing and Deactivated.
So here,you can call BackgroundAudioPlayer.Instance.Close() in "Application_Closing" event only.
I have a settings save method I call, but I tried unload, and lost focus the application will close out and not save before ever getting to either of those methods. When should I save application settings to keep this from happening?
Should I use a timer and save every 30 seconds, or what?
How often you save depends on your app. However, the key timings are:
Launching
Activated
Deactivated
Closing
Launching is called when the app is first launched from the main screen and Closing is called when the user presses the back key to exit your app. Naturally, you'll most likely want to save permanent data in the Closing event.
Activated is called when the user has closed your app via the Windows button and has gone back into it by pressing the back button. This doesn't get called if the user launches the app for the first time.
Likewise, the Deactivated event is called when the user presses the Windows button. Depending on your app, you'll want to save transient data at this point so that when it's restored, you can give the illusion that your app wasn't closed at all. (Otherwise, for example, all textboxes will become empty even if the user entered data before pressing the Windows button).
Those are the main events, so you can design your app around that. One thing to remember is that if your save files are going to be big, and they take longer than 10 seconds to save after the closing event is called, your app will be terminated immediately, possible corrupting the save file. Therefore, for large saves files, you should plan ahead by saving incrementally (for example, after the user has made a change that should remain permanent).
There's no one size fits all solution to this as saving timings are highly dependant on the type of app being developed. Have a read of the Execution Model MSDN Page as it goes into more detail and provides code examples.
Here is a sample from MSDN on how to implement settings page for Windows Phone.
http://msdn.microsoft.com/en-us/library/ff769510(v=vs.92).aspx
I doubt this is even possible. So your app is running and user decides to End Process via Task Manager. Is there a method/action to save data during process.kill? I doubt there is but I had to ask.
Also, if a user shuts down/restarts PC (as in windows update/manual restart), what action would the app execute? Window_Unloaded? On this second question, I would like to find a way to ensure my app does not show up as a 'if you want to restart, kill this app' situation and want to save needed data.
Your two cents is greatly appreciated!
It's not possible to do what you want unless you have two processes; one monitoring the other one's status and do some stuff upon its termination. The watchdog process might be a Windows Service Application without GUI.
Windows sends a quit message to every opened application when normal shutdown occurs. You can run some code (usually housekeeping stuff) upon receiving the message and exit the application. It shouldn't take long or Windows will automatically ask user if they want to kill the application.
Force shutdown kills all processes immediately (in no particular/predictable order). So you can't (easily) detect it.
I suggest you to save everything needed as soon as possible to prevent data loss when the application process gets killed.
If something terminates your running app, then you don't get an opportunity to do anything, just die. You modify your app such that all data is always saved to some persistent location, so if the app dies, the persisted data remains. Obviously you have to design for this. Then if the user does a "save", you commit to the "real" datastore.
If Windows is going to reboot, it should send a message to your app, which you can handle. Not sure if this works for all GUI/console/service -type apps however.