[Xposed Framework Modules] Roughy:
Exi for Swiftkey 2.6.5 release

2.6.5 [07.03.2020 ] - Bug fixes( Stable: 7.4.9.11 Beta: 7.5.0.8 )

Changes in 2.6.5

Fixed

- Emoji panel tab icons not displaying on some devices

- Some emoji missing skin tone modifiers

- Some emoji missing triangle indicating they support skin tones

- Insert Newline action not working when triggered via hotkey

The Xposed Installer app does not appear to be refreshing properly and may not list the latest version.

Please download it directly from the Xposed Repository below using a browser.

Download:

Exi for Swiftkey on Xposed module repository

My own mirror of all versions

Notes:

Known issues

If you enable the [Maximize suggestions] option, the replacement expand/collapse button for the toolbar sometimes doesn't work immediately afterwards.

Just restart Swiftkey ( force close ) after you enable it and it will work fine. It will keep working afterwards, just doesn't like to be enabled after Swiftkey is running.

Missing tab icons

While we don't really know why the icons disappeared on some devices, migrating from Support 28.0 to the latest AndroidX library appears to have solved that problem.

Thanks to [MENTION=8704808]MrSourceUnknown[/MENTION] [MENTION=6991637]christantoan[/MENTION] and [MENTION=7830895]MBDdk[/MENTION] for their persistence in helping track down the problem.

For those of you paying attention, I believe I have also sorted out the initial slowness when opening the emoji panel for the first time.

The various components we use from the support/androidx libraries attemp to load certain resources that should be bundled with the apk they are used in.

Since the TabLayout is code we insert into Swiftkey, the resources it wants are either in different locations or don't exist at all.

We can deal with most of these by strategically hooking of our own classes, but in one instances we are forced to hook the global Resources.getLayout() method.

Hook runs -> We compare the ID to the IDs we know will fail -> we call the same method on a different object that has access to those resources.

I'm pretty sure we were getting ourselves stuck in an infinite loop, since we were calling the same method we were hooking.

It looks like EdExposed has implemented some logic to prevent developers from making this particular mistake, so instead of a crash you just get a bit of a delay instead. Nice, but also fixed.

Missing skin tones and triangle indicator

It turns out figuring out what emoji support skin-tone modifiers and where to insert them is a bit more complicated than I remember.

Past me had a bunch of logic in place for figuring all of this out, but it unfortunately relied on a copy-pasted list of base emoji. This was not updated along with the other lists, and thus many new emoji were not considered properly.

However, even with this fixed a few emoji were still missing the little triangle in the corner indicating they support multiple skin tones.

Emoji can be a bit heavy to render, so instead of just chucking them at Android we rendering them in the background and then display the image once it's ready.

If an item doesn't contain any emoji, or is potentially too large for use to cache the rendered bitmap, we fall back to a normal TextView.

For some reason a few items end up using the wrong view type. The assumption had also been made that anything using the normal TextViews would always be normal text and thus not support skin tone modifiers, so the indicator was never implemented.

I should probably figure out why some of them are being classified incorrectly, but since it only affects a handful of items I've just implemented the same indicator for the normal TextView items as well.

Insert Newline with hotkey

I remember very vividly testing this. I have no idea how I managed to do this and have it break afterwards, especially given what the cause ended up being.

Most "text actions" are simple actions that do not take any additional input; they just do a thing.

The "insert text" action available via the quick menu would also need to accept a string containing the text to insert.

So now we have two methods.

The first one accepts a TextAction and a String. If the action is Insert Text and the String is not null we perform that action, otherwise pass through to the second method.

The second method only accepts a TextAction, and is responsible for handling all the other actions.

Instead of adding "insert newline" to the second method, I added it to the first one.

Because surely I updated the rest of the code to only use the first method, and made the second one private so it couldn't be used accidentally.

Right?

RIGHT?!

I did not.

When executing a hotkey action it was calling the second method instead of the first, which predictably did nothing because the action was not implemented there. Fixed.

(ノﾟーﾟ)ノ┻┻