I want to create an app where users can exchange messages. The app will be for both IOS and Android. I know IOS supports Emoticons but android does not. The problem I am facing is if an ios user wants to talk to an ios user emoticons will be displayed, but if an ios user talks to an android user the emoticons will not show up. I had an idea to create a single image of many emoticons and then when an android user clicks on a part of the image it would get the x, y coordinated and then send use that image. This would work because I would map all these android custom emoticons to an ios emoticon. The problem is what if IOS changes its emoticons during an update, I would need to create all new emoticons and remap them, as well users who do not update the app after my changes will not receive the benefit and this would cause inconsistency. Is there any easier approach to this type of problem?
Emoticons are unicode characters so they won't change. Doesn't Android support the unicode plane containing the emoticon characters?
See the Wikipedia page, they are basically U+1F60F through U+1F64F.
Related
I am developing android chat application and I want to add emoji button that if the user clicks on it open a page that contains all emojis (similar to Whatsapp Emoji page or telegram Emoji page), is there a library or JAR that provide all emojis ?? or Should I Implement them hard-coded in my application?
This page is what I want to implement:
emojicon can be used but is discontinued, so, for now, this emojiCompat can be used which is latest and this is from google so no need to worry about any problems.. :)
I am currently making a messenger app for android, and I just added emoticons. Now, I looked at the WhatsApp UI and I realized that they use the iOS emoticons for everything (even the ActionBar) and I was wondering how they had done this.
Is it possible to change Android's emoji texture atlas just for my app or something like that, and if so, where can I get these iOS emoticons and how do I implement that? Or do I have to write my own TextView / EditText / ... and my own emoji keyboard for it to look like WhatsApp's?
Thanks
Edit: I found out that there is an "Apple Color Emoji.ttf" without license that supports these emojis. Can I use this on android?
I'm using Delphi 10.1 Berlin for developing mobile application and when I have used the Edit box in android, I'm not getting the text movable icon in Edit box. How can I enable this to move the text in edit box for Android mobile and for iOs mobile app. With this I have attached the snap shot of the sample which I required. And also Copy, Paste, Select All options are also not displaying in edit Box. Please help me to resolve this issue. And thanks in advance.
FireMonkey controls are not Android controls so do not get the standard Android features of the equivalent controls. You will need to either find a 3rd party control that implements an equivalent capability or implement it yourself.
Otherwise you will have to wait until Embarcadero get around to supporting native controls on Android. This is on the roadmap for 2018, but bear in mind that this is no guarantee that it will actually be delivered in that timeframe.
I want to be able to send messages between android and ios devices with the use of emojis.
I know the new android 4.4 supports emoji now but I want to support older devices (2.1 and up).
How do apps like whatsapp allow emojis to be written and viewed even though it is not supported? The only way I could think to accomplish this task is to create custom emojis by creating an image of many emojis and then using the x,y coordinates to get which emoji was selected. The issues with this could be copyright and then when new emojis come out I will always have to update the image and if a user doesn't download the new image they will still have the old emojis and won't be able to view the new ones.
So is there another way of doing this to allow ios emojis to be sent to android and vice versa?
Your custom approach could work. Just add another layer of abstraction -- download the emoji from a central server. Cache it locally. Periodically check to see if there is a new version, and download it. Because it'll remain really simple, old versions of the app will still be able to download and use new emoji whenever you update it.
That is a technical solution to your problem that'll support both platforms. Any copyright concerns are kind of off topic, and very specific to the set of emoji you end up deciding to use.
A large set of emoji have been added to the Unicode standard. So, they're basically just characters you could show with a font. For modern devices, a default font (with new OpenType color support) will be used to show emoji. For older devices, you could simply create your own font or use open source emoji designs and show them in old school black 'n white.
What options are available for handling text input on Android using Adobe AIR? What are the advantages and drawbacks to each option?
The current options available to AIR developers on Android for handling text input are:
StageText native text (default)
TextInputSkin (spark.skins.mobile)
TextInputSkin (spark.skins.spark)
StageText + TextInputSkin (spark.skins.mobile) hybrid
StageWebView (explained below)
Native view
I'll discuss some of the advantages and drawbacks of each approach below. If I've missed anything (or if you have other ideas that I haven't thought about) please let me know!
StageText
Handles input properly in all cases? Yes
Displays properly in all cases? No
Vertical alignment problems when scrolling.
By default, TextInputs running on mobile devices make use of StageText (native text) for input. StageText offers several advantages, as Adobe outlines in their online documentation, including auto-correct, customization of software keyboards, etc.
The biggest disadvantage to using StageText is described in bugbase ticket 3302441. StageText's positioning becomes broken when a user scrolls. Textfields appear outside of their respective TextInputs or, even worse, inside of other TextInputs. The only work-around for this defect is to design a UI that does not allow scrolling. Obviously this can be very difficult for mobile phones and phablets.
TextInputSkin (spark.skins.mobile)
Handles input properly in all cases? Yes
Displays properly in all cases? No
Inserts random characters on certain Android versions (ex. Nook running Android 2.3).
This component uses StyleableTextField internally. It is optimized for mobile use.
This component inserts additional, arbitrary characters into the TextInput as a user is typing on certain Android versions (ex. Nook running Android 2.3, Kindle HD running Android 4.0). See bugbase ticket 3547601.
If your application is only localized into English (or latin-based languages) and does not need to support older Android versions then this component may work well for you.
TextInputSkin (spark.skins.spark)
Handles input properly in all cases? No
Does not accept certain double-byte characters (ex. Korean).
Does not accept any input on certain devices (ex. Samsung Galaxy 10.1 running Android 4.0).
Displays properly in all cases? Yes
This component uses RichEditableText internally. It is not optimized for mobile use. Beyond that it demonstrates several defects (listed above) that make it unsuitable for use.
This component does not properly handle certain double-byte characters (in languages such as Korean). These characters seem to be inserted into the TextInput (the cursor progresses, visibly) but no text is rendered to the user. (It is possible that this issue could be resolved using an embedded font.) See bugbase ticket 3547591.
While testing the 3rd item mentioned above (input not being accepted on certain devices) an interesting thing was observed. After typing a couple of characters, if a user switches focus to a TextInput that uses the default StageText, at least some of the missing characters will be automatically inserted into the new field.
StageText + TextInputSkin (spark.skins.mobile) hybrid
Handles input properly in all cases? Yes
Displays properly in all cases? No
Sometimes the software keyboard's "show" animation is triggered twice in a row, creating an undesirable visual effect.
Sometimes focus handling is difficult and can result in the StageText-TextInput showing without a software keyboard until the learner touches it again.
This approach combines the benefits of StageText with the scrolling functionality of TextInputSkin (spark.skins.mobile). The general idea is to create 1 TextInput that uses StageText and assign it to a fixed location on the screen. This TextInput should be hidden by default. Other TextInputs (using TextInputSkin) can be created and positioned as needed on the stage. When one of these TextInputs gains focus, the hidden surrogate TextInput should be shown and focus should be shifted to it. As text is entered into the surrogate, a change-handler should copy the text to the user-selected TextInput. When the user tabs or clicks to set focus elsewhere the surrogate TextInput should be hidden again.
I can provide a code example of this if desired. There are a couple of drawbacks to this approach (mentioned above) but it's possible that they are the fault of my implementation.
StageWebView
Handles input properly in all cases?
Yes/No
Depending on the value of <renderMode> and <fullscreen> this component may work properly for you.
Is a little tricky to get working.
Displays properly in all cases? Yes
This approach involves displaying a simple HTML page inside of your AIR application using StageWebView. The HTML page contains <input type="text"> objects which make use of Android's native text and software keyboard. Communicating between the HTML page and the parent AIR app though is a bit tricky, since StageWebView does not support Flash-to-JavaScript communication in the same was as ExternalInterface.
Communicating from JavaScript to Flash
Communicating from JavaScript (or HTML) to ActionScript is difficult because StageWebView does not allow ActionScript to add callbacks. StageWebViewBridge offers this functionality has not been updated in some time and when I tried it, I was unable to get content to display using Flex 4.6 and AIR 3.5.
There are still ways to convey information to ActionScript using LocationChangeEvent. The idea behind this is for the AIR app to listen to location changing events and then parse the incoming event.location for information. For simple links this works easily but things get more complicated when it comes to forms. I tried the following approaches before settling on one:
Add an onclick handler to the form-submit button that sets window.location.href to a string containing URL-encoded key/value pairs. This approach does not work for reasons described in bugbase ticket 3362483.
Add an onclick handler to the form-submit button that dynamically modifies the form-target to contain URL-encoded key/value pairs and then submits the form. This approach does not work because LocationChangeEvents are not dispatched when form.submit() is called.
Add onchange handlers to <input type="text"> tags and modify the href attribute of a "submit" link to contain URL-encoded key/value pairs. When this link is clicked, your ActionScript LocationChangeEvent handler will be invoked and you can parse the incoming data using the URLVariables class.
Communicating from Flash to JavaScript
To communicate with JavaScript (call methods, pass parameters) use the StageWebView's loadURL method like this:
_stageWebView.loadURL( 'javascript:yourMethodName( "A string", true )' );
Unfortunately the loadURL method has a void return type (meaning that you can't retrieve data this way).
Other difficulties
The biggest drawback to this approach is described in bugbase ticket 3535948. If your AIR application uses <renderMode>direct</renderMode> or <fullscreen>true</fullscreen> then text input via StageWebView will be unusable. (Response will be sluggish. Users will be unable to select or delete characters.) If your app does not require either of those flags then this route may work well for you.
One workaround for the fullscreen limitation is to disable fullscreen mode only when your application needs to make use of a StageWebView. This can be done with StageDisplayState like this:
// Turn off fullscreen
stage.displayState = StageDisplayState.NORMAL;
// Turn on fullscreen
stage.displayState = StageDisplayState.FULL_SCREEN_INTERACTIVE;
Native View
Handles input properly in all cases? Yes
Displays properly in all cases? Yes
The last remaining option (that I'm aware of) is to write a native extension that displays text-inputs and returns data to your AIR application. This is probably the safest (although most disappointing) option of the ones discussed in this thread.
We might have a solution that works atleast for our scenarios : http://blog.flexicious.com/post/Scrolling-Issues-With-TextInput-for-Flex-Air-Mobile-Native-StageText.aspx