Updating Web App code without reloading it - javascript

Is there any way or possibility to update an apps code and have the client adopt it without reloading the app/website? I mean updating live application code, like adding or removing functionality.
The iPad asks for user permission every 24 hours for fullscreen webapps, for native apps it does not. Once you grant permission it will not ask again but if you reload the app, which you usually have to when you push an update, it will ask again if 24h passed.
We are installing iPads into Taxis and want to track connectivity around the city with geolocation data, but we can't do it reliably since the app would ask the guest for permission. We also would like to provide some location based features but wen can't do it because if one guest says "No", it will impact all next guests since the iPad only allows aksing twice and then you have to wait some time before you can ask for using Geolocation again,

By update the code I presume you mean live code reload or changing the modules loaded on a page without changing it.
This would require you to have an infrastructure library that allows you to either reload or add modules of code to your applications. ncore allows this
Next you would need a communication channel from the server or some other remote end point to send new modules or module reload commands to the client browser.
The concept being that you have a websocket open and you send one of two commands
add module : url
reload module : name
The app in the browser would then either load and add that module from an url or reload that module.
This is basically remote control over the state of an application in a users browser.

Related

Google Optimization for e2e test with protractor

Login optimization should be implemented in order to speed up the execution time of all e2e tests. Currently, after each test we have, the Chrome browser closes, and the next session login should be done again in order to proceed with another test. How and what should be changed regarding this matter. Any advice?
Unfortunately without details of how your application works, i can suggest only some generic things:
Usually applications store something like session token in cookies, you can try to grab it, and set again after browser reloaded. Make sure you are trying to set cookie after page is opened. Docs to read:
browser.manage().addCookie(...)
https://selenium.dev/selenium/docs/api/javascript/module/selenium-webdriver/lib/webdriver_exports_Options.html#addCookie
You can try to make HTTP request from the page with needed credentials, so cookies that you will got in response will be set to page. To do this you can use browser.executeScript(...) with fetch/XMLhttprequest inside
You might think about running a selenium grid with different selenium nodes. Your browser instances can be configured to run in the selenium grid endlessly if you do not run browser.quit or browser.close at the end of each test. That way using the method Xotabu4 mentioned above, you can set the browser cookie using browser.manage().addCookie(...). You can also clean the browser cookies if required.
Now your running browser instance will have the auth cookie for the tests you are running and you will no longer have to worry about login. These tests are better if you run it in a selenium grid using docker containers because you can monitor different chrome/firefox nodes and if any of them die or restart. You will have to configure the chrome node containers in such a way that everytime a node is restarted, you add auth cookies to your browser.
Another suggestion I have for you is to disable authentication check in your automated test environment and test authentication in a different environment. I know the quality of this advice would vary depending on your application.
Every test scenario requiring login runs the login function before running any other tests everytime. One thing common in this is the login functionality. If you abstract that functionality out and ensure that functionality is working well and then disable that functionality and test everything else. You will save a lot of time. Only thing you need to be sure about here is that the login functionality integrates with the rest of the moving parts of your application in exactly the same way.

Custom web page and javascript routine running in the background

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?

How to maintain the page state in Domino Web Application

I am working on a Web Application developed & hosted on Domino R9 Server (Non Xpages Web Application). Each form has WebQueryOpen and WebQuerySave events implemented for the server side business logic. Problem is that on every page, when the page refreshes from the browser, application's home page/form is loaded. I want to maintain the state of a page in this application.
Moreover, is there any possibility of implementing an Ajax based session handling (backend) in case the page was idle for sometime and session expired. For example if a user was writing something in the Web Editor (implemented in CKEditor latest version) and if his session is automatically dropped he should be able to start with least hassle and his already written stuff may not be lost.
My suggestion is to not use WebQueryOpen and WebQuerySave. Instead write the application to use modern web technologies (Ajax, JSON, REST API), then you don't need to save and reopen the page all the time. Doing that will give you everything you want.
I would build the page using standard HTML and Javascript (or even jQuery), then make Ajax calls to agents on the server to read/write data.
I have given several presentations on exactly this, with plenty of code samples and even finished code to download:
http://blog.texasswede.com/mwlug-2015/
http://blog.texasswede.com/my-mwlug-presentation-2/
http://blog.texasswede.com/my-connect-2017-demo-code/
You can save the contents from all fields and CKEditor in a JSON string and also the UNID (or any "primary key") to the current entity (=page).
Afterwards, you can send this string to the server using AJAX, or as an alternative...
... have you tried using HTML5 local storage? See this page:
https://www.w3schools.com/html/html5_webstorage.asp
Tell us how do you continue!!!

Pubnub: Background Processes for an Auction App Development

Hello I am developing an auction app like tophatter.com. I want to implement an application that has background process in it. I want this process to run forever until I stop it
http://eoction.com thatss our current site. The problem on our site when we refresh the page the auction also restart. We need something like a continuous process like tophatter.com if you refresh the page it will load the updated auction process.
I found this great service called pubnub. I am thinking we need a background process for this? This will process the auction on the pubnub blocks and then when we visit the site we will just need to query on its updated process?
Does pubnub support something like this?
PubNub Web Page Best Practices
When user refreshes your web app page or navigates to another page there are things you need to consider as a web app developer no matter what technologies you may be using. I will address, at a high level, the things you need to do when PubNub is integrated into your web page.
Restore Parameter
Whether the user interrupts your connection to PubNub or it is a network failure, you will want PubNub to reconnect and continue where it left off as much as possible. The PubNub JavaScript SDK has a initialization parameter called restore that when set to true, will reconnect to PubNub and get missed messages after the connection is dropped and reestablished.
var pubnub = new PubNub({
subscribeKey: "mySubscribeKey",
publishKey: "myPublishKey",
ssl: true,
uuid: getUUID();
restore: true
});
Reuse UUID
It is important to reuse the same UUID for each end user as this will allow PubNub to identify that user uniquely when it comes to Presence so that it doesn't produce new join events for the same end user. The PubNub JavaScript SDK actually generates a UUID and stores it in localStrorage and reuses it by default but very likely you have your own UUID that you would like to use for each of your end users.
Last Message Received Timetoken
If the network disruption is brief as is the case with a page refresh or page navigation, then missed messages are retrieved when restore:true is implemented in the init as stated above. But when the user is offline for more than say 5 minutes, you may want to retrieve missed messages on one or more channels. The best way to do this is to keep track of the timetoken of the last received message by storing it in localStorage every time a message is received via subscribe callback. When the user comes back online and it is has been more than 5 minutes since they were last online, call history using this last received message timetoken on each channel that you need to get missed message from.
Subscribe to Channels
Finally, you'll want to make sure that the user is subscribed to the channel they expect to be based on what their state prior to the connection disruption. If it is a page refresh, you likely just want to resubscribe them to the same list of channels. To do this, you just need to keep a list of channels they are currently subscribed to, once again, in localStorage. If the user navigates to a new page and this causes a full page reload (modern web apps should not require this, but...) then you may want to unsubscribe from some channel(s) and subscribe to new channel(s), it just depends on what that page navigation means to your app. Modern web app frameworks do not require full page reload for page navigation since the web app acts more like a desktop app than older web apps. And again, if the the user was offline for quite some time (more than 5 minutes) then it may not make sense to subscribe them to the same channels that they were subscribed to before. Really depends on your use case.
And by the way, Tophatter uses PubNub ;) but all of the above are generic best practice guidelines and recommendations and is not referencing any one app in particular.
EDIT: To address you question specifically, as pointed out in comments below...
You can't implement long-running process in PubNub BLOCKS (not currently, anyways), so you will need a server process for this. When the user refreshes the page, you just need to hit your server for current state. If using PubNub to keep this progress bar updated in realtime, you just subscribe to that channel that is sending the state of that progress bar and update your client. Using the same best practices I provided above are still necessary.

Issues in SPA when user uses browser's back or refresh function

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.

Categories