Webapps, Widgets, API’s, Oh My!
At the 2010 AT&T Developer Summit during the CES week in Las Vegas, I gave a talk titled “Web Applications”, followed that with a webcast “Getting Started with Web Applications” on the same subject in January, and followed up with a more detailed whitepaper “Getting Started with Web Applications”. These talks are the start of a planned program of information for web application (webapp) developers. We will cover webapps as you can develop for use in browsers and as widgets, on mobile phones and other devices. There are various goals of this program, including:
- To help you understand what webapps are, and what you can do with them.
- To give guidance on specific topics of particular importance in webapp development.
- To provide introduction and links to valuable resources and tools you may find useful in developing webapps and learning about additional topics.
- To help you understand what application programming interfaces (API’s) are available to webapps, both as device API’s and network API’s.
- To inform you about the roadmap for API development and convergence in industry standards.
- To provide code examples and working webapps, so you can see concrete examples of how you can address webapp design issues, including cross-browser support and use of various API’s.
- And other things you suggest: tell us what you want to know!
The webapp I call “reader” is a simple application that allows the user to browse and read some files that are packaged with the webapp on a web server or in a widget package. Two use cases are addressed by it: use of long formatted files (HTML) such as ebooks, which might be broken up into smaller segments or chapters, and which the user can browse through using the webapp; and use of plain text files which need to be presented in a pre-formatted way, in this case music lyrics+chords. Having these files easily accessible and if desired packaged “to go” in a widget, is a simple way to meet a specific need. This is the essence of the webapp opportunity – any specific idea you can come up with, you can probably create a webapp to do it.
The version of this webapp linked above achieves cross-browser support by mostly remaining very simple, avoiding most things that are cross-browser problems, and gracefully falling back to less functionality as needed due to browser limitations. You can try out the webapp with any major browser, and you should get mostly the same experience. Once the files are loaded (by navigating through the filelist) they will remain loaded until you either navigate away from the page (in browsers without HTML5 localStorage support) or explicitly remove them from the webapp cache (through its configuration options). In the widget case, you can use the webapp and all the data in online or offline mode, until you decide to remove the webapp. I’ve provided a zipped webapp folder, so you can download it, unpack it on your own computer or upload it to a web server to try it out, modify it, etc.
The reader webapp includes these files:
- appconfig.js: application configuration, e.g. global variables and persistent storage of them.
- common.js: utility functions, e.g. logging and XHR wrapper.
- filesystem.js: storage of the application content. In this version limited to use of HTML5 localStorage, if supported.
- ui.js: user interface handling, for both output and input. The UI controls manage the header (toolbar), main text area, text formatting options, and overall application options.
- reader.js: main application logic, controlling file retrieval, storage, and selection.
- json2.js: support scripts for JSON handling, from http://json.org.
- files folder, with
- filelist.js: the list of available files, with parameters relevant to each.
- book_list.html and playlist.html: examples of using HTML files to load some files in an iframe. The content URLs in these cases are passed as parameters to a function that uses the file URL as the iframe source.
- The content files available to the webapp user. Some of the files are plain text, and others are HTML. The webapp uses the filelist data to determine how to render the files.
- images folder, with various images used by the webapp.
- in the widget case, a config.xml file that provides the widget manifest.
An Opera widget version and BONDI widget version are also available. The only difference in these versions is the config.xml file (Opera uses a pre-standard widget manifest document schema). In another blog I will introduce the use of BONDI API’s, and how these can be added to a generic, cross-browser widget/webapp so that a single version can address both cross-browser issues and support API’s of specific platforms, e.g. BONDI, JIL, etc.