Acknowledged
7 months ago

AppBase.onBackgroundData requires Application.PersistableType, whereas Background.getBackgroundData and Background.exit use Application.PropertyValueType

As per the subject, there is a type discrepancy in the API.

Now, Application.PersistableType is actually defined to be the same as Application.PropertyValueType, which is fine, but Background.getBackgroundData and Background.exit should still be listed as using Application.PersistableType for consistency.

In addition, it would be REALLY good if Application.PersistableType (and/or Application.PropertyValueType) could be extended to include Graphics.BitmapReference and Graphics.FontReference so that these objects can be passed to the foreground through Background.exit. I can't see any reason why this shouldn't be done. It otherwise requires using Storage.set/getValue, which is a heavy-handed approach for sending a tiny object.

1148788
  • 7 months ago

    It’s not super important, but I think it’s actually 1 byte for the type and 4 bytes for the value/pointer (for a total of 5 bytes). Regardless, it’s a small amount of data that’s being passed around.

  • 7 months ago

    FlowState, thanks for taking the time to explain all this.

  • 7 months ago

    If you've ever used a WeakReference in Monkey C, I think the concept is analogous to a BitmapReference. WeakReference is a reference to a reference (and you get the original reference by calling get()). (Or another way to look at it is it's an object which stores a reference. But objects are passed by reference anyway.)

    Indeed, if you use the memory viewer in an app which uses bitmaps, and expand a BitmapReference value, you'll see that it consists of a WeakReference.

  • 7 months ago

    > When you pass that BitmapResource around your app, you're passing a 6-byte value (2 bytes for type, 4 bytes for value), not a 1 MB blob of data.

    I should probably say "6-byte object", to avoid confusion.

    Also, in this case, obviously the 4-byte value is a pointer/reference to the actual data, same with any non-primitive objects, and primitive objects which are bigger than 32 bits (Long, Double, String.)

  • 7 months ago

    > It is also a bit anomalous that if you want to store a "reference" to a 1MB image, it requires 1MB of storage!

    As discussed previously, you're not storing a reference to an image, and I don't think it's ever been suggested that the actual reference is being stored. (Although the documentation doesn't really cover the case of passing a BitmapReference to setValue()).

    Again, even in the pre-graphics pool case, when you have a BitmapResource, it's still a (normal) reference. When you pass that BitmapResource around your app, you're passing a 6-byte value (2 bytes for type, 4 bytes for value), not a 1 MB blob of data.

    In this case, when you call setValue() on that normal reference, some sort of "dereferencing" has to happen.

    The only practical difference is that for normal references, you don't have to worry about their implementation details as they just work (no need to explicitly call get() or something like that).

    Most importantly, it's not practical at all in principle to store any type of reference of to any kind of object, in persistent storage. References point to objects in RAM, which won't necessarily be available once the object is retrieved from storage.