Is it ideal to convert the Keyboard View and XML layouts of an Android keyboard to Jetpack Compose? #481
Replies: 1 comment 3 replies
-
If you're taking LatinIME as base then neither are really applicable. This is all the layout of a keyboard: https://github.com/rkkr/simple-keyboard/blob/master/app/src/main/res/layout/main_keyboard_frame.xml. It's just a blank View that is then used to programmatically render buttons and animations using bitmaps. If you're thinking of replacing that with a dynamically filling view and android managed buttons it's going to be complicated. Buttons register clicks outside of their visible borders and then there's swipes (and swipe typing if it needs to be supported) and all the other things. You'll likely end up programmatically processing touch events anyways so there won't be much use to have a View with real UI elements in it. |
Beta Was this translation helpful? Give feedback.
-
I'm currently working on an Android keyboard project that uses traditional XML layouts and custom views for the keyboard interface. With the growing popularity and flexibility of Jetpack Compose, I'm considering converting these layouts and views to Compose.
However, I'm uncertain if Compose is the best choice for something as performance-critical as a keyboard, especially with potential challenges in handling InputMethodService, custom keyboard layouts, and dynamic key rendering. Are there any significant advantages or disadvantages to making this transition? Would Compose provide better long-term maintainability and customization in this scenario
Beta Was this translation helpful? Give feedback.
All reactions