Robin Jewsbury's Forum Nokia Blog

Head for the Clouds - advice for Budding Entrepreneurs

Sat, 07 Nov 2009 10:21:37 +0200

A month ago, I started my second startup and whereas I now know all the things I should not do again, I can say its just as hard this time. I continue to make mistakes but at least I've learnt from the previous ones and they're different mistakes this time. I thought though for all the other aspiring entrepreneurs out there it's worth blogging about some of my experiences. In this first article I describe my choice of where and how to host my new service.

In our previous startup, we'd used a managed hosting service from Rackspace from a server farm here in London. Rackspace have always been good and we had no complaints. They're ideal for what we wanted: they provide a server(s) which is/are 100% ours sitting in their server farm in a resilient network and have excellent "fanatical" support. The only gripe has been they always seemed a bit expensive and it seemed a big bill to pay on day 1 o f a startup, so when I started this time I looked around for possible alternatives.

An obvious starting point was to look at cloud services. An advantage for brand new startups is that they are really low cost at the beginning and they grow and scale smoothly as the service grows. My selection list took me eventually to 3 possibilities:

Amazon EC2,
Google AppEngine,
RackspaceCloud

Amazon and Google are similar in that they abstract away the database functionality in programmable objects so you do not deal directly with the database in the way my own old fashioned mind expects. For a brand new startup with no legacy code this is the ideal because the new system can be programmed directly for that system. But the issue is also it potentially locks you as a developer into one particular solution ie the Amazon way or the Google way. I did spend several days playing with the GoogeAppEngine and was very impressed. The development environment is all built into Eclipse and writing, testing and deploying code is really just a few clicks and its live. For about a week I thought this was the way and I was planning to take my code and abstract out the database and file storage layers so that I could interface with GoogleAppEngine. Incidently GoogleAppEngine has no mechanism to talk directly to the filing system and I was a little uncertain about this as it could lead to issues for my software which stores large number of images directly in the filing system.

Playing with GoogleAppEngine was free because below a certain threshold there are no charges for use - so this was also ideal for me.

However, I then looked at Rackspace Cloud and suddenly I felt more at home with the approach they had taken simply because it matched the approach we'd taken in the previous startup. With RackspaceCloud Server you get your own virtual server. You buy from them the number of (or fractions of) CPUs you want and disk space you intend to use. The lowest price is very affordable(although not free as with Google). On this server you install what you want - in my case Apache, Tomcat and MySQL server and hey presto you have a fully working service and the legacy code I had which used this directly just worked first time without any modifications needed. Incidently Rackspace have two other services called Cloud Sites and Cloud Files which are more akin with the Google and Amazon approach or taking away direct access to the low level access to the database and filing systems.

Finally, there is the issue of latency. Google and Amazon are world scalable services, but RackspaceCloud is currently only available from their Texas data centre (although its due to be installed in London next year). With Amazon you can choose for your servers to be located in the US or Europe - with Google its unclear where they are sited.

With some concern on this issue I was able to make some measurements on latency comparing the same service running in Rackspace in London with the service running in RackspaceCloud in Texas. The graph below shows the findings:

My conclusion was it was acceptable for a world service to be served from Texas - although serving from London is slightly better overall. The major users of my service are from India and the US. Serving from Texas is really poor for India but obviously for the US serving from Texas is good.

So overall, advice for new startups is think about these new cloud services. They really give you a good cost effective and scalable service. If you're brand new to the game and have no baggage then Google Appengine may be a good choice; if you have existing code and technical approach then services such as RackspaceCloud Server are worth looking at.

For more established startups I recommend moving some of your service onto these cloud services as there will be significant cost savings. Because of my experience with this approach my friends still running my previous startup have done just that and are already saving thousands of pounds in hosting and bandwidth costs.

If people find these sort of posts useful I will be doing more like this after the next few months.

Publish to OviStore hints and tips from a real user

Thu, 24 Sep 2009 22:00:48 +0300

Refresh Mobile

I've just been to a Forum Nokia developer event here in London. It was very well organised and well attended. I can say there was a real attempt and promise that Nokia are trying their hardest to solve as many issues to help developers as possible and I really believe they are doing good work here. There was some friction in the room when issues to do with developers, the Ovi Store QA Process and Ovistore in general and I realised I should do this post which gives a few hints and tips on using the Ovistore. Just a bit of background. I have written and submitted more than 20 apps to Ovi store, 3 to iPhone Appstore and more than 20 to Blackberry Appworld and do think I can put all the issues into context of what its like with all the appstores.

1) The QA process is frustrating on all the appstores. In fact by far the worst is Apple in my personal experience. One issue is they all fail to explain the real reason adequately for a rejection - its seems to be in everyone's system that they send a standard e-mail rejection where the reason for the rejection is unclear, So Ovistore is not bad in this context -it could be easier though.

2) On Ovi your app needs a certificate if its Symbian or Java but does not need a certificate for WRT. So, for ease of submission I'd recommend WRT (although the number of handsets supported is fewer than a Java submission for example. Then the question is how to sign it. The answer is you can self sign (forget java siged) and I'd recommend using the Thawte certificate for Java not a Versign (Thawte is cheaper anyway). Both have issues - neither have root certificate on all devices. But Thawte is best. If you use Thawte then deselect the following handsets 2730, 3208, 6263, 6600i, 2720 fold, 3710 fold, 3720, 7020 and 7050.

3) WRT and the N95. The N95 had WRT support in later versions. In reality most people have upgraded and therefore its usually safe to select the N95 and N958G, but it seems that sometimes the QA people don't know this and sometimes get rejection from them which you should sort out by commenting back to them. A further problem occurs with N95 because you often you get "content missing" in Ovi store if an N95 tries to download a WRT (this is simply a bug in Ovistore which I am sure will be fixed sometime soon).

4) QA is only part of the process to getting your app live. It can take up to a week for it to actually go live after it's passed QA before it appears. If you watch the "Published to" flag it will initially say 0/1 channels and later say "1/1 channel". When it does this it means its about to go live... it still takes up to a further 24 hours to actually appear. People often think its not there when it really is, because it depends which devices you published it to. So you should really look with a real phone (or use a user agent switcher plugin inside Firefox). Finally there are often cases with content which never appears in these circumstances. This is because someone in Ovi made a mistake (of course in a well designed system it should not be possible to make this sort of mistake-but I'd better not go there). In this case just fill out a comment in the content in publishers. I find they are helpful and you'll get a solution.

5) Finally depending on your content you may get the "sensitive content" email. This happens for example if you have pictures of girls in bikinis or even men in shorts in your content. Your get a list of contries you need to de-select (mostly moslem countries). This list is annoyingly long and the chances are you'll make a mistake entering the selections for the list. For until they have a "sensitive countries template" you'll have to live with this frustration.

Live from Nokia World

Thu, 03 Sep 2009 12:16:36 +0300

First thanks for all the kind remarks about us winning the calling all innovator internet innovation award 1st prize.... we're all very pleased with that result. It was a lot of hard work and its great to get something back.

Meanwhile this morning there's been a raft of interesting announcements. The Ovi Maps API looks really good and very powerful, Nokia Money have teamed up with Obopay to enable bank payments for billions of new users and finally facebook announced their new connection APIs for use with phones in applications and from the mobile web.

All very exciting. Yesterday's most interesting annoucements for me with the new N900 linux based phone which is sure to compete well and amazingly will appear as soon as Oct and the X6 phone which finally has a capacitive touh screen - its the way forward for Nokia.

Dawn of a new age for software development for phone applications

Sun, 19 Jul 2009 13:26:17 +0300

This week Palm has finally released their SDK for Palm Pre development and Google have continued in their announcements that web technologies will be the eventual approach for mobile phone development. Nokia's WRT technology is now well established and grown signficantly with S60 Ed5 services APIs. Meanwhile the real issue with this technology has been the speed of execution of Javascript is being solved using better Javascript engines and the emergence of new HTML5 functions allows browsers to get closer to native speed execution.

The common approach of all these methods is to use HTML, CSS and Javascript as the basis for writing applications. Each manufactirer is enhancing their Javascript libraries to so that there is API access to system functionalities such as media, sensors, GPS, address book and other core phone functions. Where some manufacturers have not opened up their APIs yet (eg Apple) other group are providing frameworks to do so (eg Phonegap providing plaform access for iPhone and Android).

Additionally W3C have their own widget development metholdolgy which is being supported by a number of operators via the jil.org. Ths technology is very close to WRT and indeed they provide very good tools to convert between WRT and the W3C format.

My own view is there is now a need for someone to create a framework sitting on top of all these technologies - they are all amost the same/compatible with slightly different wrappers and different syntax for the APIs. The real need for all developers is to write their applications only once for all platforms - a framework can take away these diferences.

My own experience of working with these technologies is to develop using Nokia's WRT to create working applications. I then use Phonegap to create the same applications running the same code on iPhone. Its not as easy as it should be - there are all sorts of gotyas, for example scrolling is done differently on iPhone and Android to how normal browsers work, but it can be done and its the future for a new way of doing software development.

N97 Homescreen Widgets

Fri, 03 Jul 2009 17:09:36 +0300

The N97 has a great new feature called Homescreen widgets. I thought I'd write a little here about what they do and what is involved in developing them.

So yesterday we announced that we have just released 4 homescreen widgets for the N97 and here they are shown in the screenshot below...

These widgets show the latest news for each subject area which in order above are News, Celebrity Gossip, Gaming and Tech News.

So you may ask what can homescreen widgets do? They can show dynamic content on the homescreen. In our case every 6 seconds we show a different story. The widgets can be written in C++ or HTML/Javascript and CSS - guess what the latter is much easier and that's what we use. Each widget is just an area of the screen - in our case 312 pixels wide by 91 pixels high. The graphical elements are just layered on this canvas and the content can be changed in anyway you like. There are just two restrictions:

Flash content is not allowed (which is a shame)
Any programmed interaction with the screen is translated into a single event to run the widget in full screen mode - so don't bother putting any links on the home screen they will not work.

So that just leaves you with issues when writing these things. The biggest issue is battery life and the biggest consumer of battery is going online. So you need to ensure all the content is cached and it does not need to go online continuously to get content. Fortunately Javascript has an object called Image which can store binary content and we use this to show the content on the homescreen. We only go online every 30 mins to check for the latest internet content (the user can change this value though.

Finally there's one extra trick we perform. WRT technology allows the storing of text content on the memory card, so we ensure all the text content is saved all the time. This means that if you go on a plane and have to switch your phone off, then when its back on in offline mode the application still works seemlessly. So you can always use this application and no matter what you do there is always something interesting for you to read.

Now all you developers out there may be asking how all this was done under the covers and for you the great thing about WRT is that you can read all my source code inside the application to see how I did it (although please take note of our copyright statement)- sorry if am a bit untidy sometimes :-(

All 4 widgets were submitted to Ovistore at the same time but only 1 made it to live so far (they told me they are very busy), so for now I've provided some links below and when Ovistore does publish all of them I'll remove these links from this story.

Downloads for Nokia N97, 5800 / 5530 (NB only N97 has the homescreen functionality, but it runs on all 3)

Download News Buzz widget

Download Gossip Buzz widget

Download Gaming Buzz widget

Download Tech Buzz widget

Porting Madness - square plug round hole.

Tue, 12 May 2009 16:44:29 +0300

I am amazed as the sudden interest in what's involved porting of applications between different manufacturers smart phones technologies because I really think something is being missed in many cases. Why would you want to port code between platforms? Why develop the same thing 4 times because down the line you'll have to maintain 4 different code bases? Why not develop cross platform in a single code base and use wrappers to cope with each platform idiosyncrasies? So when I say 4 platforms I am saying iPhone, Android, Blackberry and S60 (we'll leave Microsoft out for the moment but it would fit in this list at some stage).

This reminds me of a situation I was in a few years ago when we were developing an application which worked on a majority of phones. We had 12 variants of the J2ME version and 2 Symbian variants too. It ended up with 3 major code bases and with the Java one being divided into the 12 variants. It was a nightmare to deal with in terms of development, maintenance and testing.

So when would I recommend actual porting between technologies. Only in 2 circumstances:

1) When code has already been written in an existing technology (ie converting a legacy application)
2) When a display rate of greater than 2 frames per second is required (eg for fast moving games)

As developers we strive to write code only once for all platforms. This not only has the advantage of only having to write core code the first time but most importantly that the code is fully maintainable in a single code base. J2ME used to promise this capability, but the iPhone has completely destroyed this. So until recently the fragmentation of technologies in the different devices has made this impossible but the emergence of using web technologies with javascript and css has now made this a reality.

For all other cases I would recommend every developer consider web technologies for creating cross platform applications.

So how can this be achieved with the diverse platforms we have. This is how its done...

For iPhone use a native objective-c wrapper to host the web application which can have local and remote html, javascript and css. The best native wrapper to achieve this is using a project called PhoneGap (www.phonegap.com).

For Android use a native Java wrapper to host the same local/remote web application. Again use the android version of PhoneGap to accomplish this.

For S60 Ed5 touch phones use WRT again with the same local/remote web application. In this case to cope with a remote component Ajax or an iframe can be used.

For S60 non touch phones use WRT too but be aware that iframes do not currently work properly and additionally code for handling keyboard events needs to be added.

For Blackberry the situation is very fluid as the current technology does not work properly, but this is supposed to be fixed very soon and at this stage again I would recommend using Blackberry PhoneGap as the Java wrapper for web applications. Currently Blackberry PhoneGap does work but the web control used to display web pages currently ignores all formatting so it makes it pretty much useless. When this is fixed (note this is a Blackberry issue) it will only be available to latest devices.

So how do you write the cross platform web applications. In general there is good consistency between the support for Javascript and CSS across iPhone, Android and S60. So you can write code once and run it everywhere. You need to be aware of screen size and there are two approaches to ensure good behaviour. Firstly you should try to use CSS styles like "width: 100%" where possible. This is needed both within the application as well as support between devices - within the application support for portrait and landscape modes helps if you use these styles. However there are times when you need to know the screen dimensions so the following 2 variables are very useful:

var screenWidth = window.innerWidth;
var screenHeight = window.innerHeight;

These variables need to be set on a timer to cope with switching between portrait and landscape modes - there is no consistent javascript event to detect this scenario currently. Once you know the screen size then the font size can be set using Javascript to change the CSS style sheet. This is need for the S60 Ed5 phones with 360x640 pixels - in this case we would have a command "font-size: 170%" just get the font readable on these devices.

Meanwhile some of the PhoneGap developers are creating a common layer of Javascript code to deal with the native APIs for accessing GPS information, the address book and saving data locally. They do not include S60 but the translation between the two approaches is not too difficult. In fact saving data locally can be achieved purely in Javascript for iPhone, Android and S60 WRT apps and does not need the native wrapper involvement.

Conclusion:

Think twice about porting. If you can write your code just once then this is a major advantage. You just need to ensure that you screen does not need to update too quickly.

Decline of US Newspapers

Tue, 31 Mar 2009 11:01:08 +0300

There was an interesting article in Techcrunch yesterday on the decline of the US Newspapers.

Obviously we have heard this story for some years now but two things struck me. Firstly the declines are increasingly rapid and more importantly the decline are in online too. I think that the decline in online is an indication that the newspapers are failing to monetise their content in the online world. I think we all know that online consumption of news is increasing and this is at the expense of print. Furthermore the opening up of mobile content consumption through products such as our own are also reducing the need to for users to take their news via print and there are environmental benefits - removing the piles of paper waste littering our streets. It just needs the content owners to work out how their content can be monetised. Obviously we feel quite good about this as we have quite a successful route for monetisation for publishers through ad impressions.

Furthermore a billion people will be coming online via mobile in the next 4 years so its only worldwide growth or the content industry.

Automatically distinguishing between a phone and a PC on a website

Sun, 29 Mar 2009 15:29:54 +0300

Despite browsers on phones getting better and better there is still a need for Mobile formatted sites, if not just for lower end phones, but for those on high end phones that hate the waiting or the difficult navigation of the full web on a phone.
Once you acccept this the next stage after creating your mobile site (which is easy with products such as Mippin) is how does your site detect between a phone and a PC.

We get asked this question several times a month by publishers big and small. How to automatically distinguish between phones and pcs and send them to the right version of their websites. Unfortunately there is no simple answer to this question because these publishers have substantial PC users and want to do the detection without degradation to their PC website performance - so they need to do the detection on their own hardware. At the same time there is not enough standardisation on the server-side to make it a simple answer.

However, we have fully documented several approaches and we detail them here. There are 3 approaches:

1) Don't make it automatic. Just create a domain name m.yoursite.com or yoursite.mobi and send them to the right site. However, this is not very user friendly.

2) The next approach is if the publisher is using Apache servers there is a script that can be put in place. This script is here.

3) Finally for those using Wordpress we have a specific solution for wordpress owners. There can install a plugin which does it for you. Details of this plugin are here.

Note that these script are all geared with pointing the user at Mippin as the mobile rendering of the site, but this code is open and its easy to change the code to point at any mobile rendering so you are not forced to use us.

Google's Mobile Strategy

Sun, 08 Mar 2009 15:20:11 +0200

I watched Eric Schmidt on Charlie Rose last night - very interesting. Nearly all the talk was about the importance of Mobile in Google's strategy. Eric explained how Mobile was taking over from the PC in Internet access and as he said he saw another billion phones being sold in he next 3.5 years. In fact this statistic struck a chord with me as I have a site called phonecount.com which tracks the mobile phone growth and predicts 2.5 billion extra phones by mid 2012 (I wonder if he took account that the population of the earth will also increase by a billion in the same period). Now I am sure my approach to calculating this increase is flawed as I just do a linear projection on current increases and I assume lots of people will have more than 1 phone too, but I do think whereas my estimate is perhaps over optimistic Eric is under-estimating hugely. Does anyone reading this have better figures so I can make my numbers better?

Meanwhile I was also impressed by Eric's description of the need for content being implicitly personalised for users. By this he meant that the Internet server should know what content each user is interested in and exclude what they have already looked at and push that content to them. Again this struck a chord with me because this is precisely what we are trying to achieve in my own company - so perhaps we have our own strategy right :-).

Another interesting fact he mentioned was because of Moore's law our phone's storage....

" in 15 years, it’s a thousand times cheaper and faster. So unless something changes in 15 years, I have a grandson, he’ll be 18 in 15 years. He will have all of the world’s information, every video, every movie and so forth on a single hard drive. If he started watching it, he cannot finish watching it in 85 years. He’ll always be frustrated."

This is a fascinating fact. Could this mean that in 15 years time our phones will have the world's information resident on the phone. Then all we need the Internet for it how that information is changing. This offline/online approach to using data requires a re-think to how we use the Internet and the software on the phones themselves. I can see a few new businesses being created based on these new concepts :-)

An US centric view of Mobile by Marc Andressen

Sun, 22 Feb 2009 11:12:06 +0200

There is a really interesting interview with Marc Andressen on the web. There were two things in the interview which I struggled with. First he predicts the death of the print industry in favour of the Internet delivery and the other one was his glowing description of the iPhone.

Whilst I'd love it to come true I find it hard to believe that the print industry should close their presses and put all their effort into perfecting Internet delivery. But this certainly has made me think. What will it be like in 10 years time? I do think that devices which emulate the ease of reading on paper will be more prevalent (in fact the phone will will be that device). So in that sense a dramatic change for all forms of publishers (from brands down to bloggers) is about to happen, but I was shocked by the statement that the New York Times should close its presses now.

The other part of the interview which made me think was his description of the iPhone. He described it as the first phone to have a full operating system and said it had been beamed in from 5 years in the future. He mentioned RIM and Windows Mobile as other smart phones but did not mention Nokia or S60. Why? I find it quite frustrating that the American view of phones is so different from the rest of the world. Why is Symbian not viewed as a full operating system? He also described the developers eco-system round the iPhone as being a first too. I have a mixed feeling on this. Firstly, he seems to have ignored the fact that Symbian is as a full OS as the Unix on the iPhone. He ignored that its been possible to develop fully fledged applications for years on S60 and then sell them (allbeit through 3rd parties). However, Apple do currently seem to have a more complete end to end developer eco system which Nokia is now addressing with Ovi Publish. It is a shame that the US view of the world seems to have ignored the achievements of Europeans, but I guess we have to keep trying to get everything right.

Perhaps it will be Europe which gets the solutions to the print industry moving from paper to the Internet right.