We have a book reading application and I have been tasked with implementing basic chat functionality. We have chosen openfire as the chat server. My question is, while reading a book, when the user turns the page, this does a complete page refresh. How can I keep the chat going across those refreshes? I don't want to bump a user and make them rejoin. Any ideas of the path I should take to implement this? We would in theory like to drop in a client into the page and it works with minimal effort. Anyways, are their clients that persist across refreshes?
Web pages are stateless. They cannot by themselves propagate data from one load to another. For that, you need to use cookies, and/or server-side sessions. Once you've got a user logged in and a login cookie/session token established, you can SIMULATE the chat being unbroken.
Basically, you keep the state of the chat in the user's session file, and update as necessary. That way, whenever the page is reloaded or they navigate to another page, the chat's state "just follows along", making it appear it was never gone.
Use AJAX + postate/onhashchange effect for all of the pages on the website. This way the page itself (the view) can change, but the content wrapping around it (header + footer) won't change.
Related
The Dynamics documentation is just awful and I couldn't find an answer to this simple question:
In the web version of the CRM, is it possible to register a web page that can be toggled by the user and that itself has an internal state (updated regularly by an interval set with setInterval) that will persist even if the users closes the page (not the entire CRM, just the sub-page)?
We need the user to provide some information for a CTI integration, and this background process to keep alive the CTI session by polling an API while the user session is active. In addition, we need to reuse the component where the user provides the CTI information to be notified if the session fails and restore it or close it if necessary. The real purpose for this is to make a screen pop (push content information about the incoming call to the agent) which I know can be done using Xrm.Utility, although doing it with a REST API method would be much better, RouteTo Aciton looks like the best method to do this, but I'm not sure it will proactively show the item in the user's browser.
I'm not sure this question is as simple as you suggest, it seems relatively complicated, and involves an integration. I'm not suprised the Dynamics documentation doesn't provide an answer for this specific and unique scenario.
I don't believe there is any single feature within Dynamics that will meet this requirement.
You could use a HTML web resource or a web page from a seperate web site iframed into CRM. I think the possible use of these depends on your expected user experience; I believe the user would need to have the page loaded at all times showing these controls (e.g. user is looking at a dashboard) - I don't see how the controls could interact with the user client side otherwise. You could show the controls in multiple places however.
Xrm.Utility is one way to open a record, but it can also be done by Open forms, views, dialogs, and reports with a URL.
RouteToAction looks like it just adds a record into the user queue, the user would need to refresh the queues to see the changes. I don't believe there is any way for a server side REST API call to natively redirect the user.
You could add JavaScript to do this, however you might struggle to add the JavaScript into every page of CRM.
Where I have worked on a CTI integration in the past (assuming you mean computer telephony integration), we always had some other component doing the screen pops - the client's all had a desktop app installed as part of the telephony solution.
Perhaps you could look into browser notifications, or a browser plugin?
I am almost finished with a SPA application using AngularJS and Bootstrap. So far, I got everything working as desired, except for one thing: Proper handling with the users acts on the Browser's back or refresh buttons.
All the sub-pages within the application have buttons/links to the pages the user may switch to. Still, the application should handle properly back and refresh browser buttons. I should add that there is a login process to enter the application.
Also, all the critical information is stored under $rootScope, so everything is lost when the user refreshes and, in some cases, when he acts on the back button the results are not as desirable.
I actually have two questions:
What is the widely accepted standard behavior of applications like mine when browser buttons are acted on? (remember, there is a login process to begin with).
How should I start tackling the implementation of this approach?
One option I was thinking, is to intercept the request, warn the user that the action will log him off, and if the user cancels, force the browser to ignore the request (not sure this is possible).
Client side routing, each view in the application should have a URL. This week allow the browser buttons to work as expected, and gives your users the opportunity to link directly to a view.
The most commonly used client side router for angular is angular ui-router - https://angular-ui.github.io/ui-router
What is the widely accepted standard behavior of applications like
mine when browser buttons are acted on? (remember, there is a login
process to begin with).
If you are using REST services,
Store authentication token in your local storage or in a cookie
When user refresh the page send a request to server and fetch user information
If the request result in 401 then show login screen
This is one of sample applications I have done with this approach.
I had a specific questin about angularjs with websocket. I currently have an application that utilizes a websocket to communicate with a server, this is all nice and dandy - and when I move around pages in angular the websocket persists throughout all of the routes which is neat. Unfortunately the problem is that if the user refreshes the page (for some dumb reason), the websocket disconnects. I was wondering what the best method of handling this is. Should I just have an alert when the user tries to refresh, can I somehow detect that the websocket is closed when the page is refreshed and start a new one? I'm just wondering what the best practice for something like this is.
Thanks
There is nothing you can do, if the user refreshes, it is like restarting an application, all the bootstrapping happens again and connections are created again.
You can use javascript:onbeforeunload to warn the user that if refreshes or leaves he will lose the connection. But your users will hate your for that, it is very annoying.
Consider as well, that the user may open several tabs.
Starting a new connection is the best way. Just make sure that the user can somehow recover his context. If there is a different context per tab, then you will have to put a connectionID parameter in the URL to persist it through refreshes, and if the context is per user session, then a cookie with the session ID will do.
I am currently building a WebSocket-based instant chat web application, it has more than one page. Every time users refresh or click a link to another page, WebSocket has to be reconnected. Is there a solution to avoid this?
If you refresh the page it will need to reconnect, i dont think there is a way around it.
I would recommend not using page-load to navigate between pages, but to build a single page application.
If you cannot do that in any way, maybe you can have your application in a frame, and the outer html will have the socket. that could work.
You might be interested in this blog post: WebSocket - persistent across page loads?
This discusses the issue and options in depth.
Disclosure: I work for Tavendo.
I'm just getting started with Pusher and so far everything is great.
But I realize that as my user opens and closes, or clicks on an internal link in my site, the connection automatically disconnects as the page unloads.
This would make the user connect and disconnect every time he navigates to a new page.
Is there a way to keep the user's subscriptions and connections persistent as he travels through my site?
Edit: Just to clarify, I understand the behavior that Pusher disconnects the moment the user closes his browser or page. I was just wondering how do we keep a connection alive if the person visits another internal link within the same site. Or is disconnection the best practice? If so, why?
As #devnull69 says, for the moment you would need to create your application so that it didn't perform standard page navigations - you would build your app as a SPA (single-page-application). That way there are no page unloads and loads between page navigations.
It may be possible to persist a connection between page loads by using shared web workers. But as CanIUse demonstrates, browser support isn't perfect yet.
Pusher does have plans to offer message history which would mean that any messages missed during page loads can be fetched upon reconnection.
Also see:
How to maintain a WebSockets connection between pages?
Do Shared Web Workers persist across a single page reload, link navigation
The only workaround would be to switch from regular page refresh to Ajax. This would enable you to keep up the websocket connection while loading only the part(s) of the page that change using Ajax requests.