Slydr 2.4 has passed certification day before yesterday and it has been available for download since yesterday. Mandarin / Cantonese now supported in Slydr.
I finally finished changes to Alarm Clock 1.6, adds 10 new fonts making a total of 24 and 3 new tones (a total of 9 now). The users can test alarm tones while in trial mode
I have also started changes to Slydr for 2.5. So far, i have modified Trie Node to contain a word or a list of words.
Say you have god and good. in trie, you can enter god and it should display both god and good with (good before god ). However the logic in trie meant that only last entry was valid. So i have modified the code to allow for one or more entries
I have also used a different logic when using predictive typing. When adding 1st words, trie lists iterates through many words and its time consuming (faster with more character user types). i have modified the predictive code so now it doesn’t use trie when user enters first character) and it is so much faster now.
Slydr 2.3 with predictive algorithm has made it through testing and it now available.
I thought it was automatically published but for some reason i forgot select that options so today morning i manually published it.
Slydr 2.4 is ready and has been submitted. It contains dictionaries for both simplified and traditional chinese. It also contains a few bug fixes, few enhancements (toggle key background for shift / spacebar etc) and a much asked for cursor / caret for the textbox.
There i finally got around to adding it.
BTW the chinese support is using pronouciation dictionaries. The user can enter / swipe complete pronouciation or just the first char of each pronounciation. The example below should make it clearer.
如果 ru guoorrg
是的 shi de orsd
Now i have to start thinking about what to do for the next release…
I have finally submitted 2.3 for testing. It includes a significant change in functionality i.e. predictive typing.
Because the requirements for predictive typing are different as compared to sliding, i had to rework my word dictionaries slightly. hopefully it doesnt take significantly longer to load. I have used TRIE implementation as i mentioned previously instead of TST.
Apart from that i have reduced the creation of ”use and throw” threads i already had thread in background for dictionary processing, now i use extra events to cancel existing operation rather than trying to kill the thread (which of course never worked in WP7)
Finally i updated char popup width to match key width in portrait or landscape mode.
I am working on Mandarin / Cantonese dictionaries. Requires a bit more time as the dictionaries are slightly unusual
I know i talked about use of Ternary Search Tree TST earlier and TST is probably more efficient but i couldn’t the most comprehensive TST implementation could only return user specific matches based on length.
if you entered hi, it would return hi
if you entered hi*, you will get his, him etc.
if you entered hi**, you will get high, hind etc.
TST however had a simple contains for preliminary match.
This meant that i will need to run it multiple number of times to get overall matches and then sort it based on relevance. Too many calls equals eventually slower plus knowing keeping constant tab max word length and keep padding wildcards.
so I have settled on Trie, which allows individual char entries and provides option to see if its a full match (similar to contains) and gives you all matches in a single list. Sorting takes care of relevance and it works perfectly.
Thank goodness… One user complained about match list being a bit iffy, i am going to make each item have larger area which would allow more touch area !!!