Investigate how to bring the library size own about emoji HOT 22 CLOSED

you can also use Telegram app approach they save single image of all the emojis and extract emojis from it

from emoji.

@vanniktech so we could take the svg's from e.g. http://emojione.com/developers and convert them to vector drawables. Conversion is implemented with http://inloop.github.io/svg2android. This would reduce apk size and make the emojis scalable without loss of quality. We could introduce a new github repo that is automatically populated with vector drawable versions of svg emojis. What do your think?

Another approach would be to use a emoji font file. But I feel this would break your entire api

from emoji.

I think that downloading the svgs and converting them to vector drawable could be implemented into the JavaScript generator module.

from emoji.

Another option would be to generate one sprite PNG with all the emojis per category (apple, google, emojione) via the script and then extract the precise emoji within the library from the PNG.

from emoji.

How about using the Emoji support library for the Google variant (or a separate Google variant)? It doesn't come with reasonable keyboard support and the current Google impl seems to duplicate the images in the case where one is also using the support library...?

from emoji.

Can you take a look at my fork if this is heading in the right direction?
https://github.com/stefanhaustein/Emoji-1/tree/master/emoji-compat

from emoji.

Looks pretty cool & interesting while glancing over it.

• I'd rename it to emoji-google-compat.
• It still needs to be wired together with the google support libraries or did I miss it?
• I saw that you ended up extending the Emoji class maybe a simple interface would be nice here so that you won't have to call those 4 super constructors.
• We could probably generate the Categories as well since we do that already for the normal google provider so adjusting those is not gonna be a lot of work.

Definitely thanks for starting to work on this.

from emoji.

It's already working (= wired up), but some emoji are not rendered as expected and the size/position might need some fine tuning. The missing ones might be the ones that have a "text style" alternative, haven't looked into this yet, might need an extra unicode prefix. Also, I am doing the part of the emoji support lib setup that involves configuration in the app, not sure if this is what we want in the end, but I don't see an elegant alternative -- might be ok if we assume users are likely to be emoji support lib users already?

I think I'd prefer to keep an Emoji base class (for variant management etc -- opposed to an interface), but perhaps make it abstract and add "ResEmoji" or similar? Can you point me to the generator code / data for the google case?

It would be nice to route Span generation through the provider, so we won't have a span wrapped in a drawable wrapped in a span, but that's just an optimization.

Renaming to GoogleCompat sounds good to me. We could als replace Google, but it requires API 19+ and some "outside" setup, so it's probably better to keep them in parallel, at least for a while?

For optimizing the other cases, I'd probably create a sprite sheet per category or by code point range (otherwise it will get too big) and then use some kind of "SpriteDrawable", but I probably won't be able to "drive" this.

from emoji.

Also, I am doing the part of the emoji support lib setup that involves configuration in the app, not sure if this is what we want in the end, but I don't see an elegant alternative -- might be ok if we assume users are likely to be emoji support lib users already?

I'm not an google emoji support lib user. I'd say that we can fine tune that still at the end.

I think I'd prefer to keep an Emoji base class (for variant management etc -- opposed to an interface), but perhaps make it abstract and add "ResEmoji" or similar?

In general the Emoji constructors could be refactored. We might as well just leave it for now and see how to optimize that in the future.

Can you point me to the generator code / data for the google case?

It's in the repo.

It would be nice to route Span generation through the provider, so we won't have a span wrapped in a drawable wrapped in a span, but that's just an optimization.

Sounds good.

Renaming to GoogleCompat sounds good to me. We could als replace Google, but it requires API 19+ and some "outside" setup, so it's probably better to keep them in parallel, at least for a while?

Yup let's keep both of them for a good while. The user can choose which one he/she will take.

For optimizing the other cases, I'd probably create a sprite sheet per category or by code point range (otherwise it will get too big) and then use some kind of "SpriteDrawable", but I probably won't be able to "drive" this.

No worries. Little by little.

from emoji.

Concerning the other Emoji sets: Most seem to provide a TTF font, perhaps that would be a generic option? Would require API level 19+ though (variants might require even more recent Android versions). SVGs seem to be no longer available freely for EmojiOne 3.x and would require conversion to Android Vectror Drawables. Sprite sheets would work with lower Android versions but don't scale well and probably require more metadata / generator overhead.

from emoji.

I think API level 19+ is not an option (yet). According to https://developer.android.com/about/dashboards/index.html (29.08.2017) 9% still use older versions...

I tried SVGs converted to Android vectors with EmojiOne once (when they were still free) and it did not provide that big of an size improvement sadly.

I am in favor of generating a large sprite sheet (would require testing if one for each category (Telegram does that) or one for all), but have not been able to do so yet.

from emoji.

I'd start with a single sheet and relatively small images (IIRC I had some troubles loading a very large single image), then add complexity as needed. Should be relatively straightforward with some kind of nodejs canvas API, although for a Java project Java ImageIO might be more convenient O:)

from emoji.

The images we provide are already rather small given that the smartphones are getting bigger & bigger and have more and more pixels. I also already once did a big sprite sheet with the normal resolution and it's quite big. Meaning it's 12.1MB and 4606x2448 pixels.

Did the sprite running montage emoji*.png -tile 64x34 -geometry +0+0 -background transparent out.png within one of the drawables folders.

from emoji.

So if spriting doesn't help that much and doesn't scale and by the time this is implemented the number of devices not supporting ttf might be below 9%, perhaps it makes more sense to focus on ttf-based providers, addressing the resolution problem? They could be added as emoji-xyz-ttf alternatives initially (similar to the GoogleCompat case), so users would have a choice between backwards compatibility and better emoji?

from emoji.

That sounds like a solid plan yes.

from emoji.

Concerning library size and performance in general, is there any particular reason why the generated initialization data is based on long array literals, which are converted to strings at runtime (opposed to generating strings directly)? Individual longs might have less storage overheads than strings, but for long arrays I'd be quite surprised if it is not the other way around...

from emoji.

It was always like that from the beginning. Most of the emojis are single unicode though aren't they?

from emoji.

I'll close this now as we can use the google emoji appcompat system for providing the emojis - without the need to bundle the images in the apk - and also the other variants have been optimized in #252.

Thanks to everyone 👍

from emoji.

I'll close this now as we can use the google emoji appcompat system for providing the emojis - without the need to bundle the images in the apk.

• Is that means your great library will be deprecated or you will release new version that depend on emoji combat system without the need of to package emoji inside apk.

from emoji.

It won't be deprecated. You can just choose which provider you want. For now you have to use the snapshots when wanting to use the emoji combat system.

from emoji.

Is there any document for how to choose app compact emoji as provider.? so I can use snapshots

from emoji.

The demo app believe, in case it isn't feel free to make a PR for that.

from emoji.