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

2.0.3 [ 12.02.2018 ] - Theme/Incog intents, EdXposed shift fix ( Stable: 7.2.2.32, Beta: 7.2.3.20 )

Changes in 2.0.3

Fixed

- Shift key not working when used with EDxPosed

- Swipe selection cursor jumping when moving near line breaks

Added

- Intent to set theme, incognito, and vibrate

- Option to remove Bing url redirect from gifs

Changed

- Updated translations ( Polish, Russian )

- Remove vibrate quick pref ( moved to intent )

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

Notes:

Intents [MENTION=5694745]BaschtlWaschtl[/MENTION]

I already had an intent receiver set up in the system process to handle updating hardware key remapping ( a feature I'm sure nobody uses).

It was a simple copy-paste job to insert one into the Swiftkey keyboard service as well.

I imagine most of you will be using tasker, where you want to send an intent with the package set to EITHER

com.touchtype.swiftkey or com.touchtype.swiftkey.beta

depending on which version of Swiftkey you are using.

The follow intents are available:

com.mayulive.swiftkeyexi.INCOGNITO_ON

com.mayulive.swiftkeyexi.INCOGNITO_OFF

com.mayulive.swiftkeyexi.USE_SYSTEM_VIBRATE_ON

com.mayulive.swiftkeyexi.USE_SYSTEM_VIBRATE_OFF

com.mayulive.swiftkeyexi.SET_THEME ( Requires extras )

That last one there requires you include an extra value specifying the theme, which I will cover below.

Incognito mode is something we already control, so all we had to do was listen for an intent and toggle it accordingly.

This lets you do fun things like enable/disable it for specific apps:

[MENTION=5643806]Bobobot[/MENTION]

Ditto for system vibrate, which is the use-system-vibrate quick-setting we added back in 1.7.0. The hook broke and it became a bit of a pain to insert it there, but changing the setting it easy, so it's an intent now.

Theme intents

Setting the theme via intent requires that you include an extra; a value specifying the identifier of the theme you want to switch to.

You can obtain this value by going to the very bottom of your settings screen, where you will find a Keyboard Theme Hash. This is the identifier of the last theme you selected, so you may have to toggle to a different theme and back first.

Clicking it will copy the value to your clipboard, including the name of the extra ( THEME_HASH ).

In the case of Tasker, all you have to do is paste that value into one of the Extra fields in your intent.

Note that if you use the wrong identifier, Swiftkey will greet you with an error message the next time you open it.

If you get it right however, you can now use Tasker to switch themes on any condition.

Here we have it enabling one theme for Chrome, and another for Firefox

Once we receiving the intent the switch is pretty much instantaneous, but the default app-detection feature in Tasker is on a 1.5sec delay. You can mess with the settings to improve that a bit.

EdXposed compatibility [MENTION=4670577]ace_apr27[/MENTION] [MENTION=4549435]fijasko[/MENTION]

As some of you might be aware, Xposed hooks work by letting you insert some code before and/or after a method is called. You can also choose to invoke the original method, or simply prevent it from being called.

Invoking the original method inside of the hook for the method would normally result in an infinite loop, but the Xposed Framework thankfully prevents this from happening.

This is also the case in EdXposed, but only if you invoke the original method within the same hook. If you are doing weirds things like saving a reference to the method and then invoking it later on, you end up triggering the hook instead of calling the original method.

This isn't something most modules are going to doing, but it will definitely be the cause of some of them breaking.

Fixed by setting a flag when we invoke the original method, and preventing the hook from firing.

Cursor jumping near linebreaks

This is only an issue when RTL support for swipe selection is enabled.

Normally when we move the cursor, all the information we have to work with is where in the string the cursor is located. We can detect line breaks, but when we are dealing with RTL text you never really know where the cursor is going to end up, as the visual position does not match the character position in the string.

To cope with this we fall back to triggering key pressed ( left, right, up, down ) to move the cursor around. This used to work fine, but at some point Swiftkey started reverting the cursor to the last position that was explicitly set, as opposed to emulated using keypresses. Whenever you are near a line break we fall back to using this method, and this issue would appear.

Solved by checking if the last change was caused by a keypress, and reading-and-writing the final position again at the end of a swipe selection session when necessary.

Gif bing redirect [MENTION=4402493]BadToThePhone[/MENTION]

As we discovered in this post, any GIF urls inserted by Swiftkey will not be direct link to the file, but a link to bing.net that then redirects to the file.

Clearly they are using the url to track who you are sending the gif to, but the real problem is that the redirect causes some programs ( e.g. Discord ) to not realize that it is a gif, and display a still-image screenshot instead of a playable gif in the chat.

Not cool.

There is now an option to disable this. This option is enabled by default.

Note that there are some gif urls that still won't auto-play in discord, but that's not caused by anything Swiftkey is doing. Same deal if you paste them in using gboard or using a computer.

Swiftkey doesn't seem to be doing anything else bad here. It provides the text box with both an image file and a url. The image file is primarily for preview purposes I imagine, but I think it's up to the app whether it ends up pasting the actual image or a url to the image.