While I have frequently improved and updated the network compatible Android version of Freebloks, I have always neglected the Windows version. The Android version gained features like player names and the ability to choose the colors to play with. While the Windows and Android version always stayed compatible, the PC version simply did not offer these features to connecting Android devices or when connecting to a dedicated server.
Now Freebloks-1.5 for Windows is available, which lets connecting Android devices use all features and offers the player to choose his colours as well as to choose a name (which is not displayed in the game but on connected Android devices). If you frequently play Freebloks over the Internet, it is recommended to download the new version here:
I created and published an android app that bundles my ISATAP client daemon and provides a configuration front end. To run the binary on android, it requires root access, i.e. a rooted device or phone.
On my Galaxy S3 with Cyanogenmod 10.2 I successfully get a IPv6 address using the app. 😀
If you have a rooted phone and an ISATAP infrastructure close by, please feel free to give it a try:
For the port of Freebloks 3D to Android I rewrote all code from C to Java. While that was working fine and resulted in greatly simplified networking code, the speed of the AI was not so great. It took up to 10 seconds on a fairly powerful SGS 2 for the computer to find a good move.
I was trying to move the CPU intense routines of the AI to C again, using jni as a bridge between Java and C. The simple network routines should stay in Java.
But the transfer of relevant game data to C and back to Java turned out to be very ugly, yet the solution was incredibly simple:
The Freebloks code was always split in two parts, the GUI/client part and the AI/server part, with the client and server always communicating using network sockets. Yes, even the single player version starts a network server and connects to localhost. The original source code always contained a package for running a dedicated server.
It was incredibly easy to copy the dedicated server code into my project, compile the C code with the NDK and connect it to Java with only a single jni call. It was running out of the box, with almost no change of the original C code at all! Since the server is running in a thread started from the native C code, there is no additional jni call neccessary and no data transfers except for the sockets.
The average duration for the AI to calculate a complete game dropped from 87 sec to 28 sec on my SGS 2. The version 0.0.2 in the Google Play Store supports ARMv5, ARMv7 and x86. Grab it now! You may also download a free apk file here.
Oh my, my webhoster has the deflate output filter disabled by default, that enables gzip compression of outgoing content. This is important for huge xml/json data from webservices that travel over mobile networks and easily reduces used bandwith to up to 10%.
I just pushed a first playable version of Freebloks for Android, a port of Freebloks 3D to the Android system. It’s a very early development version and very rough, but you can start a single player game and join a network game and place stones. The user interface still needs a lot of love, but I might push a preview version on Google Play soon. Please get involved on GitHub, if you want to contibute.
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.
Android is an interesting platform and it’s easy and fun to develop for. My first app is a very simple tool to query the IT-Monitoring state from the University of Ravensburg-Weingarten, as also available on their public website:
On June 8th, 2011 my webhoster participated on the World IPv6 day, making my homepage temporarily IPv6-enabled. Shortly after they went productive, so all my subdomains, the homepage, this blog and even the ftp have IPv6 records enabled by default.
www.saschahlusiak.de has address 18.104.22.168
www.saschahlusiak.de has IPv6 address 2a00:1158:0:300:8e72::1
Only the email servers don’t run IPv6 yet, but I’m sure that’ll come. Welcome to the future. 🙂