Sleep Manager — An App Based on JS
This article will introduce an application called SleepManager with its story of birth, which is an Ajax-based web diary application. DWR will form the foundation of the server side of things, DB4O for the persistence tier, and some client-side DOM scripting and CSS will be used to make this application “pretty”, ExtJs will help us to do so.
Wanna try by yourself?
1. Source Code
2. War File (put it into Tomcat Server’s container)
1. The Idea.
The future applications seem to be more concerning on the individuals. Sleeping counts nearly 1/3 of life time, if an application would help people to analyze the factors of sleeping, why not spend 5 minutes on recording your sleep status and make it better. Though the improvement on quality and quantity of sleeping depends on the real actions taken by the sleepers themselves, SleepManager can help people who suffer from sleeping-troubles to record, analyze and discover their sleep patterns.
Google makes the blur idea turn to be clear. Frankly speaking, at first, the idea is nearly to lose an election when we search and find out a website in Japanese language that is already doing the same thing and is fairly mature in functionalities. However, after digging around that website and using it as a normal user’s role, we still think it is worth of building such an application of English version( there are no such a website in English language right now) since the Japanese website contains numerous modules which may not suit for the most of users ( it is a common style that asian website tend to contain as much information as it can). After all, this existent application is a tutorial, too. We learn the “use cases” from its portal (or say, user panel) and use firebug to do the “anatomy”.
Then, our task becomes to be “abstract the essentials of it and find ways to implement the functions”.
2. The Scope
Let’s now codify the features this sleep diary application will support, and the general design goals:
1, Who are our users: people living in a fast life-style, i.e. employees and students under pressure, who care about their health status and want healthy sleep.
2, In what situation, when and where: we assume the users are using our application when they are going to bed or just getting up, no much time to wait for the page jumping, so our applications should be a little easier on the eyes. User can go to the action by NO MORE THAN ONE CLICK.
3, In addition to the UI being “efficient”, We want user interface (UI) to be ”tidy”, like other Web2.0 sites do. For example, Gmail and Youtube are more like to concern on the functionalities and provide only simple but beautiful UI. (This conclusion is based on the observation more than 150 Web2.0 sites).
4, Users can see graphs demonstrating the statistics.
5, The individual user can create, update his/her sleep records;
6, What is the data being transferred and stored: Nothing much, integers and strings representing date, time and notes (that means browser-side needs to do the rendering job for statistics graphs, not server side)
The 6th scope answers the 4th scope, before reaching this point we discus a little bit on how can we render the graph (bar chart). We use firebug to dig and find that the existent application is transferring a image from server to the client. Apparently, such a solution is of slowness in performance. Therefore, we turn to use JavaScript-based to do the job. Although Flash-based solution is also a good idea, but none of team member are familiar with that one, learning Action Script costs more time and we don’t want our project get delayed. After an hour of searching work, JavaScript tends to be the one (details in Specification section).
3. Requirements
After making some decisions, more decisions are waiting! We use Google Docs to record the content of our online discussion, which becomes to perform as documentation in the following work. Furthermore, we draw a scratch and invite seven friends to give some suggestion of requirement; they are of a range of age from 12 to 65.
Figure1. Scratch of user panel (at suggestion gathering phase)
- The sleep diary form should be simple and intuitive for users to enter.
- Sleeping usually overlaps two adjacent dates. The following method is used to organize data
o Record date
o Sleep date (should either be the record date or the date before)
o Sleep time (sleep date time should precede wake-up date time)
o Wake-up date (should either be the record date or the date before)
o Wake-up time
o Wakefulness (a scale indicating wakefulness after getting up)
o Note (for user’s own reference)
- The current version does not allow users to store other information, for example, afternoon nap.
- Users can see his or her sleeping pattern in a diagram form.
- Sleep related articles can show up on users’ pages and users can click those links to read more.
- Users are identified by a user name and a password.
4. Specification and Design
Basically, to finish the task, we will write persistence beans, controller’s classes and web pages, but what is exactly the technique should be used? Which one can be used and tested most efficiently? Which one gives the best performance?
4.1 Server Side: Persistence-Tier
The use cases and objects lead to database modeling, two entities in it: user entity and diary entity, then we search for a technique for persistence-tier. The first thing comes to our mind is MySQL server, a popular and Relational Database product. It is free and well supported (lots of books and tutorials provide “Hands-On Training”). The second candidate, DB4O, is object-oriented. After checking the tutorial and guide books, we find out that:
1, the operation DB4O is transparent and friendly for programmers;
2, it provides helpful querying functionalities, handy for Java developer: Query by Example (QBE), Native Queries (NQ) and the SODA Query API (SODA);
3, DB4O can release us from headaches on writing in-line SQL statement, which tends to have error and hard to debug (from the earlier experience);
4, the migration of the DB4O database is easy — just copying the stored file. But for MySQL, we need to generate MySQL script for your schema and tables (administrator privilege is required, also maybe a new username may need to be set up), that will bring troubles and is not agile.
Because of the advantages of DB4O, we decide to choose it.
4.2 Server and Client Communication: DWR.
(In this report, the word “client” and “browser” are referring to the same concept.)
The preliminary technology is AJAX + servlet/RPC. It requires verbose and repeated coding; DWR (direct web remoting) will help us to invoke a server side method/function more easily. For example, the submitted form is treated as a bean and will be sent as a parameter via a function of a object in JavaScript, this object is mapping to a class on the server side. DWR also has a friendly test suite for debugging. Such a clear mechanism will make our life easier; furthermore, it supports reverse AJAX well, which is useful to add splashy functions (i.e. sending advertisements) in future. So we choose it!
4.3 Client-Side: User Interface
XHTML + CSS + JavaScript, which becomes the web standard, defines the “structure”, “presentation” and “behavior” very well, we cannot find another combination as competitor. Since we want our user happy with the reacting time (stated in scope 2nd), AJAX are needed (DWR-based). User Interface should be compact and tidy, so that user can go to the action he/she needs by NO MORE THAN ONE CLICK (stated in scope 3rd), in order to do so, ExtJs can be taken advantage of, because its panel has a beautiful layout with collapsibility. When going deeper into the ExtJs, we find out that it can accomplish “structure”, “presentation” and “behavior” all together. But its learning curve is steep, which means it needs professional knowledge in JavaScript. Resource are from API documents, ExtJs forum and tutorials, no book existing for ExtJs. Unless we get the official support, otherwise it is risky. But we really need ExtJs to let our users to have better experience.
We are confused at the very start to this point, since both of team members are not familiar with JavaScript. To decrease the risk, we decide to take a compromised procedure:
Phase1: Basic
Build a face/faces with DIV + CSS, accomplish JavaScript functions (i.e. form submitting, client side DWR method invoking); (Figure1)
Phase2: “ExtJslized”
Implement ExtJs, use its components to replace the module step by step.
4.4 Client-Side: Graph Module
As stated in the 6th scope, the task is to transform the integers to the bars on the chart. Some articles[1] offer us a list of possible choices, and we select Flot, which is a component of jQuery framework. Compared to some other JS-based chart rendering module (montch, flotr), Flot is kind of that can be built in an hour to archive the task, less function but easy, and we choose it.
5, Coding and Debugging
We decide to do it in “extreme programming” way, and use SVN (Subversion Control) for the “working separately” situations (both team members can update and download the edited code at home, without conflicts). Google Docs are used for task-definition and documentation. To get a better efficiency on coding work, several methods and principles are taken, which is proved to benefit a lot along the whole process:
5.1 Conventions
0. We write interfaces to communicate and express the requirements; all the implement classes should pass the tests by JUnit.
1. The classes which are used and converted by DWR should provides test method (since DWR cannot use a bean as a parameter to test) and pass the tests.
2. The client side DWR object and method should be validated
(by sending to the console: console.log (object) 
in the callback method.
3. Use Adapter Mode to assemble the classes together.
4. Use Factory Mode to provide the DAO.
5. Use Singleton Mode to avoid conflicts when connecting to ObjectContainer(the DB4O database). Why we do so: DB4O do not have a management system like traditional 6. Relational Database, it may have risk on concurrency operations. Fortunately, its CRUD(Create, Retrieve, Update, Delete) methods are syncronized, so, if DBConnector returns a static singleton instance of ObjectContainer, the concurrency problem, when each DAO instance are accessing the same database, can be solved.
7. Use DWR to set and get the information in session. Why we do so: JavaScript cannot access session (of course), but we want to record the information of user in the page he/she is opening, after googling we find DWR has such utilities. By doing this, we actually abandon the utilities of JSP.
5.2 Re-design
5.2.1 On which side should we put validation?
In the coding process, there are re-design session, for example, when doing the user register module, we change the decision: making the validation from the client side (by JavaScript hard coding) to server side, to make our system more robust in future (because in future we may tranform the application for different language, so the validation rules change due to some reason such as encoding charset or length of username) .
5.2.2 Refractor by ExtJs framework
After finishing all the components on the server side and the basic functions by JavaScript + DWR-mapping-object, we feel safe about this “0.9″ version, planning to go to Phase2 and make it “ExtJslized”.
ExtJs is chosen to make the UI more compact by using its collapsing panel layout (and yes, it’s a one page application). Since there are many JavaScript libraries are imported in one page (ExtJs, DWR, Flot, our own usages), we use name space to avoid collisions on naming. We write ExtJs components in object-oriented way to let them reflect to the major DOM elements, for example, a nested panel reflects to a div called “left-side” bar.
5.2.3 RSS feature
After the phase 2, we decide to put more features on it about RSS generating and subscribing. The system will help user to subscribe feed on the topic of sleeping heath, taking advantage of yahoo service. User can also generate their own feed of sleep diaries. This is done by ROME, a Java library for RSS; we choose it simply because the tutorial gives enough information to implement our functions.
5.3 Tools and Plug-in
Firebugs in firefox and Spket plug-in for Eclipse are good tools for JavaScript Coding. If not using such kits, a missing semi-colon will kill us. ExtJs forum is a good place to ask questions, if the question is presented clearly, people here are willing to help. It is always good to ask people.
6. Screen-shots of version1.0
Figure2. User panel with record graph
Figure3. User panel(collapsed) with amount graph
Figure4. User registering
Figure5. Register success and redirecting
Figure6. Validation of login panel
[1] http://www.smashingmagazine.com/2007/10/18/charts-and-graphs-modern-solutions/
Recent Comments