In keeping with the modular nature of the original SDK, I have broken apart the source-code into separate assemblies.
Contains common classes.
Contains low-level PAP core and configuration classes.
Contains high-level push core, subscription, application management, request tracking and statistics.
Contains all acknowledgement handling extensions.
The code base has been updated so that SDK assemblies now share common version information via a custom (TFS Build friendly) target file – there be some cool tech in there that you may find useful in you own projects and solutions.
I have also started work on the deployment technology, enabling easy installation of the SDK for developers.
The installer project makes use of WiX and is dependent on WiX 3.6 Release Candidate (available at Windows Installer for XML
At the time of writing the project is bound to the latest build (v3.6.3025.0). In due course a merge-module project will be added to support your own deployment scenarios.
Finally I will be looking into a clean method for adding code-signing into the project files without having to go through the pain of actually having the signing file in source control (I’ll get endless requests for the signing password) – I suspect this will be best achieved with a tweak to my custom build target.
I’ll try and put together a new build and release to CodePlex over the coming week – real busy though so please be patient!
You can now download the sources for the BlackBerry Push Service SDK from the CodePlex web site from this link.
You should refer to the RIM Java documentation as this is a fairly close port however a sample web-site and test library is in-progress…
I am also looking for helpers for maintaining this project and adding source-level documentation 🙂
To be honest porting an API from one language to another can be pretty dull however once the grunt work is finished you can sometimes tweak the code to take advantage of specific language and/or platform features.
Since the shape of the existing API is synchronous I knew early on that changing the communications stack from blocking to non-blocking would be high on the ToDo list – to be fair if .NET did not have the async/await keywords I wouldn’t have bothered as writing async code without this feature is difficult and error-prone.
With this in mind I started with the lowest layer code that handled the request/reply over HTTP with the PPG inside IPapService – fairly simple since the comms classes already have Task-based wrappers.
After that follow the logic (and the build errors) into IPushService. The public API featured simple changes however under the covers the changes were more widespread…
ISubscriptionService is teeming with multi-threaded parallelised code so not only were there API changes but there was also an opportunity for refactoring a lot of the job partitioning logic into something much more concise and therefore easier to understand.
All this work meant that it was easy to update the acknowledgement HTTP handlers so that they are now implementing IHttpAsyncHandler which is good news!
So where are we? Well the CodePlex project has been created and the source will be checked in over the next few days – initially for Visual Studio 2010 but with VS2012 .NET 4.5RC version to follow.
Finished the subscription service and with that also concluded the implementation of the high-level push service interface: IPushService. I also knocked out the acknowledgement service and placeholders for the content provider notification and authentication services.
This means that all the major parts of the SDK have now been ported!
Now I am looking at parameter validation, type-safe exception types, Enterprise Library logging support and fully documenting the source to ensure the SDK is nice, robust and easy to debug/maintain.
I will then look at making the comms logic asynchronous and seeing how far up the call chain that work goes – perhaps IPapService and IPushService will go from synchronous to async APIs – I certainly hope so!
Finally I will start a Push Plus evaluation so that the advanced functional support can be fully tested.
At that point I will upload the solution to CodePlex for consideration by the community.
Once I completed and tested this code I will be looking at which API segments can be switched into Task based async methods.
The communication methods that form the IPapService and IPushService, the synchronisation and PPG notification methods in ISubscriptionService are all obvious candidates as they currently rely on blocking I/O calls.
I will be releasing three solutions;
- VS2010 + Async CTP
- VS2012 + .NET 4
- VS2012 + .NET 4.5
Please don’t thank me all at once… Rest assured I have my reasons for doing this!
I’ll dive straight into today’s changes. The subscription service repository is fully coded – a lot of functions but easy enough.
The subscription service itself is 70% completed with all the validation and query methods done.
Thankfully the Task Parallel Library and the new async/await keywords has meant that implementing the multi-path parallelised synchronisation code was a breeze.
Work is underway to implement the subscription code which is more complicated than it first appears – no surprise really as it must cope with users swapping device and other weird and wonderful use-case scenarios.
I had to re-code the SubscriptionQueryResponse class so as to flatten the XML returned from the server. Makes life simpler.
It was fun tracking down the endpoint addresses used by the subscription service – at one point I thought I might have to install the Java API along with Apache and watch network connections via Fiddler…
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…