question

What is the intended paradigm that will allow the end user to backup their Html5 app data? Are the following limitations specific to Kindle devices or all Android devices in general? Using the PC based Amazon Cloud Drive app, one may transfer back-n-forth between those devices. http://www.amazon.com/CloudDrive/ If for example, an end user archives a .pdf file or photo on their device, it is saved in: /mnt/sdcard/Documents /mnt/sdcard/Pictures Using ES3 this is easily verified. When taking a picture with the built in Camera app, images are saved in: /mnt/sdcard/DCIM/Kindle/ drw 10/28/2013 /mnt/sdcard/DCIM/Kindle/KINDLE_CAMERA_138065014000.jpg 90.09KB -rw 10/28/2013 But, . . . this does not hold true for Html5 apps purchased from the Amazon app store. That sandboxed area is not accessible to developer use. Knowing the following: Html5 apps are bundled inside a native .apk wrapper [1][2] Each native .apk app executes in its own sandboxed process Using the Silk browser, Html5 web page requests are sandboxed The Silk browser has as it's maximum, the minimum 5Meg limit on localStorage as the W3 spec indicates. [3] Simple testing shows access is also slower than snot, taking ten seconds to retrieve a 2Meg blob. By design, Html5 apps are blocked from archiving to the sdcard [4] Using the FileSystem API, which appears to still (Nov 2013) be in it's infancy, only temporary storage is available and this is also non-accessible by Amazon Cloud Storage, other .apk native apps and neither to the developer other than building a Javascript DOM node viewer using the API itself. [5][6] It appears that one may develop an Html5 app using the web-app tester, but I have uncovered an anomaly that wont allow the same app to run inside the Silk browser. [7] There also doesn't appear to be a way to programmatically access user data via an Amazon Cloud API either. [8] The crux of it all. The end user purchases resources and other downloads, images for instance, over the web. This data is then saved in the only app writable sandboxed sections of the Kindle. This sandboxed area is not accessible by external means, e.g. utility or other native app. It might be that some data may even be saved (unknown - LogCat ref amazon9) on the Amazon servers based on the split architecture design of the Silk browser itself. [9] Something goes awry with the device, necessitating a contact call to Amazon for just a re-register. "Everything should get restored as purchases are saved in the cloud" I was informed. But, when this happened to me . . . already, six weeks into owning the device, and yes data gets whacked, what I wasn't informed of, including original out-of-box device docs, along with Silk browser favorites, history, trending-now, most-visited and bookmarks. I can't confirm that File API saves would remain in tact as I hadn't started that attempt at development yet. But, localStorage did, . . . and that means development of Html5 apps for browsing use in the Silk browser is limited. My assumption that each wrapped Html5 .apk would have to be re-installed as they would need be fetched from (a restore) the accessible cloud server, which would then create a unique new area within the device itself. This implies the old data will be lost. Building a web service solution could be accomplished, but with a high development cost-time overhead, including the dual round-trip required as the Html5 app requires same domain access when using localStorage. The same would hold true should one be able to access using the File API when that becomes available. ex: Preserve:: Kindle -> domain -> PC future reset Restore:: PC -> domain -> Kindle I can't imagine an end user going through the machinations required to archive their data when inside a wrapped Html5 app. Presumably it also alleviates the $0.99 app option as the costs for AWS services for just the spin-up instance would limit the profitability to only a handful of users. For me Html5 app solutions for the Kindle product line has been over-hyped. Simple animation game within a WebKit hybrid, . . . perhaps. Anyone able to shed some light on their solutions to this apparent device limitation? Robin [1] https://developer.amazon.com/sdk/webapps/submitting.html [2] https://forums.developer.amazon.com/forums/thread.jspa?threadID=1566&tstart=0 [3] http://www.w3.org/TR/webstorage/ [4] https://forums.developer.amazon.com/forums/thread.jspa?threadID=1557&tstart=0 [5] http://docs.aws.amazon.com/silk/latest/developerguide/html5-apis.html#file-system-api [6] https://forums.developer.amazon.com/forums/thread.jspa?threadID=1599&tstart=0 [7] https://forums.developer.amazon.com/forums/thread.jspa?threadID=1846&tstart=0 [8] https://forums.developer.amazon.com/forums/thread.jspa?threadID=1866 [9] http://en.wikipedia.org/wiki/Amazon_Silk