Authors: Dave Bach and Priya Vaidya
Summary
Google Chromebooks* are relatively new to the computing scene, but already they are becoming increasingly popular within the education space. Schools and instructors favor Chromebooks because of their competitive pricing and undeniable reliability; whereas, students favor them for their ease of use and trouble-free operation. A common misconception is that Chromebooks have to be connected to the Internet in order to function. This misconception is well-founded because most developers don’t utilize the ability of apps to work offline. If developed correctly, Chromebooks are as flexible as any other PC platform. This case study outlines the lessons learned in developing an educational flashcard client and server that utilize some of the unique features of Chromebooks and the Chrome* web browser.
It is important to note that apps developed for Chromebooks are fully compatible with other operating systems that support the Google Chrome browser. The fact that an app will behave the same across platforms makes developing for Chromebooks an ideal one-size-fits-all solution.
Introduction
Chromebooks are built around the Chrome OS, which is a very lightweight flavor of Linux*. The Linux heritage is very obvious when the user boots into developer mode, where the familiar Linux shell presents itself. For most users, however, the centerpiece of the operating system is the preinstalled Chrome web browser. The Chrome web browser on the Chrome OS can do everything that the Chrome browser can do on a Windows*, MAC*, or Linux* platform. This might sound very limited in terms of flexibility, but the Chrome web browser, in its latest rendition, offers APIs that can make Chrome applications feel and behave very similar to native apps.
Developers have two approaches for Chrome OS development either build a hosted app or a packaged app:
- Packaged apps are, by far, the best way to develop an application for the Chromebook. Packaged apps work either online or offline and are executed on the host’s local hard drive. The user can access the app simply by launching it from the app launcher. Also, using sockets and http requests, packaged apps can optionally establish connections and communicate with remote servers to update their content. Packaged applications are very similar to native apps on Windows and Mac OS*.
- Hosted apps are very similar to web apps, the only difference is the inclusion of some metadata. The files for a hosted app reside on a remote server, which requires users to have Internet connection to access and use the app. Hosted apps are always opened from the web browser window versus their own window. The majority of apps on the Chrome Web Store are hosted apps or relinks to web apps.
Many hosted apps on the web store, such as calculator apps, timer apps, note taking, or other apps that don’t require an Internet connection to function, would greatly benefit if they were converted to packaged apps. The following flowchart can help you choose the right type of app. Notice that a web app can easily be made into a hosted app, and a packaged app requires more work and planning from the developers’ standpoint.
When building both hosted and packaged apps, the first step is to create a directory for the app. After the directory is created, the next step is to create a JSON file, manifest.json file, for the app’s metadata. The field entitled “launch” in the manifest file determines whether the app is hosted or packaged. If the “launch” field has a subfield titled, “web_url”, the app is a hosted app and its content can be found at the specified URL. Conversely, if the “launch” field has a subfield titled either “script” or “local-path,” it’s a packaged app. The difference between “local-path” and “script” is that the former opens the app inside the Chrome browser, while the latter runs the application in the background or opens up a dedicated window for the application to run in. For both “local-path” and “script,” the value must point to a local file. Please refer to Section 1 in the Appendix for examples of manifest files.
Hosted apps and packaged apps are further differentiated in the packaging step, at which point the app directory is zipped and uploaded onto Google. A hosted app should only contain the manifest file and the launcher icon, whereas a packaged app must contain the manifest file, the launch icon, and the CSS, JavaScript*, and HTML5 files. In practice, a packaged application must be self-sufficient and all of its files must be stored locally in order to run offline. A packaged app cannot rely on scripts or style sheets hosted on a remote server. Other than the manifest and the icon, a hosted app has its JavaScript, CSS, and HTML on a remote server.
This case study shows how to make a packaged app specifically for Chromebooks and showcases the details for developing the packaged client and a remote server. The app’s theme is educational.
Content Design
In order to decide what our app would be, we talked with consultants in the educational sector. The consultants identified that the educational market prefers apps that foster student-to-student learning. They recommended focusing around the idea of a student note/content sharing app.
Combining the technology available on Chromebooks and the recommendation from consultants , we initially decided to make a screen-sharing app that would allow students to share their screens and interact with each other in real time. Screen sharing isn’t new; there are plenty of web sites and online services. What we wanted was a Local Area Network, direct peer-to-peer, screen-sharing app. Interestingly, the Chrome browser has an API for capturing screen events; all we would have to do is send the data over the LAN using a TCP/IP protocol. Unfortunately, we found out that direct P2P communication on Chrome isn’t possible. Safety features and IP table rules prevent Chromebooks from connecting to each other directly. There are ways around this, but they require root privileges and booting into developer mode.
Because P2P connections are not supported, we decided to drop the screen casting concept and instead develop another form of content sharing. The idea was to provide students with a way to share notes and educational materials with each other. Combining this with other technologies available on Chromebooks today, such as the ability to optionally work online or offline, we set out to develop an application that has yet to be done on Chromebooks/Chrome browsers.
Working offline in the educational space is very important. Although a school might have Internet, it may not work outside of the classrooms. Internet is common in countries like the U.S., but many other places in the world do not have it. An educational app that works offline ensures that no student is at a disadvantage and gives everyone an opportunity to learn regardless of where they are, outside under a tree or in a classroom.
User Interface Design
After trying out a few successful educational apps for the Android* and iOS* markets, we finalized what we wanted our application to be. From a user standpoint, an application that gets used is one that is intuitive and responsive. So we decided to create an application where users can create and share flashcards, a concept familiar to everyone. Essentially, users create their own flashcards by entering questions and answers into a template the app provides. The following screenshots show the UI of our application:
To use the application, the user must first log in.
If the user doesn’t have an account, one can be created by clicking the register button. The account info is stored on a local database.
Once logged in, users will be see a list of all the card sets they either made or downloaded from an online repository.
They can then click on any set to proceed to the game screen. This particular card set has five questions
As the user goes through the questions, the application keeps track of the number of right and wrong answers.
When all the questions are answered, a completion screen displays. It has two options: restart and new level.
When new level is clicked, a selection page displays. On this page, users can also choose to make a new set of cards.
If a user clicks the “make your own” button, the application will ask for the name and description of the new set.
By default, each set has one question, but by clicking add question, additional questions can be added. When they are finished, they can click finish.
The level select page will then display. Notice that a new level is added.
Similarly, users can also add a level to their level select page by importing sets from an online repository. All they have to do is go into the catalog page and enter a search key. Using regular expressions, the server will then return relevant packages. Once a list of packages is returned, users can then choose which package to add onto their account.
Architecture
The system includes a client and a socket server. Communication will be done via socket communication:
Technologies Used
- Client
- Single HTML page– The client is built on top of a single HTML page, to give the application a more native app experience. Using multiple interlinked HTML pages is also a possibility, but doing so will result in a noticeable transition from one frame to another, much like transitioning between pages within the browser.
- CSS3 animations– The decision to use CSS3 animations instead of the traditional JQuery animation is speed. CSS3 animations are faster and are natively supported by the Chrome browser. Refer to this link for comparison:
- JQuery– JQuery seems to be the JavaScript package of choice for Google-developed Chrome sample apps. Instead of JQuery, developers could use another JavaScript library that doesn’t require in-line scripting. Be aware that some packages such as Angular JS do not work due to its inline nature.
- JavaScript– is the preferred scripting language because of its native support and speed. JQuery and JavaScript have some overlapping features. Whenever possible, standard JavaScript was used instead of JQuery. Refer to this link for comparison:
- Server
- Node.js*– There is no set standard for what language can be used on the server side—it could have been PHP, Ruby*, or Python*. Node.js was chosen because it is a relatively new language that is gaining traction in the web development space. Compared to older languages, such as PHP, it is much easier to use. More information on node.js can be found at:
- WS– This package is a Node.js websocket implementation that enables socket communication between the client side and the socket server. WS was chosen over the more popular socket.io extension because it does not require the client to download any additional script package from the server; whereas, socket.io requires the client to download a script hosted on the server.
- MongoDB– This noSQL database is a very popular combination to use with Node.js. However, a SQL database will also work with Node.js. Refer to the link below for more info.
Database Structure
The application utilizes two types of databases: client-side and server-side. When an Internet connection is available, the two databases work with each other.
- Client-side database (indexedDB) stores:
- User names
- Passcodes
- Multiple question sets
- each set has an array of questions and answers
- Server-side database stores:
- Multiple user uploaded question sets
- each set has an array of questions and answers
- Accounts
- usernames
- passwords
- the set ID for each user
- Multiple user uploaded question sets
Packaged App Standards
- Required files
- Manifest.js – used for granting permissions and referencing files
- HTML page– the program view, what the user sees
- Icon – an icon used for launch
- JS pages
- CSS pages
- Please see: https://developer.chrome.com/apps/first_app
- Security
- No inline scripts– All scripts are stored in external files.
- Self-contained– Everything that is needed for the packaged app to run has to be provided locally. No remote scripts can be referenced.
- Supported APIs – A few APIs are not supported in a packagedApp for security reasons.
Online vs. Offline Users
- Similarities
- both can create accounts
- both have password-protected privacy
- both can make flashcards
- both can review each specific set of flashcards
- both benefit from automatic grading
- Differences
- offline users cannot share their flash cards
- offline players cannot search and import flashcards from the online database
Organization and Presentation
Our application is organized around the underlying structure of the database. It is, in essence, a graphical interface with functionalities built on the database. With this application, users are performing database transactions. They allocate a portion of the database for themselves by registering an account, add content to their accounts by adding card sets. They can also add questions to those card sets.
This application extends the database in that it provides users with feedback. For instance, when users are reviewing their notes, the app checks their answers against the correct one on file. Furthermore, it provides a level of social interaction. Users can share content by copying their card sets from local storage to global storage. Once content is in global storage, other users can download it.
Outcomes
As beginners in web development, learning to develop for Chrome OS was relatively easy. Unlike full-on web development, we did not have to account for compatibility issues between the different browsers such as Firefox*, Internet Explorer*, Safari*, Opera*, and Chrome. With Chrome applications, developers only have to ensure the application works on the Chrome browser, so no extraneous source code must be added to correctly render across browsers. As of this writing, our flashcard application has been tested on:
- 64-bit Windows 8 Enterprise laptop
- 32-bit Windows 8 Professional tablet
- 32-bit Ubuntu* Desktop
- 32-bit ARM* processor-based Chromebook
- 32-bit Intel® processor-based Chromebook
Across all platforms the app behaves the same.
Possible Future Upgrades
This app would really benefit with the ability to upload pictures onto the flashcards. This would provide a new way of taking notes. Chromebooks already have the ability to take pictures using the built-in camera, so it is only a natural step to integrate pictures into our app.
Another upgrade that would make this app accessible to everyone is the ability to import and export card sets to and from a local storage device via a USB connection. The rationale for this is that not everyone is connected to the Internet. A large part of our app is about sharing notes and ideas. Users who are not connected to the Internet can’t share their creations with friends or family.
For those who are connected to the Internet, their ability to share shouldn’t be limited to the people around them. A possible upgrade that would extend the social reach of this app is the ability to share card sets on social networks such as Facebook or Twitter. This upgrade would make it possible for users to make flashcards, post their scores, and challenge friends to beat their scores on the web.
Appendix
Section 1: Sample Manifest
Sample Hosted app manifest
{"name": "Sprinkle Tinkler","version":"1.2","manifest_version": 2,"minimum_chrome_version": "23","app": {"urls": ["*://www.sprinkletinkler.com"
],"launch": {"web_url": "http://sprinkletinkler.com"
}
},"icons": {"16" : "icon-128x128.png","128": "icon-128x128.png"
},"permissions": ["unlimitedStorage","notifications"
]
}Sample Packaged app manifest (web browser)
{
"name":"Flash Mania","description": "An educational exploration.","version":"1.2","manifest_version": 3,"minimum_chrome_version": "23","app": {"launch": {"local_path": "index.html"
}
},
"icons": {"16" : "assets/icon-128x128.png","128" : "assets/icon-128x128.png"
},"permissions": ["<all_urls>","storage","fileSystem",
{"socket":["tcp-connect:*:*"]}
]
}Sample Packaged app
{
"name":"Flash Mania","description": "An educational exploration.","version":"1.2","manifest_version": 3,"minimum_chrome_version": "23","app":{"background": {"scripts":["main.js"]
}
},"icons": {"16" : "assets/icon-128x128.png","128" : "assets/icon-128x128.png"
},"permissions": ["<all_urls>","storage","fileSystem",
{"socket":["tcp-connect:*:*"]}
]
}Section 2: Loading packaged app onto Chrome for testing
- Store app directory on a reachable location
- Open the Google Chrome browser
- Click the menu button
- Select Tools -> Extensions
- Select developer mode
- Click on the load unpacked extension
- Select the application folder
- Your app should now be loaded onto the Chrome browser. Go to upper right hand corner and click “app”
- Click the app you just uploaded to launch it.
Section 3: Useful links
- Pros and cons of hosted apps and packaged apps:
- Helpful link for working with indexDB (local database):
- Chromebook security measures:
- Working with CSS animations
Section 4: Licenses
- Node.js: Free to use
- https://raw.githubusercontent.com/joyent/node/v0.10.29/LICENSE
- WS for Node.js: MIT license. Free to use
- Jquery: MIT license. Free to use
Credits
Node.js - http://nodejs.org/
WS for Node.js - https://github.com/einaros/ws
JQuery - http://jquery.com/
JQuery-UI - http://jqueryui.com/
CSS/HTML/JavaScript