WIP Wiki

wipwiki.gifCarlo Longino from MobHappy and Caroline Lewko from the Wireless Industry Partnership have created a new mobile resource called the WIP Wiki. It’s aimed at helping developers find the tools, resources and partners they need to move ahead with their work.


The wiki includes company listings, developer programs from handset and platform suppliers/operators and a tips section.

I have been meaning to create a site like this for a long time now as a resource to point people to when I get leads for work that I am unsuited for or for which I don’t have the time. My site was going to be more of a ‘developer’s co-operative’ – however, the WIP Wiki is much more than this because it lists a lot more than just developers.

AMF Ventures Research

Last January, AMF Ventures conducted a survey of 400 mobile professionals…

"to delve deeper into the technical environment of mobile devices, the policies and behaviours around them, and the impact that this has on the further development of the industry as a whole."


The results of the survey are available on slideshare.

I personally think native applications and the web browser execution environment will continue to coexist and neither will be the main execution environment. In fact, as I have previously commented, despite standards, the web browser execution environment may become more fragmented once it gains access to large numbers of phone features.

One thing that troubles me is that we are only just starting to think about these issues. Standards will take time. Implementations take time. Phones incorporating the implementations take time.  It will be many years before we see a standards based web browser execution environment and even longer before we see them in a viable number of end-user phones.

Carbide.c++ Team Considering ARM Emulator

carbideexpress.gifFollowing on from my post on the deficiencies of the Symbian/S60 emulator and subsequent comments at Nokia Forum, it appears that the Carbide.c++ team are considering changing the emulator.

How to Satisfy Symbian Signed & Nokia Criteria

nokia.gifOne of the difficulties of creating your first Symbian Signed application is knowing how to code your application in such a way that it is compliant. The test criteria just say how your application should behave – they don’t give any clue as to what extra code you might need to pass the tests.

Hence, it’s great to see that there’s a new document on the Forum Nokia Wiki that goes through each test case and explains the areas of code you need to consider in order to pass each test. It also covers extra Nokia test cases for applications that include manufacturer capabilities and TPO project applications.


Native vs Java ME

symbian.gifSymbian have a useful new paper comparing native and Java development. The paper covers application startup, installation, APIs, portability, fragmentation, security and tools.

In practice, most companies I work with find the choice of programming language (and platform) is driven mainly by…

  • the features provided by the API
  • the number of shipped devices in the target geographic region

Assessing whether a platform has the required API features for a project can be tricky. Sometimes when doing feasibility studies for companies I need to experiment with the APIs to determine whether the APIs are available, work correctly and have no limitations.

It should go without saying that risky areas such as this should be evaluated prior to a project commencing. However, I am sometimes approached by companies to ‘solve the problem’ only to find what they want to do wasn’t ever possible.

Mobile Apps vs Web

mobileopportunity.gifThere’s a very dramatic post at MobileOpportunity entitled Mobile Applications: RIP. Michael Mace’s observations are based on a company that has been trying to sell applications.

While I agree that creating a mobile application for sale is now a dead end (and had been for many years), the smart people have since moved on to ‘free’ applications that generate revenue in other ways (e.g. Ad funded) or provide interfaces to existing products/services that themselves provide revenue. I wrote about this type of development just under 2 years ago.

Web applications are not the golden bullet. They have their own challenges (see links below). I believe native, runtime and web apps will continue to coexist for now. From my angle, there has never been a time when there are more companies looking for someone to create their native application.

With Nokia, Google and AOL creating application development platforms, I believe it’s far too early to be making any predictions either way.

One Button Cross Platform Development Framework

One of the guys from navxs.com has emailed me about their new Cross Platform Development Framework for Mobile Applications…


They can deploy to Android, Java ME, Windows Mobile and Blackberry. They started on a Symbian port but later decided to put their (limited) time on the other ports. Their first reference implementation is a Location Based Social Network called NavXS. There’s a short movie on YouTube explaining the framework.

Previously, I was of the opinion that there’s no money in writing tools – especially mobile tools. Just look at Borland and AppForge. However, with the new trend of higher level cross-development tools I think there are now opportunities in this space.

Carbide.c++ UIQ UI Designer

carbidecxx13.gifAfter last year’s Symbian Smartphone show I commented that the UIQ 3.x UI Designer would become part of the Carbide.c++ beta around January.

Nokia has now released their release candidate 1 for Carbide.c++ 1.3. This Beta-release is the first one that contains UI-designer with support for UIQ applications. It can be downloaded from http://groups.google.com/group/carbidecpp-beta after you have registered.

The UIQ UI designer has come late to the Carbide 1.3 beta hence the timeframe for beta testing is a bit tight. UIQ are looking for bug reports during this week and you have until 10th of February (Sunday) to submit any bugs.

If you are wondering, you can run Carbide 1.3 side by side with Carbide 1.2. However, you can’t share the same projects. Opening a 1.2 project in 1.3 will cause it to be upgraded to the new project format. You will have to re-import your project to get it back into 1.2 format.