Hey I have a compose multiplatform project with android and desktop. Is it normal that I can access ...

# compose

[Jan]

Hey I have a compose multiplatform project with android and desktop. Is it normal that I can access AlertDialog and Dialog in android and desktop specific code but not in the common code?

[jim]

Yes, there are important differences between the APIs on the various paltforms, and there is not yet concensus about what the public API should be for a common-code. For this reason, if you need to invoke Dialogs from common code and have your own ideas about what the "best" behavior would be on each platform, you are encouraged to define your own expact-actuals to provide your desired functionality.

[jim]

Defining expect-actuals is not an unusual operation when targeting multiple platforms.

[Jan]

okay thanks

[Michael Paus]

But in the long run constantly having to write your own expect/actual code for things like this should be avoided as much as possible. It quickly becomes a PITA.

[jim]

Yeah, agree'd. FWIW, we do provide common code for most widgets. There are just a few that don't have a clear MPP API and require a bit of design work. Keep in mind that when we make a decision, any changes/removals become breaking changes for people, so we need to be super cautious/confident about anything we add.

If you have ideas about what would be a good common API, you'd be encouraged to publish a community library that provides a set of common APIs. If the library gains traction, that is a good signal that it is useful and that the designs you choose which become popular strike a good/useful API balance, and could inform the design of any such common widgets. In the mean time, you help the ecosystem by providing a library that is useful for people. The bar for 3rd-party widgets/libraries is much lower than for official compose distribution, so it is a very appropriate way for members of the community to move the ecosystem forward for everyone.

[Michael Paus]

Maybe I misunderstood your point but I was talking about the currently existing API of the standard widgets which are often incompatible between the different platforms and I think that will become a problem in the long run if it isn’t fixed. I do not quite understand how that is related to 3rd-party widgets. My goal is to write as much common code as possible and I thought that this is a general consensus, isn’t it.

[jim]

I'm not sure where the misunderstanding is being introduced, maybe you can elaborate with a question?

Here are some facts:
• We try to provide common code for most widgets.

[jim]

I'm not sure where the misunderstanding is being introduced, maybe you can elaborate with a question? Is there anything I said in my previous message that was contentious? Or any step in the reasoning which doesn't follow from the previous step?

• We provide common API for the vast majority of widgets. Common API is compatible across all platforms.
• For some widgets (like Dialog), there is insufficient consensus/confidence about the common API because of underlying/fundamental platform differences which are difficult to abstract.
• As a 1st-party vendor, we need to be super careful about which APIs we add, because are held to a higher bar in terms of making future changes and breaking people. This means that if there is insufficient consensus/confidence about the common API, we need to error on the side of caution and not publish the common code for that widget (like Dialog).
• 3rd-party vendors are not held to the same high bar, because users can more easily choose which 3rd-party vendors they want to add/remove from their dependencies. This means 3rd-party vendors can freely publish APIs even if there isn't consensus/confidence, because they are held to a lower support and stability standards.
• If a 3rd party vendor provides a common API for a widget (like Dialog), people can use that without implementing their own expect-actuals. This helps the whole ecosystem and can help mitigate the PITA problem you mentioned.
• If a 3rd party vendor provides a common API that becomes popular, that helps us have confidence in the quality of the API, and we can consider releasing a similar common API as an officially supported 1st party stable API.

[jim]

@Michael Paus Maybe the missing step is that 3rd-parties can publish their own common-code version of Dialog by publishing their own expect-actuals which paper over the platform differences in our stable 1st-party platform-specific APIs?

[Michael Paus]

Yes, I misunderstood the role that 3rd-parties are supposed to play here. Otherwise I fully agree with you.