Are there android emojis

Support Modern Emoji

Emojis! They are everywhere! Since their release they have become a huge part of our language. They are a way to efficiently express yourself in a way that words cannot. While you may not think a banking app, fitness app or meal delivery app would need to support emojis they do! Emojis have transcended texting or messenger apps and now are a common part of our language. If your app has any text views then it should support emojis, read on to see why. 🥳

So what’s the problem? 😖

When your app doesn’t handle emojis, older versions of Android may not know how to render them. Most commonly, what will appear is a blank box, which we refer to as a tofu. This can cause confusion in cases where an emoji is displayed in an app that is not correctly set up to handle emojis. When a user adds a 🐶 emoji to a task in a todo app in an EditText, the user would be very confused to see a tofu instead of a dog, and they’d think your app has a bug.

To make emoji more interesting, in many cases, an emoji will be a combination of other emojis. For example, 💪🏾 is a combination of 💪 and 🟫.

If you try to type the flexing arm and it displays an arm and a color box it is not only an issue about confusion but also misrepresentation around various skin tones which contributes to a poor experience in your app.

As language changes, so do emojis. New emojis are added by Unicode yearly as part of the new Android release, but unfortunately, there’s no way to ship new emoji fonts to old versions of Android prior to S.

So what’s the solution?

The emoji2 library is integrated into AppCompat 1.4 meaning all you have to do is update to AppCompat1.4 and you can display modern emojis on API 19 and higher! All TextViews in AppCompat work by default because we added automatic configuration, so it can configure itself to load the correct emoji font. If needed, you can disable it for a specific text view in XML or code.

Let’s take a look at how these emojis render in AppCompat 1.3 vs AppCompat 1.4.

In simple terms, a graphical emoji is really just a 🖼️ that displays inside text. It is represented by a unicode codepoint(s), just like the letter ‘e’, but unicode specified that when these codepoint(s) display they should show an emoji-image instead of an ‘e’. The picture is really just a png in a font file (you can find the emoji font we make for Android here). Normally you might think of fonts as containing the character ‘e’, which is defined with strokes, but fonts are actually pretty powerful and can contain bitmaps, pngs, svgs, or even full programs — someone even made a game entirely in a font 🤯.

When new emojis are added by Unicode, a new emoji requires a new glyph, or printable character, be added to the emoji font — and updating tables so the font knows which codepoint(s) display this glyph.

When the platform gets an input string, EmojiCompat.process needs to transform it to have an EmojiSpan which basically tells Android to not render a portion of the string. The EmojiSpan understands how to render the emoji.

EmojiCompat.process iterates over the string and finds all emoji, adding EmojiSpan for any emojis. An EmojiSpan basically tells Android to not render a portion of the string, and instead call the draw method. The EmojiCompat.process uses a trie to find all substrings that match a known emoji.

A trie is a fun data structure that is really good at looking words (or emojis) up in a dictionary efficiently. EmojiCompat iterates through the string, checking each codepoint against the trie. Whenever it finds a complete emoji in the trie, it checks to see if the platform doesn’t know how to render that emoji and adds an EmojiSpan. You can think of EmojiCompat as using a dictionary to find emoji in a string, and the definition is how to render the emoji using an EmojiSpan.

Now that we know how EmojiCompat retrieves an emoji, let’s talk about how to render the string “Hi.”

A string is just a set of codepoints which are numbers that represent glyphs like the letter ‘m’ or the number ‘1’. Emojis are also assigned codepoints — you can see them all on Emojipedia, including the waving hand emoji that we are rendering now.

Lastly, the draw function is called and paints the emoji directly from the font file and there you have it — your string! 🥳🥳🥳

In closing…

Emojis are not only great, but also an essential part of our language. To give your users the best experience including modern emojis — use AppCompat 1.4.

Take a look at the new Play policy around emoji here.

Источник

Exploring the Android EmojiCompat Library

Emojis are everywhere — it’s hard to visit a website, app or have a conversation without emojis popping up somewhere along the line 😀 Because of this, it’s important that all users who are involved in these kind of activities are able to see the emojis being used. If not, textual content can be misunderstood or misinterpreted. Luckily for us on Android, Google have released a new library known as the EmojiCompat library to help solve this issue and bring a better experience for both ends of the conversation.

In a nutshell, the aim of the EmojiCompat library is to try and ensure that older devices (with older OS versions) are kept up to date with the latest emojis. It’s quite common for older OS versions to be unable to display certain Emojis because of newer versions of Emojis are not backwards compatible. This can result in these kind of situations occurring:

Not great right? How will the receiver of that message know what they’re to buy on the way home? And this is just one example — the same problems can occur in other situations, causing confusion and annoyance for the user.

With EmojiCompat, we get something more like this:

Now I know what to buy on the way home and we won’t have to go 🥑-less when it comes to dinner.

The EmojiCompat library

The EmojiCompat library contains a bunch of useful components which we can utilise to ensure this consistent experience across devices. These include the EmojiTextView, EmojiEditText and EmojiButton — which when used to display unsupported emojis, in comparison to a regular textview, look like so:

But how does this work? Well, the library takes the given Unicode from the given CharSequence that is representing an Emoji and if the Emoji isn’t one that is recognised on the given device, then the library replaces it with EmojiSpan instances. Once this is all complete, EmojiCompat renders the required Glyphs into view.

An EmojiSpan is a new class available as of API 26.0.0 (it’s an extension of the ReplacementSpan class which you may have come across before). When an Emoji needs to be replaced into a CharSequence, a new instance is instantiated from this base class and added to to sequence — this is the process which ensures that the device will display the given Emoji.

Components of the EmojiCompat library

It’s clear that there’s a little bit going on behind the scenes for this to all work. When this process takes place, there are several different library components involved in the conversion of unrecognisable characters to the display of Emoji glyphs:

• The Widgets component consists of the view components that we have available to use in our application — this includes the EmojiEditText, EmojiTextView and EmojiButton. We’ll get more into these in a bit, but essentially they are default implementations that we can use to display EmojiCompat Glyphs in our application.
• The EmojiCompat component is responsible for handling all communication that takes place between the application and external entities. And in turn with this, the Config component is used to set configuration details for our instantiated EmojiCompat instance.

There are several different configuration properties that we can set for this Config component:

setReplaceAll — The default behaviour for EmojiCompat is to only replace emojis that it can render. We can use this configuration to replace all emojis it finds with EmojiSpan instances.

setEmojiSpanIndicatorEnabled — This allows you to set an indicator to display whether or not an Emoji has been replaced by an EmojiSpan — if set to true then a background will be drawn for the EmojiSpan.

setEmojiSpanIndicatorColor — This sets the color to be used for indicating an EmojiSpan. If this value sin’t set then the Color.GREEN property is used by default.

registerInitCallback — This callback can be used to receive events within our application regarding the state of the EmojiCompat initialisation

unregisterInitCallback — this can be used to remove the previously set callback from the Config instance

Creating an instance of this Config class just requires instantiating the relevant Config class (here we are using the FontRequestEmojiCompatConfig class, if you are using bundled fonts then this would be the BundledEmojiCompatConfig class) and using the provided methods from the Emoji.Compat class that it extends to set these given properties.

Once we have done so, we can then set the configuration for our EmojiCompat instance during initialisation:

• The EmojiSpan class is the subclass of the ReplacementSpan which replaces the relevant character sequences in our application and renders the required glyphs to display our emojis in our app.
• Finally, the EmojiCompat component uses a font in-order to display the required emojis. The font which is used is a slightly modified version of the Android Emoji Font that allows the library to provide backward compatibility for older OS versions.

EmojiCompat Fonts

When it comes to the fonts used for our EmojiCompat instance, there are two ways in which EmojiCompat can be configured, this can be done by using either:

• Bundled fonts — Fonts are bundled into the APK
• Downloadable fonts — Fonts are downloaded at runtime as required

Bundled Fonts

If we wish to have the required font bundled with our APK, then we need to add the dependancy to our app-level build.gradle file that includes the font resource required for the EmojiCompat functionality:

Next, we simply just configure our EmojiCompat instance with an instance of the BundledEmojiCompatConfig class which handles the loading of the font metadata for us from the bundled resources.

Downloadable Fonts

Using Downloadable fonts means that the fonts we need are downloaded at runtime. You can read more about Downloadable Fonts here, but this approach essentially allows us to reduce our APK size and allow multiple APKs access to these downloaded font resources. All devices running API version 14 above that are using version 26.0.0 of the support library have access to the Downloadable fonts api.

To begin with, we need to add the dependancy to our app-level build.gradle file — this dependency is different from the previous as it does not contain the bundled font:

We next need to initialise EmojiCompat with a font configuration — here, we create an instance of the FontRequest and pass in the required parameters for its initialisation. There is more information on this process and the parameters used here.

Now that we have this FontRequest instance, we can go ahead and pass it in as a parameter when creating our EmojiCompat Config instance. This is letting our configuration know the details about what font to use and where it is accessible from.

EmojiCompat View Components

Once we’ve configured our fonts, we just simply need to switch out the views that we’re using in our layouts for the corresponding EmojiCompat-View. The EmojiCompat library provides three widgets for us — the EmojiTextView, EmojiEditText and EmojiButton:

When using these, the views will automatically handle the display of the emojis for us — that means it’s just a simple case of setting the text of the view and the rest is handled for us! However, if for whatever reason you can’t or don’t want to use one of the above views then it is still possible to use EmojiCompat with standard views — we just have to handle the processing manually:

To begin with, we fetch our EmojiCompat instance and use the registerInitCallback() method to register a callback for when our EmojiCompat instance is ready to use. Once ready, we can use this instance of our EmojiCompat class to manually call its process() method. This method checks the given CharSequence for any Emoji instances and adds the required EmojiSpans if any are found. This is essentially the same process that goes on behind the scenes for the EmojiCompat-Views.

Note: It’s important to remember to make use of the unregisterInitCallback() method when you are finished with the listener.

App Compat Support

If you’re using classes from AppCompat then good news, EmojiCompat is also supported in these setups too! You’ll have to add a different dependancy for this:

Once you’ve added the dependancy, you’ll have access to the AppCompat versions of the Emoji-View classes that we previously looked at.

I’m not using Widgets though!

Even if you’re not using widgets, you can still use the EmojiCompat library to convert CharSequences to fully support Emojis. Because the process() method returns a CharSequence with the conversion result, we can simply use it like so:

At this point we have a CharSequence with our passed in text now containing our EmojiCompat-ified content.

As you can see, add backward compatibility for emojis in your applications isn’t much of a task to carry out. The benefits from doing so includes a more consistent experience for your user and a better overall experience from both parties at each end of the conversation.

Are you using EmojiCompat already? Have any questions or suggestions? Leave a response below or drop me a tweet 🙂

Источник