locked
Windows 8 XAML- Storing objects in Application.Resources Resource Dictionary

    Question

  • I am still relatively new to development for Windows Store Apps in XAML/C# and I'm currently dealing with some very random and intermittent problems in my app - possibly memory issues.

    I am now starting to doubt whether my approach to storing data in my app is the correct one

    Firstly a quick overview of how my app works - user logs on once a day, downloads data from web service and stores the data in xml files. Each time the app opens/resumes the data is loaded from xml, deserialized and stored in memory in the Application.Resouces Resource Dictionary.

    The objects I am storing are my own classes which contain Observable Collections of other classes. I have declared these in App.xaml
    <localdata:MyClass x:Key="MyClassResource">

    When a page needs this data I reference it using
    MyClass myClass = (MyClass)App.Current.Resources["MyClassResource"];

    In my OnSuspending method I clear down these objects and create them again in OnResuming.

    This approach doesn't give my users any problems for the majority of times - however I am experiencing some very intermittent problems in my app and I am trying to rule out whether this is the right approach for storing my data.

    Thanks

    Tuesday, February 24, 2015 1:44 PM

Answers

  • The benefit of defining a resource in App.Current.Resources is that it keeps this object around and makes it accessible across the various pages in your app. An instance of the resource will be automatically created for you at start up which may be a good thing depending on your requirements.

    You generally store styles and other UI stuff in App.Current.Resources but there is nothing that stops you from storing CLR objects in there as well.

    I would however store an ObservabkeCollection that you add and remove objects to and from during runtime in a view model or in some kind of application service class depending on how and from where you use it, e.g:

      public class ApplicationService
      {
        public static ObservableCollection<string> MyCollection {
          get {
            return _theCollection;
          }
        }
      }

    But I don't think the actual place where you store the collection has anything to do with your memory issues.

    Hope that helps anyway.


    Please remember to close your threads by marking helpful posts as answer.

    • Marked as answer by Ryan Cairns Tuesday, February 24, 2015 2:45 PM
    Tuesday, February 24, 2015 2:29 PM

All replies

  • >>In my OnSuspending method I clear down these objects and create them again in OnResuming.

    Why and how do you "clear down" the objects? When you declare a resource in App.xaml it is supposed to live as long as your application lives and you can reference it from any class in your application using App.Current.Resources like you are doing.

    You shouldn't remove the resource if you intend to use it again later on. If you don't remove or "clear down" the resource you should be able to get a reference to it like this at any time:

    MyClass myClass = (MyClass)App.Current.Resources["MyClassResource"];

    The MyClass objects that you define in App.xaml is created only once the application starts up. It is not recreated for you when the application resumes. If you want to be able to "clear down" resources at runtime for whatever reason, then App.xaml is probably not the place to define these resources.

    Please remember to mark helpful posts as answer and/or helpful.

    Tuesday, February 24, 2015 2:03 PM
  • Hi - thanks for the fast response.

    The MyClass objects contain ObservableCollections so I am simply calling

    MyClass myClass = (MyClass)App.Current.Resources["MyClassResource"];
    myClass.MyCollection.Clear();

    I am then filling up MyCollection again in OnResume.

    From what you are saying it is perfectly acceptable to store large objects in App.Current.Resources?

    The only reason I added code to clear these collections down was because it was an attempt to try and get to the bottom of memory issues I am having with the app resuming- notably this one:

    https://social.msdn.microsoft.com/Forums/windowsapps/en-US/59faa19f-78f2-42de-a7f0-5091bd4c1dbf/controls-disappearing-not-rendering-intermittently?forum=winappswithcsharp#d63f2de3-fb13-42e5-8309-ce1882b83a1e

    Tuesday, February 24, 2015 2:18 PM
  • The benefit of defining a resource in App.Current.Resources is that it keeps this object around and makes it accessible across the various pages in your app. An instance of the resource will be automatically created for you at start up which may be a good thing depending on your requirements.

    You generally store styles and other UI stuff in App.Current.Resources but there is nothing that stops you from storing CLR objects in there as well.

    I would however store an ObservabkeCollection that you add and remove objects to and from during runtime in a view model or in some kind of application service class depending on how and from where you use it, e.g:

      public class ApplicationService
      {
        public static ObservableCollection<string> MyCollection {
          get {
            return _theCollection;
          }
        }
      }

    But I don't think the actual place where you store the collection has anything to do with your memory issues.

    Hope that helps anyway.


    Please remember to close your threads by marking helpful posts as answer.

    • Marked as answer by Ryan Cairns Tuesday, February 24, 2015 2:45 PM
    Tuesday, February 24, 2015 2:29 PM
  • Thanks - this answers my question. I had read that App.Current.Resources should only be used for UI elements - so I think I'd prefer to stick to that guideline and use a static class.

    Tuesday, February 24, 2015 3:02 PM