Опечатка

I set out to make the keyboard actually look like the design I’d settled on.Everything worked by then but it still wore a generic light theme, and the wholepitch is a keyboard that looks and types like Samsung’s, so the look had to land. Ipulled every color and a few sizing numbers into one theme object and repaintedthrough it: a black keyboard, near-black keys, white letters, and red used for onething only, the key you’re pressing. On top of that I added the pieces the mockupshowed — a floating preview of the letter above your finger, a permanent numberrow, a dim symbol in the corner of every key that you get by long-pressing, atwo-page ?123 layer, a blue enter key that turns into a magnifier in search boxes, arow of toolbar icons up top, and holding the spacebar to slide the cursor throughtext.
The part I was wary of was the number row, because it doesn’t just sit on top, itgoes into the same grid the autocorrect uses to read where your taps land. Adding a fifth row shifts every letter’s position, and the worry was that it would quietlythrow off the typo-fixing and start mangling words. It turned out not to matter: thedecoder measures distances in key-widths rather than pixels, so adding oneevenly-sized row leaves the spacing between letters exactly what it was, and thedigits aren’t letters so they never enter the word search at all. The offline testthat runs thousands of fake typos came back with the same numbers as before thechange, false corrections still at zero, which is what let me put the row in the reallayout instead of bolting it on as a separate strip.
The screenshot shows the new black keyboard with the number row on top and a pressedkey lit red with its letter popped up above it.

Note, found while testing the redesign and not caused by it: two things in the decoder are worth fixing later. The bar offers “дом ас” when you type “домас”,because the run-together splitter will break a word in two as long as both halves are real, and “ас” happens to be a real word, so it peels it off even though that’s almost never what you want. And “домасний” won’t correct to “домашний”: that’s aс-for-ш mistake, but с and ш sit on opposite rows of the keyboard, and the auto correct only ever considers the key you hit and its close neighbors, so it never even weighsш as a possibility. The first is a small tuning fix; the second would mean teaching it to consider letter swaps beyond fat-finger range, which is a real feature and has to be done without breaking the zero-false-correction rule.
( the toolbar icons along the top aren’t wired up yet. The language one switches keyboards, but emoji, clipboard, settings, and the overflow menu are drawn for now and don’t do anything — they’re waiting for future wiring)

I wanted to close a gap that felt wrong in real use: autocorrect only ever looked at the word being typed right now. If a typo had already landed in the text and you tapped back into it, the keyboard just sat there and wouldn’t re-check the word or offer the right spelling. An earlier pass had made tapping into a word safe so it no longer mangled it, but the part you actually expect, tap the broken word and get the fix, wasn’t there yet. So now when the cursor lands inside a finished word the keyboard adopts it: it works out where the word starts and ends and, since the original taps are long gone, recreates them by dropping one tap dead-center on each letter’s key, then runs the same autocorrect search it uses while typing. The correct spelling shows up in the bar and one tap swaps it in where the word sits, without disturbing the spaces or words around it, and you can also just backspace and retype and it re-checks live. It never changes the word on its own - tapping in only offers a fix -which keeps the rule the whole project lives by, never correct a word that was already fine, intact at zero false corrections. The tricky part was telling apart the two times the cursor moves - when I move it, since right after committing a word the system reports the cursor now sitting after it, versus when you tap somewhere new. Treating my own cursor updates as a fresh tap made the keyboard re-grab and re-offer the word it had just finished, in a loop. I fixed it by remembering exactly where I last put the cursor and only reacting when it turns up somewhere I didn’t put it. The other half was being conservative about which words to touch: only plain Russian words, never names, numbers, or anything with characters that don’t exist on the keyboard, and never a half-typed fragment.

Finally I was also able to fix a bug word-tearing. At first I had marked it done, but the exact thing that happens when you edit a word still broke. Type a word, press space, backspace into it, keep typing, and the keyboard treats the new letters as a separate new word and splits the old one in half. So I reproduced it on the emulator in the Settings search box, the field from the screenshots, and changed how typing into existing text works.
Now when you start typing with the cursor inside a word the keyboard adopts that whole word and edits it as one unit instead of starting a loose fragment beside it, and I gave it a cursor index within the word so an inserted or deleted letter lands where the cursor actually is instead of always at the end. What slowed me down was that clean scripted taps would not tear the word no matter what I tried, which is the same trap I have fell into earlier. The bug was never in the path I kept testing. It only shows up once space has committed the word, and my reproductions weren’t pressing space first.

Only after many many tries I was able to finally understand the logic of the bug. Space, then backspace, then type. With space, the word is committed text, so backspacing into it does plain deletes and the old code then composed only the new letter as its own fragment. Replacing that “cursor sits inside text” path with whole-word adoption fixed it, and false corrections stayed at zero the whole time since an adopted word is only ever offered, never swapped on its own.

What I set out to do. Build the core of the keyboard: a full Russian ЙЦУКЕН layout that doesn’t just type letters, but fixes fat-finger typos as you go. The whole reason for this project is that Samsung’s Russian autocorrect is rough, so this part had to genuinely work, not just look the part.

Drew the keyboard as a custom Canvas view instead of a UI framework, so it stays small and opens fast on old phones. Then wrote the autocorrect engine - it treats every tap as a point on the screen, not a fixed key, and runs a search over a word dictionary that scores how well your taps match each word against how common that word is. On space it decides whether to swap your typo for the best match. Never touch a word that’s already spelled right.

At first the system said the keyboard was visible, the process was running, no crash in the logs, just a thin blank strip at the bottom. I lost a good while on this. Turned out Android measures the keyboard once with a width of zero before the real layout pass, and I was computing the keyboard’s height from its width, so zero width meant zero height and it never recovered. Fixed it by falling back to the actual screen width when the measured width comes back as zero. Keyboard popped straight up after that.

(to be honest there are still problems with this system which i aim to soon fix, like for example starting mid word, or not spaced word. But at least I was able to get it to work in the most ideal conditions)