Search

How am I to code my BUI extensions to ensure they release memory appropriately?

Environment:

Agent Browser UI (BUI) Extensibility Framework

Issue:

BUI Extensibility Framework documentation does contain some information on how to evaluate memory usage here. Still, I am left to use general information on managing memory in Javascript to determine if my BUI extensions are coded appropriately - as I am finding no recommendation on best-practices etc. for managing memory in BUI extensions.

I have referred to this reference that looks to be knowledgeable. The reference contains this information:

"Frameworks and libraries such as jQuery do remove listeners before disposing of a node (when using their specific APIs for that). This is handled internally by the libraries and makes sure that no leaks are produced, even when run under problematic browsers such as the old Internet Explorer."

So the question is - does the BUI extension framework handle the disposing of event listeners and take care of other potential problems within - or should developers be concerned with any specific details around Javascript memory management when developing BUI extensions?

Further, I am seeing some code in an B2C Service accelerator that includes BUI extensions as part of the demonstrated/provided functionality. Please see code in attached Sample_CTI_Extensions.zip - specifically at this file:

Sample_CTI_Extensions\MSE_CTI_Workshop\toolbar\toolbar.html

Is it a best practice to include the memory management code within this section of that file?

Resolution:

There are various kinds of extensions in browser UI:

1. Console
2. Workspace
3. Analytics
4. Library

All the extension except library will create a separate iframe. The library alone will be loaded as part of any other extension's iframe. Hence, the lifespan of these extensions is the period over which these iframes are kept alive.

Console and Analytics extensions load during application login and will not be removed until one log out. Hence, while creating console and analytics extension one should be careful on the number of objects being referred from these extensions. However, in case of workspace extensions, the extension gets created only if someone opens the workspace embedded with the extension and will be removed once the workspace is closed. The framework will remove all the listeners added here automatically, along with the extent of other memory utilized by the extension, as long as there is not a console/analytics (or other extension still in use/memory) holding a reference to the extension at the time the object is being disposed of/destroyed.

In case of extensions, every object provided has a dispose method and once called it will free up / unsubscribe all the memory/subscriptions related to the objects and its children if any. Therefore, its good practice to call dispose of once the need for the extension object is no more required. This guideline even applies to accelerator code that you have taken as an example. The place where the memory cleanup needs to be done changes based on what the extension is intending to perform. In the CTI simulator, record closing is indeed a right place where we can dispose the workspaceRecord object. However, the basic guidelines are to call dispose on the object as soon as the object is no more required.