C# BlackBerry Push Service SDK – Part II

The low-level push API code is complete with support added for RIM specific messages.

The next layer (IPapService) which exposes a low-level facade that can send messages and return responses together with a listener that can called by the push service itself is now complete.

Layer three is next. This is a terribly complex layer and contains the majority of the SDK.

Thankfully it is split into manageable segments.

IPushApplicationService and it’s repository has been completed – although additional validation is still required.

IPushCountService and it’s repository has been completed – this was an easy one…

IPushRequestService and IPushRequestDetailService and the associated repositories have been completed.

IPushStatsService and IPushStatsBatchUpdaterService together the the stats repository are fully implemented – a tricky little devil but now implemented according to the SDK documentation.

So far so good – next I tried to write the IPushService code and realised that I really need the subscription service support before it will make sense! So the ISubscriptionService is now being looked at – this is a very wide interface so will take a day or two to write.

Obviously on the way to implementing subscription I will also implement ISubscriptionQueryService needed to talk to the BlackBerry infrastructure however unlike the Java API, I will reuse the PAP service to handle the message routing…

Last up will be acknowledgement support and providing the hooks necessary for SDK users’ to utilise inbound data.

Clearly once this code is done I will be getting a Push Plus experimental key and putting the code through its paces to see if the subscription, acknowledgements and request storage code works as expected – that will be fun…


C# BlackBerry Push Service SDK

So among the many aspects of my day-job I’ve been looking into how mobile devices can be integrated into my mega .NET application – a giant line-of-business client/server monster.

Since I recently bought a BlackBerry this device will be integrated first. Now the BB supports a push mechanism which allows me to send data to a BB application in a way that doesn’t require client-side polling.

This sounds pretty neat – it could be used to notify tech support of server problems or notify a customer of a change in their order.

The only problem is the fact that the current API is written in Java by RIM and my application is not – it’s a C# piece of beauty… Still with me?

All this preamble is the sauce for the meat of this post – namely I want to write a native C# API that supports all the features of the RIM Java API.

Looking at the documentation the API is split into two tiers. The first tier manages the communication with the push service. The higher level tier builds upon this low-level tier providing subscriptions, persistent messaging, acknowledgements and full cancellation support.

Last week I started on the low-level tier. This tier is basically concerned with marshalling and unmarshalling messages sent to and received from the Push Service Gateway.

The gateway is a HTTPS web-server that accepts messages posted to the request URI.

Push Requests

    Push requests fall into two types:

  1. XML request
  2. XML request and payload in a multipart MIME package

As I’ve found out, the documentation is rather terse and worse the request parser is very strict on the format of the mime package and gives cryptic errors when it throws up.

Sounds like fun eh?

The Problems
In no particular order – here is a list of issues I found while getting my low-level API to work…

1. HttpWebRequest – obviously I use this object to handle HTTP requests – do not use the Credentials property to set your username and password. It doesn’t work. The API gives instructions on how to setup the Authorization header – follow them!
2. When building the multi-part MIME content make sure there isn’t a blank line between the end of the message XML and the boundary (that took a while to find)
3. The URL given in the email from RIM specifies the address of the gateway – this is a base URL – you will need to add a suffix before you have the actual address necessary the suffix is “mms/PD_pushRequest” without quotes…
4. The SourceReference for a push message is your RIM provided application ID.

After all that I had to get the message response parsed – thankfully this is relatively easy – it’s just XML so I can use a standard object model decorated with XML serialisation attributes.

Some gotchas – the date format requires a custom string for parsing and so the containing class must derive from IXmlSerializable and do things long hand…

So far so good – I’ve finally sent my first push message successfully! The rest of the low-level tier will roll along now.

When it’s in a happy state – I’ll upload it to CodePlex as a open source API.

Happy coding

Relaxed Jaw Dropping

Seems my saxophone playing has entered a new phase. I’m sounding brighter, clearer and even the low notes are sounding less raucous. Why? Well the two pronged relax and drop-your-jaw approach is finally paying dividends.

Last mouth my tutor told me to expand the area inside my mouth – in effect create a larger chamber in my mouth – I did this by adjusting my jaw “from the back” and this helped for sure.

Now I am also dropping my chin to avoid clamping the reed – this means the muscles around my lips have more work to do and this means that control is also trickier…

The final piece of the jigsaw is learning how to relax – this is the most abstract and difficult task to get to grips with. If I am not relaxed when I play then all the technique in the world won’t help my music.

It seems relaxation and core strength (your core muscles are your abdominal muscles and diaphragm) are not only essential to saxophone playing but many, many diverse activities – from breathing (low breaths aka diaphragm breathing) to motorcycling (using your abs to support your torso relieves your wrists from carrying the weight of your upper body leaving them free to manage directional control) – being relaxed also means you will tend to suffer fewer injuries.

Alas your relaxation technique will probably be different to mine – infact how you relax may even differ according to the task you will undertake. For many athletes doing muscle stretching before an event or workout is common whereas pianists tend to shake their hands. I’m still experimenting to find what works best for me – you’ll have to do the same!

Happy saxing

What water festival?

Apparently there was a water festival here in Thailand – I really couldn’t tell you for sure – I’ve seen evidence of war – I mean festivities but managed to completely miss it all. Pretty good going if you ask me.

So what else was I up to? Well first off was that wonder task The Network Upgrade. This took place on the first day of Songkran (see first paragraph one) and despite a few hiccups was concluded successfully.

What with the water war the unicycling had to be put on hold – getting a mouthful of eau du khlong while rocking is not my idea of a winning scenario…


WAWB Day otherwise known as Weird And Wacky Bug Day has bowled me a few bouncers I can tell you.

My latest database update script contained an error – I’m rather surprised I didn’t catch it during script testing – then again maybe I did as the dev branch database has the correct view definition… Weird.

I missed off an ordering LINQ clause when I refactored some code and this omission suddenly presented itself – again only on the live database – maybe I just wasn’t paying attention earlier. Hey ho easy to fix… Wacky.

A Silverlight duplex WCF object wasn’t re-established in the event of an error – added code to attempt reconnection automatically. How was that missed?

WAWB Day is a sure sign that I need both a break and a dedicated team of testers – oh well – wish me luck!

Silverlight Surprise

Just fixed an interesting little bug discovered late in pre-rollout testing.

Seems when your Silverlight application is installed in Out Of Browser mode you have to explicitly setup the culture for the UI thread – if you want something other than the default assigned to new OOB sessions.

Since I use the English language version of Windows and Silverlight the default culture is en-US even though my application installs while running under en-GB.

The answer was simple – when running in browser save the thread culture to local storage and when running out of browser set the thread culture explicitly from the saved state.

Incidentally this bug is only noticeable if you have XAML bindings that use binding converters or perhaps the StringFormat binding attribute.

In my program it showed itself in some dates shown on the UI where I use a custom converter to show UTC dates in local time.

Hope this helps somebody else – happy coding!

Why is it only Tuesday?

This is clearly going to be a VTW or a Very Trying Week – it’s only Tuesday, I’ve not even made it into the office yet and that feeling of impending doom is already ebbing at my feet like the incoming tide.

So what has caused this feeling of unease? Well I have a network upgrade to do at a customer site on Monday – which yesterday changed to this Friday due to Songkran festivities – not so bad – well the uograde involves removing an apparently redundant router and replacing an ancient switch with a nice managed one.

The router is a potential banana skin but otherwise okay – the switch is being sourced from a company in Thailand and this is where things can go awry.

Their website says the switch is in stock. I got a quotation from them with a real price and everything. Now they say the item is out of stock – three days before we need it. Okay don’t panic – find the main distributors for Cisco stuff in Thailand – a 60sec search – paste the link into an email to my client and before I can click send he calls me up to say that the supplier has the switch after all. This might end well but don’t be surprised if it doesn’t…

In other news my ERP program is about to start testing in the factory – I should run a sweepstake on the number of bugs that will be discovered in the first month of testing.

Hey ho I’ll probably look back at this week and laugh – well possibly