Home | DevStory | Changelog | Support/Feedback

About the Development

I started working on this tweak as soon as I saw the first presentation video of BB10. Since that time, many things have happened and this article gives you more info about the whole development process and problems I have come across.

I wanted to try this keyboard idea myself so I decided to implement it on iOS. Immediately I ran the IDA Pro disassembler, class-dump and started investigating how text input works on iOS. I had the first testing tweak working in about 4 hours (my work folder is still at /Work/testtweak :D). It was drawing text over the keyboard. Then I started investigating KBTrees and individual geometry of keys on keyplane. The hard work was correctly reacting to swipes.

I started with a naive approach. Do not use separate dictionary and have only one list of words with frequencies. These words were stored in GNU dbm database, supplying stored words to libface. It worked fine but the problems were: no pre-made dictionaries, no autocorrection and more importantly it was not storing the previousWord-currentWord relation which is needed for next word prediction. At that time, the dictionary was loaded each time the keyboard was shown which was slowing it down. This was the first alpha version for iDownloadBlog.

Because of the huge popularity of alpha version, guys from Keypoint Technologies contacted me and offered their open-source input library OpenAdapTxt. After trying out their Android app I decided to use this as a backend for Octopus. It offered many features I needed. At that time, I started a new subproject for a daemon. Having a separate daemon running in background makes it possible to load dictionaries/profile data once and allow to share those data for keyboards in every app. I had been using CPDistributedMessagingCenter but I decided that Octopus needs something faster and more robust so I started learning Mach-O native IPC (inter-process communication) which uses shared memory and is very effective. This complicated the development a bit but worked really well. Connecting to daemon is very fast and reliable. In case the daemon crashes, it is restarted by launchd and clients connect to it immediately again.

OpenAdapTxt is a pretty complex thing so I wanted to squeeze as much from it as possible. I spent a lot of time trying to get the input buffer working correctly (synchronizing what you see on the screen with the input engine). The tricky part was also to get context working fine - e.g. when you write something or when you move the cursor, it needs to take previous word in account to get the suggestions as relevant as possible. All this needed to be implemented the most logical way so that it not break existing iOS keyboard functionality or existing keyboard-related tweaks. Integrating OpenAdapTxt also brought additional work - learning their documentation, examples and facing undocumented issues like the fact that keys in the keyboard layout can't have a different size than 1x1. One of the hardest problems here was how to manage dictionaries and where to store them. OpenAdapTxt needs to have at least one dictionary installed (otherwise it crashes) so I needed to deal with it. First I tried to fix it in their code, next I decided to leave English pre-installed and implement the ability to enable/disable individual dictionaries.

The next big thing was to get my own anti-piracy system working with Octopus. It was designed for protecting tweaks - dynamic libraries. But in this case I wanted to protect the octopus daemon itself. Thus I needed to rewrite it a bit. The anti-piracy system used the old CPDistributedMessagingCenter which caused additional problems so I rewrote it to Mach-O IPC as well.

At the end, there were ~30 beta testers helping me find problems I hadn't been aware of. The biggest issue to solve at that time was to get caps and capitalization working correctly. It needed to store caps and to detect whether the user started the first character uppercase or not and to look at the context to see what part of the sentence you are writing. I used Octopus on my iPhone all the time during development but I was not able to get used to it and test it thoroughly because of different issues during the development (it's not a good experience to swipe up and get a "can'Can't" word instead of "can't"). This is when I also realized it needs to work perfectly from day one in order for an user to get used to it. And this is why I didn't want to release it sooner for too many people.

In addition to this Octopus Keyboard development, I had to finish updates for our Plague Inc AppStore game (which was #1 in US and many other stores for a couple of weeks). During recent months I have been working almost all day long... To be honest, working on a tweak like Octopus is more complicated than general app programming, mainly because of the fact you have to learn how Apple's frameworks work internally and not to break anything by adding your changes. It's a lot of try-and-see until it works correctly.




Want to review? Have a site/channel?
Mail me and mention you want to review + website + proof that your are a reviewer.


Copyright © 2012-2013 K3A (twitter @kexik).
Fork me on GitHub