Isolated (per page) App Part communication

Question

Many of you may know this blog post which explains how to communicate between app parts (from the same provider). Unfortunately the post only describes how to communicate between "all app parts of this provider", e.g. if you have multiple tabs or even multiple browser sessions open (or are even logged in with different users) and are on the same page all app parts on all these open tabs will get notified when a change occurs.

My question is: Does anybody know a solution on how you can isolate this communication to the current-page-session the user is on? This means I only want the communication to be between app parts which are on the currently loaded site (if the site is open in another tab I don't want to communicate with the app parts there).

My issue is, that I don’t know how to recognize which AppParts are on the same page and within 'the same' page request – I would therefore need a unique page-request identifier and a way to pass this identifier to all AppParts to avoid cross-tab / -browser / -user / -session etc. communication.

I thought it may be possible via the AppManifest.xml file by adjusting the Query string parameters (e.g. pass a Unique-per-Page-ID) - which then would have been passed to the loading URL of the IFrames - but I could not find a parameter which helps me with this.

Has anyone any idea how to do this? Or has anyone done this?

PS: I know you can do it via PostMessages but this is not a good solution since you have to place some JavaScript directly on the parent SharePoint page (outside the app part).

Answer 1

This is not a problem of SharePoint or the AppModel this needs to be Addressed with signalR.

A possible solution is this: https://stackoverflow.com/questions/10089386/signalr-push-notifications-to-all-browser-instances-of-single-authenticated-user

You create a subscription Group with the Username, this will dismiss the different user problem. Leaves the Tab problem, concatenated with some parameter unique for this tab should solve this, too. But now it becomes tricky. Due to the internet stateless habit each iframe is something like a tab on its own, just embedded in another site. No connection possible when in different (sub)domains.

I see only two options:

• Use some JS on SP Site to deliver some unique parameter to both iframeurls. Unfortunately i do not set any AppUrlTokens which can be used for this in AppManifest: https://msdn.microsoft.com/en-us/library/office/jj163816.aspx
• Find something both have in common like current time stamp of pageload +/-2 Seconds(a bit obscure, i know)

Hope this helps you.

Answer 2

Ok, so i think i stumbled upon a method which might solve the issue: The postMessages API. This is nothing SharePoint related but can be used with SharePoint though it features communication between host and iFrame sites. So the way to go should be:

1. postMessage the host site
2. return something unique for the page like the __REQUESTDIGEST or something self generated
3. use this as your SubscriptionGroup in AppParts on the site.

This should solve the problem: all the AppParts have the same unique information to differentiate them from other tabs. This method is also very good for retrieving information from the host site like querystring parameters for use in AppParts.

A great source how to accomplish this is this blogpost by Adam Toth

Answer 3

I finally found a solution which is satisfying for me.

Even though I wrote, that postMessage is not what I want to do - this has now become the solution.

I always knew that I can solve this problem with postMessage (refer to @Rafael Dabrowski post for details).

What I didn't like about it, was always that I thought I would have to edit every single page where I wanted to make use of postMessage and add a JavaScript WebPart which then acts as aMessageHub to receive postMessages and then forward them to the iFrames.

However I recently realized that you actually can inject JavaScript into the whole web or even site collection (see here and here) where your app was installed - you can even do this in an App Installed Event Receiver ! This is great because now every SP page is already ready for the postMessage - so it's enough to just place the AppParts on a page and they can start communicating immediately.