handling failure

[patrickkettner]

Excited to see this!

If you do wish to support something other than ints, I was wondering how you would expect to fallback from an arbitrary emoji to something else?

Would a failed Badge.set() throw?
Would you specify multiple values as an explicit fallback (e.g. Badge.set({rich: '💯', plaintext: 100}) or Badge.set('💔', '零', 0)?

[mgiuca]

I'm not super keen on providing fallbacks; I'd rather developers just give us data and we try and make a best effort attempt to represent that data (otherwise you could see completely different data on different platforms). But I'm certainly open to it.

I don't think it should throw: in all cases, we should be able to satisfy "some sort of badge is being shown" even if the symbol can't be shown exactly right, or at all (the lowest common denominator being Android, which shows just a dot with no symbol). It wouldn't make sense if Android succeeds, showing a dot, while Windows fails because the symbol could not be found.

My idea in the case of UWP — possibly oversimplified — is to do a best effort as shown in the explainer:

String badges: if the string equals a Unicode character corresponding to one of the fixed glyphs, use that glyph (e.g., "✉" -> "newMessage"). Otherwise, fall back to the same as the Flag badge, "attention".

So "💯" just looks like a generic "!", but "✉" and "▶" would be mapped onto the appropriate symbols. It's possible we want to special-case the semantic badges "available", "away", "busy" and "unavailable" (basically, user presence statuses) because they are usually expressed with colour, not with a symbol, and I think that concept generalizes beyond UWP.

We can also use the Unicode database to derive fallbacks, such as normalization, or in the numeric case, just looking at the numeric value. For U+2462 "③", an implementation could use its Numeric_Value property, which is the integer value 3, and set that as a numeric badge rather than the generic fallback. Unfortunately, U+1F4AF "💯" has no associated Numeric_Value (why?) so this wouldn't work in that case. But it's quite an edge case that developers would be setting Unicode characters instead of just numbers, and we would certainly advise against that.

[patrickkettner]

I'm not super keen on providing fallbacks; I'd rather developers just give us data and we try and make a best effort attempt to represent that data (otherwise you could see completely different data on different platforms).

Assuming that platform support was there already, it feels really strange that we have an API that has a set, but no get, or any way to validate that it was used.

I don't think it should throw: in all cases, we should be able to satisfy "some sort of badge is being shown" even if the symbol can't be shown exactly right

Maybe im being pessimistic, but I dont think that is the case. Realistically, very few if any of these platforms will update how badging works in order to satisfy this spec. For it to be successful, it needs to more or less just map over to the way that badging works for them already (as far as potential values go).
The most common feature set here is ints, which could easily and clearly fallback to a solid dot. I honestly think that that is the only thing that should be in the spec, at least for v1.

Once you open up the can of worms of arbitrary grapheme clusters - without fallback, error checks, or value introspection - you are creating an interoperability nightmare. While some things like "✉" and "▶" have straightforward analogues, your earlier example of "💯" mapping to "!" is not obvious. 100 !== attention. It has a number of different connotations that may or may not mean that (it could literally just be a fancy way of saying the int 100, for example). How would one create a predictable fallback for 🕴or 🗽or any other of the hundreds of abstract concepts available inside emoji that have tons of different meanings based on context and culture? Considering the huge differences that exist for different emoji in different implementations, which are done with a full text description and as many pixels as they wish, the idea that all of them could be boiled down to a handful of potential mappings that were created with none of this in mind feels...optimistic. Making it a part of the spec makes it exponentially harder to get this spec to rec.

[mgiuca]

We're not currently supporting anything other than a number or flag (in the current API). We'd like to explore some kind of more advanced status icons (either full Unicode glyphs, or an enum of common statuses) in the future, then we'll re-open this.