As of this past Friday, the line to buy an iPhone 3G at Apple's Michigan Ave. store in Chicago was still almost a block long - apparently, the same scene is repeating itself across the country. For the most part, this isn't because of low inventory, but because of the ridiculous in-store activation process every customer has to go through.
A group of us on the way to lunch were joking about the iPhone 3G's (I refuse to refer to it as just "iPhone", it's the iPhone) successful but frustrating launch, when the conversation turned to Apple's new service MobileMe.
It's amusing how people are so willing to forgive Apple when they fumble something. MobileMe wasn't even working for a few days after its launch. Even funnier, Apple had to clarify what what they really meant by "push", and that some of MobileMe's services didn't actually use "push" technology.
Someone then mentioned that if you browsed MobileMe in IE7, you would get warned that you wouldn't enjoy the full experience because of IE7's compatibility issues with web standards.
I had to see this for myself ...
Let me say this up front, I am not an Apple basher ... As a matter of fact, I am writing this on a Macbook Pro, my wife and I stood in line and bought our iPhone 3Gs last weekend, and our place is littered with various generation iPods.
Maybe Apple is making a statement; that they're sick of having to program around IE's non-compliance with web standards? I commend that - I'm having to deal with some cross-browser JavaScript issues on a project, and let me tell you, it ain't fun.
Did Apple somehow forget though that the overwhelming majority of iPod and iPhone users will connect them to XP and Vista machines running IE6 or IE7?
Do they think that Joe-web-surfer understands the first thing about web standards compliance?
I guess somebody eventually has to draw a line in the sand when it comes to this. Just found it funny that Apple would call out IE7 like this, when as of June 2008 IE7 and IE6 combined still account for over 50% of the browser market share.
Getting called out for using IE7 is bad enough, I wouldn't want to see what MobileMe says if you browse it using IE6 :)
A colleague of mine - Peter Walke - was working on an internal project where he needed to quickly integrate some functionality provided by the Office Communicator SDK. Having worked on several projects involving Communicator automation, he asked me if I could give him some code he could simply drop into his project.
The Office Communicator SDK is generally easy to use, however, the code to connect to communicator, monitor the status of the connection, and clean up if the connection is lost can be complicated. I quickly realized that it's very inefficient and inelegant to have to paste this large blob of code into every project that used the Office Communicator SDK.
I decided to wrap that functionality into a helpful class library, where the developer's only responsibility would be to create an instance of the class - letting it handle all the underlying plumbing with Communicator.
While I was at it, I also baked in a number of helpful utility functions into the wrapper. This includes functions to trigger various types of Communicator conversations, perform Contact maintenance, query presence, and several others.
I create and published the OCSDKWrapper project, along with a sample application built using it, into CodePlex. You can find the project at http://www.codeplex.com/OCSDKWrapper.
Design Decisions
I worked on this over a couple of days this weekend, and made a couple of design decisions to finish the project quickly and get it published:
- You still have to reference CommunicatorAPI in your application.
- I didn't see any real worth in creating DTO classes for every class in the Office Communicator SDK.
- I left all the Communicator event parameter variable names as-is, even though I wasn't fond of the naming scheme
CodePlex
I've never created a project on CodePlex before, who knew picking what type of license to use would be so complicated.
If you're interested in contributing to the project, have some feedback, or want to report a bug, please contact me via this blog or by posting on the project page on CodePlex.
Sample Application
In the project's source code, you will find a simple sample application that was built using the OCSDKWrapper. The application displays the current connection status, the signed in user's status, and a running list of events that were raised by Office Communicator.
Take a look at the source code in the sample application, you'll see how quickly you can get up and running.
To do