I'm currently having some network issues, and my Wicket application does not react very nicely to the network being sluggish or down. I.e. I see no reaction in my webpage, not even the AjaxIndicator.
What would be the approach to tackle shaky networks in Wicket Ajax? And how to present this to the user in such a way that it is not annoyong (like pop-ups etc).
The application is responsible to show Ajax indicator when needed. E.g. you can show it always, or show it only after a delay of N ms [1].
You can also use the browser navigator's online/offline events to tell the user that her connection is down [2].
https://github.com/apache/isis/blob/587a8bd622c9511389b92102c4308f6dd0dfabab/core/viewer-wicket-ui/src/main/java/org/apache/isis/viewer/wicket/ui/pages/jquery.isis.wicket.viewer.js#L88-L96
https://developer.mozilla.org/en-US/docs/Online_and_offline_events
Related
We are developing a web application which will be deployed to many clients. The application handles sensitive data, so security is necessary.
We are using Spring 4 MVC and Spring Security. Currently I have the session-timeout set up and that works fine, but I need a way for the client to be automatically redirected (client leaves application running and computer unlocked, people passing by would have access).
I was thinking of a way to accomplish this would be to have the client somehow send out periodic (every minute?) fake requests to the server. Maybe just a refresh? This way when the session gets invalidated, the client will automatically get redirected out of the application. I do not know if this is possible, and if it it is, how to implement it. Any suggestions?
You can watch mouse movement, but that's about the best you're going to get for indication of a user still being there without listening to the click event. But there is no way for javascript to tell if it is the active tab or if the browser is even open. (well, you could get the width and height of the browser and that'd tell you if it was minimized)
How can I detect with JavaScript/jQuery if the user is currently active on the page?
How can I hide api service request from the network tab of the browser developer tool?
Any suggestion
Although I would strongly disadvice from doing so (as it won't stop any serious user), it would be possible to for example send it through flash or for that matter any other plugin with such functionality. The easiest way to achieve this would be to use a flash-enabled XHR proxy object like the one provided by the flXHR project (though you would have to force it to also function on the same domain, rather than only cross domain). Let me finish once again with not advicing you to do so, as the use of plugins will cause for a significant subset of your users messages to appear or not to work at all, which is in no way a good experience.
We are developing a free, open source Google Reader alternative at http://reader.pykih.com and the code is at http://github.com/pykih/reader
When a user signs up or adds a RSS feed, we add the feed url to the database and then ask a DelayedJob to fetch articles from that RSS url. This typically takes few seconds to minute or two, depending on the DelayedJob queue. Many users have complained that RSS feed is not being fetched at all when in reality it is being fetched. All that the user has to do is refresh his own page. We wrote a message there, yet users are complaining.
Can anyone point us in direction towards - what is the best way to design a Facebook or Google style "Loading" (icon in yellow) functionality and once loaded it automatically adds the entries to the screen without page refresh.
Thank you in advance
If I understand correctly, you basically want to update the user's view of the page while it's still open, in real time. (At any rate, that's what Facebook and most Google products do nowadays). This technique is usually called server push - information is pushed from the server to the client, instead of having the client request (pull) information from the server.
There are multiple ways to implement server push.
You could use AJAX to 'reload' the page every ten seconds or so. This is very easy to implement, but not realtime at all, and could cause unneeded load on your server. It works with all browsers.
You could use EventSource, a relatively new format supported by Firefox, Chrome, Safari, Opera and others (but not IE). It's a very simple format and easy to implement. EventSource is one-way communication only: it sends events from the server to the client, not in reverse.
You could use WebSockets, probably using a library like EventMachine and a WebSocket library. WebSockets allow fast bidirectional communication, but it's more complex than EventSource and only the newest IE versions support it.
You could use a commercial service like Pusher. Pusher is easy to integrate and fast, but not free. Browser compatibility is great, though.
The options differ primarily in the amount of client support (do you need IE support?) and the amount of Ruby integration you get.
I am facing a scenario where live Twilio call gets dropped, if the browser window in which call is received is reloaded. Is there a way to overcome this set-back without affecting the live calls?
Twilio Evangelist here.
Based on your question, I assume you are using the Twilio Client JavaScript SDK? If that is indeed the case, then unfortunately, if the page thats hosting the SDK gets reloaded the connection between the browser and Twilio will drop since the browser is reloading everything, including the JavaScript SDK.
There are a couple of different techniques I can think of off the top of my head that you can use to help avoid page reloads, and another idea that could help you recover a call where the connection to the browser has dropped because of a page reload. A lot of this is going to depend on your specific app and the experience you are trying to create for your users.
So to help avoid having to reload the page:
1) Use AJAX requests to your server in order to avoid page reloads. If your page includes content like a form, or you want to update the page content with data form the server, you can look using AJAX requests to the server instead of a normal full page postback to submit the form, or to retrieve the data form the server. This would help in avoiding having to reload the entire page in those two scenarios.
2) Use an iFrame to host your page content, and then put the Twilio SDK in the parent page (the one that defined the iFrame). This would let you reload the content hosted in the iframe, without having to reload the entire host page, avoiding a reload the the Twilio library. The downside to this is that communicating between content in an iframe and its host can get really messy fast.
Neither of these two techniques is fool-proof. Obviously a user can always just hit the refresh button on their browser, and thats going to cause the connection to drop.
In a case where the page does get reloaded, and the connection from Twilio to the browser gets dropped, one idea is to leverage Twilios capability to help reconnect the caller together. When a user calls your twilio phone number, instead of connecting them directly to the Twilio Client running in the browser (by dialing a client with <Client>), instead dial that caller into a conference <Conference>, and then have the browser client connect into that same conference. The benefit to that is if the browser disconnects, the original caller won't get hung up on, they will still be sitting in the conference room. As long as you've saved the Conference SID or name, you can have the browser client reconnect to that conference.
Hope that helps point you in the right direction.
What is the difference between all three? They seem to do the exact same thing. Why and when would you choose to use one method over the other?
AJAX and websockets do similar tasks — they both establish a communication channel to a server. Web workers have nothing to do with either of them, they are just separate threads of JS execution.
AJAX is more mature than websockets — it has been around much longer and has a much wider browser support. AJAX is request-oriented — you make a request to the server, the server responds, and the connection is closed. Websockets on the other hand establish a persistent connection to the server, over which you exchange multiple messages in both directions.
Webworkers are useful if you want to perform a processor intensive task without blocking the browser interface.
They are not same. But one can use them together to build advanced application.
Ajax: As abbrevation States is asynchronous javascript and xml.. is used to load the content dynamically from the server upon called.
Websockets : Websockets is the feature defined in HTML5 . As wikipedia states "WebSocket is a protocol providing full-duplex communications channels over a single TCP connection." so this is mainly used for real time communication such as video call, live chat etc..
WebWorkers : this feature is also defined in HTML5. This is basically used to make bring multi threading feature in Javascript. Since javascript is a single threaded programming language , it breaks or pause whenever i.e heavy calculation tasks are done using it. to overcome this breakage , Webworkers are added to javascript.
You can perform Ajax and Websockets inside Webworkers . however you cannot manipulate DOM using webworkers due to security reasons.
They are not the same.
Ajax: It is a way of interacting with a web server asynchronously from a UI renderer
Web Sockets: An HTML5 feature using which you can interact with any Socket server extending the reach of the browser
Web Workers : Another HTML5 feature that helps you do multi-threaded programming from a web browser using Java Script
Ajax & Websockers are siblings.
Webworkers are completely different.
AJAX
The best example of AJAX is Google's search bar - suggestions appear as you type, but the current webpage is not redirected or refreshed! (10 years ago this was amazing, not so much anymore). This is AJAX in action.
AJAX uses what's called a "request" and "response" model: you ask a question, and you receive an answer from the 'server'.
AJAX allows webpages to talk to "servers" behind the scenes, allowing you to update a webpage without navigating away from your URL. Back in the old days of the web, if you wanted to show different content on a webpage, users would have to navigate to a different URL: not any more. This concept has been taken to the next level with single page apps and applications (like React, Vue, Elm etc.).
Websockets:
With websockets, your web-page talks to your server (as with Ajax), and your server responds - except you do so like you're talking on the phone. There is a "connection" between your users and your server. This "connection" is not there with AJAX: in that case, you have a simple request and a response coming back from the server.
In other words, if you wanted to stream stock market data, constantly updating it to your users: it would probably be better to use websockets, than AJAX.
Web-workers:
Use When you need intensive calculations - if you were to ask a web-page to calculate Pi to 100000 decimal places: that might take a while. The web-page might freeze, and you might lose $$. The intensive calculations can be done in the background, without freezing your webpage. People using your site can do other things - e.g. click around, while waiting for the result in the meantime.