Nokia Is Keeping Things Interesting

Stephen Elop, CEO @ Nokia

Nokia announced today it was making Windows Phone its primary smartphone platform. If you look at the Nokia stock price you might guess that the company just made a fatal mistake.  But, that’s probably far from the case.

Gartner says Nokia currently has about 37% of the smartphone market share, and Microsoft has about 4%.  Two turkeys may not make an eagle as Google’s VP of Engineering, Vic Gundotra, quips but if Nokia can keep the numbers that high with Windows Phone, they’ll make a lot of turkey dinners for a lot of people.

Supper Is On the Table. Eat While the Food Is Hot.

My attitude toward mobile development is this: any platform, any mobile device, any market, any time. If you’ve locked yourself into a single platform you tend to get worried if your mobile platform of choice isn’t king.  I avoid that trap completely by mastering as many platforms as humanly possible.  If it computes and you can hold it in your hand or embed it, I’m interested in it.

With Nokia/Microsoft blending forces, it feels as though me and my clients just gained a few billion potential customers.  Hey – the more mobile marketplaces and platforms for me to write software for, the better.  Nokia and Microsoft in effect are going to open up more mobile software markets globally.  Nokia already has a very strong global distribution and sales network for cell phones.  And both companies have the ability to host and manage vibrant mobile software marketplaces to the world’s masses.

I know that no matter what, regardless of the platform that’s “hot”, I can literally turn around in my chair at work, look at my co-workers and know that a software product can be written for it.  I work daily side by side with crack iPhone and Windows Phone developers.  As a team we round out quite an option for people wanting to get mobile software written: Android, iPhone, Windows Phone, Blackberry, WebOS, Symbian … you name it.  Including devices that aren’t even on the market yet.  Elop and Balmer hinted at their future hardware platforms as well, but that’s another story.

A 100,000 Cooks Are About To Show Up.

In working with Nokia, Microsoft will garner the focus, over time, of more than 100,000 Nokia workers who will want to keep Windows Phone alive.  They’re going to keep the Windows Phone software marketplace alive as well.  And that’s a good thing all around.

And to Elop’s credit, he hasn’t handed the keys to the kingdom over to a Microsoft platform completely.  Nokia is going to keep its own projects like Meego and Ovi alive.  Who knows ….

we may even see a version of Qt available for Windows Phone in the near future.  Now that would be pretty cool.

Why Nokia and Microsoft, You Ask?

That was seemingly a big question revolving around today’s press conference, and David Murphy from Mobile Marketing Magazine asked just that at four minutes, eight seconds (04:08) into the presentation.  Why not Android, he simply asked.  Elop had an answer of course, but it was just as telling about Google as it was about Nokia’s hardware platform.  Elop had this to say:

If we tipped over into the Android ecosystem and there was a sense that that was the dominate ecosystem at that point, the commoditization risk was very high:  prices, profits, everything being pushed down.  Value being moved out to Google essentially which was concerning to us.  So the Microsoft option represented to us the best opportunity to build and lead and fight [emphasis his] through a new ecosystem that we take into the marketplace.  Remarkably complimentary assets that in totality is going to offer consumers tremendous choice and a great option in the marketplace.

This tells me a couple things which I was surprised about, and which Elop and Balmer reinforced at various points in the discussion.

First, Nokia simply seems to have gotten a better deal in working with Microsoft.  There were concessions made on both sides.  Yes, Nokia is going to pay licensing fees to Microsoft for the platform.  But at the same time, there seems to be an arrangement worked out where Microsoft will be also sending money back to Nokia to get access to Nokia’s hardware and software innovations.  Very interesting.

Second, “Remarkably complimentary assets” to me is a code phrase for “Nokia knows its hardware stack limits its choices of OS.”  Nokia can’t afford to choose an OS that won’t possibly work on it’s limited hardware stack.  That would be worse than anything.  I’m grasping at straws here, but it’s possible.

Turkey Dinners Are O.K.  But TurDucken Is Just Wrong.

Put the wrong OS on Nokia’s hardware (current or planned), and you’re likely to get something equivalent to turducken.  Something that technically can be made but just plain sucks.


Elop seems to recognize that Nokia is forced to put a new operating system on its hardware now, and I mean right now, that will function and function well.  It’s very possible that the other platforms Nokia was considering would have demanded too much performance out of Nokia’s hardware to run.  An entire software ecosystem after all, demands a lot of a mobile device.

Whenever I hear an executive at a cell phone OEM speak about fitting a complimentary OS on top of the available and planned hardware, it tells me that the executive is aware of the limitations of his company’s hardware.  That’s pretty smart and realistic.

Time will tell if all this is the right decision.  As for me, I’m just glad to have another mobile marketplace to write software for.


Image sources: wikipedia,

Some Mobile Software Product GPS Best Practices

Here are some GPS best practices I’ve put together for Android.  It can apply to other phones as well.

GPS Failures

My uncle, Gary Barett, is a PhD in electrical engineering and a GPS engineer as well.  He’s a really sharp guy and available for hire, BTW (if you need a GPS expert let me know – I’ll hook you up).  During his career, he spent a lot of time working on GPS when it was relatively new.  Gary has, in his career, spoken with one of the few people at the DoD who really understands GPS. So, when it comes to GPS he really knows his stuff.  Here’s what I learned from Gary about some common reasons why GPS fails.

1. Antenna Movement.

GPS antennas work on phase shifting (look it up if you don’t know).  GPS transceivers and their antennae are very sensitive to movement.  So, if your GPS unit is on a boat, a buoy, a bouncing car, or you wave around your GPS enabled phone like an excited Italian trying to give driving directions, you can loose your signal.  Loose your signal enough times, and the transceiver will turn off for long periods of time or do a cold reboot.  You know you have this problem if your GPS signal suddenly disappears and the GPS antenna won’t latch on again for long periods of time (or sometimes until your phone gets rebooted).

2. GPS Dead Spots Always In the Same Place (Phase Shift Issues).

Most people know that a GPS transceiver needs at least four satellites to get any kind of a fix.  But few people know that there are actually GPS dead spots that remain in the same place on the earth’s surface.  Intuitively, we know they’re there in places where there’s no line of sight (like an urban canyon).  But, few, if any of us are ever told that even on flat ground with a clear line of sight there can be dead spots.

Here’s why.  In order for your GPS transceiver to detect a satellite, the signal from the given satellite must be strong enough for the transceiver to pick it out of all the background noise.  The way the GPS transceiver detects a signal however, is through detecting phase shifts in the satellite signals.  Too many satellite signals canceling out or distorting or too similar to each other will make it hard for the transceiver to know what satellite is what.  So, the transceiver just gives up as if there were no satellites were there.

But, you might ask, if the earth is rotating and the satellites are always moving, how come the dead spots never change?  Simple.  The GPS satellites, even though they are moving, always follow the same path in space.  There are places below the constellation where the satellites always converge in just the right spot to cause enough of a phase shift interference in the same spot.

This explanation was the answer to a long standing dilemma I had at my previous company, Root Wireless.  During testing, we showed that cell phones always just seemed to die in a particular spot during drive tests, and then not pick up a GPS signal for many minutes (sometimes 20-30).  What happened most likely, it seems, is a particular geographic location always was washed in GPS signals that overlapped just enough to cause phase shift problems.  This one spot confused the cell phone transceivers on different cell phones.  The transceivers thought the satellites were missing, and after trying again and a gain, they just gave up.

You know you have this problem when you drive the same rout many times and your GPS always looses it’s fix in the same spot, regardless of day, weather, or other factors.

3. Satellite Maintenance.

Satellites need to undergo routine maintenance.  It’s common for a satellite to be shut off during a maintenance cycle.  This can cause you to spontaneously loose one or more satellites.  A suddenly disappearing satellite can confuse your GPS transceiver.

4. It Could Be the Russians.

Probably the coolest explanation I heard from Gary had to do with espionage and The Cold War.  When the Russians built their GPS constellation, they did two things. They put up their own satellites, but they also tried to use our own satellites against us.  The idea, apparently, was that the GPS signals from the Russian satellites would somehow overlap our own signal (“piggyback”). This apparently served two purposes.  First, it allowed the Russians to use the freely available signal to guide their own ICMBs and other weapons.  After all, who needs three meter accuracy to target a city with a nuclear missile?  Anything within a few thousand feet will do nicely thank-you-very-much.  Second, it gave the Russians the opportunity to confuse our own GPS sensing equipment by spoofing our own GPS signals.  No better way to cause your GPS transceiver to go haywire.

Some GPS Best Practices

Here’s some additional information about some GPS best practices you might find useful.  Whether your a developer, product designer, or you just simply have your head in the sky about what GPS  can and cannot do, this may help.

1. Treat GPS Transceivers as Phantom Users of Your Applications

GPS transceivers live to feed data into your application. If you treat the GPS service as if it were another user competing for input time and screen space on your cell phone, you’ll write software that co-exists with GPS in peaceful ways.

2. If I’ve Told You Once ….

GPS is a line of sight technology. It doesn’t work indoors or in canyons. If you get GPS data when you’re indoors, it’s simply because your cell phone got the location from another source (e.g. a network server).  There’s no sense in trying to get the GPS to put out if you don’t get a solution.

3. Cell Phones Aren’t Personal Computers or Servers or Dedicated GPS units.

Using the GPS requires a thread.  Cell phones don’t usually handle multi-threading well, even though the capability is there to do background processing.  Be overt about your GPS usage in the user interface.  Design your GPS application around a single thread or design well-thought out pre-emption.

4. Decide Early on What Your Performance Envelope Is.

Decide how accurate you need a fix, how often you need the fix, and what conditions you need the fix in.  That’s your basic GPS “performance envelope.”  If your product designers want to use GPS outside that envelope, then they need to rethink their requirements.

5. If It Walks Like a Duck, It’s Ain’t Always a Duck.

GPS readings from the network are not the same as solutions from an antenna.  Know and talk about the differences.

6. GPS Chipsets and Transceivers In Cell Phones Are Flakey

… even in phones of the same model.  One cell phone may work better than another.  So, don’t “rely” GPS working too much.  They’re either working or not. And, expect them to magically go offline at any time. As the FAA can tell you, GPS receivers on airplanes are much different than the ones in your phone.

7. Use GPS as Infrequently as Possible.

The less your application uses GPS, the happier your user will be.  Stick to a bare minimum.

8. Avoid Spying and Spy-Like Behavior.

Cell phone GPS is not a tracking tool like the one Batman uses to tail bad guys.  Off-shipping GPS data from the cell phone should be avoided if possible.  Nobody likes a peeping Ron.

9. Keep GPS In the User Command and UI Loop.

A quick peak at your handy thesaurus will tell you how you should make GPS appear on your app.  Make it

accessible, barefaced, bright, clear, clear as a bell, conclusive, conspicuous, discernible, distinct, distinguishable, evident, explicit, exposed, glaring, in evidence, indisputable, lucid, manifest, noticeable, observable, open, overt, palpable, patent, perceivable, perceptible, plain, precise, prominent, pronounced, public, recognizable, self-evident, self-explanatory, standing out, straightforward, transparent, unconcealed, undeniable, undisguised, unmistakable, unsubtle, visible

… you get the point.

10.  For Some Phones, GPS is Vaporware.

Manufacturers may promise, but you must prove on each phone that GPS works as advertised before you design your products around it.  This means testing GPS on a particular make/model of a phone on a specific carrier.

11.  Time to First Fix is Always Slow.

If it’s not, then you didn’t get the first fix.  First fix can take minutes.

12. 3′

One meter accuracy is the best you can hope for.

13. Balance Accuracy with Time

The more accuracy you want from your fixes, the longer it take to get that fix.  And the harder it is to keep getting those fixes.  Simply changing your accuracy requirements to 20 meters can save you a lot of headaches.

14. GPS Fades In and Out, and Sometimes More Out than In.

GPS comes and goes.  Using an accelerometer is a good way to track your location when your GPS goes kaputt.

15. Allow the User to Use a Usable GPS Antenna

GPS antennas in cell phones are lame.  Always detect alternate GPS sources, like bluetooth antennas.

16.  If You Fly with Cell Phone GPS, You Die with Cell Phone GPS.

GPS doesn’t kill people.  But, GPS users navigating planes with cell phone GPS units can.  Cell phones should never be used for flight navigation.  If you write an airplane navigation tool on for a cell phone, you could be contributing to someone’s death.

17. Papers Before Positioning

Keep up to date on GPS research and papers.

18. Network GPS Isn’t Available on All Phones.

See #10.  But, if the cell phone you target can see a web server, consider setting up a server based location lookup (e.g. Secure User Plane Location – SUPL).  There are many servers out there you can set up yourself.

Will the Blackberry Tablet (and tools) Impress?

I am excited to see new innovation come out of Research in Motion with the announcement of their tablet. And, I hope it works well.

What I can’t help wonder about though is the quality of the underlying development tools that will be shipped with that product. Is it JDK 6.0? One might assume, but we’ll see when it comes out. But that’s neither here nor there. What’s important is this:

Overall quality of a mobile device is defined as much by the software development toolkit as the device itself.

And that, my friends, is what I’m looking out for.

A healthy, super usable, software development toolkit means you’re going to get healthy, super usable software for the phone/tablet/device/whatever…

On Blackberry devices, the jury is still out.  What is clear however, is that many IDEs have long set the standards for mobile development: great toolchains like those for iPhone, cutting edge Android development tools, great IDEs like Netbeans, and even not-so-great IDEs like Eclipse.  Even Windows Mobile development tools have a history be being stable and working well.  Will RIM finally step up to the plate?

I may have been the first to blog that the lack of an easy to use, stable development and debugging platform, threatens RIM’s domination in the market as much as anything.

JAD properties specific to RIM.

In addition to the normal J2ME properties that go into a JAD file (.jad), RIM has a set of properties that are specific to the RIM platform that go there too.  Here they are:


Properties of BlackBerry device application .jad files

The BlackBerry® Integrated Development Environment lets you create a dual-purpose .jad file to support the downloading of MIDlets onto BlackBerry devices and other wireless devices. To do this, create a .jad file that contains both the RIM-COD-URL and RIM-COD-Size attributes and the MIDlet-Jar-URL and MIDlet-Jar-Size attributes. On BlackBerry devices, download the .cod files; on other wireless devices, download the .jar files.
Required RIM attribute Description
RIM-COD-Creation-Time creation time of the .cod file
RIM-COD-Module-Dependencies list of modules that the .cod file requires
RIM-COD-Module-Name name of the module that the .cod file contains
RIM-COD-SHA1 SHA1 hash of the .cod file
RIM-COD-Size size (in bytes) of the .cod file
RIM-COD-URL URL from which the .cod file can be loaded
Optional RIM attribute Description
RIM-Library-Flags reserved for use by Research In Motion
RIM-MIDlet-Flags reserved for use by RIM
RIM-MIDlet-NameResourceBundle name of the resource bundle on which the BlackBerry device application depends
RIM-MIDlet-Position suggested position of the BlackBerry device application icon on the Home screen might not be the actual position of the icon on the Home screen