Stories projects: interoperability discussion

[mzorz]

Note: keeping this PR as draft (WIP), we may probably not merge in the end, but serves as a placeholder for the discussion about formatting to happen freely but yet on with a more structured discussion flow.

The file being added in this PR is a sample of the serialized state we're using on Android as is (see refs #414 and #435); we'll use this as a starting point to discuss which parts need to be platform agnostic in order to come up with a serialized format that works for everyone.

This base PR only adds a sample file with an actual output of the current format being used on Android, and as such there are things super local to the variables being used there.

I'll describe each of the parts of the structure here, and pose the following questions:

• what things are local and need to be normalized?
• what data types should we use?
• what things are missing here that would need to be added to move the project from one device to another device?
• is there anything on another platform that needs be taken into account?

Follow up PRs can suggest modifications to this structure in order to bring in the normalized information we'd need to be able to share this structure among platforms.

Description

• a Story is a collection of frames, and may have a title or not.

• basically a frame is a story slide (we could rename it to slides)

Frames

Then for each frame:

• source is the background media descriptor, and it also indicates the type which is relevant for Android (is it a Uri or an actual File)
• frameItemType tells us whether this is a video or an image. For video, we also have a property "muteAudio": false that describes the audio setting for this video.
• addedViews is the collection of views the user put on top of each slide (text, emoji)
• saveResultReason is how things went when we tried to save this slide to disk the last time - this is a save state that is passed around for internal communication in Android between the Activity and the Service, notifying the user about what went wrong if unsuccessful, etc. This is a candidate to be removed for an actual interoperable / exchange format.

AddedViews (within a frame)

Then, addedViews is a collection of objects that belong to a frame, that have this information:

• viewType could be TEXT or EMOJI for now (we also could be adding animated gif stickers, for example, which the Android stories lib is capable of but not using atm)
• uri in the case this addedView has some background (we’re not using it for now, but we would have to use it in the case of animated gif or just plain images being added)
• viewInfo has information to understand how to position the view with regards to the screen
• rotation, translation, and scale are the exact values each View had at the moment of serialization, and are indicators of their positioning on the screen. As we can see, the information about the screen it taken for obvious and is not explicitly defined.
• addedViewTextInfo has information about views that are of viewType == TEXT: text (contains the text), fontSizePx contains the font size in device pixels (this is dependent on the device where things were created, we could do conversions ofc it’s just that we don’t care for now), textColor has the textColor code in signed Integer format (we can change that), and textAlignment has a value of 0, 1, or 2 for text aligned to the left, center or right respectively (currently matches the values for View.setTextAlignment` on Android but give we defined our own values here we can make it interoperable as well).

The Story represented in the Story composer

The Story being represented in this example is shown like this on the Composer:

[bjtitus]

I wonder if it would be better to break this into position and info where info is the extra type specific values and position is the translation, rotation, and scale.

[mzorz]

good idea! 👍