You Are Here:

Community: Blogs

Who am I?

grahamhughes

I'm a commercially-focused software engineer, with experience in developing mobile apps for global, mass market deployment.

 

Calendar

« November 2009 »
Mo Tu We Th Fr Sa Su
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30            
 

Graham Hughes' Forum Nokia Blog

Head in the Cloud

grahamhughes | 24 October, 2009 18:17

In the corner of my living room sits a Western Digital My Book World Edition II.  It's basically two 500Gb hard drives plugged into a 150MHz ARM processor running Linux.  It acts as my file server, and I have Subversion running on it too.  The drives are configured as a mirrored pair, so all the data is instantly backed up.  I can access it from my laptop, or using a Samba client on my phone.

One former colleague of mine thinks I'm living in the past.  The Cloud is the way forward.  Information stored on proper servers with proper administrators.  Information you can access from anywhere.  Information you won't lose if your house burns down.

This is all very cool, especially as I think mobile technology is very cool, and Cloud computing fits very well with that.  It means you can do everything you need, without having to have terabytes of storage in your phone or netbook, without having to have huge amounts of battery-draining processor power, and without having to have an air-conditioned room to keep all your servers.  You can reach a point where you can do your entire job, using a smart phone while sat in a coffee shop.  And not see that as being "out of the office", because you don't have an office.  And that is cool.

Now, call me a control freak, but where my personal and business data are concerned, I do like a certain amount of control.

Now, I'm not suggesting that the companies concerned necessarily did a bad job.  Upgrades are usually a point when services must be temporarily suspended, and are a great opportunity for things to go wrong.  Sometimes, hideously wrong.  That's true of a private system as much as a public one.  The difference with a private system is that you can decide when to upgrade.  You can choose not to upgrade, for example, during the last week of a project, or in the middle of a sales presentation.  At the very least, you'd like to know in advance when an upgrade is going to happen, and have the means to plan around it.

You're also at the mercy of your service provider in other ways.

They might change their business model, and stop providing the service you currently use.

They might decide to withdraw support for the platform you use.   Or, the other way around, the range of platforms the service provider supports may limit your choice of platform.  For example, in a commercial choice guaranteed to alienate many potential business customers, Dropbox supports an iPhone client, but no client for the more popular platforms like Symbian, BlackBerry and Windows Mobile.  Many services might seem platform-neutral, providing access through web browsers.  But at what point will these add some feature (probably a cosmetic feature, which you didn't want anyway) that relies on some new scripting feature that your browser doesn't support?  Assuming the service works through your browser in the first place, that is.

Then there is the issue of security.  Personally, if I discover that any of my friends or colleagues are using Google Voice, I won't be leaving them any voice mail.

Before considering a Cloud service for anything really important, there are certainly some questions I'd like to ask.

  1. Is there any Service Level Agreement?  If the service is free, then probably not.  If you rely on a free service (particularly for a business requirement), then you're asking for trouble.
  2. Can you get all the data back from the service?  Can you get it in a format you can use, say, to transfer to another product?  Remember that they might lose your data, they might withdraw the service, or you needs might simply change.
  3. Is this service the provider's speciality, or do they have another agenda?  How important to them are you as a customer?  Do you want to entrust confidential information to a company that specializes in web-searching or social networking (basically, in making information more accessible)?
  4. Where is your information going?  Geographically, I mean.  Is it covered by the data protection laws you're used to in your home country?

For now, at least, my NAS and my smoke-alarm are keeping my data safe...

Whither, BREW?

grahamhughes | 27 June, 2009 19:59

If you're not in North America, BREW might not be familiar to you.  Qualcomm's Binary Runtime Environment for Wireless is a C-based API for application development on mobile phones.  Qualcomm are the developers of CDMA (an alternative to GSM, used mainly in North America), and so BREW was initially unique to CDMA handsets.  BREW has been around since 2001.

As an API, BREW can be supported on any device.  There are, for example, Nokia Series 40 devices with BREW support.  But it is also supported directly through Qualcomm's BrewMP (BREW Mobile Platform) operating system.  Support for BREW and BrewMP is built into Qualcomm chipsets.  Qualcomm's ARM-based processors power a wide range of mobile devices.

Unlike the heavyweight operating systems of modern smartphones, BREW can be supported with a much lighter-weight implementation.  That, coupled with the ability to compile C to native ARM code, can result in higher performance than Java can achieve on the same hardware.

What's Interesting About BREW?

The BREW development process is very different from that of, say, Java.  The development kits are freely available, but before you can even install anything on your own phone, you must become an authenticated BREW developer.  This involves buying the ubiquitous Verisign signature, and so costs around $400.

Anything published must be certified and signed, without which an application cannot even be installed.  This requires submission to NSTL for TrueBREW Testing.  Last time I checked, this cost about $1000 for an initial test.  Having a build that has already passed for one device retested on another device has a lower cost, around $250.

The need for extensive testing comes from the ability of a BREW application to work at a low-level, without any sandboxing or other constraints.

With these high barriers to entry, you'd wonder why anyone would be interested.  The interesting part is that BREW provides a standardized delivery system for applications.

Once certified, an application is available from Qualcomm's servers.  Individual operators provide their customers with access to this, filtering only the content they wish to offer.  Operators can restrict access to any content that does not fit with their own brand image.  Operators like this kind of control.  Meanwhile, developers have a single marketplace that can potentially give them access to every BREW device in the world.  End users get games and applications that have all passed strict quality standards.

Qualcomm claim that BREW developers have netted $2 billion, as of March 2009.

Verizon Go Java

US network operator Verizon have historically been the biggest market for BREW devices and applications.  But at JavaOne this year, they announced that they will be opening up to the Java developer community.

The Death of BREW?

BREW's demise has been predicted by many for a couple of years now, and Verizon's change in strategy sounds very much like a vigorous nailing of the coffin lid.

But, at the same time, we're entering the Age of The Appstore, and the appstore is a concept Qualcomm pretty much invented.

Today, everyone wants "the iPhone experience".  But we all define that experience in our own way.  For some, it's the user interface.  For others, it means nothing more than having a touch screen.  Apple is pushing apps very hard as a key part of the experience.

An important aspect is: a lot of people who want the iPhone experience cannot afford an $800 handset.

BREW's ability to support limited (read: "cheap") hardware, its large developer community, and its well-established delivery infrastructure, make it an ideal platform for providing a budget iPhone experience.

So, put down the hammer and fetch a mirror... there might just be signs of life yet...

How Smart is My Phone?

grahamhughes | 25 June, 2009 17:09

I've been looking a lot at the mobile phone market over the past few months.  A lot has changed recently, with Apple and Google entering the game.  In particular, these high-profile players have increased the level of interest in smartphones.  Depending on who you ask, some 25-35% of phones out there are smart, and smartphones are expected to represent more than 50% of sales by 2012.  But... being a programmer by nature, I like to be able to define terminology.  Why are some phones "smart" and others "dumb"?

If we're asked to categorize a phone as smart or dumb, none of us has much problem associating each term with some brand names.

Smartphones:

  • Symbian
  • Windows Mobile
  • iPhone
  • Android
  • BlackBerry
  • Palm Pre

Dumbphones:

  • Series 40
  • Sony Ericsson's proprietary platform
  • Motorola's proprietary platform
  • Proprietary platforms from Samsung, LG, etc.

Why do we do this?  Is it just because the smartphone platforms have nice names?  Somehow, they seem like "proper" operating systems, because they have a brand name.  Surely, there must be some... technical reason?  I tried looking for some rules that can be applied to a candidate device, to judge its smartness.

"Smartphones Run Native Applications"

Don't think so.  BlackBerry apps are Java.  Palm Pre has no native API, so far as I know.  Android's primary application format is... well... not native.

BREW devices run native apps, but no one would say that an LG VX6000 is a smartphone.  (In fact, no one seems to mention BREW as a smartphone platform at all.  I'm sure some BREW devices must qualify as smart.)

"Smartphones Have Touch Screens"

Most BlackBerry devices don't.  Nor most Nokia Series 60s.  While most Windows Mobile devices run the Professional edition (touch), Windows Mobile Standard is built for non-touch screen devices.

Check out the Orange Vegas for a touch screen dumbphone.

"Smartphones Are PDAs"

Maybe, but what's a PDA?  A top-end Nokia Series 40 has an address book, calendar, task list, alarm clock, email client with POP3 and IMAP support, web browser, camera, MP3 player, streaming video over 3G, and can install new applications (Opera, Google Maps, etc.).  Sounds like a PDA to me.

"Smartphone Operating Systems Are Not Proprietary"

Well, except Apple's and BlackBerry's.  Oh, and Palm's.

"Smartphones Have PC-like Functionality"

Like what?  All phones have email and some kind of browsing.  Google Maps runs on everything.  Windows Mobile ships with Word and Excel, but most other smartphones only ship with viewers (if you're lucky).

"Smartphones Can Be Extended With New Applications"

So can anything that runs Java.  Nothing to stop you writing an "Excel" viewer (or even editor) in MIDP Java.

"It's About the Hardware"

Is it?  There are smartphones with no wifi, no GPS, no 3G, no touch screen, no keyboard.

"It's...a Certain Je Ne Sais Quoi"

Maybe it's a different thing for each platform.  For Series 60, it's the huge volume of sophisticated native applications.  For Windows Mobile, the "pocket pc" experience.  For iPhone, it's iTunes, and for BlackBerry it's push email.

Or maybe it really is just a brand name for the software platform.

One way or another, smartphones are "in", and every manufacturer will be trying to create the illusion of smartness for their products.

Does this mean anything for developers?  Does it mean we will all be writing C++?  Or JavaScript?  Or some new, more exotic flavour of Java?  So far, it looks like all of the above.

 
 

Rate This

 
 
Bookmark this page: DeliciousDiggFacebookGoogleYahooStumbleUponRedditDiigoTechnocratiTwitter  Share this page Share this page Print this Page Print this page Invite a friend Invite a friend
京ICP备05048969号    Email Newsletters Press Terms & Conditions Privacy Policy Sitemap Contact Us © 2009 Nokia 
RDF Facets: qdcZrelationQUxhttpE3aE2fE2fswE2enokiaE2ecomE2fschemasE2fnokiaE2fFNE2d1E2e58E2eowlX qdcZtitleQSxForumE20NokiaE20BlogsE20WebE20SiteXLen qdcZtitleQSxForumE20NokiaE20BlogsE20WebE20SiteXLen qdcZtypeQUqfnZE44istributionQ qdcZtypeQUqfnZSiteQ qdcZtypeQUqvocZTermQ qdcZtypeQUqvocZVocabularyConstructQ qdcZtypeQUqwebZSiteQ qdcZtypeQUqrdfsZE52esourceQ qswZserviceQUxhttpE3aE2fE2fswE2enokiaE2ecomE2furiE71aX quriE71aZserviceQUxhttpE3aE2fE2fswE2enokiaE2ecomE2furiE71aX qvocZpartOfQUqfnZPublicationQ qwebZserviceQUxhttpE3aE2fE2fswE2enokiaE2ecomE2furiE71aX qrdfZtypeQUqfnZE44istributionQ qrdfZtypeQUqfnZSiteQ qrdfZtypeQUqvocZTermQ qrdfZtypeQUqvocZVocabularyConstructQ qrdfZtypeQUqwebZSiteQ qrdfZtypeQUqrdfsZE52esourceQ qrdfsZisE44efinedByQUxhttpE3aE2fE2fswE2enokiaE2ecomE2fschemasE2fnokiaE2fFNE2d1E2e58E2eowlX qrdfsZlabelQSxForumE20NokiaE20BlogsE20WebE20SiteXLen qrdfsZlabelQSxForumE20NokiaE20BlogsE20WebE20SiteXLen qrdfsZseeAlsoQUxhttpE3aE2fE2fswE2enokiaE2ecomE2fschemasE2fnokiaE2fFNE2d1E2e58E2eowlX