26 November 2013
This article requires that the reader have an understanding of Web Content overlays in DPS. In addition, CSS styling and HTML coding is required to extend or customize the solution.
Required Adobe products
Additional required other products
Note: If you have questions about this article, use the comments feature at the bottom of the article. Please don’t contact technical support with questions about Adobe Developer Connection articles.
One of the many uses of DPS is as a delivery system for training material. When coupled with Direct Entitlement, DPS can be a robust platform for eLearning. In that use case, many customers require that their learners be able to take notes while reading. This article provides a flexible, easy to deploy HTML-based note taking system.
At the current time, DPS does not provide a mechanism for persistent data storage. It does permit the use of HTML5 Local Storage, however, but device manufacturers reserve the right to clear that out at any time when device resources become scarce. Nevertheless, the HTML5
localStorage array offers a convenient place to store notes. Each note is stored in a key-value pair called
localStorage[folioArticlePath()] in the
localStorage. In addition, another key-value pair called
localStorage[folio()+".noteList"] stores the list of all of the keys, so that we have an index of the notes and can keep track of them. So long as the device OS doesn’t clear out the
localStorage array, our notes will remain in memory, even if we close the folio we are reading, shut down the app or even force quit the app.
There are a number of strategies to make note-taking work with DPS, and many resort to brute-force methods that use hard-coding of every overlay to ensure that note storage does not collide with other stored data. The method presented here leverages techniques found in another article on determining Content Context in DPS to ensure conflict-free storage with no hard-coding for variables. In addition, it uses form elements and a button-based control interface to allow the user to reset the current note, reset all notes in the folio, and to email all of the notes as one email message.
So long as you do not re-use any of the HTML files in the same article, you now have an article with separate, persistent notes on each page. The beauty of this system is that you do not need to put anything into the folio or article’s HTMLResources folder in order for it to work. You can re-use the HTML files as many times as you want in as many articles in the same folio as you want, too, so long as you don’t re-use the same HTML file in any given article. Of course, if you want to have shared notes on every page in an article, then go ahead and use the same HTML file over and over in that article. I have provided the note page with a simple form field and basic buttons. In practice, you would likely re-skin the HTML to match your branding. If you do that, then edit Notes.1.html and then copy it as many times as you need it. You do not need to customize all of the note pages, unless there is a specific design requirement.
The note-taking system has four basic functions. The first is to allow the reader to type notes onto the form field. This is obvious. Under the hood, though, whenever the form field changes, the record keeping function called
addNote() does two things: it keeps an index of all of the notes in the folio, and it stores the note that has just changed. This uses an entry keyed to the folio to store a list of each note that’s in the folio. This index enables two other functions,
clearAllNotes() to work.
sendMail() will gather up all of the notes in the folio, attach them to an email message as the message body, and open up Mail on the iPad.
clearNote() resets the current note and clears its contents, and
clearAllNotes() deletes the contents of all of the notes in the folio.
As delivered, the system consists of the four functions:
addNote, sendMail, clearNote, and clearAllNotes(). Feel free to throw away the sample form and make your own. For some projects, we have used editable DIVs rather than form fields. This gives the designers access to rich CSS styling for the note field, and it gives the note taker access to some text formatting options (bold, italic and underline) and lets them paste images into the note field. The drawback is that there is no
onChange() event on the DIV to trigger the
addNote() function, so you need to use something like
onKeyUp(), which is not as responsive.
This note-taking system provides a flexible framework that can be used as is or extended to meet multiple business and design requirements. The four basic functions deliver persistence and indexing for multiple notes, insofar as the device will maintain
Comments are currently closed as we migrate to a new commenting system. In the interim, please provide any feedback using our feedback form. Thank you for your patience.