If you’ve arrived here after clicking on a link in a Twitter message, welcome!  Please read on.

Historically, providing developer-level access to any features of a mobile network has been tricky, to say the least. Even with the relevant service provisioning completed, you’re still stuck with a myriad of interfaces, standards, web protocols and security methods. And that’s just with one operator. As soon as you hit your second there’s usually a whole new set of enabler access methods to implement.

These difficulties have resulted in relatively few applications making use of mobile network APIs. Some operator groups – notably Telenor and Vodafone – have been piloting developer programs which generally formalize broader access to the various enablers (e.g. messaging, location, billing), but are still dependent on underlying platform technologies. (Orange, for example, exposes nearly 30 different APIs via their developer program!)

The GSMA’s OneAPI inititive is an attempt to revert this situation, and it is something we’re proudly supporting. Standing for Open Network Enablers, the OneAPI aims to bring network features to a much broader audience of Web and Web 2.0 developers. Practically speaking, it is a single API – REST and SOAP access methods are supported – through which developers can access services consistently across multiple operators. The project goal is to make it easy, safe, and beneficial for developers to utilise mobile capabilities in a far broader set of applications.

One of the OneAPI objectives is simplicity; it’s not trying to be a massive or overly-complex single platform that must be adopted by all. Instead it is a set of simple functions that will be accessible and friendly to any of the typical web development languages like Perl, PHP, Python and Java. A kind of mobile API for the masses, if you like.

Locatrix has recently deployed our reference implementation of the OneAPI at http://oneapi.locatrix.com and, being the intrepid former software engineer that I am, I set out today to create a mashup between the OneAPI, our favourite network operator, Chime – our social SMS solution, Google Latitude and the Locatrix XLF application service in a little PHP script. Proving that we do “eat our own dog food” (or “drink our own champagne” – with thanks to Kevin Smith), the code was built, tested and deployed in a couple of hours. By a distinctly former software developer!

The OneAPI initiative has the potential to change the way application developers think about mobile networks, and also to create genuine revenue opportunities for monetizing applications. If you’re interested in learning more about the OneAPI there’s some more material here, and I would welcome you to contact us if you’re a web developer interested in trying it out. Those in the Twitterverse can also follow the OneAPI account here, and you could also subscribe to our newsletter Position Update, which provides a wealth of location, mobile and social networking industry information each month.

Thanks for reading, and we now welcome you back to regular Twittering!

A couple of months ago we were meeting with a product manager for a European mobile operator, who confessed he had a big problem with mobile social networking. His manager had done a “link deal” with one of the big social networks – you can probably guess which one – and with much fanfare, a new link and logo appeared on that operator’s mobile home page.

At first glance, this initiative had a tremendously successful outcome for the MNO. Their mobile Internet usage saw double-digit percentage growth overnight. And kept growing.

A week later, the operator announced increased usage caps for all of its data plans. No great problem here, as subscribers rapidly became new mobile social networking enthusiasts, often in their thousands each day. But certainly less revenue per MB.

In fact everyone was terribly pleased until later in the month they discovered that while overall mobile data was substantially up, their on-portal traffic had actually decreased, by more than 30 percent. And adding to that dilemma, ARPU decreased for nearly every VAS product they offered to their subscribers.

So while the social networking traffic was increasing, the mobile operator had become a dumb pipe – and found themselves dramatically exposed to churn in a competitive market. Because “m-site” social networking on network A is an identical experience on network B. And C. Or even D. Popular social networking sites are attracting millions of unique visitors to their mobile portals every month, and while mobile data usage rises, the ARPU curve – from data usage alone – is trending ever downwards. What should be an opportunity for mobile operators can very quickly become a massive problem.

To help mobile product and VAS managers meet this challenge, we devised the Locatrix (Re)Engage Workshops. Our thesis is this: mobile operators don’t need to “introduce” social networking services – their subscribers are already there. Instead, they need to formulate and execute strategies which provide a re-engagement path, via and through existing social networking services such as Facebook, Twitter and Friendster.

Delivered in either half-day and full-day seminar formats, our (Re)Engage Workshops help mobile product managers and network executives better understand the demographic mix of social networking users, and teaches them how to create a subscriber engagement strategy by working within the social networking paradigm. Creating, for example, a framework for injecting your mobile brand and VAS solutions into social networking portals, and helping your customers promote their favorite services to their friends. And while we of course present engagement examples based on Locatrix solutions and services, there is no ongoing commercial obligation from the (Re)Engage workshop – just an opportunity to learn and refresh your strategies for leveraging mobile social networking within your subscriber base. And (Re)Engaging with your customers!

There’s more information about the Locatrix (Re)Engage Workshops on our website, but for a limited time we are offering a free half-day (Re)Engage Workshop to qualifying operators who are readers of this newsletter: simply mention “Position Update” when you contact us, or use this special e-mail link.

Most developers writing web applications for mobile devices decide to:

• Develop for the most common devices.
• Develop so that it looks “kinda ok” on most devices.
• Use hacks to get it to work on a couple of other devices.
• Somehow use the WURFL database.

Several of our solutions revolve around displaying maps. We want the maps to fit to the width of each device. We also like to know what an acceptable base font size is. We want to know as much as we can about every device, so that our solutions work perfectly regardless of device. We run Salamander behind every major (and minor!) solution we develop here at Locatrix Communications to solve this.

Salamander lets developers write layout code for all devices at once. By allowing any service to get any attributes about any device. Mobile applications no longer have to look “kinda ok” on some devices. Applications become tailored to each device. For example:

• Display size
• Supported WAP version
• Supported Java version
• Official support by an MNO
• Default font size.

The web-based front end of Salamander also allows us to instantly change and/or rollback changes on any device-specific attributes across all our solutions. Additionally, it automagically pulls community updates from the WURFL database.

To call Salamander, we simply create a new Salamander object and then query the attributes we need.

if (!isset($_SESSION['device'])
{
    require_once('/include/Salamander.class.php');
    $salamander = new Salamander("http://salamander.me");
    $_SESSION['device'] = $salamander->getSalamanderDevice($_SERVER["HTTP_USER_AGENT"]);
}

The Salamander class handles all the communications with the Salamander server. It returns an array of various required attributes for applications to query.

We then query attributes such as:

• $_SESSION['device']['baseFontSize']
• $_SESSION['device']['imageType']
• $_SESSION['device']['imageWidth']
• $_SESSION['device']['imageHeight']
• $_SESSION['device']['is3G']

From there we resize images, set font sizes, enable/disable bandwidth intensive features, etc.

Want to try out Salamander with your applications? Want to send feedback? Send me an email!