Here are some of my notes from the evening…

• Audioboo has managed to get 38,000 users in 10 months.
• Is the async side of voice a missed opportunity?
• A challenge for small developers working with voice is that IP is tied up with large companies.
• Another problem is the large volumes of data that need to be handled.
• Skype has an open source codec.
• Voice is becoming a new input method for applications (can choose to speak rather than type on Android keyboard).
• Similarly, voice will become a new application output method.
• Nuance app (their iPhone app) sends data to the server for recognition. Unable to do recognition on the phone as it is not powerful enough and vocabulary/accents variants would take up too much space. (Their iPhone app has had over 3 million downloads)
• Nuance are open to sharing voice technologies via SDK.
• On H3G, network capacity consumed by voice is much less than that used by data (due to dongles I suspect).
• H3G are already seeing voice being substituted by sms, email, IM, especially in younger age groups, as it’s seen as cheaper.
• Why hasn’t visual voicemail (controlling voicemail via app) become ubiquitous? Hard to get compatibility across all handsets. No standard API that works with all carrier messaging systems.
• Why does H3G use normal phone call for Skype rather than VOIP (more details in my previous post)? To guarantee good call quality.
• Voice recognition (Nuanace) works well in ideal situations but not so good in noisy or (network) bandwidth limited situations.
• There may be a social barrier to using voice to control things in public places. It may need social acceptance.
• It has been shown that people can’t do complex tasks using audio. We aren’t wired that way.

Related Articles:

• Voice 2.0
• 3 SkypePhone

However, this doesn’t mean they can’t be used to write certain types of application. One requirement I am increasing getting is from small/self publishers and brands who want to publish information (usually on the iPhone) without actually interacting with any phone specific features.

This can, of course, be done on the web without an application but you lose the discoverability that’s provided by an app store. However, some might argue that, with 140,000+ apps, iPhone apps have also lost the ability to be easily discovered. Coincidentally, Taptu’s (the mobile search people) latest metrics show there’s growing life in the mobile web.

It’s possible to use one of many (paid for) online iPhone app generators to auto-generate an application. However, in many cases you will want more control than the templates provide.

It’s actually relatively easy (and free) to create a more customised app for the web or for the phone. Start by looking at jQTouch. It’s probably the best plugin/library that allows you to write html pages with an iPhone look and feel. This will get you a great mobile web app with minimal effort.

If you need an installable application as opposed to a web application then take a look at PhoneGap. I was once wary about using frameworks like PhoneGap and Rhomobile because of the problems with Apple rejecting applications because they were using 3rd party frameworks. Since then, lots of lobbying has made PhoneGap (v 0.8.0) officially permitted on the app store so I now take it more seriously.

It’s possible to use jQTouch within PhoneGap. There’s a very recent tutorial at tutsplus. Also, if you are quick, there’s a whole O’Reilly book online (for review) at the moment on building iPhone Apps with HTML that includes a great chapter on including jQTouch within PhoneGap.

Related Articles:

• 509 Bridges the App Web Gap
• iPhone Push Notification Tutorial
• Rhomobile and App Store Rules
• PhoneGap on iPhone
• iPhone Runtimes and Interpreters
• Rhomobile Cross Platform Ruby Framework

 
You can join via the registration page. New registrations are moderated but after that, new ads aren’t and are shown immediately. The Platform APIs page explains how to go about adding the links to your mobile web page or application.

Please let me know if you have any problems or new ideas. The Mobile Advert Network is something I want to slowly evolve and refine over time.

5o9 told me that their view of the future is that for mobile to really take off the web has to know the end-user better. This means that web browsers need better access to phone features.

If you go to the 5o9 web site you can learn more. However, what it doesn’t say is how this technology works and how it might be integrated into your mobile solution… so I dug deeper.

The 5o9 solution is a simple mobile application that can share critical meta data (without the need to type it in) with any web app in the world. It works by extending the HTTP protocol with new customizable HTTP_X headers. At the server side the data is accessed via php, perl, asp or whatever you like. In addition, menus options can be added to the browser.

5o9 actually provides a set of complementary tools…

• A web browser helper application that injects extra http headers containing phone information (location etc) into a http request, that can be read at the server. It also improves the UI of the browser to make it more contextually aware just like a mobile application. The web browser UI is also programmable from the web server side with existing server-side skill sets.
• The simple application I mentioned is auto generated via the online ‘Maggie’ tool. You get the auto generated source code that allows you adapt (for example brand) it to your own needs. End users can install multiple mobile (Maggie generated) apps and they all communicate to the web server via the browser helper object.
• JSAPI for Windows Mobile, Symbian and iPhone solutions allows you to write Javascript to access the device side capabilities. You can see how this works by going to http://www.5o9mm.com/jsapime.htm and do a view source.

The licensing model is currently free for Windows Mobile & BlackBerry. Customised versions for all platforms are available for $5k per platform (you get your own brand and specific data sets, plus more contextual menus). Real time encryption and content acceleration starts at $15k per server. If you are an ISP or MVNO and want a site license to install it on everything then they can accommodate that as well

Some people think that the future of mobile is the web. Until such time, technologies such as those offered by 5o9 can be used to bridge the gap.

Speaking to operators, I get the feeling that some of them realise that it’s getting increasingly difficult to be part of every service offering (music, maps, apps etc). In 2007, I wrote how five years earlier, I had been to an Ovum presentation where they predicted today’s events.

However, with bandwidth becoming sparse, there will be opportunities for networks to differentiate themselves through providing different size pipes for different types of data. Operators are already starting to understand the types of (application) data traffic going though their networks. For example, email doesn’t need the same priority as video. In the future, some operators see themselves as offering prioritised data services to end users or even in partnership with companies such as Google and Apple who will come to depend on more reliable connections for particular types of data.

Related Articles:

• Carrier Uncertainty and Doubt
• Carrier Strategy
• What are Operators Doing to Support Developers and Innovation?
• Android for Network Operators

In my spare time, as a hobby activity, I have been working on a mobile link exchange. It allows text links to be placed on mobile web sites or within applications. Each request for ads returns two ads. Showing someone else’s ad gets you a credit for displaying ads on yet someone else’s site or application. So, for every view by your end user, you get up to two ads shown on other sites or applications.

I am looking for a few people to try it out. It works on wml, xhtml, iPhone, Symbian, Android, Blackberry and Windows Mobile. In fact, it’s possible to swap ads on one platform for ads on another. It’s also possible to target ads by country and network operator.

The system supports static mobile web pages, via javascript, where end users have javascript available. Alternatively, I have examples for use from php, cgi (perl), jsp, classic asp, c# (.NET) and vb (.NET). I also have tips how to integrate into the various mobile platforms or use the HTTP GET or POST API.

I’ll post another time on how it was built. I had to think carefully about supporting lots of requests per second as well as serving ads very quickly. I wasn’t able to use CGI (php or perl) nor conventional databases.

Meanwhile, if you are interested in being one of the first people to give it a try, free of charge (the final service will also be free), then please contact me at simon@simonjudge.com explaining who you are and a bit about your mobile site or application.

Related Articles:

• Paying to Promote your App
• UK Mobile Advertising
• Mobile Advertising
• Monitising the Mobile Internet
• Ad-Funded Model
• Monetisation through Advertising

This shows that it will be ‘business as usual’ for Java ME.

Oracle have also announced they will be unifying Java ME with Java SE to revive the "write once, run anywhere" ambition. I suspect the Android Java implementation has had something to do with this decision. It shows how close a mobile Java implementation can be to Java SE.

However, I am sceptical we will ever get "write once, run anywhere" not just between server and mobile but between mobile devices. Mobile device capability varies too much. A new ‘more Java SE’esque version of Java ME certainly wouldn’t be compatible with existing phone runtimes. Also, old Java ME applications wouldn’t be (source code) compatible.

Oracle’s plans mean that there is likely to be a large compatibility break in mobile Java in the coming years. A break to a newer, more capable mobile Java is certainly what’s needed. However, I question how long this is going to take?

Related Articles:

• Java ME Still Strong
• Java ME Add-Ons
• Future of MIDP3 and Java on Symbian
• Java Verified Tips
• Oracle and Appforge

From a mobile developer perspective they will be introducing the Samsung Galaxy (Android) by the end of March. They have six Android devices planned in the medium term. It was interesting to learn that network data is still being dominated by PC dongles. Any contribution from Smartphones is small and is expected to remain negligible compared to dongle usage.

3 sees itself a differentiating though openness. For example, while some other networks are wary of Spotify, 3 has an open attitude. It was also interesting to know that 3 has tens of thousands of iPhones on its network even though it doesn’t sell them. People have moved from O2 when their expensive tariffs have expired.

Related Articles:

• UK 3 Openness and Innovation
• 3 Mobile Broadband
• Rise of the Chinese ODM
• 3 SkypePhone

There’s also another issue with using cloud services for mobile. The problem is well described by a non-mobile article that was published yesterday…

"Second fundamental rule of cloud deployments: All machines will be affected by the same networking and IO constraints

Amazon lets people get pretty big virtual boxes in terms of processor or memory power. However, IO and networking are a completely different issue. For in-house data grid deployments, getting a separate set of network cards and putting them on a dedicated VLAN or even their own switch is a really good idea, because of the broadcast traffic between the nodes. You can’t do that on the cloud. Putting a card with hardware TCP offloading is not an option (and broadcast is also not an option at least on Amazon, but that’s another story). So the architecture has to work around this. Bottlenecks can’t be just solved by getting better hardware. Beware of this while designing an architecture that depends on all traffic going through a single file server, database machine or load balancer. If all the traffic goes through a single point, the entire capacity of the cluster will be limited to that machine’s IO or network constraints (which is probably shared with who knows how many other virtual machines on the same physical box)."

With most mobile applications, with many phones regularly reporting status to a server, IO and network constraints can be more of an issue. The problem with the cloud is that you are sharing the server IO and network capacity with someone else. When you start asking how much available IO and bandwidth you will get, what happens when this exceeded and how to detect when this exceeded, things usually tend to get a bit vague. The bottom line is that you can’t assume, just because its the Cloud, that you have unlimited server IO and networking bandwidth.

For very busy mobile services you get more control and more certainty if you can control network cards, switches and bandwidth. However, whether you use the cloud or not, you may eventually run out of IO and bandwidth. The article I referenced, mentions the solution… "Partition, partition, partition". You need to design for scalability. What does this mean? Well, think about your service and split it by type of user, category, geography or whatever makes most sense. While not mobile specific nor cloud specific, there’s a great pdf about ebay on how they have partitioned the system in various ways over the years.

The article nor Continental Airlines explain why this is the case. Maybe people implicitly expect to browse to other sites when using a web browser as opposed to not wanting to leave an App because they are using it for a specific purpose?

Related Articles:

• Paying to Promote your App
• UK Mobile Advertising
• Mobile Advertising
• Monitising the Mobile Internet
• Free vs Sold Applications
• Monetisation through Advertising
• November MoMo London: Ad Funded Mobile Services