CODEWITHSUNDEEP
c#cachingwindows-runtimeuwp
user2921851
user2921851

Reputation: 990

Is using global cache a bad idea for passig complex object on navigation? If it's, any alternative?

I have been using parameter passing with page Navigate method in UWP app without a problem (with object serialization and deserialization). As my objects (passed as parameters) grew in size, I started hitting a problem when the app is suspended and the SuspensionManager attempts to serialize the navigation parameter and save it to a local storage. I get an exception indicating size limit of 8K I think (and assume I have no control over this size).

So I am considering passing the parameter via memory cache rather than navigation parameter(say, save my complex data object to a dictionary in memory with nameof(PageNavigatedToType) as key and retrieve the cached data on NavigatedTo in the destination page. My concern is a possible memory usage increase and not sure for instance if setting a particular dictionary value to null (when no more needed) makes that much of a difference to global memory (I mean app scope).

Any thoughts and suggestions appreciated.

Upvotes: 0

Views: 376

Answers (1)

JuanK
JuanK

Reputation: 2094

You can't use LocalSettings to store a value higher than 8k and each composite setting can't be higher than 64K bytes in size.

ApplicationData.LocalSettings | localSettings property

If you need to much data to restore when SuspensionManager handle the app restoration maybe a better idea is just to save a value as key and then restore the full object from another place or procedure. As you have suggested.

I am considering passing the parameter via memory cache rather than navigation parameter(say, save my complex data object to a dictionary in memory with nameof(PageNavigatedToType) as key and retrieve the cached data on NavigatedTo in the destination page.

Your concern

My concern is a possible memory usage increase and not sure for instance if setting a particular dictionary value to null (when no more needed) makes that much of a difference to global memory (I mean app scope).

Is a legit concern, but you can handle the object scope to be short, once the GC "detects" memory needings It'll free the objects according your object scope into the code.

If you free a dictionary value -setting it to null- could be enough to be recycled "if and when " there doesn't exists more references to such object.

short object scope could be achieve it in many ways because this is a concept.

  • Just declaring local method variables instead of class variables/properties is one of them.
  • When you're using IDisposable objects. The using keyword ensures the correct use of IDisposable objects and allow them to be garbagecollect
using (Font font1 = new Font("Arial", 10.0f)) 
{
    byte charset = font1.GdiCharSet;
}
  • C# allows you to control a field scope into a method thru brackets, this is a syntax helper to control in which scope your field would be used and because of that you can opt to free those resources just after close the brackets. For sure you could use that if your field isn't an IDisposable field.
public void MyMethod()
{
    ...
    ...
    {
        var o = new MyObject();
        var otherReferenceToSameObject = o;
        var s = "my string";
        ...
        ...
        ...
        ...

        otherReferenceToSameObject = o = null;
        s = null;
    }
    ...
    ...
}
  • Any way remember that GC is deterministic by its own algorithms, We don't have enough control over that, but keep some control over our resources could help the GC to do a better work.

Upvotes: 0

Related Questions