Laut Alexa gehört bluewin.ch zu den 10 am meisten besuchten Webseiten der Schweiz (Rang 8). Und ist gleichzeitig die beliebteste, von einer Schweizer Firma betriebene.
Nun hat sich die Swisscom entschieden, das gesamte Design von Bluewin zu aktualisieren und ihr einen frischeren Look zu verpassen.

Gleichzeitig sollen möglichst viele Dienste von Swiscom in Bluewin.ch integriert werden. So verweisen viele Links direkt zum Swisscom Online-Kundencenter und das gesamte Swisscom Angebot ist in die Seite integriert/verlinkt.

Also äusserst nützlich finde ich beispielsweise die “CenterBar”. Dort sind viele wichtige Funktionen wie Telefonbuch (local.ch), Radio, Wetter, TV+Kino usw. zusammenfasst und übersichtlich dargestellt.

Zusammenfassend kann ich sagen, gefällt mir die aufgeräumte Seite. Sie wirkt sauber und trotz vielen Javascript Effekten nicht zu verspielt. Natürlich passt das neue Design mehr ins Corporate Design von Swisscom.
Leider fehlt jedoch eine Personalisierung. Ich kann weiterhin nicht auswählen, welche News-Bereiche mich nicht interessieren und diese ausblenden.
Ausserdem ist es etwas umständlich, zwischen den Hauptkategorien zu wechseln. Wenn ich beispielsweise einen Artikel in der Kategorie “Sport” lese, dann aber auf “Digital” wechseln möchte, muss ich immer über das riesige “Page-Down Popup” gehen.

Leider ist auch die “Seite Drucken” Funktion nicht wirklich nützlich. Neben der Werbung (die da definitiv nicht hingehört), wird das gesamte Seitenlayout, Navigation und der grosse Footer gedruckt. Definitiv eine Stelle, die noch verbessert werden muss.

Hier noch ein direkter Vergleich der alten, aktuellen Bluewin Seite und der Beta Version.

Artikel auf der aktuellen Bluewin Seite

Artikel in der Bluewin Beta

Die Beta-Version des neuen Bluewin-Portals ist frei zugänglich und kann über diesen Link erreicht werden. Wie findest du die Seite? Gut, schlecht? Was fehlt, was wurde gut gelöst? Feedback wie immer in die Kommentare

Related Posts

• Exklusiv: Screenshots der neue Swisscom Xtra-Zone
• TechCrunch Meetup 2008 – A Look Back
• Google to buy Global IP Solutions from Norway

Yes, after days and weeks of speculation, it seems HTC has finally committed to an Android update for the HTC Desire mobile phone. I have been using a leaked Android 2.2 with Sense for my Desire for a few weeks now. Not much has changed over Android 2.1.

The press release has some words about new features. I’ll explain some of them in this post and show you with the leaked ROM how they look and what they do.

HD Video (720p) recording
Quality is great. You get 24 fps, which is enough. Check out this example video.

App Sharing (Widget)
Nothing brand know (Barcode Scanner can do this as well).

Multi Language Keyboard
Very nice for people that write or type texts/emails/sms in different languages. In the lower left corner you can switch between languages, with a simple click.

iTunes Sync
I could not try this. The leaked ROM seems to miss that. Was never really an issue for me anyway. Question just is, how long will Apple allow this? They don’t like it, if other manufacturer tap into their ecosystem.

FM Radio UI Updated
Just a minor update. But the user interface has changed a little bit.

Move Apps to SD Card
Something a lot of people are looking forward. If an app developer allows it, apps can now be installed or moved to the SD card. This should spare you some space on the internal memory and allow you to install more apps. But there are currently very few apps allowing this.

Additional Widgets
HTC has added a few new widgets for changing settings. Namely WiFi, Mobile network, Hotspot and so on.

So if you want Android 2.2 on your Desire, head to
Settings -> About phone -> System software updates
If you own a branded device (most likely you bought it from Swisscom, Orange, Vodafone, Sunrise, …) you need a few more weeks of patience. Or you use a Goldcard to unlock your device.

Pre-Rooted updates will be available very soon. I’ll update if any news are out or a direct download link is available. Should not take too long

Related Posts

• Gallery 3D (Froyo) for HTC Desire
• @HTC removes Desire Kernel Sources?
• Zattoo on Android Mobile Phones

If you want to do something in Java, there’s certainly Java library which helps you with to achieve your goal. However, for some stuff (3D rendering, accessing I/O devices) the Java API’s are not enough and you need to interact directly with the target platform.  In such cases, you need to use the Java Native Interface and provide a native library. This also means that you need to ship your application with additional native libraries. Here’s where the issues start.

Java and Native Libraries

When you use native-libraries, the JVM needs to load those. By default the JVM loads those libraries from a few standard system paths. Of course you don’t want to touch those. The other alternative is to specify an look-up path with the JVM-argument ‘java.library.path’. This works most of the time, but still has its issues! First, it doesn’t work with a simple jar-launcher! In order to specify this JVM-argument, you need to add a launch-script. The second issue has to with packaging your application. Imagine that you ship your application for different OS, like Linux, Windows 32- and 64-Bit etc. The native binaries are named the same, but are actually for different versions. For example there are two versions of ‘coolLibrary.dll’ one for 32-Bit, one for 64-Bit. You cannot have both in the same directory. You somehow need to decide at runtime which one you pick.

So what you want is to be more flexible how to resolve a native library. And you can! Thanks to our friend ClassLoader. Basically you can overwrite the ClassLoader.findLibrary()-method and implement you own resolving strategy. For example:

Source-Link for RSS

Of course, this class-loader should be the ‘root’ class loader of your application. This means this class loader should be responsible for loading all application-classes. To do this, I usually create a small ‘boot’-application, which starts the real application. Basically what it does is to instantiate the NativeLibPathClassLoader, pass it the location of the application with dependencies and then load the real application. Not that your ‘real’ application shouldn’t be on the regular class-path. Otherwise everything is loaded by the system class loader:
Source-Link for RSS

This is how I start up Java Desktop Applications which need native libraries. It works wonderful and it solves the annoying ‘java.library.path’-path issue.