As luck would have it, the journey didn't end there. In the months that followed, I ended up working with customers to help them take that sample and deploy in the real world. That process of putting theory into practice presented some challenges to overcome. Rather than attempt to rewrite the article taking these extra details into account, I have decided to write a short follow-up to discuss those challenges, and how they were addressed. In taking this approach, it is my hope to keep the initial article as clear and uncluttered as possible, so that its fundamentals are not lost.
In the sample attached to this article, there is an updated EmbeddedViewerPlugin sample plugin, and two sample HTML files, named XDomainViewerAPI.html and XDomainViewerWindow.html. As a starting point, both of these would be deployed within the application that will call into ICN.
With the XDomainViewerAPI.html described in the previous section, a second browser window must be opened and managed. The time that it takes for the second window to open may vary depending on platform, and the time it takes to load the content of that second window may take varying time as well. While we can do our best to set up a "handshake" between these windows, there is always some chance that the window will take longer to open than expected, or may not open at all, or may be inadvertently closed by the user.
The sample attached to this article has been tested and used on customer systems successfully. There are two important details to point out with it.
First, the handshake to the second window has been set up so that once it is launched, no further attempt is made to launch it a second time, either until the window opens and can be accessed, or the script times out waiting for the window to open.
Second, the code functions that open the window, and obtain the window for calling are all wrapped in try/catch structures. Any error that occurs in these areas will cause the code to reset its state and start over with opening the browser window.
Additional checks are placed to detect, where possible, when the window has been closed by the user, and logging is added to help with diagnosing issues that may arise.
With the caller code implemented this way, the worst that can happen therefore, is that the script resets itself and starts over - opening a new viewer window.
Other than the items covered in this article, the script contains the same function calls, and works in the same intended fashion as those in the first article.