sockethelpers-for-pcl: Making socket tasks easy that should be

When I first started thinking about the API design for sockets-for-pcl, I made the decision build a minimally functional, unopinionated and lightweight wrapper over the existing platform implementations - no extra features. Part of the reason was to adhere to the Xamarin contest's "no dependencies" suggestion, but it was also to allow users of the library the freedom to work with it however they wanted, rather than be constrained by decisions I'd have made when putting it together. The upside is that you can use sockets-for-pcl to do pretty much everything you can do directly on the native platforms. The challenge is - particularly on mobile - that a lot of the time you don't need all that flexibility; a simple API that covers typical tasks will do. For that, I earmarked the sockethelpers-for-pcl project.

What kind of typical tasks?

The opportunity here is to build extensions onto the core library that cover what could almost be considered 'boilerplate code' for the common use cases in mobile platforms, if not for the edge cases. Some of these would include:

  • Communication between devices at a higher level of abstraction than the byte streams exposed by the standard sockets - for example, communicating via strings or strongly-typed instances. Useful for pretty much any two-way communication scenario.
  • Messaging patterns and abstraction from the socket classes - for example, hub-style communication and working with proxies that represent other devices, rather than interacting with sockets directly. Useful for situations such as cross-platform multiplayer games.
  • Handling device lifecycle events - for example, having support in a protocol for notifying a connected party that the local device has been locked/application suspended, having support for reconnect, and a means to associate the restablished connection with the previous state, playback missed messages, etc.
  • Service/device "discovery" - for example, broadcasting availablity or sending discovery requests to determine what other users may be nearby. Again useful for multiplayer scenarios.

Some of these are problems are considered "solved" outside of the mobile/PCL world. For example, several mature libraries for hub communication, and pub/sub style messaging exist. The right approach there might be to sub in sockets-for-pcl at the transport layer. For now, I have been working on making the last point - service discovery - super easy, and I'll be giving an overview of how it's looking in a future post. For anyone that has views on the above and wants to help out -- the empty repo lives here; open an issue and lets get chatting.

Title inspired by Splat +500 internet points if you recognised the reference.