Support for managing state

There should be built in support to handle saving/loading state when the app is terminated/suspended/closed by the OS.

This is something that practically all apps needs to deal with, and at least Apple requires that an app can restore state when it is resumed.

I'm not sure exactly what the best way to do this would be, perhaps attributes similar to DataContract would be the way to go, then the framework could automatically save all attributed classes when needed, and then automatically restore them when resuming.

Tagged:

Open · Last Updated

Posts

  • HunumanHunuman GBMember ✭✭✭✭

    Hi @ThereIsNoUsername

    I am not sure what functionality you are proposing beyond the existing support.

    I assume you are aware that you can use the Application.Settings collection to preserve App state.
    Obviously for complex state a database or some other data store is needed.

    Please clarify, thanks,

    Tim

  • anton.emelyancevanton.emelyancev USMember ✭✭

    There are OnStart/OnSleep/OnResume methods of XF Application class which hooked with corresponding native platform methods. Provide your own implementation of storing/receiving databy overriding that methods and you'll get what you want (if I got you).
    I think 'saving/loading state' is a bit unclear feature. What do you mean by state and how XF should process user-implemented features?

  • ThereIsNoUsernameThereIsNoUsername USMember ✭✭

    Think Hibernate. If we can get a whole OS to save the state of all applications, then we should be able to handle the state of a single app.
    It should all be automatically handled.
    Developers should focus on the features and functionality of the app, not writing plumbing code to satisfy strange and unwanted behaviours by to OS.

  • JulienRosenJulienRosen CAMember ✭✭✭✭

    ? it is not clear at all what you are asking for here.

    can you provide an example?

  • ThereIsNoUsernameThereIsNoUsername USMember ✭✭

    For me it's obvious.

    When a customer comes to me and say: "hey, I have this problem (ProblemA) here that I want you to fix".

    Then the customer want to pay me for handling ProblemA. The customer has little to no understanding why he should pay me for writhing any other code than the code that handles and fix ProblemA.
    If I go back to the customer and say: "I have a solution to your ProblemA, I can make a program which rater easily solves the whole thing, and I think I can write the code for this in three days."
    If I now send a quote to the customer including the three days for coding the solution to ProblemA, and two days for coding a lot of plumbing just to get standard functionality that every single application need, I will have a problem. The customer will argue that he don't want to pay for this "plumbing", and it surely has already been solved. He will continue to argue that his windows laptop saves the state of all programs automatically, and he has never heard of anyone needing to to "plumbing" to get a traditional application in windows to support the hibernation process in windows.

    And this is also my point.
    Xamarin.Forms should out of the box just support this. It should be impossible for me as a developer to write an app with Xamarin.Forms that is not just has it's entire state automatically serialized and persisted, and then brought back again when needed.
    Why should every single developer have to deal with this?

Sign In or Register to comment.