0

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.

user2921851
  • 990
  • 12
  • 26
  • [This answer](http://stackoverflow.com/a/33238983/2132796) of mine might help you. – Stefan Over Jan 21 '16 at 13:07
  • Thanks for the pointer. I'm presuming that global cache is not a good idea. Do you have a reference link (if any) that explains the second bullet point referring to " Or keep a reference to them in any kind of Manager class, that is a member of...". Thanks. – user2921851 Jan 21 '16 at 13:17
  • There's no kind of reference, sadly. It ends up in a global cache - or call it manager - for complex data. There's no points in handling those via the navigation parameters. However, this manager should more or less act like a `Stack`: Put something onto the navigation (parameter) stack, and the next page opening will take that navigation (parameter). – Stefan Over Jan 21 '16 at 15:21
  • @Hedro But the problem kicks in when the app is suspended. On suspension the navigation parameters need to be serialized and saved to local storage, causing exception when a certain size is exceeded. That 's where my problem started. I have been using navigation parameter without a problem even with complex objects. – user2921851 Jan 22 '16 at 09:26

1 Answers1

0

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.
JuanK
  • 2,056
  • 19
  • 32
  • Thank you for the reply. Can you please explain the following: *"but you can handle the object scope to be short"* How? You also say *"setting it no null"* -- is this a typo or you mean *setting it to null*. If there is a means to mark my global object to have short scope so that GC can act upon quicker -- that I am not aware and would like to know. – user2921851 Jan 27 '16 at 07:37
  • I ahve added some complementary info to the answer. – JuanK Jan 27 '16 at 14:38
  • I can understanding scoping -- no doubt there. My issue is once an object is global, there isn't much control other than setting it null and hope the GC will reclaim the memory. That's my dilemma and wondered if there is a more clever way of dealing with global objects defined at App scope. Navigation parameter serialization and deserialization is great but as you indicated fails terribly when an app is suspended because NavigationService attempts to save to Local Storage with memory size limitation. – user2921851 Jan 27 '16 at 15:00
  • The only thing you can do with Global objects defined at App scope is to ensure they are set to null when you don't need it any more. Also verified child objects could be useful to GC. – JuanK Jan 27 '16 at 15:41
  • Thanks, makes sense. I can understand child objects when disposing of a global object, but the phrase you used *verified child objects* caught my attention. Care to comment on *verified child objects* ? Thanks. – user2921851 Jan 27 '16 at 16:54
  • sorry , I'm not a native english speaker, it was a typo. I mean "Also verify child objects" – JuanK Jan 27 '16 at 19:32