Difference between revisions of "Getting Started Tutorial"
|Line 1:||Line 1:|
Revision as of 01:56, 31 July 2008
Several of the applications described in this article are written to target the .NET platform on Windows PCs. For this you will need to have already installed the Microsoft .NET Framework v1.1. This is a 23Mb download from Microsoft. More details below:
There's a bit of an article on xAP Hubs to be found here:
It talks about the xAPFramework-based hubs though, so mainly Windows only at this time (one of these days I'll find a crack of time to explore Linux some more). There are others for Linux too:
One thing worth knowing is that whilst a hub is essential to run multiple xAPplications on the same machine, many xAPplications can provide hub duties automatically. So you can just start one, any one, it'll detect that the lack of presence of a full xAP Hub and assume the role for itself. All xAPFramework-based applications have this ability built-in. You can customise this feature too, but that's another topic for another day - and one that nobody has ever asked me about so I guess it's unimportant at this stage.
Anyway, it's probably good to have a dedicated Hub without a lot of fluff built on top. That's why my own comes in 3 flavours; console mode, Windows Service and with a pretty GUI.
Personally speaking I'd suggest then moving onto something such as my xFx Viewer application. This seems like a quite useful tool to see what's going on and follow the interactions of various xAPplications and xAP-talking devices.
You'll find lots of words and pretty pictures here:
With these 2 apps running you should see them hearing each other, rather than directly talking to each other.
I guess Step 3 would be to actually send a xAP message of your own to check everything is working fine. There are a couple of Send type apps that take xAP messages from simple text files and send them off into the xAP network.
These are useful not only for debugging and demonstrations, but you can hook these into other applications that provide command line execution hooks. E.g. you might be able to invoke another application upon some event. Here you could predefine a xAP message as a text file where native xAP support isn't (yet) present, and invoke a send application with that file as a parameter.
Or you may just want to initiate something such as turning a light off via X10 or whatever, by 2x clicking a file on your desktop.
Patrick has a version of this here:
And my version is available from the following page. There are a few subtle differences between these two implementations but nothing worth noting within the scope of this article.
My version is Windows only (unless somebody fancies giving it a go with Mono on Linux. Anyone?) and comes packaged as a Windows Installer file that automatically associates itself with .xap files. There is a ton of example messages contained within a "Sample Messages" folder upon installation. You just need to 2x click a .xap file after installation. You can use the supplied examples as templates for your own messages or create new files from scratch.
So now you should be seeing Hub and Viewer, each aware of each other, and also have the ability to send messages. You'll be able to see them arrive at Hub, be forwarded onto client applications (ie Viewer), and be able to see a new node appear in the Viewer display.
I find Viewer fantastically useful for xAP network monitoring. There were some truly impressive xAP node-network displays to be seen at UKHA2004 for instance, stuff waaaaayyyy more detailed than I've ever personally seen before.
It's unlikely that the GUI xAP Hub application will see much enhancement as it starts to become kitchen-sink and unneeded. But Viewer has a whole series of upgrades planned when I can find the time.
Hopefully this gives a tiny bit of a feel for xAP. Ask away and somebody can answer in more detail on various topics. I'm thinking that if we waffle about the topics here then I can take the text and use it as the basis for some web site articles. As much as I waffle in emails, I don't find writing documentation to be particularly interesting. It looks like I'm not alone! :)