Having written a small amount of WPF code for the previous post, I was wondering how hard it’d be to now write a Silverlight Mesh Enabled Web Application ( MEWA ) and access the same data that I was using from my WPF application.
I set off down the route of building a Silverlight MEWA. So, in Visual Studio with the Live Framework Tools installed that’s File->New Project;
and then I did a quick Build to make sure I had something that was basically working and then I pressed F5 which sprung up this dialog;
and that launched this dialog;
which led me through visiting the developer portal;
creating a new project up there;
entering some details like the name (TestMewa), choosing to create a “MEWA” rather than a “Web Site”, and then revisiting the dialog in Visual Studio and clicking the “Copy Link to ZIP file” entry;
and then using that to upload the package on the website;
which then gave me the Application’s Self-Link to paste back into the dialog in Visual Studio;
Visual Studio then did some uploading and launched the Live Desktop where it had already installed my TestMewa application and debugging of that application worked just fine. From there in, the debug cycle is a lot quicker in that Visual Studio just seems to deploy new bits when you press F5 and you don’t have to run through the portal stuff every time you want to rebuild/debug.
When I started to write code there were a couple of things that first struck me ( which stem from me not understanding Live Framework enough at this point ).
The first was around connecting to the Live Framework.
In my WPF code I’d done some work to explicitly connect to the Cloud Live Operating Environment (LOE) for certain things and then to generally work with the Local LOE for most things.
However…in a MEWA that doesn’t really seem to apply or perhaps even make that much sense.
In a MEWA, it looks like I’m given an LiveOperatingEnvironment that’s already connected to the [Cloud/Local LOE] depending on whether the application is run from the [Live Desktop/Windows Desktop]. I can get a MeshApplicationService instance from the GetMeshApplicationService extension method on my Silverlight Application class and it then has a property LiveOperatingEnvironment ( and I can check the IsLocalConnection property to know whether I’m talking to the Cloud/Local LOE ).
So…that explicit connection code kind of goes away in a MEWA.
The other thing that really hit me was that I was struggling to get to the MeshObject that I’d created in my WPF code.
That is, in my WPF code if I ran something like this code;
LiveOperatingEnvironment loe = new LiveOperatingEnvironment(); loe.Connect(new NetworkCredential(userName, password)); Console.WriteLine(loe.Mesh.MeshObjects.Entries.Count());
then this reports a value of 2 whereas if I ran this code inside my Silverlight MEWA;
LiveOperatingEnvironment loe = Application.Current.GetMeshApplicationService().LiveOperatingEnvironment; int x = loe.Mesh.MeshObjects.Entries.Count();
then this reports a value of 0.
So, the MEWA did not seem to be looking at the same list of MeshObjects as my WPF code. As far as I know, by default, a MEWA isn’t at liberty to access all of my MeshObjects and that feels like how it should be from a security perspective. I can see from the Framework Resource Browser that a MEWA gets a MeshObject of its own and it appears that it then works within that “container” rather than going beyond it.
However, I learnt that a MEWA is able to access a MeshObject outside of its own MeshObject but it has to ask in order to be able to do that and the mechanism for “asking” looks to be here and involves me creating a custom type for any MeshObjects that I want to share with the MEWA.
That meant that the MeshObject that I was creating from my WPF application wasn’t going to be visible to my MEWA because it didn’t have a custom type associated with it.
The first step then was to revisit my WPF code and ensure that when it creates its MeshObject, it uses a custom type for that MeshObject. This was a bit tricky for me because I’d created my MeshObject from a resource script ( as detailed in excruciating detail here 🙂 ) and I didn’t see a way in which I could create the category at the same time as the MeshObject in the resource script.
So, I added in a bit of code that tried to do its best around ascertaining whether the MeshObject had just been created on the server-side and, if it has, it tries to add a category to it as in ( taken straight from the doc link under the section “creating a custom type” );
SyndicationCategory category = new SyndicationCategory();
category.Label = "myPhoto";
category.Name = "myPhoto";
category.Scheme = @"http://www.mesh.com/DelegatedAuthObj/myPhoto";
photosMeshObject.Resource.Categories.Add(category);
photosMeshObject.Update();
And, hopefully, this puts my MeshObject into a custom category called “myPhoto” – I destroyed my original MeshObject and re-created it using this code in my WPF application and that all seemed fine.
But how do I now get my MEWA to be able to access that MeshObject?
There’s a lot on this page about constructing a Consent URL for an application that includes what resources it is trying to access. It seems like the idea is that at the time the user then installs the application they will be able to grant/deny consent to access those objects. On the Live Desktop, I can see the UI that offers the user a chance to accept/reject this kind of consent request;
and I can also see that if I have folders in my mesh such as a folder called “Foo” which I created as a test then there’s some additional UI;
where the “(Change)” hyperlink gives me;
but how do I get this UI to ask about access to my MeshObject of type “myPhoto” rather than just Folders which are already a part of Live?
This turned out to be a lot simpler than I thought it would be and was exactly as the document said it was but I was confused about what was meant by “install an application” . I need to take the installation URL of my application which is here;
and ensure that I add to it a request to give access to myPhoto objects. That is, I construct a URL that looks like this ( with PS=myPhoto.Full on the end of it );
and if I then go and visit that URL to try and install the application then I can see that the Consent UI that the Live Desktop is offering me for the application looks like this;
and if I click Change then ( WOOHOO! ) I see the MeshObject that my WPF code created;
now it looks to me like I probably also want to add back in to the URL the “standard” permissions so I perhaps want a URL that looks more like this;
which is then asking for a set of permissions more like;
Profiles.Read
Devices.Read
News.Full
Contacts.Read
Contacts.Write
myPhoto.Full
if I then use that URL to install the application to my Live Mesh rather then I can see that when I re-run this code from my MEWA;
LiveOperatingEnvironment loe = Application.Current.GetMeshApplicationService().LiveOperatingEnvironment; int x = loe.Mesh.MeshObjects.Entries.Count();
then I do now see the one MeshObject that my original WPF code created ( exciting! ) which had been proving to be so elusive up until now.
And so it turned out to be crucial that when my application is installed it offers the right installation URL to ensure that it has access to the MeshObjects that it needs and that the user ( in my case, this is me ) installs it using that URL and offers consent to those MeshObjects. Otherwise, the application won’t get to the objects it needs.
With that in place, I can now try and build a Silverlight MEWA that picks up the same photographs that my WPF code has been creating.
Having already built this once for WPF, I pretty much took my code and XAML from WPF and brought it into the Silverlight version of the “application” ( quotes because it’s not much of an application 🙂 ).
I left a couple of bits out of the Silverlight code;
- The initialisation code which creates the MeshObject and DataFeed using a resource script. I figured that ( for now ) the Silverlight application could just “assume” that these objects had already been created as it makes life simpler for me.
- The code which deletes the MeshObject and DataFeed ( if you can’t create then it seems unfair to allow delete 🙂 ).
- The code which explicitly connects to the Cloud LOE or the Local LOE – as mentioned previously, I’m not sure that there’s any need for that in a MEWA.
and pretty much brought the rest of the code across. Running it up I can get the full spectrum of application types on my desktop;
The application on the left is (clearly :-)) running in a browser and is the Silverlight MEWA running on my Live Desktop against the Cloud LOE.
The application in the middle is (not so clearly) the same Silverlight MEWA running from my Windows Desktop against the Local LOE.
The application on the right is the WPF application running locally against the Local LOE ( it sometimes talks to the Cloud LOE at initialisation time as previous posts have outlined ).
If I use one of the applications to add a photograph – e.g. the application in the middle;
then it shows up across all 3 application instances;
I’ve shared the code for download. Not sure how “re-usable” it is in the sense that you have to set a few things up in order to make it work and even then it might be flaky 🙂 but feel free to have a try.
Note 1: the WPF code needs credentials to log on to the developer Mesh and those live in a file called credentials.cs so you’d need to change those in order to get this code to log in.
Note 2: In the Silverlight project, I tried to break the link between the project and the particular application (in my Mesh) up at Live by changing this solution property;
Not sure exactly what that will do but hopefully it’ll ask you to enter a new Self-Link if you’ve gone as far as that with this solution.
What I’d be interested in next would be how to invite other Live Contacts into using this application.
Mike Taulty 