Only applying the both methods seemed to fix the issue. Apparently calling alert leaks memory when used several times so that the accumulated garbage is not collected from the memory when exiting the app, causing it to be slower after restart

Instead of simply calling ndReturnEvent() I redirect the user to a new page exit.html (using ), which is almost empty, except for an onload handler, which calls the following commands (which are equivalent to ndReadyEvent() and ndReturnEvent() but without needing to include the Widget.js file)ĬtPreference('return','true').

I have tried to eliminate possible JS memory leak sources (using JS programming best practices and advice from Samsung), but that has not remedied the problem. I hope somebody has some first-person experience and advice regarding this. How can I return the user to the Smart Hub programatically so that the app does not get slower when starting it again? However, it is not a very clean method, and furthermore I would prefer to use the sendReturnEvent command.

Through trial and error I discovered that making the app crash on purpose solves the problem - this results in an identical behaviour to the user as calling the sendExitEvent method. (which returns the user to the Smart Hub instead of exiting completely). becomes slower after starting again) when using the command ndReturnEvent() The exit is realized by executing the JS command var widgetAPI = new () This behavior happens on all devices (TV and Blu-Ray Player devices with Smart TV Platform). The measured JS execution times are only slightly slower, but the HTML elements are rendered much slower to the screen.

Normally the app is performing well, but after exiting the app becomes very slow, by a factor of six. We have developed a Samsung Smart TV app for the 2011 & 2012 platforms.

Issues with glwiz app in samsung tv