Tag Archives: mobile

Ubiquitous Connectivity & Time-based Internet Billing

I am currently sitting on board the Dawn Princess with anchors down in Akaroa. I am half way through a two week cruise around New Zealand with my family. It’s a good break from our busy lifestyle back in Melbourne.

The timing of our family holiday is a little awkward because I am missing the excitement around the announcements made at BUILD 2014 last week. Or I would be if I wasn’t able to connect from the Internet from the ship as the details unfold.

Aboard the Dawn Princess is a ubiquitous Wi-Fi network which is available in all the staterooms and most of the common areas. The Wi-Fi network routes through a satellite connection backed by MTN Satellite Communications. When using the Internet I pay at a rate of approximately $0.30 to $0.80 per minute depending on the package.

Having cruised before I was aware of these pretty steep charges so we organised a local SIM card for mobile data access when ashore. The mobile data plan is of course tied to data volume usage rather than time. Time-based billing for Internet access to be strange in this era of mobile computing. The thing that I miss most about not being connected all the time is the absence of casual interaction with my information sources (e-mail, social media, news headlines, browsing etc).

I certainly can’t afford to be online all the time to receive these notifications, so for BUILD 2014 content, I logged in to get a quick synopsis of what is being discussed and disconnect. When I was ashore I set my various mobile devices to download content (such as the keynote videos).

The whole experience has left me pondering why satellite access (at least in this instance) is charged on a time based model. Surely the ship maintains a constant satellite connection so why not allow passengers to be constantly connected and then bill a lower rate for actual usage. The administrator of the ship-based network could apply QoS to the traffic to ensure essential traffic is given preference.

Another curious aspect of the setup here is that I can’t access OneDrive or OneNote (which is backed by OneDrive). I can understand that the ship might not want passengers syncing their local content across the link (especially with all the high resolution photos captured) but it sure is a pain when I want to access one of my Notebooks from OneNote. This makes me think that the critical resource is indeed bandwidth, but by charging for time the ship ensures that passengers don’t accidentally set their devices syncing constantly.

Overall I have been pretty impressed with the strength of Wi-Fi connectivity on the ship (kudos to Princess Cruises for that). I just wish that the route to the Internet didn’t have such a big toll gate in front of it. Is there a cruise ship out there that caters to geeks wanting to be constantly connected?

Maybe someone from MTN Satellite Communications could explain why satellite communications might be billed on a time basis.

The NFC wave is coming…kinda.

I stepped out yesterday morning to go to an appointment and when I got back I dumped my wallet on my desk then neatly stacked my phone on top of it. I’ve got a Nokia Lumia 920 running Windows Phone 8. After a second my phone chimed. I was familiar with the noise because I have a wireless charging stand by my bedside table.

Turns out that the NFC proximity sensor on the Nokia Lumia 920 had picked up an NFC chip from the many cards within my wallet. This afternoon I sat down to figure out which card it was and how I could use the proximity API within Windows RT to read the card.

As I flicked through the cards in my wallet and held them out to my phone I found that if the 23 cards in my wallet, six of them had NFC chips within them. Of those there were 3 bank cards, 2 transport cards and 1 loyalty card.

My next goal was to figure out how the proximity API within Windows Phone works to see whether I could get access to any of the details on the cards. I’ve slapped together a quick example of how to use the proximity API. The code uses the ProximityDevice and hooks up to the DeviceArrived and DeviceDeparted events and also calls SubscribeForMessage.

Unfortunately none of the cards that I had in my wallet contained an NFC device which was in a format that Windows Phone 8 could understand. NFC messages that Windows RT supports are listed on the PublishBinaryMessage documentation page. From what I can tell Windows Phone 8 only supports a subset of these, and other than Windows specific message types, the messages need to be formatted using NDEF. If you happen to have an NDEF formatted card you can use the NDEF library hosted at CodePlex to work with the data directly.

I hope that in the future Microsoft will open up more of the NFC device capabilities on their mobile platform. I suspect that many loyalty card programs that use NFC won’t necessarily encode their messages with NDEF which will limit the ability to do anything interesting with Windows Phone unless they take the step to redistribute cards (unlikely).

Either way, I think that we are going to see more and more NFC moving forward. It is already quickly taking hold with credit card/over-the-counter transactions, but so much more is possible with mobile integration. Maybe I’ll look at using NFC in between mobile devices next. The NFC wave is coming…kinda.

More Windows Phone 8 sillyness.

I’ve been watching the Windows Phone 8 conversation with great interest. I say conversation, but it has been kind of one sided. That said, Todd Brix who posted the most recent post (12 Sept) on the WP development blog has chimed in on the comments following the post. Here is a copy of what he commented:

I wanted to respond to those of you who are frustrated about the fact that we haven’t publicly released the Windows Phone 8 SDK. This year we’ve taken the approach of unveiling the new features of the OS as close to device availability as possible.  Unfortunately we can’t release the SDK without revealing all of the new features and capabilities.  I recognize this is a departure from how we’ve operated in years past and some of you are questioning our thinking.  That’s ok – let me give you a little more to consider.

Windows Phone 8 was designed to run the apps written with the Windows Phone 7 SDK which is available today.  Right now and for most devs the high-volume app development opportunity remains on the Windows Phone 7 SDK because these apps will run on phones available later this year, regardless of what OS version is on the phone.  If you want to help make sure your Windows Phone 7 app runs well on Windows Phone 8, when it is released, you’ll want to take a look at the Sept 12th post from Andrew Whitechapel . And while I know you want to test your app in our new emulator, the reality is that you will also want to do final testing with Windows Phone 8 devices which are not yet in market.

There are also devs who want to jump on new Windows Phone 8 technologies before anyone has bought a device, which is fantastic.  This is why we’re doing the early Preview Program. For those who don’t get the Windows Phone 8 SDK via the program, we will get the final SDK out in time for you to capitalize on the wave of new devices.

Thanks for your interest in Windows Phone!

Todd makes several good points in his comment:

  1. The biggest opportunity right now for Windows Phone developers is the 7.x generation of devices.
  2. They can’t release the Windows Phone 8 SDK without developers figuring out what the platform has on offer.

Unfortunately, the comment still completely misses the point. Firstly, even if I am going to target Windows Phone 7.x generation devices, I still want to work within the latest version of Microsoft’s IDE. Developers don’t just write Windows Phone applications, they build the backends which support those applications and when your vendor doesn’t continually bring their SDKs up to a level where you can use a single IDE they are effectively introducing a productivity burden. I want an updated SDK which allows me to use Visual Studio 2012, I’m actually less concerned about the Windows Phone 8 specifics right now.

The other point, which has been raised by others is that by sharing the SDK with some developers, they are effectively sharing the SDK with all developers. We are already hearing rumours about WP8 devices being found in the wild. It is possible that these are just unfounded rumours, but it definitely appears like they have RTM’d the operating system. Sorry guys – you can’t contain this stuff it will leak out. Developers will be pissed if they are the last to know – it is a great way to completely screw an product eco-system and fill it with ill-will.

So where are we after my previous post? Nowhere. I had hoped that Microsoft would quickly switch strategies and open up access to the SDK as soon as it was ready (so no super secret preview program). That is looking less and less likely now. Not only that, but it appears that Microsoft is suggesting that we should be happy and target the mobile platform with the most opportunity (see highlighted second in Todd’s comment). Fair enough – here are some statistics for you to consider (according to the Mobile Mix report):

  • 46% Android
  • 34% iPhone
  • 15% BlackBerry
  • 4% Windows
  • 1% Symbian

Time to leap to action! Go and download the Android SDK and the iOS SDK.

Windows Phone 8 SDK? Srsly?

The Windows Phone 8 SDK Preview program is now open. Except you can’t download the bits, and it isn’t the least bit open. If you are a software developer that has been loyal to the Microsoft platform for years (or decades) you have the right to be pissed.

Many developers have been eagerly waiting for the release of an updated SDK for Windows Phone. Microsoft didn’t see fit to release an update with Visual Studio 2012 so that developers could use the latest IDE to target Windows Phone 7.x, and so an updated SDK was really overdue.

Unfortunately on the 5th of September Microsoft announced that they would only be opening up the Windows Phone 8 SDK in preview mode to a select few, basically cutting off those who had been waiting for an update in the SDK to start work on their projects (whether they are Windows Phone 7.x or Windows Phone 8.x). The overwhelming reaction of developers commenting on that post and today’s update was clear (epic fail).

In order to get access to the SDK you need the following:

  1. Publisher Name
  2. Dev Center Publisher GUID
  3. Registered Country
  4. Application Name
  5. Application GUID

As an MVP I’m used to filling in forms on the Microsoft Connect, but normally it is just basic demographic and organisation information. This is a whole new level and it basically excludes a lot of really passionate developers from getting access. The form of course is not the only blocker, Microsoft then needs to “select you” because it’s not just a case of filling in the form and automatically getting access to the bits.

The Windows Phone 8 SDK preview is not open, its closed. Period.

Sure the marketing folks in charge of this decision are quickly reconsidering their options. Firstly – the requirement to go through this process will detract from developer adoption of their platform. Right now they are getting a strong reaction from a small number of developers passionate enough give a crap.

I’m already feeling cheated having paid good money (USD$99) to get access to the Windows Phone Dev Center, only to have Microsoft completely drop the ball on SDK updates after the RTM of Visual Studio 2012.

Right now Microsoft has sub-10% market share in the mobile operating system space. This strategy of locking loyal developers out of the platform updates (combined with not releasing updates to existing tools) is completely wrong-headed.