Automated User Interface Derivation for Remote Data ...

POSTER 2015, PRAGUE MAY 14

1

Automated User Interface Derivation for Remote Data in Standalone Apps Martin Tomasek1 , Tomas Cerny1 1

Dept. of Computer Science, FEE, Czech Technical University in Prague, Technick´a 2, 166 27 Praha, Czech Republic [email protected], [email protected]

Abstract. Present day applications usually use the clientserver architecture involving web services. The client is usually tight to the server-side API and must follow the message format, location of endpoints, service parameters, security restrictions, etc. User interface (UI) of the client-side application interprets and manipulates server-provided data. There exists significant duplication of the data model on both the server and client sides, which must correlate to avoid inconsitency error. This increases the efforts in the development phase as well as in maintenance. Future changes to the server-side data model must be reflected by the client-side and since this involves manuall change propagation, it is a significant source of errors. Furthermore, such errors are usually resolved at runtime, which makes their avoidance hard. In this paper we address the above difficulties, and consider extention to the server-side that besides the data itsels provide a UI model that allows us to determine and generate the client-side UI while avoiding the duplication. Moreover, we consider the message format, user input validation rules, type safety and information centralization. We evaluate the proposed solution on a prototype and compare its advantages and disadvantages from the UI perspecive, development and maintenance efforts.

nology that is used to generate the UI and technology to process a particular request. The preferred concept is to divide the application to web services [10] as processor and a thick client as UI representation. The thick client can involve technologies such as Java, AngularJS [7], HTML5 [6], etc.

1. Introduction

Usually we need to represent the actual application state at the client-side. The state can be captured by a visual object that holds the particular state information, its representation usually consists of application data as well as of information reflecting particular field, their types, etc. However, the object that deals with the representation does not generate the UI representation. A particular UI is manually described by developers. Unfortunately, designing a particular UI is time-consuming and error-prone process [8]. For instance, that time that is allocated to UI design is around 50% [8] from the overall development time. The applications requirements and possibly the application data model may change during the development life cycle and all the changes must propagate to be reflected in the UI. Moreover, we have to consider application security and access rights because each user may have different rights and thus some actions are restricted to certain users only. To increase usability each user is presented a UI that reflects his access rights and concrete purpose of his goal. This implies that often we need to describe multiple distinct UI presentations for these varying situations which further extends the involved efforts and the level of duplication. If there was a way to generate parts of UIs based on the data model, the process could be automated and server-side changes would be immediately reflects by the client-side. Such automation would also mitigate inconsistency and human errors. So far we described just one perspective and we did not take into account the involved client-server communication.

Software applications usually provide User Interface (UI) that acts as the gateway to the application. It allows users to display and manage data, control processes, derive reports and access information they need. The UI should reflect the purpose of application and provides users a tool which is used to control the application. In order to increase efficiency and usability it provide a proper feedback on user actions. Contemporary applications aim to separate the tech-

The server-side usually considers public and private web resources and underneath consists of object-oriented classes responsible for business validation or a dedicated persistence layer responsible for maintaining data. Each web resource has a unique location accessible through a URL and either consumes or produces a concrete instance of data. The message accepted by producers and consumers usually expects a standard format such as JSON or XML [10]. How-

Keywords User interfaces, web services, UI generated based model,

2

Martin Tomasek, Tomase Cerny, Automated User Interface Derivation for Remote Data in Standalone Apps

ever, in order to make the client application aware of the server provided data, the client must follow the data structures defined by the server. Thus the client application must create equivalent projections of the data structures. The client application then synchronizes the data, following the structures separately defined by both sides. The business validation applies on data provided to the server followed by passing the actual data to the persistence layer for storage. The main problem we depict here is the client-server data synchronization that must consider separately defined data models that must correlate. Consequently, wrong model on either side may lead to information loss or to integrity issue. When the model changes at the server-side it must change also at the client, which most likely impacts the UI presentation of the data. In this paper we consider alternative approach to generate client-sides. The main problem we consider in contemporary approaches is the model synchronization, the clientserver model correlation and needs to reflect all server model changes at the client-side. At the same time, we aim to avoid the need to design multiple slightly different UI presentations for users with different access rights. We address these issues by exposing the UI definition model at the serverside for clients in a machine format so that they interpret the model content to derive the UI presentation for data elements. Having the server-side responsible for the providing the UI definition model makes the client-side unaware and loosely coupled of particular data structures involved in the UI presentation. This brings the flexibility to automatically adjust to changes at the server-side. Furthermore, the approach reduces possible typological errors and avoid inconsistency. Furthermore, we extend the UI definition model for data element with rules for user input validation and show their integration to the client-side application at a case study. This paper is organized as follows. The next chapter describes the related work. Our proposed solution is described next. The following chapter evaluates our approach. The paper ends with conclusion.

2. Related work There exists various concepts that address the introduced issues and we discuss them in this section. We divide the section to two subsections. First, the generation of UIs, next, the data representation for clients, including the data transmission.

advantage is that generated UI is always actual and reflects all changes made to the model. The model transformation can consists of multiple strategies which can take into account input validations or even access rights. In the effect the efforts to provide various UIs for different goals and users reduce since duplication can be reduced. It also brings good abstraction to manipulate the data definitions and to see its relations. Furthermore, novel technology can be supported simply be adding new transformation rules, while reusing the model. On the other hand there are multiple issues with the MDD approach, for instance we would need to generate from the model not only the client-side, but also the serverside to keep them in correlation. This might become impractical as many developers prefer to make changes in code rather than in model [3], which consequently disallows future model-to-code transformations since all manual changes would erase. Thus having solely the client-side generated from the model is impractical as we only delegate the issue from client-server correlation to model-server correlation. Next, the MDD is usually executing the transformation at the compile time [3], which might be a difficulty for context-aware systems that consists of large amount application states that might be dependent and forming exponential grow of states that in result occupy disk space, even though they are just hypothetical. This may further impact the UI description transmission as multiple states might require to be transmitted to the client-side [4]. Another idea considers code-inspection and consequent transformation [1] [12]. Thus compare to MDD the information is captured in code, and the model is generated add-hoc at the code-inspection. Compare to MDD this can take the advantage of runtime transformation. The framework called AspectFaces [11] generates UI based on codeinspection model and involves Aspect-Oriented Programming for the transformation. It considers all the enterprise standards and information from the code, the transformation is template based, which allows to influence the transformation result. The code-inspection idea based on metaprogramming that gives the program the ability to describe itself and deduce what properties the program components have, which fits to the UI derivation since most of these information is used in the UI. Another idea, which is used in this approach combines metaprogramming and declarative programming [9]. Declarative metaprogramming is used to configure generative programming with the concept introduced in [9]. In this concept uses Smalltalk Open Unification Language as part of transformation syntax-tree such as XML to combine logic facts.

2.1. Generating user interface There exists a significant amount of work in the area of Model-Driven Development (MDD) [2] [1]. The rational is to design models from which the UI can be generated based on model description and its information. The main

2.2. Data representation for clients So far we did not discuss the way the client application presents the UI to users. For instance, the AspectFaces

POSTER 2015, PRAGUE MAY 14

extend the server-side UI representation, the Java ServerFaces (JSF) component tree, that renders to clients with webbrowsers as HTML fragments. The presentation is assembled during the rendering JSF phase. However, our aim is to build UIs on the client-side independent on particular technology. Another framework called MetaWidget [12], which is used to generate UI has an extension to generate UI on the client-side. MetaWidget comes with the idea that inspection is set up based on application, then specific elements are used for the UI assembly. Next, it is possible to use the standard REST [10] protocol to transfer data between client and server for Angular JS technology. The idea introduced in [5] suggests to divide and untangle various elements involved in the UI assembly, so that their transmission size can reduce and independent decisions on client-based caching can be made to optimize the transmission.

3. Proposed solution This section presents our proposed solution. We use the model derived from code-inspection to generate the UI. In the consequent text we divide three subsections. First section, explains the UI generation. Second, shows the way it is processed at the client-side. Finally, we describe the integration of the ideas from the previous subsections. We demonstrate the prototype application created based on the proposed architecture.

3.1. Code-based, Model-driven UI generation The UI generated based on model derived from code brings multiple advantages. The actual information applied at the code at the server-side are used, which in result avoids typographical error and reduces issues with type safe variables and consistency issues between the model and UI. However, we need propagate the derived model to the client-side. The abstract UI representation is derived at the server-side and then provided to clients, which we mention later. We use the AspectFaces approach and thus apply code inspect to objects that are subjects of visualization in the UI, and for these objects we derive the abstract UI definition. The result is a platform-independent UI representation. That is provided to clients through a machine readable way through web services. Our goal is that the generated UI reflects the actual state of model as well as the application context, security and possibly other custom conditions provided by developers. Our approach is to provide presentation for data elements such as forms, tables, lists, reports, etc. The generation process has 3 phases and takes as the input a reference to data that are intended to be presented in given UI in given context. The phase 1 applies code inspection to the data reference, this determines the ad-hoc model that is used for the transformation. The inspection can be applied at runtime but since the

3

result does not change, caching can apply for performance optimization. The phase 2 is invoked during the phase 1 and applies the transformation. It maps the model properties to it UI representation, such as widgets. Each widget is described through a template and specifies the component type, behavior and settings. The phase 2 resolves the property representations and through their integration produces the complete component. The phase 3 customizes the generated components. This last phase is optional, and is intended for customizations of the UI. Next, we look at these phases closer. Based on the visual objects is generated the UI presentation. The phase 1 audits each field of the object and based on the field type it starts the transformation process with the goal to find an appropriate component template to use. The transformation rules used in the transformation are part of phase 2. They query the inspected field properties and based on the queried clause they determine whether to use a particular template. The transformation rules are described through an XMLbased Domain-Specific Language (DSL). Developer can adjust and define custom rules to reflect the actual needs. The transformation rules are aware of field properties but also have the ability to consider runtime application context, such as access rights, geo-location, user input validation failure rate, etc. The result of the field transformation is the selection of the most suitable template and its content resolution towards the data field and the application context. The phase 2 determines the content for all visual object fields using a particular layout specification. The layout specifies individual field composition at page,window or a panel. At this point the suitable abstract UI presentation is resolved. "widgetType": "TEXTFIELD", "id": "login", "label": "Login", "classType": false, "readOnly": false, "visible": true, "layout": { "layoutDefinition": "ONECOLUMNLAYOUT", "layoutOrientation": "AXISY", "labelPosstion": "BEFORE" }, "rules": [ { "validationType": "REQUIRED", "value": "true" }, { "validationType": "MAXLENGTH", "value": "255" } ], "options": null

Code 1. Example of retrieve generated UI from server

4

Martin Tomasek, Tomase Cerny, Automated User Interface Derivation for Remote Data in Standalone Apps

There exists, although one more transformation, which converts the abstract UI presentation description to objects, which could be used in the final phase to customize the components. These objects can be modified or extended to influence the final definition. At this point we generated the platform-independent definition of given visual object. The Code 1 shows an example. In the example is a single component type, component identification, settings, general information about layout and validations rules. The layout only describes that there should be a single column layout applied in the interpretation, which should have the orientation based on the axis X. The concrete layout implementation is determined upon interpretation at the client-side. The same applies for user input validation rules and for the way how to interpret and represent the component represent at the client-side.

3.2. Interpreting the abstract UI at the clientside So far we discussed the server-side responsibilities. This section shows the interpretation of the abstract UI at the client-side. The server provides the platform-independent abstract UI description in a machine readable format, such as JSON [10]. The content can be interpreted on various platforms using native components, which further improves the usability for the end users. Thus the single description provided by the server can have multiple interpretation and possible slightly different results reflecting the client-side platform. As described in the previous subsection the component definition is represented through an object, which means that we know the object structure and we can work with it even if the visual object or resource has been modified. When a client aims to derive a UI presentation for a particular data element the abstract UI description is requested from the server-side. Based on response that provides the contextaware UI description is derived the UI for the particular data. Our preliminary prototype interpreter is Java-based application that uses the SWING framework. It process the abstract UI definition, however, the interpreter can be written in any language. We describe the prototype later in more details, and explain the interpretation. The client-side application issues a request to the server-side and based on the response is derives the concrete presentation using native components, such as input fields, combo boxes, radio buttons, etc., An example of code is shown in Code 2. This code retrieve definition from server. The definition which is used is on Code 1 and shows only a single field from a more complex visual object. The example in Code 2 built form and interpret field as JTextField based on definition in code 1 with label Login and this element is visible to users. It also sets up layout, which means that the label is positioned right before the input text and the text field will be on the

right side of the label. The border layout is be used. This is a concrete layout specific for the SWING. We also take care of the additional settings, which mean that there could be specifies custom skin of generated components, such as colors, sizes, fonts, etc. The validations are set up as well. The validation in this case requires at least one character in the input text field. The field is assembled and when the user selects a particular data element then it is received from the server-side and integrated to the field. The matching bases on the field name in hierarchy, which mean that it can recognize for example this person.name, person.pet.name , etc. in the object graph. When user finishes the interaction with the component it sends back the server the data to create, update or delete. Specification of this action could described in a global XML configuration that describes the configuration information, such us locations of resource with definition, data and endpoint to accept objects to commit data changes, etc. Next, let us consider the client-side process of the UI assembly. Consider the example in Code 2. First of all a builder initiated. Developer specifies the identification of the intended page/window UI fragment, that is to be assembled. Next, parameter identifies the connection resource to use, finally, other parameters are provided. The connection resource is specified through the XML configuration. In this file can found be all the the necessary information such as resources, parameters, authorization, etc. The expression language is used to specify variables that should be resolved at runtime. AFSwinxFormBuilder formBuilder = AFSwinx. getInstance().getFormBuilder(); formBuilder.initBuilder("personForm", connectionResource, "personFormConnection", parameters); AFSwinxForm form = formBuilder.buildComponent(); Code 2. Example of retrieve generated UI from server

The complete communication and UI assembly, which was discussed above is displayed in the Fig. 1. First, the client requests to obtain the UI definition. Based on this request is created the definition involving the model and codeinspection, transformation and the combination phase. The client-side builds the UI based on the definition and then requests the particular data values. The server find the data to display, provides them back and the client display them in the assembled UI. The component is embedded to the UI in the application. When the interaction finished then the client asks the server to process the data and server commits a particular action.

4. Evaluation We tested this concept on a prototype. First, we like to present the framework restriction. Arrays and collections

POSTER 2015, PRAGUE MAY 14

5

Fields

Server

Client

Total

2

9,9+0 ∆

5,9+0,5 ∆

16,3 ∆

13

25,7+2,5 ∆

30,3+1,8 ∆

60,3 ∆

Tab. 1. Measurement - average time required to create definition and build view in ms ∆. Number of measuremenet 30.

the average times of overall composition take lite more that 60ms for the 13 fields sample and about 16ms for the 2 field sample. The resulting times are promising for the requirements of production applications. Example of generated form is shown in Figure 2. There are read-only elements and elements, which are used to insert date. There is a two column layouts and in the combo box are values specified during the 3rd phase, which brings the component customization. Fig. 1. Complete communication between server and client.

are not supported as the data field, however, we support all the non-primitive data types, such us provided by various persistence frameworks, which can be integrated with this approach. The JSON messages are supported and only a limited amount of layouts is provided. For the evaluation we consider an application, which is used to manage person’s absence at work. This application has a server-side with database using standard Java Persistence API and REST API [10], which is used to obtain the abstract UI definition and data. The client-side has login form, security control is on the server-side. At the client-side are 7 views, which are used to control the application. To generate input component or tables we use only the represented technology, but buttons in menus and buttons, which control the application flow are created at the clientside. Notice the Code 2, only 3 line of code are necessary to assemble the data UI presentation. In the end it is about 23 lines of code to generated the UI and set up the data or to send the data back to the server. On the server-side must exists a corresponding mapping and an component definition. These mappings and definitions are reusable. We decided to separate the definition resource from data resource. The reason is that when the developer wants to integrate this approach to already existing application the change of public or private API is complex and this can provide smooth integration. Next we consider the performance. We divide the measurement to two parts, the client part and the server part. We ignore the time needed for the transfer of data from the client to server. The object, which is considered has 13 fields, the second measurement has an object with 2 fields. The measurement results are shown in the Table 1. At the server column is a number, which indicates generation plus customization. At the client column is a number, which indicates generation from definition plus setting the data to generated fields. The measurement was repeated 30 times and

Fig. 2. Example of generated view.

5. Conclusion In this paper we present alternative approach to assemble UIs at the client-side for situations when all data are stored at the server. We considered the use of codeinspection approach and MDD to generate a platform independent UI description that is transformed to the UI. We demonstrated concept on prototype basing on SWING technology and provide information about performance. The advantages of the approach is that it is possible to reflect all changes made at the server-side automatically at the client with not manual work, avoiding human errors and inconsistencies. However the approach only consider the derivation for data presentations and actions and navigation is left to developers. The approach brings the benefits of platform independent UI description provided in machine readable format from the server to native clients, which allows to derive UI using native components ti increase user comfort and integrate native features. In future work we like to focus on Mobile and JavaScript apps using the same concept we presented in this paper.

References [1] Tomas Cerny, Karel Cemus, Michael J. Donahoo, and Eunjee Song. Aspect-driven, data-reflective and context-aware user interfaces design. Applied Computing Review, 13(4):53–65, 2013 [2] Miroslav Macik, Tomas Cerny, and Pavel Slavik. Context-sensitive, cross-platform user interface generation. Journal on Multimodal User Interfaces, pages 1–13. Springer Berlin Heidelberg, 2014.

6

Martin Tomasek, Tomase Cerny, Automated User Interface Derivation for Remote Data in Standalone Apps

[3] Tomas Cerny and Eunjee Song. Model-driven rich form generation. INFORMATION-An International Interdisciplinary Journal, 15(7, SI):2695–2714, JUL 2012. [4] Tomas Cerny, Lubos Matl, Karel Cemus and Michael J.Donahoo. Evaluation of Separated Concerns in Web-based Delivery of User Interfaces. (To appear) In Proceedings of International Conference on Information Science and Applications, LNEE, Springer, 2015. (WOS) [5] Tomas Cerny and Michael J.Donahoo. Separating out Platformindependent Particles of User Interfaces. (To appear) In Proceedings of International Conference on Information Science and Applications, LNEE, Springer, 2015. (WOS) [6] Hickson I., Berjon R and collective HTML 5.1 W3C Working Draft 17 March 2015. Could be downloaded from: http://www.w3.org/TR/html51 , 21.3.2015 [7] PhoneCat Tutorial App. Could be downloaded from: https://docs.angularjs.org/tutorial , 21.3.2015 [8] CERNY, T. - CHALUPA, V. - DONAHOO, M. Towards Smart User Interface Design. In Information Science and Applications (ICISA), 2012 International Conference 1-6, May 2012. [9] GODERIS, S. - MEUTER W. Generating User Interfaces by Means of Declarative Meta Programming. In ECOOP02 Workshop on Generative Programming, 2012 [10] Fredrich, T. RESTful Service Best Practices Recommendations for Creating Web Services Could be downloaded from: http://www.restapitutorial.com/media/RESTful Best Practicesv1 1.pdf, 21.3.2015 [11] CERNY, T. - CEMUS K. AspectFaces documentation Could be downloaded from: http://wiki.codingcrayons.com/display/af/AspectFaces, 21.3.2015 [12] KENNARD, R. MetaWidget documentation Could be downloaded from: http://metawidget.sourceforge.net/documentation.php, 21.3.2015

About Authors. . . Martin Tomasek received his Bachelors and Masters degrees from Faculty of Electrical Engineering of Czech Technical University (CTU) in Prague. He currently works in the public sector and applies for the Ph.D. program at CTU in Prague. His area of interest are enterprise application and user interface development. Tomas CERNY received his Bachelor’s and Master’s degrees from Faculty of Electrical Engineering of Czech Technical University in Prague, and M.S. degree from Baylor University. He is currently an Assistant Professor of Computer Science at Czech Technical University in Prague. He is also a Ph.D. student in Prague. His area of research is software engineering, model-driven development, enterprise application development and networking.