A recent WordMix update brings much improved support for Android tablets as well as experimental support for Japanese dictionary.
Improvements to the layout for 7″ and 10″ Android tablets were long overdue, fixing some issues where activities and controls looked out of place because they were initially created and optimised for mobile phones.
Further I based the App’s theme on Holo for Android 4 and on Material for Android 5, ditching the DeviceDefault as a recommendation. In my experience, vendors quite often ship a DeviceDefault implementation, that is inconsistent, incomplete and quite often breaks visual appearance. In order to work around inconsistent presentation on some Android devices, I have decided to pin the theme to a set of known appearance with some custom styling, bringing a consistent look across all Android 4 and Android 5 devices (Android 2 and 3 support has been removed).
Only new feature is the experimental support for Japanese as a language, including a Japanese dictionary (needs to be downloaded after installing the App). Japanese is particularly difficult to implement in this game due to the high number of different letters and combinations. Similar sound combinations have been combined as single letters, allowing to choose the specific sound by tapping on the dice. Feedback is appreciated!
As always, get it in Google Play Store, while it’s hot!
I was debugging my Frupic Android app the other day, trying to rotate images according to the orientation stored in their exif headers.
The necessary Android class ExifInterface(String filename) to read exif information from local files was quickly set up, but I couldn’t get it to report the correct orientation, it always returned ORIENTATION_UNDEFINED (0).
After debugging my code for a while on my physical device, double and triple checking on my PC that the file to be downloaded actually contained correct exif information, I found out that the file on the phone was about 2kb smaller than the file on the PC and on the server.
I knew my phone was downloading the file over my German T-Mobile data connection, believing that T-Mobile does not touch the files when requesting the image directly. I also knew that T-Mobile does replace image URLs in HTML files to be able to cache requested images on a server close by and I also knew they might compress them. I assumed, T-Mobile would not binarily alter a file if it is directly requested.
Browsing to http://speed.telekom.de (only available from within their mobile data network), customers are able to alter the behaviour of T-Mobile’s transparent HTTP proxy:
Compress Picture- and Video transfers (this reduces quality and filesize)
Optimize transfer without loss in quality
Default is to optimize the transfer without loss in quality, which apparently does remove all exif headers from downloaded images but is also told to remove comments from HTML code and doing other micro optimazion stuff.
While I can choose to enable exif headers for slightly more traffic, it’s clear that my Android App can not rely on the exif information being available, unless the images are downloaded over SSL. I guess I am just one of few who have actually hit this limitation and I do not mind it being there. Could have saved me a lot of debugging time though.