Engineering JavaScript State Persistence Of Web Applications Migrating .

interaction resources available in the target device.Afterwards, the Migration Server analyses such a targetlogical description containing all the various presentationsand identifies the currently focused presentation. Finally,the identified logical presentation is then transformed inorder to build the corresponding implementation for thetarget device, which is sent to the target client so that theuser can load the adapted page with the state resulting fromthe interactions occurred on the source device and thencontinue the interaction with the new version of the page.this library in order to serialise the objects that are nothandled by standard JSON (Dates, array properties, DOMelements) and we manage the serialisation of objects thatdo not appear in global variables (e.g. timers), by using alibrary-independent mechanism explained in the followingsection.Global and BOM variablesIn JavaScript code, every object/variable defined in theglobal environment is simply a property of the globalWindow object (which in turn represents the browserwindow). In order to programmatically capture the valuesof the user-defined global variables, we use the JavaScriptfor.in statement, which enumerates the properties ofobjects (without knowing their names in advance).However, there are some window properties that, thoughenumerated, should not finally be included in the migrationstate. These are the properties belonging to the so-calledBrowser Object Model (BOM), an interface provided bythe browser, which makes available a number of “utility”properties (e.g. the address of the page currently loaded inthe browser, the reference to the DOM root, the historyproduced by using “Back” and “Forward” browserbuttons). Such properties should be excluded from themigration state since on the one hand some of them arebrowser-dependent, while, on the other, some properties(like the reference to the DOM root) are already handled bythe migration platform, thus they are useless for migrationpurposes. The mechanism we use to exclude the BOMrelated variables is to create a “filter” list for each browserconsidered (Internet Explorer, Safari, Opera, Firefox,Chrome). This support works with any web application.The state that we preserve is composed of the valuesassociated with all the forms elements, the current focus,the cookies, and the state of the JavaScript code. The lastone has shown to be the most problematic aspect, whichwas not supported by previous solutions for migratory userinterfaces and, thus, in this paper we discuss extensively itssolution, whose importance also derives from theincreasing use of JavaScript code.MANAGING JAVASCRIPT STATE WITHIN MIGRATIONThe problem of correctly managing the JavaScript state inmigratory Web applications is a critical point, and sinceWeb applications are becoming more and more interactive,it is likely to play an even more important role in the future.Indeed, if the state associated with JavaScript variables isnot properly saved and restored, inconsistencies can beexperienced when the user migrates to the target device.This means that exceptions could be raised due to the factthat some variables no longer exist in the new versionuploaded on the target device, or even worse, no exceptionis raised, but some variables might hold incorrect values(namely, ones that are different from those held when themigration was triggered).Object ReferencesThis case refers to when the migration platform has toserialise two variables or properties that refer to the samevalue and the value type is non-primitive (then, it is a typedifferent from Number, Boolean, etc.). For instance:To capture and restore the JavaScript state of a Webapplication we basically use JavaScript code (automaticallyincluded in the concerned Web page by the Migrationplatform). Regarding the format for saving the state, weuse the JavaScript Object Notation (JSON), since it is alightweight format and in addition the JSONserialisation/parsing support is natively integrated withinmost currently available browsers.var x anObject ;var y x ;In this situation, standard JSON would i) serialise twice anObject and ii) serialise it into two separate objects(one for the x variable and the other one for y). Instead, inour solution the result of the serialiser is that the y variableis associated with a unique reference to the x variable. Withthis mechanism (called object referencing) we avoidduplication of value serialisation and preserve, aftermigration, the fact that the y variable will continue to referto the x variable.The data types that are supported by the standard JSONformat are: i) primitive types (Number, String, Boolean,null); ii) arrays (like [value1, value2, .]); iii) associativearrays (also known as “Maps”), like {key1: value1, key2:value2, .}. However, just using a standard JSON serialiseris not sufficient, since – as we will see – some problemsare not appropriately handled by using it alone (objectreferences, non-numeric properties of arrays, timers, ). Inthe following sections we describe the main issues we haveaddressed regarding the capture and restoration ofmigration JavaScript state, and the associated solutions weadopted. As we will see, such solutions include using aJavaScript library (dojox.json.ref [3]), which we havecustomized in order to properly handle specific issues.More specifically, we made a number of modifications toCircular ReferencesA special case of object references is represented bycircular references. We have circular references when thereis a variable, which is defined through another variable,which in turn is defined through the first one. Let usconsider the following JavaScript excerpt:var johnJohnson {name : "John" ,107

father : {name : "Paul" ,son : johnJohnson}global/public list of timers saved in the state and then, byre-starting the central timer, all the connected timers willalso be re-started. In this way, the active timers will beconsequently restored in the target device.};DatesThe Date object is used to work with dates and times.Standard JSON does not support the serialisation of a Dateobject since it serialises it as a void object. Thedojox.json.ref library provides only a partial solution forthis problem. Indeed, it correctly serialises the Date objectinto an ISO-UTC –formatted string, but it is not able to reconvert it again into a Date object without explicitlyinstructing the deserialiser with a list of Date propertynames. However, even doing this, the solution was not ableto cover some situations, for instance when an object hasmultiple properties of Date type at different nesting levelsand the same name. In this case only the first occurrencewas correctly preserved with that technique. Our solution issimpler and more general: we encapsulate the ISOformatted date in an object holding a property that marksthe object in such a way that the deserialiser can quicklyidentify and correctly restore the object as a Date Object.By using standard JSON, the variable johnJohnson couldnot be correctly serialised, since standard JSON serialisesevery object through its value and therefore an endlessrecursion will result, eventually raising an exception. In ourcase, in order to correctly preserve the object state, weserialise the reference to the object (not the value). This hasbeen done by exploiting the dojox.json.ref library, which incorrespondence of the value of the “son” property puts areference by using a path-based referencing mechanism.The latter technique supports the identification of an objectproperty by specifying its location within the object’sstructure. Thus, in this case, in order to identify the “son”property of the object we provide the path that goes fromthe root of the tree (where the tree represents the object), tothe leaf (representing the property involved).TimersTimers are generally used when the developer wants toinclude some time dependency within the code (e.g.indicating that a certain portion of the code should beexecuted after a specific number of seconds). They arehandled through the methods setTimeout and setInterval(resp.: to activate a single timer which triggers a handler atits end; to repeat a portion of code after a specific timeinterval); and through the clearTimeout and clearIntervalmethods (resp.: to stop a currently active timer, which isidentified by an ID; and to clear a timer set with thesetInterval method). In the following example handler isthe code excerpt to run after ms milliseconds have elapsed;timerId is the identifier associated with the timer:Properties dynamically assigned to objectsIn JavaScript all the non-primitive data types (likeassociative arrays, arrays, strings, functions.) are objectsand, as such, can have dynamically assigned properties.Such properties are saved in the state by standard JSONonly if the object containing them is an associative array(or Map), otherwise (namely, if they are included by othertypes of objects) they are ignored. An example of thisproblem can occur while serialising the following excerpt:var array [value1 , value2];array.dynProp someValue;In order to manage this issue, we have identified a solutionthat successfully manages saving such dynamic propertiesalso for other types of objects apart from associative arrays.So far we have implemented this solution for managingarrays, though our solution is easily extendible to othercases. In our solution we appropriately modified thedojox.json.ref serialiser in such a way that it encapsulateseach array in an object holding a property that contains allthe array’s dynamic properties.var timerId setTimeout (handler , ms);clearTimeout (timerId);Timers can affect the state in two possible manners: first,we can have timers that are currently active/pending at thetime when the migration occurs; secondly, in the code wemight have variables containing references to timers.Unfortunately, the ECMAScript APIs neither offer methodsenabling to access the state of an active JavaScript Timer,nor do they allow enumerating the list of active Timers.In order to cope with this issue and allow the correctrestoring of timers after migration, in our solution weoverride the standard behaviour of setTimeout by addingadditional code able to appropriately handle the state oftimers. More specifically, the solution we adopted creates aglobal/public list of Timers, by adding a Timer object tosuch a list every time the setTimeout (or setInterval) isinvoked. Since such a list is global, it will be easilyaccessed in the global state. The timers of such a list will beupdated by a single “central” timer which will invoke atregular intervals the update function of each active timer. Inorder to correctly restore timers after migration, in thetarget device we build a list of timers starting from theReferences to DOM nodesThe JavaScript of a web page can access the DOM treenodes by reference (e.g. to read or modify them). Thus, thepersistence of such references is needed in order topreserve the state.Indeed, one of the most common operations carried out onthe DOM tree is to find a node by providing its identifier(by using the getElementById method, which provides areference to a DOM node that has a unique ID).Unfortunately, standard JSON is not able to correctlyserialise JavaScript variables containing references to DOMnodes. The following cases can happen: either the108

concerned element has an ID, or it does not have an ID, orit does not belong to the DOM.Consider the following excerpt:However, the entire JavaScript state is now included insuch a JSON message. loadState(), takes as input parameter the JSON messagerepresenting the state of the migrated application andrestores it within the target device.Transmitting and restoring the stateRegarding the transmission of such a JSON message, this iscarried out by an AJAX request directed to the MigrationServer. Through such a request, the client passes both theDOM of the page and the JavaScript state to a servlet(which is on the Migration Server). According to suchinformation, the servlet creates the corresponding page.This means that first the servlet identifies the body element of the page derived from the received DOM. Then,it appends a JavaScript function, whose goal is to updatethe JavaScript variables contained in the page, to thecurrent content (if any) of the onload attribute of the body element. After having done such modifications tothe page, the servlet stores the updated page (containing theup-to-date state) in a specific location of the server, andalso stores the JSON message received from the AJAXscript in a file. According to such information, the serverthen builds the URL from which the target device browserwill load the page with the updated state. So, by analysingthe received JSON message the target device browser willbe able to restore the state in the target device (loadState()method). This is done by deserialising all the properties ofthe abovementioned JSON object and restoring them ontothe corresponding global variables. Then, the pendingtimers are also created and the central timer is started again(as explained above). So, the actual restoring of theJavaScript state of the Web application is carried out withinthe client, after the Web page has been loaded.In the following sections we describe them further.AN APPLICATION EXAMPLE: JS-TETRISSaving the StateThe saveState() method works in the following way. Aspreviously mentioned, we use the for in statement as themain mechanism for saving the value of all the JavaScriptglobal variables (which are properties of the windowobject). As also noted before, we added to the for.in cyclea condition to check whether a certain property has to beexcluded since it belongs to the BOM variables. Afterhaving done this, we create a JSON message containing acouple (key, value) for each property of the concernedglobal object. It is worth noting that the serialisedJavaScript state is no longer in standard JSON, because theserialised properties are enriched with additionalinformation that will enable the custom deserialiser tocorrectly handle special objects that cannot be[de]serialised by using standard JSON (e.g. Date objects,array properties with non-numerical keys, DOM elements,or even HTML elements which are not in the DOM).To show an example application, we consider a Web(XHTML pl/tetris/), a widely known arcade game.The considered game (see Figure 2) is composed of a12x22 grid, in which objects with different geometricalshapes fall to the bottom of the game board. The playercontrols the pieces by moving/rotating them, trying to makethem fit each other so as to compose a horizontal linethrough them. When this occurs, the line(s) of piecesdisappear and the score increases. As the horizontal linesare completed, the game becomes more difficult (e.g. thepieces fall progressively faster). Alternatively, if the playerleaves holes within the horizontal piece rows, they do notdisappear but start to pile up, until the player is no longerable to play, and the game will end. The UI of the game iscomposed of a number of nested DIV elements. First, thereis the top level DIV (representing the whole game), whichin turn is vertically decomposed into a DIV element (for themenu) and another DIV element (with the game board).var element getElementById("myHtmlElement");var image new Image("imageSource");In our solution, when an object of type HtmlElement isactually a reference to a DOM node, we verify whether ithas an ID. In this case, such an ID is saved within the state,otherwise our solution assigns an ID to it. In the remainingcase (when the object does not belong to the DOM, like theimage variable included in the above code excerpt), thevalue of the object is saved by storing the values of all ofits public properties using the JavaScript library JsonML(http://jsonml.org/).SAVING, TRANSMITTING AND RESTORING THE STATEWITHIN THE MIGRATION PLATFORMIn this section we focus on how the migration platformsupports the saving, transmission and restoring of theJavaScript state of Web pages. The core of our solution isrepresented by the JavaScript JSStateMigrator library wehave developed for this goal. Such a library has two mainmethods: saveState(): saves the current JavaScript state into aJSON message represented by a Map object, andincludes all the global variables of the application andtheir properties;109

Figure 2: Desktop-to-mobile Migration of the ExampleThe menu is in turn composed of a number of DIVelements, each of them including a menu item (the controlbuttons, the next piece, the score data, .). The board areais a DIV element which initially contains only the twelvevertical columns, which act as guides for the pieces.However, as soon as the game progresses, such elementswill contain the various small, elementary squares (eachof them represented by a DIV element) composing eachgame piece. The game layout and the initial positioning ofits elements are handled by an associated CSS stylesheet.and describe its application to a case study in the gamedomain. Future work will be dedicated to carrying out anumber of user tests to assess the usability of thepresented solution on various case studies.ACKNOWLEDGMENTSWe gratefully acknowledge support from the Artemis EUSMARCOS and the ICT EU SERENOA projects.REFERENCES1. Bharat, K. A. and Cardelli L. Migratory Applications.In proceedings of User Interface Software andTechnology (UIST ‘95), 1995, pp. 133-142.All the JavaScript code is included within the constructorfunction Tetris, instantiated after the Web page is loaded,and then saved in a global variable. Within this function,various nested functions are defined: start, reset, pause,gameOver, random, as well as up, down, left, right, spacein order to control the pieces. In addition, otherconstructor functions are defined such as Window,Keyboard, Area, Puzzle, Stats, HighScores, which definecorresponding properties of the game. In addition, in theTetris code there is also the definition of some anonymousfunctions, which are assigned to properties of DOMnodes, for instance ( ("tetris-menu-start").onclick is forstarting a new game). Finally, there are also additionalproperties defining the board area (unit, areaX, areaY). Inthe desktop-to-mobile migration of the Tetris game (seeFigure 2) our migration platform exploits some of thefeatures for managing the JavaScript state we describedbefore. Indeed, this game has object references such asreferences to HTML elements, and timers.2. Chung, G., Dewan P. A mechanism for SupportingClient Migration in a Shared Window System,Proceedings UIST’96, pp.11-20, ACM Press.3. Dojox.json.ref library, available athttp://docs.dojocampus.org/dojox/json/ref4. Ghiani, G., Paternò F., Santoro C. On-demand CrossDevice Interface Components Migration, ProceedingsMobile HCI 2010, pp. 299 – 308, 2010, ACM Press.5. Kozuch, M., Satyanarayanan, M. InternetSuspend/Resume, Proceedings of the Fourth IEEEWorkshop on Mobile Computing Systems andApplications (WMCSA’02) IEEE Press, 2002.6. Melchior, J., Grolaux, D., Vanderdonckt, J., Van Roy,P. A toolkit for peer-to-peer distributed user interfaces:concepts, implementation, and applications.Proceedings ACM EICS 2009: 69-78.CONCLUSIONS AND FUTURE WORK7. Quan, D., Huynh, D., Karger, D. R., and Miller, R.User interface Continuations. Proceedings 16th ACMUIST Symposium. 2003. ACM Press, pp. 145-148.In this paper we have presented our approach forsupporting JavaScript state persistence and, consequently,task continuity in interactive Web migratory applications,110

domains: for instance, applications whose tasks require time to be carried out (such as games, business applications) or applications that have some rigid deadline and thus need to be completed wherever the user is (e.g.: online auctions). We focus on Web applications, which have limited support for state persistence and continuity