After implementing and deploying several offline apps, I discovered that many user were confused by the interaction design proposed in the previous lecture, Design for Offline<\/a>. User were confused by the meaning of the “save” and “upload” buttons. Users would ask, “When do I save and when do I upload the data?” Although the users were aware when they might be offline, they did\u00a0not understand that the “save” button would save the data to the device and that “upload” would submit the data to server. Users understand that a website saves data on the sever. They are not aware that HTML5 allows websites to save data on their device. Consequently, they do not understand the need two different saves.<\/p>\n Zack Duford, a former student, proposed new offline interaction. Zack’s interaction design eliminates the “save” button. Weather online or offline, the button for saving the data is “upload” (or “submit”). If the app is online then the app automatically saves the data to the server. If the app is offline the app saves the data on the device and displaces the data in a “queue”. While offline, the\u00a0user can view the “queue” which shows all the data already collected\u00a0offline. Consequently, users can view the queue receive feedback that the data “will be uploaded”. Zack proposed that user should not be permitted to edit the data in the queue.\u00a0At the time, Zack and I thought that HTML5 Service Workers<\/a>\u00a0would be able to detect online status and automatically upload the data in the queue to the server.<\/p>\n Zack made a prototype of a fishing app using Adobe XD<\/a>. Fishermen can record catches that make out on lake on offline entering the location, description and photo of the catch. You can view screen shoots of Zack’s prototype in Zack’s Offline Fishing App Views<\/a>. During the usability test, Zack tried to ascertain the participants mental model of the app by asking two questions after each test scenario:<\/p>\n Zack tested 7 participants, 3 CS majors and 4 non-CS majors. Only\u00a0one non-CS major participant show some confusion by the questions. You can read Zack’s Offline Design Usability\u00a0Report<\/a>\u00a0and Zack’s Usability Test Plan for Offline Fishing App<\/a>.<\/p>\n Later, I discovered that the Service Workers cannot automatically upload the app’s data when an internet connection is established. After an internet connection is established, the user must interact with the app and click a “submit” or “upload” button. Nevertheless this does not invalidate all of Zack’s design. The queue does give the user concrete and visual display of where the data is and that it ready for uploading.<\/p>\n In my previous lecture about Offline Implementation<\/a>, my students and I describe an architecture for the offline component of the app that mirrors the online design pattern, meaning Model-View-Controller design pattern. The offline line component of the app had separate views that mirrored the online views and JavaScript files that assumed the role of controllers of respective controller. Finally, they were JavaScript classes that assumed the role of domain objects in online component. I proposed this architectural design because I felt this would allow developers to first develop the online app using well established frameworks, e.g. Grails. But the architectural design was awkward to\u00a0maintain and inefficient. Both the offline and online views were very similar and change in one view would frequently require change the corresponding view. Also changing views would require retrieving the new view from cache.<\/p>\n Recently, industry proposes an new architectural for offline app, Single Page Application<\/a> (SPA).\u00a0 In a SPA, there is only one html or gsp file. The JavaScript code of the app control or simulate different views by hiding and showing divs. Developer has only a single code base to manage. JavaScript runs very fast and render the page quickly.<\/p>\n A new HTML5 standard, Service Worker<\/a>, will make App Cache\u00a0obsolete<\/a>. The very humorous blog, Application Cache is a Douchebag<\/a>, illustrates the many problems with app cache. Service workers are more flexible<\/a>, but they are still not implemented in the iOS and Edge<\/a>. Although the app cache is limited, for our applications it suffices, but implementing offline caching using service workers is not difficult for our applications<\/a>\u00a0once the initial configuration is set up.<\/p>\n Jake Mager, a former student, developed a tutorial demonstrating implementing an offline SPA for the fishing app. To learn from Jake’s tutorial clone the repository, fishing-tutorial<\/a>, onto your development machine. Import the source code into IntelliJ. Be sure that the SDK used by IntelliJ is Java 8. In the repository you find a Tutorial directory with tutorial.html. Right click tutorial.html and select Open in Browser. Follow along with the tutorial developing the app in another project.<\/p>\n Jake uses only JQuery show and hide functions to implement the view changes in the SPA:<\/p>\n The views are primarily generated by the index.js file.<\/p>\n Grails domain object are still used as Object Relational Model<\/a> (ORM) to interface between the business code on the server and the database. Controller methods represent endpoints for AJAX calls made by JavaScript code.<\/p>\n The tutorial also explains how to implement service workers in Grails for caching the app. In particular the grails resource pattern must be configured:<\/p>\n The service worker file in src\/main\/webapp\/sw.js is simple:<\/p>\n The service worker is registered after the document has loaded in index.js<\/p>\n There are several JavaScript framework for developing single page applications. For example:<\/p>\n React, in particular, is effective for SPA development because it is very light weight and responsive. It is also support by Facebook. Although Angular is also supported by a large company, Google, React is a simpler framework, and I think has a shorter learning curve. React is unique from the other JavaScript frameworks because it moves the HTML code into JavaScript code.\u00a0 Combining JavaScript and HTML code in the same file does invalidate “division of concerns”, specifically visual from logic. React recognizes the coupling of logic with the UI. React uses JSX to express HTML in the JavaScript code:<\/p>\n https:\/\/reactjs.org\/docs\/introducing-jsx.html<\/a><\/p>\n Instead of making the separation of concern between visual (or layout) and logic, using React with JSX separates concerns between components<\/em> of the UI so that the logic associated with the view component are together in one file.\u00a0 For software engineering developers at MTU, separation by component view is better because the developers implement both the visual presentation and the logic of the view.<\/p>\n The structure of the react components is hierarchical just like the DOM:<\/p>\n https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/API\/Document_Object_Model\/Introduction<\/a><\/p>\n Components of the app communicate by passing down properties, called props<\/em>, down the\u00a0component hierarchy. Props that are objects send messages down the\u00a0component hierachy, and properties that are functions for event listener send messages up the component hierarchy.<\/p>\n React introduces another concept, the application state<\/em>. The state of the application is expressed as as object of a property of a component class. Ideally, there is only one state object for the entire web app, or a major portion of the app. This is advantageous because there is a single place of truth. It also facilitate the responsiveness of React because if the state should change then JSX knows to propagate down the component\u00a0hierarchy to change the view. There are cases were a single state object is not appropriate. An example for a small web app is a form. Forms need there own state object so that validation can occur during user input.<\/p>\n Bryce Williams, a former student,\u00a0developed a second fishing app tutorial using the React framework. To learn React from Bryce’s tutorial, clone the repository:<\/p>\n https:\/\/github.com\/2017-SD\/fishing-tutorial-2<\/a><\/p>\n Look for the tutorial folder for the GrailsReactOfflineAppTutorial.pdf<\/p>\n\n
Single Page Application and Service Workers<\/h1>\n
$(\"#showCatchesButton\").hide()\r\n$(\"#editCatchButton\").show();\r\n<\/pre>\n
grails:\r\n resources:\r\n pattern: '\/**'\r\n<\/pre>\n
self.addEventListener('install', function (event) {\r\n self.skipWaiting();\r\n event.waitUntil(\r\n caches.open('fishingApp').then(function (cache) {\r\n return cache.addAll(\r\n [\r\n '\/',\r\n '\/assets\/jquery-3.1.1.js?compile=false',\r\n '\/assets\/index.css?compile=false',\r\n '\/assets\/main.css?compile=false',\r\n '\/assets\/bootstrap.css?compile=false',\r\n '\/assets\/bootstrap-theme.css?compile=false',\r\n '\/assets\/bootstrap.js?compile=false',\r\n '\/assets\/index.js?compile=false',\r\n '\/assets\/application.js?compile=false',\r\n '\/assets\/logo.png',\r\n '\/assets\/localforage\/localforage.js?compile=false',\r\n '\/assets\/localforage\/localforage.min.js?compile=false',\r\n '\/assets\/localforage\/localforage.nopromises.js?compile=false',\r\n '\/assets\/localforage\/localforage.nopromises.min.js?compile=false',\r\n ]\r\n );\r\n })\r\n );\r\n console.log('Install event:', event);\r\n});<\/pre>\n$(document).ready(function() {\r\n\r\n \/\/ check if user is online with navigator\r\n if (navigator.onLine) {\r\n\r\n \/\/ check if a service worker is supported then register it\r\n if ('serviceWorker' in navigator) {\r\n navigator.serviceWorker\r\n .register('\/sw.js')\r\n .then(function() { console.log(\"Service Worker Registered\"); });\r\n }\r\n...\r\n}<\/pre>\nReact JavaScript Framework<\/h1>\n
\n