The theme for last night’s Mobile Monday London was ‘Enabling Location in Applications’. The presenters included Ted Morgan, CEO of Skyhook Wireless, Ben Ward from Yahoo! Fire Eagle, Charles Wiles from Google (Gears), Andrew Scott from Rummble, Justin Davis from Buddy Ping, Mark White from Locatrix and Matt Womer from W3C.

Here’s what I took away from the event (my personal thoughts in italic)…

iPhone 3G actually uses Skyhook. This aggregates cellid, WiFi and GPS information to provide location where GPS alone might not work (indoors, height urban areas). Skyhook already have 50 million wireless access points (16 million in Europe) mapped by driving around various countries. While Skyhook uses cellids, it does not obtain any information from network operators.

If it does all this, I can’t help but wonder why my iPhone 3G is so slow at getting a fix. The maximum time to get a rough fix should be the time to get the cellid (negligible) and do a http or ip based lookup to a server somewhere. This should take seconds not minutes. Also, WiFi and cells change over time - how will this information be kept up to date?

Skyhook also have a ‘loki’ iPhone app that can invoke a request that includes location, to a web site through the web browser. This allows remote web sites to know the user location. It’s a clunky workaround as it requires the user to start an application to invoke the browser in this way.

Yahoo’s FireEagle is essentially a database or broker for current and past locations. Anyone can either provide or consume locations according to end-user defined privacy criteria.

I came a across FireEagle a few weeks ago. I must admit I was sceptical. Why would anyone want to trust Yahoo with their location? What’s in it for Yahoo? Having thought about it some more, an aggregated location information makes sense. The alternative, having lots of applications each providing and consuming locations drains battery. There must be some savings from aggregating this stuff. Also, there are classes of applications (proof of concepts, mashups, hobby) where people don’t really want or need to create their own database of locations.

Google told us ‘the web is the platform’. Interesting given they are championing Android. Anyway, the new Geolocation API will provide a Google Gears interface for mobile web browser based applications. There’s a synchronous getCurrentPosition() call as well an asynchronous watchCurrentPosition() that will allow for more battery friendly applications. The actual location can come from a variety of providers - Skyhook, Vodafone, Google etc. There will be implementations (plug-ins) for Windows Mobile, Android, PC and one other platform by the end of the year.

I am still wondering about this merits of this. I presume the the plug-ins themselves will require the installation of a download which is effectively an application (Ok, a DLL in most cases) and the supported mobile platforms won’t be that pervasive.

The W3C has just started to look into providing a standard location API for web browsers.

It seems to me that many organisations are all doing the same thing (trying to get the browser to support location) but in different ways. Let’s hope they converge otherwise we will have yet another set of fragmented APIs.

Rummble gave an interesting presentation and proclaimed ‘Mobile Internet will be the Internet’. Given enough time, people might use their mobile devices as their main device and hook it up to a monitor at home in place of today’s PC. Interesting. Andrew explained how their first iteration ‘Play txt’ failed because users ‘didn’t get it’. I actually see this a lot - tech people such as us can get too embroiled in things that the (lazy) mass market care little about and projects can go off the rails when mildly complex features detract uptake.

Locatrix’s presentation (and the Q&A) made me think more about privacy. There seems to be contention between allowing the user to control their location privacy and ease of use. The more control you give, the more annoying prompts and options need to be tolerated. Another aspect Mark touched on was white label branding. If you are a startup, consider this as it makes your idea much more sellable.

The most interesting part of the Q&A was when someone asked about the need to know other peoples’ locations without them having to push this information or use power hungry GPS, and the importance of cellid in this respect. The iPhone was briefly mentioned in particular it’s inability to run background 3rd party applications. There was also disagreement as to whether cellid on its own is good enough to determine location.

UPDATE: Interesting read from Nokia Conversations, ‘Location based services still do not measure up? Or do they?’

Related Articles:

• GSMA 3rd Party Access Project
• Navizon Cellid Based Location
• Google MyLocation: How Does it Work?
• Google Maps Mobile: How does it work?
• Location without GPS or Operator LBS
• LBS at MoMo London
• Location Based Services

Shai, of LWUIT (Java UI) fame has a post on how people want to access the mobile Internet now and not when browsers have matured.

There is currently lots of talk about widgets, Javascript and web functionality that might rely on functionality deeper in the phone. However, for now, only a small percentage of the mass market can access any of this on their current phones (or even the new phones they are buying now).

I have already come across several companies working with Java ME just because they see this as a technology that can be used now rather than a future indeterminate time (some might say if ever?). Shai builds on this thinking in that the pent up demand for accessible mobile information makes LWUIT very suitable for a mobile front end to your Web 2.0 property.

I tend to agree, but only if you are sensible with your choice of device support and feature support. See my previous post, again commenting of Shai’s thoughts on this.

Related Articles:

• Java: Attempting to Support All Devices
• Java One Sessions
• Lightweight UI Toolkit for Java ME
• Native vs Java ME
• Java ME Optimization
• Is the Future of Mobile the Web?
• Java's not worth building in?

I was lucky enough to grab an O2 3G iPhone online last Monday when they were briefly offering pre-ordering online. Here are my first impressions together with a few development implications. I’ll concentrate on the new features.

I am surprised the iPhone App store is so populated. OK, there are lots of e-books but there are also many real applications. Neither Windows Mobile nor S60 achieved this number of apps in such a short space of time. There’s one catch - you can’t download the free apps until you have added a credit card to your Apple ID based account. If you don’t, you just get the unhelpful error "Authorization Failed, Please connect to iTunes".

One observation I have is that it’s going to be difficult to discover apps on the phone - especially when there becomes thousands rather than hundreds. The iPhone’s simple but clear standard UI only allows viewing of a few on the screen at any one time. In time, expect they will have to create a full screen application (Apple call it an immersive application) to allow more applications to be discovered at any one time. Apps can also be discovered and downloaded on the Mac so it’s not too great a problem.

GPS? At first I thought it wasn’t working. I took it inside, outside and I just got the busy icon in the maps app. While writing this, I left it searching and it’s got a fix… but took 15 minutes! It’s currently accurate to about a 3m and it successfully tracks me within a few seconds as I move around. I am not sure yet if the long lock time is a one off thing or not.

Despite 3G, the iTunes application still insists on a WiFi connection to download. This is a pain for me as I have now standardised on power line (IP over mains) networking for reliability. My WiFi access point has now come out of retirement.

It’s interesting that people have been approaching me with cross platform native projects that include iPhone but not Android development. I think this is mainly because the iPhone is a real device and it’s already being offered by 22 network operators. Android still has a long way to go in this respect.

In what little time I have (I am very busy at the moment), I am getting up to speed with iPhone development. I can’t talk much about the SDK because you sign away such rights when you agree to the SDK agreement. However, generally, I am seeing how you use the iPhone screen assets (table Views, toolbars, tabbars, alerts etc) being more of an issue than learning the Cocoa/Objective-C idioms.

It’s interesting that of the initial set of released applications, very few actually need to be native. However, it all depends on how good your connection is at any one time - online apps obviously need to connect.

Another interesting observation is that Apple is allowing applications to be free but ad-funded. This is good news as the current trend seems to be for applications of this type.

Related Articles:

• Who Really Manufactures the Phones?
• Free vs Sold Applications
• Apple WDC2008
• iPhone Long Running Applications
• iPhone SDK - Initial Impressions
• iPhone Code Signing

The GSMA 3rd Party Access Project aims to simplify access to network operators’ proprietary APIs. At the moment such APIs are either not available, only available to large companies who can negotiate access or where available are different for each operator.

The goal of the GSMA Access API project is for operators to present a common, lightweight API to developers to encourage the kind of innovation that has been seen on the ‘fixed’ Web with open APIs.

The GSMA have gathered together 14 operators and determined the initial list of capabilities to be exposed, based on the feasibility/value/current exposure of various network capabilities and functions.
 
The initial proposal defines the following capabilities:

• Charging users for your applications, via the operator phone bill
• Messaging users via SMS and MMS
• Anonymous Subscriber Identification: recognise your users without broaching their privacy, including operator identification
• Connection profile, to help tailor your content accordingly
• Location of the handset
• User profile: to help ensure age group and user opt-in is considered in delivering suitable content

The GSMA is currently asking for feedback on these and other capabilities you might need. You need to register your interest on the GSMA web site after which you can comment on the capabilities. I have already left some comments regarding native vs. application development, messaging and authentication. Note, their secure portal site only worked under IE (not Firefox) for me.

Symbian created a new partner program this week, the Symbian Partner Network (SPN). This will replace the existing Symbian Platinum Partner Program. Why have Symbian done this and what does it mean for developers?

The SPN will…

"make use of a range of technical, marketing and business development tools and resources, including the Symbian OS Binary Access Kit."

Some people are asking Why Is Symbian Charging Its Partners? I see SPN as a stepping stone. It will pacify existing partners who might ask why pay $5000 for the current Platinum program when the OS is about to become open source in the very near future. I suspect Symbian is also hoping to attract some new partners. Why not free? The $1500 is probably to filter out people who are serious about developing from those with just an idle interest because Symbian has to administer all this.

What’s in it for developers? Ignoring the marketing aspects there’s the Binary Access Kit (BAK). What is it? First of all, you don’t need it to do most 3rd party application development. You can just use the freely available S60 and UIQ SDKs. Some sites have commented the BAK includes source code - it doesn’t - only samples you might find in a S60 or UIQ SDK. Instead it includes headers, binaries to allow use of the partner APIs.

If you want source code then you should license the DevKit which costs a lot more (tens of thousands of pounds). It’s used by companies supplying components to Nokia/Sony Ericsson/Motorola/Samsung and those that need examples of how to implement particular features of the OS.

A full explanation of the various SDKs is given in ‘What Symbian OS Development Kit Do I Need?’

Also be careful. What you need might not even be in the Symbian SDK. Over time, much functionality has been implemented in S60 rather than Symbian. This means, for some areas, you may have to partner with Nokia rather than Symbian. Obviously, all these complications should go away once the Symbian Foundation open source the Symbian and S60 code.

Related Articles:

• Symbian Foundation Comments
• Symbian Foundation
• Symbian 10 Years Old
• Symbian Signed Under Attack
• Symbian Market Share
• Slow Symbian Emulator
• Developing Software for Symbian OS

These last few weeks I have been porting a Windows Mobile application from Pocket PC Phone (touch based UI) to Smartphone (button based UI). These are called Windows Mobile Professional and Standard respectively, as of Windows Mobile 6.

To be honest, I previously didn’t like the Windows Mobile Smartphone software variant. I worked on it when the first Smartphone (Orange SPV) shipped in late 2002. It was a hideous phone. The software APIs were incomplete and I just didn’t see the point when the Pocket PC was much more capable.

Fast forward to today and all the Windows Mobile work I have done since then has been on the Pocket PC Phone variant because this has been more commercially available (via network operators). Since my early adventures with the Smartphone variant, the variants merged (in Windows Mobile 5 in 2005) such that there’s much more common code and APIs.

I recently purchased a Samsung i320 (now off contract for only £99.99 on Expansys) for development and I have been reflecting on how much the Microsoft Smartphone platform and phones have moved on. The phone is brilliant (for the price - OK, it’s not 3G) - small, light, keyboard, camera and it even comes with two batteries and a carry case of spare battery! In my opinion, the button/list based UI makes more sense than the traditional Pocket PC variant’s Start menu popping up when you click Start.

[As an aside, if you use a Pocket PC, check out SPB Mobile Shell. While it doesn’t turn your device into an iPhone, it provides a much more intuitive UI that makes Windows Mobile much more appealing.]

Back to the Smartphone and coding. I am finding a considerable amount of code can be shared across Pocket PC and Smartphone - it just needs tweaking here and there to make it work. The main areas I am having to change involve install locations, resources and some command and key handling.

What I had written off years ago has evolved over time into something much more appealing - both from consumer and developer viewpoints.

Related Articles:

• Windows Mobile Trends
• Windows Mobile Gaining Ground?
• Windows Mobile Market
• Windows & Linux to Displace Symbian as Dominant Force in Advanced Mobile Operating Systems
• New Windows Mobile Development Wiki
• Developing for Windows Mobile 5.0

‘Quick Recipes on Symbian OS‘ has just been published.

It’s often the case developers with no Symbian experience are asked to produce an application yesterday. The aim of the book is to get these people up and running as quickly as possible. Quick guidelines how to set up the IDE and SDK, a summary of Symbian idioms and a comprehensive set of ‘recipes’ reduce the length of time needed to implement code. The recipes include file handling, PIM, networking, messaging, graphics, multimedia, telephony, connectivity and location based services. The book covers both S60 and UIQ as well as generic Symbian APIs.

The lead author, Michael Aubert says in the interview on developer.symbian.com published today…

"Each recipe represents code that developers often actually need; the readers will be able to reuse them simply by copying them. The book is structured as a two-weeks learning exercise but the code samples are taken from real-life experience."

What I particularly like about the book is that it includes panels with ‘tips’ and ‘what may go wrong if you do this’. The latter are particularly helpful as it’s sometimes the case that it’s the 1% of the code that consumes most of the effort - when it just doesn’t seem to behave as it should.

Code examples for the book can be found on the Symbian Developer web site.

It’s no secret that Symbian OS isn’t that accessible for first-timers. It’s a steep learning curve. Books like this and the opening up of the OS via the Symbian foundation will provide examples that make Symbian OS much more accessible for first timers.

Related Articles:

• Symbian Foundation Comments
• Symbian Foundation
• Symbian 10 Years Old
• How to Satisfy Symbian Signed & Nokia Criteria
• Symbian and Nokia Partner APIs
• Client Server Example for Symbian 9.x
• Symbian DevCerts and Validity Periods
• AllFiles Capability and File Explorers
• Symbian 9.1 Development Tip and Warning
• Symbian OS Basics - Workbook