Sylvain Wallez

One week ago I got a T-Mobile G1, the very first phone powered by Android (thanks Phil!). Being the CTO of a mobile-oriented company, I see and use lots and lots of phones. All "iPhone killers" I had in my hands before the G1 were quite crappy (don't get me started on the Samsung Player), but that one is definitely different.

The G1's touch screen is as sensitive as the iPhone's, the usability is very close to that of an iPhone, and it has a similar set of built-in applications, including an application catalog. So the comparison definitely makes sense. Where the G1 falls short though is the hardware itself, which isn't pretty and not even as good as other HTC phones. But Android is an open source operating system, and lots of manufacturers have joined the club so we can expect shiny devices to appear soon.

One very nice Android feature is the notification bar. When an application wants to notify the user that something has happened in the background (incoming email, IM, application download, etc), a little icon appears in the top bar and you can "open" that bar to browse through notifications and launch the corresponding applications.

Android can't run J2ME midlets and hence can't run the Goojet client application. So I started writing a specific client with the Eclipse-based SDK. It just took me a couple of hours to have the first version running, thanks to the WebView user interface widget that is a simple wrapper around a WebKit browser, and the fact that it is Java.

Compared to our iPhone application, also based on WebKit, developing on Android is way easier for a Java developer. You don't have to learn Objective-C, Interface Builder and be forced to use a Mac (although it's been my computer of choice for years). And once the application is built, you don't need complex signing procedures and insane validation (our application got rejected 2 times already for minor problems).

The application architecture of Android is really powerful, being centered around a message bus that allows applications to listen to and contribute to other applications and components. The system provides lots of reuse and extension points. For example, it was rather trivial to plug Goojet in the "Share picture via..." command of the photo application in addition to the existing "Mail" and "Instant messaging" options, or allow adding shortcuts to our widgets on the phone's home screen. At a lower level, the security model is very clever in its simplicity: every application runs as a different Unix user, and that user belongs to groups related to the permissions granted to the application. No need for sandboxing or code verification, all this is handled by the Linux kernel!

So, bad things about Android? From the user point of view, beyond the fact that the G1's design isn't shiny, and I'm not a big fan of white text on a dark background which is the standard color scheme. I'm also missing the "pinch" and other multi-touch gestures of the iPhone, which aren't present most probably because Apple patented them.

From a developer point of view, the documentation is scarce and a bit confusing (I want a proper Javadoc with frames!), but since it's open source, you can browse the code of the built-in applications for non-trivial examples which helps tremendously. There is also some strange usage of XML namespaces and weird text escaping in resource files. But overall it's a really pleasant and productive experience, and I should mentioned on-device debugging which is as easy as connecting the phone to the computer with a USB cable.

As a conclusion, my impression is that Android will really change the phone market, building on the road opened by the iPhone: a friendly user interface, lots of communication features. But on top of that it adds an easy development environment and no vendor lock-in. So I think the iPhone will keep its luxury design market niche, BlackBerry will stay for a while because big companies like it, Nokia will keep on using Symbian, but most other smartphones will run Android, and Windows Mobile will finally die.

How is Google going to make money out of Android is still unclear to me. Is it through the application store, where they will also keep 30% of the price like Apple does? This is a quite different revenue model from their current core business. There are certainly preparing location-based services, some sort of geo-adsense that will suggest interesting things depending on where you are and what they have learned from you by scanning your email and instant messages. And as usual, people will be ok with giving away a lot about them for nice services and features.

Posted by Sylvain Wallez at 11:51 AM | Permalink | Comments (3) | TrackBacks (0)

Yes, Mario is alive! Have a look at this video, where he drives in the streets of Montpellier (France).

Mario is actually played by Rémi Gaillard, a french guy who does stupid but hilarating things in front of a camera!

Posted by Sylvain Wallez at 06:30 PM | Permalink | Comments (1) | TrackBacks (0)

Currently working on taking pictures with J2ME phones, I banged my head a large part of this afternoon against a SonyEricsson phone that "refused" to take a picture for really unexpected reasons. Also, other applications on the same phone were able to take pictures but not mine. Why, oh why?

I finally did what I should have done right in the beginning: copy/paste the exception message in Google and see what comes up. And here is the answer...

What's happening is that the phone allows to start an application directly after download, when the web browser is still running. In that case, the browser still runs in the background, and the phone cannot allocate enough contiguous memory to capture the picture, and fails! And I spent the afternoon changing the code, downloading new versions on the phone, and starting these new versions directly from the browser...

The solution? Well, don't try to take pictures when the application is started from the browser. I now have to include an ugly hack in the code to detect this situation and display a friendly warning to the user.

Ah, the joys of mobile development...

Posted by Sylvain Wallez at 07:01 PM | Permalink | Comments (0) | TrackBacks (0)

The Apple business and his Steveness in Simpsons land: incredibly funny, because so true! What are we ready to give away for some apple goodness! Even for iPhone developpment where you almost need to get an Apple tatoo on your heart to go to AppStore heaven!

Check out part 1 and part 2 on Dailymotion. Don't know how long they will be available, since Twentieth Century Fox already had them removed from Youtube.

And see also a similar movie on Joost.

Posted by Sylvain Wallez at 02:36 PM | Permalink | Comments (1) | TrackBacks (0)

Today I was at the Eclipse Marketing Symposium that was held as part as the Eclipse Summit Europe close to Stuttgart (Germany). I was an invited speaker there, giving a talk on the various business opportunities I discovered and explored in my 10 years of involvement in the open source world. This symposium was gathering marketing people from companies members of the Eclipse Foundation to share experiences and discuss how to best promote the use of the Eclipse open source framework as the base of customer projects.

Apache and Eclipse are very different when it comes to their relation with companies. Apache only knows about individuals, even if it is well-known that most often their contributions wouldn’t be possible without, and are driven by, the company that employs these individuals. Apache therefore cares a lot about diversity that ensures a long term viability of projects, and isn’t really concerned with the business ecosystem that exists around them.

Eclipse on the other hand, has a membership consisting mostly in companies (individuals can be members too, but it’s more the exception rather than the rule). So as much as Apache has formed a strong community of individuals, Eclipse has formed a community of companies, that are now working together to define strategies and actions to promote their Eclipse-related activities. The foundation itself has interests in making sure these activities flourish, since this is how it ensures its members continue contributing. One of the outcomes of the symposium was the need for a common set of presentations, document templates, success stories around Eclipse-related projects, and the willingness to create these documents so that every member company can use them to convince their customer to go for Eclipse-based solutions.

So after open source, we see here the emergence of open marketing, with companies building together “marketing commons” for their mutual benefit. There has been some attempts in doing similar things in the Apache world, namely with Orixo, but that did not really succeed. In this case, it’s more likely to be successful since it happens within the Eclipse Foundation and with its oversight, with a collaboration on common assets rather than a collaboration on customer projects, where market or revenue share issues can block the good will of people.

It will be interesting to follow this collaborative marketing activity, see how it works and if it succeeds. It would be nice to see the open source collaboration model extended to new areas within companies.

Posted by Sylvain Wallez at 11:44 PM | Permalink | Comments (1) | TrackBacks (0)

More than 2 years ago, I was searching for a web application framework to build some of the Joost backoffice systems. I was looking for something simple yet powerful, if that thing existed, and did not require a massive amount of learning nor lots of XML configuration files to be able to develop something useful. I stumbled upon a series of articles on JavaLobby about something called Wicket, and it was jaw-dropping: a simple Swing-like Java library, plain HTML with a few added attributes was all what was needed to build useful web applications.

Two years later, Wicket has found a new home at Apache (I'm happy if I helped by mentoring the transition), has a vibrant community and a great team of talented developers, and Martijn and Eelco, two of the main developers, have written Wicket in Action, a book you definitely should read if you want to quickly cover most of what you can do with Wicket.

The book is written in a humorous and entertaining style which makes reading its 350 pages a real pleasure, without sacrificing the needed technical strictness. It's also full of hints and advices that show the deep real-world experience accumulated by the authors, which is also present in many aspects of the framework itself.

The first section of book goes through the classical "Hello world" to explain the basics and the main principles underlying Wicket's architecture. The rest of the book then uses the "Cheesr" online cheese shop for the examples, with hilarious comparisons between software architecture and lasagna layers :-)

The next chapters cover the essentials of Wicket: models (an essential aspect of Wicket), the extensive component collection, tables, form processing and validation, reusable web components and templates and page composition. Wicket provides a lot out of the box, but the authors often explain how to extend the framework to handle specific needs.

Then comes internationalization, resource management (where do you place the images and CSS that go with your reusable Java components?), producing something different than HTML, with a nice CAPTCHA component. The chapter about Ajax shows how the component-oriented architecture of Wicket makes it very easy to perform partial page rendering to react to user actions.

And since Wicket is "just" a web application framework, a chapter covers integration with Spring and Hibernate, although you can use anything you want for your application and data layers.

Some critics about the book? A bit surprising is that installing Wicket is covered a "bonus chapter" available online. Sure, it is mostly about Ant and Maven, but adding a few pages about how to setup Wicket in your web.xml in the book would have been good. Also, the last chapters about unit tests and production deployment are a bit short. I would also have loved details about the many options Wicket provides for session management on which it relies a lot, and which is an important concern on a busy website.

But overall this is an excellent book. This is a labor of love as Martijn and Eelco have spent a huge amount of time and energy on it (I've been reading some early chapters more than 18 months ago) and it shows in the final result. If you're using or are considering using Wicket, it's very much worth it.

Posted by Sylvain Wallez at 07:10 PM | Permalink | Comments (0) | TrackBacks (0)

If your Java application uses java.net.URL, and chances it does are very high, and you are using Sun's JVM (since 1.4.2), you should set the sun.net.client.defaultConnectTimeout and sun.net.client.defaultReadTimeout system properties to a reasonable value. Otherwise, if a remote site hangs, your application or server will also hang.

This is what happened to Goojet this morning: because of a problem at our ISP, the TCP connections to some remote websites were just stuck, without succeeding nor failing. Our backend quickly became unresponsive, all threads waiting for remote connections.

We use HttpClient with timeouts in our own code, but the culprits were some third-party libraries that use java.net.URL for http access without allowing us to set timeouts.

Setting the default timeouts at the JVM level solved the issue, and our ISP solved its own issues a couple of hours later. Situation back to normal!

Posted by Sylvain Wallez at 06:27 PM | Permalink | Comments (0) | TrackBacks (0)