Sonopia is the ‘Do-it-yourself’ MVNO. You may remember I wondered how programmable the phones were and whether it would be possible to create a Sonopia MVNO differentiated by some kind of mobile application.
Sonopia Customer Service previously told me that only BREW was supported. I have since had an email from the VP Engineering at Sonopia. In actual fact, Sonopia looked into the BREW J2ME runtime but it wasn’t considered ready for commercial usage. Instead, in addition to BREW, Sonopia supports FlashLite that they are encouraging 3rd party developers to use.
The RAZR is currently the only FlashLite handset but more handsets are planned. What’s good is that it’s the newer FlashLite 2.1 installed on the RAZRs. This presents lots of interesting possibilities for creating mobile application differentiated MVNOs. It will be even more interesting if and when Sonopia makes it to Europe.
Just came across the new Google Code Search. It works very much like my popular Symbian Codex and J2ME Codex which I produced about a year ago.
I thought I would see how useful the Google Code Search will be for mobile developers. I typed in ‘extends midlet’ to get all J2ME applications. I got ‘about’ 700 references. Wow. Next I tried to see how many Symbian applications are listed. A search for ‘public CAknApplication’ and got ‘about’ 100 references. Again, very impressive given that Symbian code is a very specialist area within what must be a huge amount of indexed open source code.
Last year, I had heard that Symbian were creating their own code search repository. I don’t see much point now unless they can index internal non-public source code and/or also classify code by Symbian OS version.
There’s a relatively new Wiki on Mobile Development. It gives a fair indication of the pros and cons of various mobile development platforms and the tools required to develop for them. In practice, you will need a bit more than the Wiki to choose a platform. Deeper technical, marketing and political issues usually pervade a given project rather than the issues presented.
The IBM web site contains an article by Mikko Kontio comparing six mobile development technologies. He makes a brave effort of comparing SMS/MMS, MIDP, Symbian, Pocket PC, Smartphone, and Palm OS.
I find that the most important factor, not featured in the article, is whether what you want to do is actually possible under each technology. People often come to me with a chosen technology well before they know it’s even possible. For example, many people come to me with ideas for J2ME applications that require access to the phone’s internal APIs. Similarly, it’s common for people also think they can change the user interface of the Series 60 built in applications.
Looking through the shared links on a bookmarking service, I came across a site that saddened me. A site with lots of pirated Nokia Series 60 and UIQ Symbian software. I am not including the link here as I don’t really want to everyone going there. If you are from Adobe, contact me and I’ll give you the link!
The situation is much the same as it was with Microsoft in the late 90’s. At the time, I was creating lots of applications for the Pocket PC. Pocket PC warez was rampant and I saw many of my fellow developers give up or slow down Pocket PC development when they saw so much of their software being illegally distributed. Thanks to the Microsoft fraud team and a few determined Windows CE developers, at the time most of the warez disappeared from the public eye (probably underground to IRC).
So what can be done? The larger companies (like Adobe!) probably have enough weight to get the sites shut down. Smaller companies don’t have the necessary time to pursue these sites – they tend to move to a new domain when pushed and eventually close down when they have moved the site a few times – which takes a lot of time and effort.
What can the Symbian developer do? Currently, applications tend to tie themselves to one IMEI. Unfortunately, as the Adobe case shows, this can obviously be circumvented by a determined hacker. One advantage of the new Symbian Platform Security is that if applications are Symbian Signed, they cannot be tampered with – or more specifically, they can be tampered with but not put back into the original signed .SIS installation file. Putting the tampered application in a new .SIS file won’t work as the program will probably require capabilities enabled by the Symbian Signing.
With some developers currently unhappy with the extra time and cost associated with Symbian Signed, it may just turn out to be exactly what they need!
Adobe will release Flash Lite 2.0 this month which should solve some of the limitations inherent in Flash 1.1. Announced improvements include better device integration (for example vibration support), performance improvements, dynamic media loading and most importantly persistent data.
Other than the Nokia N90 mentioned in the Flash Lite 2.0 Introduction seminar, there’s no official word yet on handset support or whether any further devices will have the Flash Lite player ‘in the box’. A voucher in the authoring kit gives you the FlashLite 2 Player for free.
The Flash Lite 2.0 Introduction seminar also demonstrates an interesting use of Flash as the UI for a (Samsung) phone.
You can find my Flash Lite 1.1 Dictionary Freeware for the Series 60 on my web site.
Opera applications can be likened to Flash. They are written in a easy-to-program high level script language. Unfortunately, they also suffer from the same shortcoming…. licensing. Both require a runtime (the Opera web browser in this case) which isn’t already on the phone and require end users to purchase. Opera and Macromedia are hoping the likes of Nokia will license the runtime for inclusion in future phones.
In the case of Macromedia Flash, Nokia announced a licensing agreement last February. It’s still not known which, if any, Nokia Series 60 device will be the first to include Flash. Many people expected this to be a device in the NSeries but this doesn’t seem to be the case.
In the case of Opera, Nokia have gone off and created their own web browser. Hence, it’s very unlikely Opera will be included in future phones.
Thus, most freeware and commercial developers won’t be that interested in creating Flash and Opera applications as there are very very few users.
I have just taken a look at Flash Pro 8. This improves authoring of Flash Lite content by providing a dedicated Flash Player (emulator) for mobile. The emulator is now Flash Lite itself running on the PC. Hence, it’s possible to accurately target and test specific device types.
Unfortunately, accuracy and testing of device types weren’t Flash Lite’s main weaknesses. In a previous post, I criticised Macromedia’s licensing policy. Having used Flash Lite, in my personal opinion, there are three areas Macromedia has to address in the forthcoming Flash Lite 2.0 release:
Flash Lite 2.0 will be discussed in October at MAX 2005.