Get in touch

Pages

Using Google Keyboard when typing in language different than English can be really frustrating. Neuxs 5X default keyboard keeps changing correctly spelled Polish sentences into utter nonsense. It is a lot better for English but the spell checker still doesn’t recognize many correctly spelled words.

To get some hard data on the subject I compared a Google Keyboard dictionary with Hunspell, a popular spellchecking library used in Chrome, Firefox, Mac OS X, Ubuntu and many others. Depending on language Google Keyboard is able to recognize between 4% and 77% of words known to Hunspell.

Language

Hunspell words

Recognized

Unrecognized

% Recognized

en_US

152582

7747

2254

77%

es_ES

885418

2480

7521

25%

pl_PL

3624473

511

9490

5%

ru_RU

4201083

361

9640

4%

You can find a test rig on GitHub. It generates a list of all words in Hunspell dictionary and checks if Google Keyboard can recognize randomly selected words. It uses the Android Spell Checker API as it’s easier to automatically test than the autocomplete and apparently they use the same dictionary.

Diagnose

Google Keyboard uses fixed list of around 200k words and it is not able to recognize many derived words created by appending suffixes (e.g. ~’s for English nouns in possessive form). Other tested languages have a much larger number of suffixes and prefixes because of conjugation and declension. This explains why the percentage of recognized words in these languages is dramatically smaller.

Solution

The dictionaries used by Android keyboard apps should be generated from the complete lists of correct words. Available spellchecking dictionaries can be used to generate such lists. The frequencies of different words (used to order autocorrect suggestions) should be applied to the the list taking into account relative frequency of different derived forms. The frequencies should reflect the nature of texts usually typed on mobile. Currently the words “study” and “therefore” are marked as more popular than “hi” or “guys”.

I recently had a chance to report a security issue to the Android Security Team and it was a pathetic experience. They didn’t know how permissions are presented in Play Store, couldn’t decide if it’s a feature or a bug and then changed their mind regarding issue severity for no apparent reason.Continue reading Reporting Android Security Issue

When Android 5.0 shipped with a number of bugs and memory leaks many people complained about apparent Google QA deficiencies. Surely, the initial Lollipop ROMs shouldn’t get a green flag from QA but it looks like the problem lies much deeper in Google’s delivery process.

I don’t have enough insider knowledge to point out where exactly the organizational problem lies but based on the code analysis I can demonstrate that issues span from APIs design through implementation to testing. I am going to use Lollipop Screen Capture API as an example.Continue reading What’s wrong with Lollipop

Android SDK provides access to many great APIs and features but there are still many missing or incomplete. This is especially true about access to some slightly non-standard features. For example hardware video encoding API got added in Android 4.0 but it took four major releases before the usable API got exposed in Android 4.4 SDK.

Luckily for those of you who are not patient enough to wait two year for the private API to get publisher it’s possible to access such private APIs using couple tricks I’m going to describe in this post.

It’s been five years since I last posted here.
Not that I haven’t got anything interesting to say, I was just too occupied with my day-to-day work and, well… life. Working in confidentially-obsessed banking industry didn’t help much with sharing my work related thoughts either.

My focus changed initially from Flex to HTML5/JavaScript and then to Android.

Just like with Flex, with Android I couldn’t resist peeking under the hood and figuring out how things work. And, as before, I ended up contributing to the project and relying on my in-depth understanding of the system in my day job.

Some of my findings regarding AOSP (Android Open Source Project) seem worth sharing so I decided to resurrect this blog.

It is quite common in Flex applications (and other RIAs) to divide screen content into two parts: the navigation/configuration panel on the left and the actual content on the right.
The examples of such apps are FlexStore sample and famous Style Explorer.

I followed this pattern in many projects and several times we come to the point that navigation/configuration panel requires too much space and that there should be a possibility to minimize it. Probably designers of Style Explorer has a similar idea since their navigation control can be minimized. Unfortunately they haven’t created reusable component to do this.Continue reading Creating Collapsible Panel in Flex 4

Title of this post is a little bit misleading because it is not possible to use ChartScroller directly with CategoryAxis. This is because ChartScroller relays on axis minimum/maximum properties which are not present in CategoryAxis. Luckily it is possible to simulate CategoryAxis behavior with LinearAxis which is supported by ChartScroller. I will describe how to do it in this post.Continue reading Scrolling and zooming chart with CategoryAxis

Some time ago I presented scrolling chart by using modified axis renderer (ScrollableAxisRenderer). I rethought this concept and come to the point that axis renderer should render axis not scroll the chart, so chart scrolling should be implemented as separate component. This is especially true in case of charts with many axes and renderers. My new idea was to create nonvisual component which will take reference to a chart and add appropriate listeners modifying axes minimum/maximum to achieve scrolling /zooming.Continue reading Scrolling and zooming chart with ChartScroller