Tag Archives: android

A day at the Android Developer Lab World Tour in Zürich

Posted on by
Reply

What would you do if you had the chance to meet some fellow android developers at Google’s Europe HQ in Zürich for free? Yes, you register and go there. As did I, we. Unfortunately, someone at Google’s messed the times up, which lead to us having to depart in Stuttgart at 6am rather than 10am, but nevertheless we made it on time.

What’s the impression of the Google HQ? It’s quite hard to remain objective and unimpressed, so the report may well be seriously biased. Sights along the way in: Streetview car, Google Sign. No suits. Sights in the entrance area: Pool table ( playable ), fridge, Google Sign. Very colourful, nice. Once we waited about 10 minutes we were guided to the conference location, which was also located on the ground floor, right next to the cafeteria and the ( ! ) gym. The overall impression on the way there was that it’s actually not a place that’s perfectly suitable for working there, but it’s a place where living might be fun as well :-)

We had to wait some time until the event kicked off, but the time was spent more or less usefully setting up wifi, talking to other developers and the android stuff ( specifically Reto Meier who held the talk ) and drinking free coke. The event started, but was interrupted to give away free nexus ones. This came not really as a surprise as a) the boxes were located next to the entry, so it was not hard to spot and b) most of the participants I talked to followed the other lab sessions e.g. in Berlin and Paris. But forget about surprises, it’s so amazing to get a phone for free ( actually, it’s even more amazing if it’s the second one ). And what can I say, it rocks, you need to play with one for a little while, forget the iPhone, honestly.

After about half an hour later, the talk finally began, very interactive, very well-held. It basically included a what is android-primer, as well as some focus on technologies available and best practices. After a short while ( let’s guess it was 30 minutes ), we switched over to having .. lunch. And damn, it was tasty like hell. Just like the whole day, all people were nice, friendly, it was a really great atmosphere even just to eat.. wow.

The second part of the talk focused on some code examples, and afterwards, the fun part of the event began: the big bang question session. I had some prepared, as had almost all other people there. And it’s just great to talk to someone who knows ( omitting the should here ), and gives you a clear answer. Reto Meier, again, did a great job on this.I also showed some people qwerted, and I guess some even liked it :-) . There is one app I really want to recommend, it’s called Music Queue and tries to change the way we listen to music and organize our on-the-fly playlist. Great app, cool developer!

What can I see? We left too soon ( for my impression ), and I need to work there. Like, really. Unfortunately, picture taking is generally not allowed on the premises, yet we were able to take some at the conference room itself.

Thanks to all the great people there, was a really cool day.. next year again, hm?

<embed type=”application/x-shockwave-flash” src=”http://picasaweb.google.com/s/c/bin/slideshow.swf” width=”400″ height=”267″ flashvars=”host=picasaweb.google.com&hl=de&feat=flashalbum&RGB=0×000000&feed=http%3A%2F

qwerted status update

Posted on by
Reply

Wow. just wow. The last few days, I received tons of emails from people who want to beta test qwerted, have been featured on some blogs ( androidguys.com , ignore the code , mobiflip , some other languaged-blogs ), thanks to the all writers, and got a lot of motivation from the positive reactions.

There are some things I’d like to adress in a short here. First of all, iPhone indeed has some kind of resizing of the touch areas for specific keys, but it’s not as extensive as qwerted’s resizing. Just try it ( I did )! Overall, qwerted and all other android keyboards do have a special problem, and that is that screen estate is fairly limited, and at least on my devices ( g1, google ion ) the screen is notably smaller than the iphone’s.

The next issue is word suggestions. Many people approached me with that wish. I’m currently in the process of building “more necessary” things, like a dictionary installer, and qwerted will get suggested words after that. But I guess not in the plain way you know word suggestions. Maybe context aware, maybe something else. But they are definitely on the agenda.

A word on pricing. I set up a small survey for beta users ( If you’re one of those, the survey is on google ), and the results at this point indicate a selling price of about $2.49. I think this is quite fair and reasonable.

I’m sorry if I forgot to answer some mails or didn’t reply to questions, it’s been a few busy days, and I’m still overwhelmed, amazed and thrilled by the way the whole qwerted-thing developed. And it’s just the start.

Finally: I guess I’m going to make the end-of-january deadline!

iType Demo Video online – finally getting real

Posted on by
Reply

iType, my project, is finally getting close to release state. But talking is boring, so here is a short demo clip. If you have any questions, please write to itypeapp @ gmail.com

I am looking for beta testers, so if you want to test it, please let me know!

iType Demo Video from Moritz Haarmann on Vimeo.

Related Blogs

RandomAccessFile weirdness explained, no buffers, just pain.

Posted on by
Reply

Ola! I’ve been coding a new android keyboard lately, a project for my university degree but also : for fun. While I was doing this, specially while implementing a file-based dictionary containing frequency information of all words stored in there, I stumbled upon a very, very weird Java-behavior.

Let’s explain it. Using RandomAccessFile, you have both Interfaces, DataInput and DataOutput ( and Closeable ) at your service. Wonderful, I thought, and started to use them. Well, two weeks and endless debugging sessions later I figured out why nothing worked the way it should: RandomAccessFile.

This little class is unable to provide the most simple functionality: Write a byte value, say 42, to a certain position, say 11223 in a file, then seek back to 11223, read a byte value, and make sure it’s the same. The reason for this odd, strange, undesired, undocumented feature? No shared buffers. In fact, no buffers, just for the explicit read and write operations ( they are mapped to native methods anyway ). So basically, everything should work fine in an unbuffered environment, with an operating system directly writing everything down on file.

Because virtually no operating system works unbuffered, RandomAccessFile doesn’t work. The working workaround is to sleep for some time or something alike.

By the way, I was only able to figure it out by looking at the openJDK source, an excellent source in case you’re wondering about some Java behaviour. And thanks to Marc Seeger for his help!

Android 1.5 SDK Released

Posted on by
Reply

Google has just today released the SDK for Android 1.5, the upcoming version. Not only is my beloved InputMethodService package finally included, but it seems that many cupcake-innovations found their way to the official SDK, which means that they are now open and free.

My planned tutorial on getting ADT for Eclipse working with cupcake is not necessary anymore, luckily, and I’m really looking forward on writing a tutorial about how to create a custom input service. Stay tuned, once again.

Waiting for… Android wishlist

Posted on by
Reply

Welcome in the middle of my night, I’m currently spending my days working, my evenings eating ( barbecue, it’s gettin’ hot in here.. ) and my nights either trying to watch my favorite TV-shows or sleeping. And if none of those shows is on, my head notices me of several thoughts, most of the time presented at a rather disturbing concurrency level, related to … android.

I’m still exploring the API, and Android as a complete product, and the more I learn, the more I’m getting caught by it. And I’m sure that a few years from now, many people now using costly, unhandy notebooks will be using devices based on something like Android.

But let’s try to stick to the title of this post. First of all, I’m really looking forward to Google I/O. I booked a flight, it’s my 2nd time in San Francisco ( I don’t know where to sleep yet, but there’s some time left to figure it out, hints welcome ), excited. And I’m working towards finishing my own keyboard implementation to show it off. I’m not going to talk about it in detail as long as there is no working demo available, and it will take some time, trust me.

I’m also waiting for Cupcake. Cupcake, for the ones of you who are not familiar with Android, is a read-only development branch, meant to publish non open-source development efforts. These efforts also include the creation of an Interface to implement custom Input Methods, be it a Keyboard or anything else that allows for input of textual data. One could very well think of a Morse-to-Text button ( idea for a tutorial ), a rotate-to-write or an application using an artificial neural network to do some lip-reading using the phones camera. Though the last one will be quite resource-consuming, the point is, anything can be done using the very generic API.

Once again, if you want to use it, get yourself the Cupcake Sources. It’s well explained at source.android.com. I somehow made it, without spending more than about 30 minutes, to build emulator images and the rest i needed to get going. And although the Eclipse plugin reports an error, it’s working even for cupcake.

Luckily, when building the stuff you need the docs are also being created, explaining what you need. I especially recommend to take a look at the built-in keyboard’s implementation, as it’s very readable and self-explaining.

I’m really hoping to find some time to publish a tutorial on this topic, but I’m not able to promise anything.

Android, building a custom Keyboard

Posted on by
Reply

G1 has hit the market, and since typing on a touchscreen is still a pretty unpretty thing, I decided to build my own softkeyboard. Doing so is not possible with the current SDK downloadable from the android site, but you can ( not easily.. ) build all the required libs ( mainly android.jar ) using the sdk source and even use the adt 0.8 eclipse-plugin. Even though it confronts you with some errors, hitting ok will do the job.

Android features the ability to select your preferred input service, enabling a developer to create a custom keyboard from scratch. android.inputmethodservice seems to be the entry-point for any such efforts, and I will keep you up-to-date here on how it works. And how it doesn’t.