Ed Page recently blogged about his idea to improve the Swipe UI. Fortunately for him, a bunch of people and I had the same idea inside Nokia

Nokia N9 won’t be available in Germany, Austria and Switzerland either, besides US and UK, report Engadget and Slashgear.

This phone thus becomes the smartest phone Nokia built, unavailable anywhere!

I think I’ve never seen so much confusion, lack of strategy, PR suicidal actions and so many believers let down in such a short time.

Could anyone imagine the company that actually made the app-enabled OS massively popular in Europe is now refraining from launching a linux-based project that so many people strove to bring alive? What else could be worse than to trash your best efforts and ideas?

I know, there are several logistic and marketing reasons for not launching the N9 in these countries; but why should they reach to this point, in the first place? Why would anybody work for a dead project? Who is the person that makes Nokia project managers accept it’s reasonable to seed dead seeds and bear dead children? That person, my friends, is something you should avoid at all costs, as it literally sells death instead of life to its own people.

Mobile Fun, an online UK mobile phone and accessory retailer has announced that it is accepting pre-orders of the Nokia N9. The retailer does not yet have a release date for the device, but it has confirmed a retail price of £519.95 (UK Pounds). Pre-orders have also been announced at Expansys, but the price has yet be confirmed. This comes amid speculation around which international markets in which the Nokia N9 will be available. It also highlights the point that a lack of operator support does not equal a complete retail black-out.

Nokia has rolled out a beta of the Ovi Store for the developer only Nokia N950. While the release is still beta, it does give us an idea of what the Ovi Store will look like on the not so widely available Nokia N9. The design of the store is based on the MeeGo Harmattan UI that can be seen on the rest of the device with certain similarities with the Ovi Store on Symbian.

The N950 will find the Ovi Store automatically, but if you don’t see it, you can go to settings, applications and check for updates. Since the client is beta and the developer devices aren’t upto speed with the internal Nokia firmwares, there might be a few applications that have installation issues.

Most of the available applications will work on your N950 and existing publicly available firmware (1.2011.22-6). However, there are a few applications in OVI Store that are created with newer pre-production SDK that may fail to install in your device for now. These applications will work also on your device after we have the next SW update available. If a downloaded application does not install, your download history in Ovi Store means that once you have the newer firmware you can download/install the application.

I’m surprised Nokia is still calling it the Ovi Store, after killing the Ovi brand a few months ago. My Nokia Blog a bunch of screenshots if you’re keen on checking the store out in a little more detail.

Similar Posts:

• Nokia Music PC Application Launched
• How To Recover Phone Memory On Your Nokia N97
• Get The Theme Icon Back In The Main Menu: N95
• Wazapp Is WhatsApp For The Nokia N9, Now Available For Download
• How To Hack Your Device In Under 5 Minutes

As I was introducing in the former entry QUrl (mis)usage, the direct creation of a QUrl from a QString should be avoided in any software that is not trying to smartly guess what a user input should lead to.

So, going directly to the ham, to avoid mistakes due to automatic conversions from QString to QUrl, I encourage the usage of the QT_NO_URL_CAST_FROM_STRING macro. The only thing you have to do is adding a line to your qmake project file like this:

# Avoid automatic casts from QString to QUrl. Dangerous!!!
DEFINES += QT_NO_URL_CAST_FROM_STRING

Or add it directly to the compilation line, like this

g++ ... -DQT_NO_URL_CAST_FROM_STRING ...

As I was pointing in my previous post, the usage of QUrl::fromLocalFile(QString) and QUrl::fromEncoded(QByteArray, QUrl::StrictMode) is recommended when dealing with QString and QUrl, but committing mistakes is a human condition so it is pretty easy to end passing a QString as a parameter to some API expecting a QUrl, or assigning a QString to a QUrl with the “=” operator through the C++ automatic cast mechanism which is implemented in the QUrl class. That’s why forbidding these automatic casts in our code is of such importantance.