Stories projects interoperability: strip Android specifics

[mzorz]

See #477 first

Discussion

Here I'm proposing some of the changes to the current serialization format, to get to a format that works for both Android and iOS.

• 28b78d2 removed SaveResultReason which was a very local state representation
• 7188bcd normalized fontSize, textColor, textAlignment
• 186679d added metadata object which tells more about the context in which this Story has been created:

  "metadata": {
    "revision": "1.0",
    "device": {
      "screen": {
        "width": 1080,
        "height": 1280
      },
      "platform": "android|ios",
      "model": "iphone10"
    }
  },

• the revision is the interop JSON definition revision number to correctly attempt deserialization.
• the device object for now contains a screen width/height measures as informed by the device, given all other positioning measures will be relative to this canvas size.
• platform and model are self-explanative. We can add brand or vendor too which makes sense for Android.

Adding more comments on the code itself down here in the PR 👍

[mzorz]

regarding this:
"type": "com.wordpress.stories.compose.story.StoryFrameItem.BackgroundSource.FileBackgroundSource",
I'm not sure we can change this on Android - we could by writing our own serializer for this class though, just commenting here. Maybe we can keep the format, even if this verbose?

[mzorz]

             "translationX": -180,
            "translationY": -861.4966,

these would remain the same, and are always calculated from the center of the screen where the object is initially placed. Added the screen size for this as part of the metadata object. In this particular example, the user would have moved the object 861 dp up (that's why it has a negative Y translation) and 180 dp to the left.

[mzorz]

suggest we change this from fontSizePx to fontSize where the size is expressed in pt (which would be absolute) or em? deferring to @aforcier here, don't know what the best unit would be here

[mzorz]

also, what looks like a good "universal" unit on iOS @bjtitus ? wonder if they save this information in Kanvas already, maybe we can borrow any ideas from there?

[bjtitus]

We use point sizes, typically. I believe this is the same as the "density-independent pixels" size on Android:
https://en.wikipedia.org/wiki/Point_(typography)#Apple_point

[mzorz]

ah cool! yes they even seem to have the same correlation, TIL @bjtitus 👍

[aforcier]

Sounds like sp would be the way to go then 👍 A few more text size-related things are added with #494, most of them (shadow radius, shadow dx, shadow dy) can be in sp as well.

One exception would be letterspacing, which is stored in ems (here's the documentation), which should be an appropriate unit to keep it in.

@mzorz probably once the text feature work is done we can update this with all the new units and expand the discussion a bit - I'll follow up with you on this.

[mzorz]

sounds good!

[mzorz]

I think this hex code format comes in handy for cross-platform text representation so, maybe a no-brainer, let me know if there's any other better options.

[mzorz]

Probably we can do some app-level defined values like these three?

[bjtitus]

iOS has 4 built in text alignments:

• left
• right
• center
• justified
• natural

[mzorz]

I see! is natural something to do with RTL, or is it dependent on the font?
[searches for it]
ah I see yes it goes with the default alignment for RTL https://developer.apple.com/documentation/uikit/nstextalignment/natural
I think if we use this we'd need to also add information about RTL to treat it the same way on every device / platform. We may want to just use maybe the first four and make sure all is contained for interoperability, or we can make this a "loose" field value and let the app figure out whatever it wants / can do with the given value here.

[mzorz]

Regarding this:
- "contentUri": "content://media/external/video/media/639"
We should probably get rid of this one altogether, it made sense for Android at the beginning since the source of a background image could be a third party app for example, that implements a Content Provider. I think given other reasons we've been discussing, we're going to have a local copy of the background image, and as such, we'll only need a file source here.
In the context of WordPress, such background image will also need to be uploaded to the WordPress site, and as such this will end up always being an https:// URL pointing to the background file (we could do a mediaID but the stories library should be agnostic of WordPress entities).

[mzorz]

this would be the revision number to correctly attempt deserialization.

[mzorz]

the device object for now contains a screen width/height measures as informed by the device, given all other positioning measures will be relative to this canvas size.