Multiplatform

[svenjacobs]

Everyone is talking about Compose Multiplatform right now.
This is a discussion to figure out how Reveal can be ported to multiplatform.

---

The biggest challenge I currently see is the dependence on Android's ComposeView and Context in the Fullscreen composable, which renders the Reveal effect on top of all other composables, regardless where in the UI hierarchy it's placed.

[svenjacobs]

The biggest challenge I currently see is the dependence on Android's ComposeView and Context in the Fullscreen composable, which renders the Reveal effect on top of all other composables, regardless where in the UI hierarchy it's placed.

This was introduced with PR #25 in version 0.0.14. Before this change the Reveal composable needed to be one of the top most composables of the whole Compose hierarchy in order to render the "full screen" effect over all other composables. This also meant that RevealScope, which is required for the revealable() modifier, needed to be passed down to the composable where needed. The change simplified the usage of Reveal because Reveal could be just added where needed, in a separate module for example, but the effect would still render full screen.

However this has introduced a dependency to Android's Context. In order to remove this dependency again and pave the way for multiplatform support, we would have to change the behaviour of Reveal to how it was before this change. This is obviously a breaking change and would call for a new major version (2.0).

In summary, this would mean:

• Reveal needs to be declared as one of the top most composables. Reveal becomes a dependency of the whole project.
• RevealScope needs to be passed down to the place where the revealable() modifier is applied. This will inevitable introduce some noise and boiler plate code. Since scopes are often used in Compose UI (like BoxScope, RowScope, etc.), this will likely introduce "scope conflicts" where one of the scopes need to be passed as an explicit parameter instead of a receiver. Since multiple context receivers are still experimental and will likely become stable after Kotlin 2.0 — probably in 2024 (just guessing) — we have no nice solution for this until Kotlin supports it.

@DatL4g what do you think?

[svenjacobs]

As an intermediate step towards Compose Multiplatform compatibility, in this PR I removed the Context dependency from the core artifact and moved it to a new reveal-compat-android artifact. I introduced a RevealOverlayInserter, which declares a strategy of how the overlay is added to the composition. The current backwards compatible strategy is to still use the FullscreenRevealOverlayInserter, which requires an Android Context. Also I added the unbounded modifier variants that take a state argument as mentioned above.

All modules are still Android libraries and use Jetpack Compose, however now it should be much easier to migrate all modules except reveal-compat-android to Compose Multiplatform.

If one would prepare their application for a future version of Reveal with Compose Multiplatform support now, they should just use a single instance of the Reveal composable at the root of the tree and specify InPlaceRevealOverlayInserter for the overlayInserter argument.

[DatL4g]

Alright hit me up if you need help towards the multiplatform migration

[svenjacobs]

Thinking about this a bit more, I noticed a few problems with only having one Reveal composable in an application:

Currently you define the click listener on a revealable item or the overlay via onRevealableClick and onOverlayClick of Reveal. Also you define the overlay content via overlayContent there as well. This is fine when you have multiple Reveal instances, one per "screen" of your application, probably spread over separate modules.

Now when you have only one Reveal in your whole application, you have to deal with all click events and overlay content of our whole application in a single location! Also you have to delegate click events somehow down to the screen where you actually want to handle the click, probably performing some business logic in a ViewModel or so. This is a violation of separation of concerns.

Therefor I think we should separate the composable that draws the overlay and the composable that handles the registration and interaction of revealable items for a single screen. I created a RevealCanvas as a proof of concept. There should only be a single RevealCanvas at the top of the composable tree in your application but there can be many Reveal instances. What do you think about this design @DatL4g?

[DatL4g]

LGTM makes way more sense

[svenjacobs]

Alright. I think this change will be a 2.0 because the behavior has changed significantly and the Multiplatform support will be a 3.0 later.

[svenjacobs]

I'm happy to announce that version 3.0 supports Compose Multiplatform!