I have an Instance member in the MainPage.xaml.cs ie in the MainPage class extending from PhoneApplicationPage
When I navigate to another page and back again I want to have the value of the Instance member ... How do i persist across Page calls ?
Have only a couple of pages and the member object class is small
Should I Push into PhoneApplicationService?? and into the State?
Is this the cleanest and best performing way??
First time in Mobile dev ... Thanx in advance :)
In general use, the Page instance will be preserved in RAM - so you don't need to do anything.
However, in tombstoning situations then your page instance will get flushed from RAM.
To preserve a value or a string, the easiest thing to do is to save/load your value to IsolatedStorageSettings - http://msdn.microsoft.com/en-us/library/system.io.isolatedstorage.isolatedstoragesettings(v=VS.95).aspx
You can use the OnNavigateTo method to load this, and the OnNavigatedFrom method to save it.
If you need to persist a larger or more complicated object, then you can use JSON or XML to serialize/deserialize the object - and you can look at using more general storage techniques - e.g. files in IsolatedStorage or a database solution like SQLCE, SQLite or Sterling
I don't think the instance member will get destroyed during navigation unless the page is removed from backstack or application is tombstoned. you don't have to write extra line of code in order to keep the instance member alive. So you don't have to store it in PhoneApplicationService's State.
Related
If I lock my phone while running my application and unlock it say after 30 minutes or 60 minutes, my screen appears blank. All my data (its a huge list compare it to a user's twitter feed) which was in an Observable collection in my ViewModel has disappeared. When I refresh I get NullReferenceException. Note that I am not handling any state save while locking and unlocking the phone. Is that the reason for the loss of my data? How can I handle it? Since there is a limit on the state data which can be saved of 4Mb Max, will it affect the functioning of my application even if I do implement it?
[Update]
I have tried the following things:
1) http://www.scottlogic.co.uk/blog/colin/2011/05/a-simple-windows-phone-7-mvvm-tombstoning-example/
2) http://www.scottlogic.co.uk/blog/colin/2011/10/a-windows-phone-7-1-mango-mvvm-tombstoning-example/
and many more.
The problem which I now face is that my application's viewModel contains an observable collection which I have binded to the UI. This observable collection is a collection of my user-defined class which contains complex data members. One of them is a dictionary. When i try to save my viewModel using XMLSerialization it throws an error as XML serialization doesn't support Dictionary.
I have also tried to write my viewmodel after Data contract serialization onto the IS during App_Deactivated and retrieve it on App_Activated. But my collection is null on resume. On opening the IS file it shows that the collection was not written onto the file. Am I missing some key ingredient in-order to solve this problem?
Note: I need my list. I cannot refresh data.
I'd suggest that this is the wrong approach.
Tombstoning is designed to allow you to save your state, not your data. You want to store the following:
The page you're currently on
The parameters, if any, that were used to get your list of data that you are currently showing
Any selection state (has the user selected a row, etc)
Any page state (is it in edit-mode, etc)
Not all of these things will apply, but it should provide you with an idea of what you should be storing.
This will be a significantly smaller set of data using simple data types rather than large chains of complex objects.
So:
Store the properties/parameters that you use to get your data
When the app resumes go get your data again using the params. If this take a while give the user some form of progress notification. If you can't accurately do this then display activity on the screen until the load finishes so the user knows that something is happening.
Since Wicket automatically manages session state by serializing the components in my page, I'm left wondering, at which level I should attach my state data. More specifically, it seems like a bug I'm having is caused by the WebApplication object being shared among sessions.
Is the application instance shared between sessions?
Should I always attach session data to the Page instance?
What happens if I reuse components with attached session state on multiple pages? Are those instances shared, i.e. if I set the state on the component on one page, is it carried over to another?
I'm guessing, the third bullet point depends on object identity. What does Wicket use to determine that, equals() (like, is it using a Map)?
The data I attached to the application object is state I would need in many pages, so I didn't attach it to the page objects. Is that the correct way to do it in Wicket?
Yes, that's the point of having an Application object. You can store and access application-wide data (usually config) through your Application subclass at any point.
No. There are cases when you need to share session data across multiple pages where storing it in a Session object is more adequate. (An example could be a user login, which definitely belongs to the session and may be used by any page.) Of course you can pass the data around between the pages but it's not a very good strategy. Where the cutoff point is will be your decision: if data is shared between two pages, you might want to pass it from one to the other, if there are 20 pages, you definitely won't want to.
You're not supposed to reuse component instances across different pages. Of course you'll reuse the class but you'll have to construct a new one on each page. This is exactly where storing data in the Session object might come handy.
To clarify: The number of pages sharing state is an indication of where to put the data, but what really matters is how tightly you want the items sharing data to be coupled:
If you pass data as parameters between pages, they will form a tightly coupled group. Depending on what the pages represent, this might be desirable. An example for this may be a wizard-like sequence of pages, with each page knowing what the pages before and after are.
But in the login example we see the opposite: the component populating the login name (probably some kind of login form) must not know about what other components are going to use it. So the logical solution is to store the login name in the session and let each component fetch it as and when they need it.
There are multiple ways to get hold of the current Session object. Check the documentation of the class to see how.
To summarize the information there: Wicket discourages type-unsafe session properties by not providing generic setProperty-like methods. Instead, you are supposed to extend Session, or for most projects, more adequately, WebSession and place typesafe properties in that class. You then override newSession on your application class.
When user click the Bing Search or Start button, this will cause Deactivated event.
So, when user press Bing Search or Start Button, How do I store the data. What type of Data can be stored and What to use to store?
You can save:
Page state (textbox values, scroll positions) by overriding OnNavigatedFrom and writing values to the Page's State property. You can reload the data in OnNavigatedTo
Application state (stuff that applies to all pages that you'd keep if the user hit back to return to the application, but not if they re-launched the application from Start) by handling the Activated / Deactivated events of PhoneApplicationPage and storing data in its State property. If targetting Mango, you can (and should) skip loading your application state if ActivatedEventArgs.IsApplicationInstancePreserved is true.
Permanent state (data caches, encrypted user sessions keys) to the file system using IsolatedStorageFile. It's better to do this when you receive that data, rather than waiting for the Deactivated event as taking too long to write data can result in your application being terminated (and corrupting your isolated storage files)
Page/application state dictionaries can store simple types as well as dictionaries and any serialiazable class (which has an empty constructor requirement).
You need to "tombstone" your data. First of all, read about the Execution Model for Windows Phone
After that, read one of the many guides on the subject.
You can use IsolatedStorage or the Application State environment to store information. Sorry to say, but start googling.. you would probably found this if you did.
I'm working on a ColdFusion dynamic website. For this website, there are a lot of CFCs and a lot of functions within each CFC. Would it be more efficient to store an instance of the CFC in an application variable, then to instance each CFC separately on each page load.
For each page, at most 2 separate CFCs get called. I'm also interested in how performance will be effected when requests increase (Stress).
Thanks!
It depends. If the CFCs in question are singletons then yes, it's wise to instantiate them once and store them into the Application scope. As you get more experienced and your application grows you'll find that the best tool to manage object dependencies is ColdSpring, but for now just creating the object in onApplicationStart() would be your best bet. If you are dealing with transient objects then you'd need to create the object per request.
Hey guys, I've got a subclass of an NSManagedObject. In awakeFromInsert and awakeFromFetch I'm calling an initialization method which, among other things, starts an NSTimer.
Now i need a place to invalidate the timer. However, dealloc, finalize, didTurnIntoFault, prepareForDeletion and willTurnIntoFault aren't getting called.
According to the documentation, these methods should all get called when the object is cleared from memory. None of them are, however all the data is saved in the persistent store. I'm puzzled as to why or how.
Is there anything i could be doing that could cause these methods to not get called during the objects life cycle?
Core data controls the lifetime of NSManagedObjects. It's not going to flush an object from memory by itself unless you ask it to. Looking at the documentation, there appear to be two ways:
sending refresh:mergeChanges: to the MOC causes the object to turn into a fault.
sending reset to the MOC causes it to reset itself as if it has just been created.
However, any of the above requires explicit action on your part, so you might as well add a method to the object to invalidate its timer and invoke that.
In fact, your problem probably indicates a design issue. An NSTimer is essentially a user interface event. It should probably be controlled by your MVC controller which sends a message to the model object (the NSManagedObject) to do the action.