I'm building a custom soft keyboard for android and would like to add a layout to include the emoji keys similar to what the default android keyboard (AOSP) is doing. I've searched around but it seems that most people are trying to display custom emoji from images. I'm looking to show the built-in icons that comes with Android (as shown below):
It seems that I should be able to use the Unicode characters to send images from the keyboard, but my first attempt seems to generate only the older versions of the emojis. How do I support the latest emoji the phone can handle? Also, how do I display the emojis in my keyboard as in the image above?
Emoticons-Keyboard
1) instead emitos ,Iam replacing the ImageView containing an asset with a TextView containing a Unicode sequence.
After cross referencing Supported Unicode Sequences as well as the Visual Unicode Database I realized that **u1F601** was a 32 bit Unicode representation, and the 16bit representation can be set like :
EditText messageInput = (EditText) findViewById(R.id.message_input);
messageInput.getText().append("\ud83d\ude01");
2) http://android.appstorm.net/how-to/customization/how-to-use-emojis-on-your-android-device/
Go to https://en.m.wikipedia.org/wiki/Emoji to see which emojis your device supports with unicode.
As you know which emoji is shown depends on the font you use, so to get the latest emojis use NotoColorEmoji.ttf as font for your app.
Thanks for all the suggestions. What I got to work for showing an emoji layout in my custom keyboard was the following:
In the .xml layout file, for each emoji you want to add, create a line like this: <Key android:codes="0x1F602" android:keyLabel="\ud83d\ude02"/>
When committing the key, use: getCurrentInputConnection().commitText(String.valueOf(Character.toChars(primaryCode)), 1);
Emoticon support doesn't work like you think it does. There is no universal set of emojis supported by all android devices, and the emojis your device does support may show differently on different devices. Emojis are done on Android in 1 of 2 ways.
1)Unicode. What emojis the device supports then depends on the font the app is using. You just send the unicode just like you would normal text, and you'd display it on your keyboard by displaying that character. For this method, you guess on which ones the phone will support. And its a total guess, because it depends on what font the app is using.
2)Image spans. You embed an ImageSpannable into the text you send via commitText. The advantage of this is you're sure you have an image (you need to include the images with your app). The disadvantage is it can't be sent to another device, saved, and may not work in all apps (they may not be displaying spannable objects).
Related
I've been trying to make use of the Unicode symbols for astrology in products for both Apple and iOS. I'm getting inconsistent results, as shown here:
Most of these are coming out as I like, but for some reason the Taurus symbol is appearing one way on the first line, following the Moon, and a very different way, with the Emoji-like purple button, when it follows Mars. These results are consistent for different symbols and across Apple hardware; here's a screen capture from my phone showing the same problem with some other signs - Scorpio comes out all right, but Libra and Cancer are buttons.
The strings are extremely straightforward; "Moon Taurus" in the first image is \u263D for Moon, \u2649 for Taurus, basically assembled as [NSString stringWithFormat:#"%#%#", #"\u263D", #"\u2649"]. The "Mars Taurus" image is the same, only with \u2642 for Mars. The string formatting is identical in the different cells of the OSX table, and in the iOS AttributedString.
Any idea what makes these symbols appear one way sometimes, and another way other times?
Unicode uses variation sequences to select between different renderings for certain code points—listed in the StandardizedVariants.txt file. In your case, the astrological symbols have both "text style" and "emoji style" variants that are selected between by a U+FEOE (text style) or U+FE0F (emoji style) following the code point:
U+2650 U+FE0E: ♐︎
U+2650 U+FE0F: ♐️
Note that correct interpretation of the variation selector depends on support from both the application/framework and the fonts being used. On Chrome (42) there doesn't appear to be any difference between my examples above, but on Safari (8) they are distinct.
I want to implement an android emoji keyboard just using emoji unicode array, without any extra res.
So for the emoji unicode character, I need to get the drawable from android system, if the system doesn't support the charactor, I just ignore this character.
After some basic research,
emojicon, https://github.com/rockerhieu/emojicon
emojicon, https://github.com/ankushsachdeva/emojicon
These implements all use self made resources.
use TextView setText, tv.setText("\u263A"); TextView can show the resource, but how can I get the resource?
Here's the problem- the system doesn't determine what characters can be displayed. The font does. The font needs to define how to draw every character it will display. That's why you'll see boxes or ? for missing characters- that's the font's default render. There is no method on Android to test if a character will display in a given font (although it would be really nice). And since there's no way to know what font the EditText is using, there's no way to know if a given character is supported. Your best bet is to limit yourself to characters defined in the default Android System font. But even then you're assuming the OEM didn't use a different default font, the user hasn't overridden it, and the app hasn't overridden it. Basically, you're forced to guess and hope.
Special characters such as
📂 ★ ✉
Are being replaced with images in the Android OS. As you can see, this seems to affect native TextViews (see screenshot).
My problem is they are also affecting the HTML I am loading through my app via WebView. The main problem is stars of different colors are all showing up as the same gray star. And other than that, you can imagine the visual inconsistency problems that arise.
If you load this page on Chrome for Android, the characters don't load at all. But if you copy the question and paste it into a plain text program such as ColorNote, you will see what I'm experiencing.
Is there a way to get my own WebView or even my entire app to use the font-family, rather than an image?
A wild guess, since I've only heard about this happening on iOS now.
How can I disable the unicode black telephone from being rendered as a red phone on iOS Mail app?
I need help getting a normal looking unicode down arrow in a UILabel like this ⬇
Unicode has this nifty thing that's called "Variation selectors", which can be used, among others, to select a variant shape of a letter, or to select whether a glyph is to be rendered as a black-and-white standard glyph, or as a colourful picture.
This variants are characters \uFE00 to \uFE0F. In case of emoji, \uFE0E means "render the previous character as a black-and-white glyph", and \uFE0F means "try to draw the previous character as a colourful picture".
So in your case, add \uFE0E after the character.
I would like to display special characters such as: ṁ ṭ m ē. In case they don't display here as well, this is how the four characters should look like:
In Android, these will display in squares. For other scripts, I am able to come over this problem with using a different font. But in this case setting the font (TextView.setTypeFace) will not solve this issue. These characters display correctly in for example OpenOffice (using Arial or Courier New), but inside Android it doesn't even when using the same fonts).
I also tried having the string saved as a unicode encoded string (e.g. in strings.xml: \u1E41 \u1E6D) getting the same result (in the logs they appear as they should). Any ideas?
If these characters are representable in Unicode, then you should be able to use Html.fromHtml() to get the glyph into a TextView, e.g.
textView.setText(Html.fromHtml("Ӓ"), TextView.BufferType.SPANNABLE);
It was really only a font issue. It was just hard to find a font that supports all characters I need.
Seeing that Google Translate has no problems with transliteration characters motivated me to make a more thorough search for fonts. Below is a list of useful fonts for this purpose:
http://guindo.pntic.mec.es/jmag0042/alphaeng.html (extensive but non-free)
http://users.teilar.gr/~g1951d/
http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=FontDownloads
http://www.mufi.info/fonts/
I want to be able to run a "Hello World" application on my android emulator in hebrew
How can I do that? is it supported?
thanks
Though android does not have complete support for Hebrew if you are just displaying text, then it turns out to be pretty easy to do.
First you want to add a Hebrew font to your app. For this you simply put a true type font file (with Hebrew characters) in your assets directory. Then you load the font and use it on your view. For any view that inherits from TextView (which includes just about any view that displays text), you do the following:
AssetManager assets = getAssets();
Typeface font = Typeface.createFromAsset(assets, "hebrewfont.ttf");
view.setTypeface(font);
This will cause Hebrew characters to be visible. You may need to use the RTL mode character (\u200F) to force your text to display in the correct order. You may also need to set the gravity to right in order to right align the text.
I've found no way to get the scrollbar to appear on the left side. :( Cantilation marks to however display properly starting in android 2.2. I've tested Nequdot in all versions since 1.5, and they work as well. You may want to use some of the precombined characters, such as shuruq (\ufb35) instead of vav+dagesh (\u05d5\u05bc), as this isn't necessarily handled properly.
I have had good results with the DejaVu font, which is freely available.
Although this has been asked a long time ago, there is a native Hebrew support in later versions. The avd with API15 (Android 4.0.3) can display Hebrew nicely out of the box. I'm not sure which version is the earliest with this capability.