question

Hi Robin, I would like to clarify whether I have understood your query correctly! According to below url the File System Api is going to be discontinued http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0010.html Now, you want to know whether we would continue to support it in our WebApp or AWV hybrid app environment or not? Am I correct? Have you already built up an web or hybrid app and distributed through Amazon App Store? If yes, can you give us the name of it? It would help me to clarify the query from internal appropriate team. Thanks.

Sujoy, Thank you for the prompt response. Yes you understood correctly, both environments. Was in the process of pre-submittal to the app store and going over the testing requirments. [1] Without the FileSystem API, any Html5 app will not run in airplane mode, as resources would have to remain web on demand available, confusing users not immediately understanding, blaming the app instead of the lack of a WiFi connection. The manifest file then is also not needed. Re-fetching the same images is resource intense and wasteful when local storage is (should always) be available. The File API allows for a snappy immediate rendering with no time delay as if the images are hard wired. Have spent several months development time modifying an existing app to allow saving image files to the local file system specifically for Kindle devices. Think 100 image flip carousel. Had two other apps started for simialar funtionality now that I had conquered the FileSystem API. This appears to be the only way to save large blobs of data via Html5 as localStorage is too limited. Limit 5Meg The FileSystem API as is, is snappy and I have been successful up to 1.2Gig of local file storage with no concern. Wasn't going to invest more time in a losing deployment challenge if Amazon was dropping support for this much needed interface option. Would hate to see this feature dropped, if, only as the spec is no longer supported. I'm sure others have this same design requirment also. If not, would deter and possibly negate any further development for Html5 apps. This would give Amazon a black eye after all the hoopla over the formal announcement back in Sept-Oct 2013 for Html5 app store submissions. Robin [1] https://developer.amazon.com/sdk/fire/fire-testing.html

Thanks Robin. I have understood your concern. Is your app running on top of Amazon Web View? Or it stock Android web View? Or it's a pure Amazon Web app? I can not see any live app associated with your account.

At this time, I have plans to launch several ideas as Html5 only apps running inside the Amazon web view to create optimized for Kindle Fire HD/HDX devices only, competing with the iOS educational market. This would benefit us both in this special niche. I could possibly revert back to the Android web view if integration of the Amazon flavor was the concern to make the above inquiry. With the need to incorporate upgrade purchases, one childrens educational app using Amazon coins for micro-payments for instance, it makes more sense to use the I.A.P. developed for native apps, as I've found it easier to integrate with less testing headaches. I'm currently toying with a hybrid design that would meet the above two requirements, but, . . . without the ability to save many web retrieved images to the file system from a web view, it appears I may have to scrap all (jQuery plugins required and Html5 canvas with touch-drag requirement) this effort. It would be nice if the above discovery would apply only to the spec not going to be maintained and continue with the existing File API and FileSystem API as is, with the understanding there wont be any future revision upgrades. As it is not clear how many apps at AWS currently use the FileSystem API for Silk browser web service integration, it is not clear what impact the spec decisions will have on those existing efforts. See link [2] "File API: Directories and System" section in the initial post.

Hi Robin, AWV is built on top of Chromium open source project. FileSystem API is working with latest version of Fire OS. We don't see any documents from chromium open source to obsolete these APIs. As long as Chromium supports it, we also would support this API in AWV. Thanks for your patience.

Correction of last post. File System API does not work Amazon Web View and it would be discontinued in future since From Kitkat webview documentation we can see that 'FileSystem' APIs is no longer supported. https://developer.chrome.com/multidevice/webview/overview In AWV v25 (the one currently released), the requestFileSystem object is there, but it won't full functional, it will crash if you request quota with window.PERSISTENT. It works fine if you request with window.TEMPRARY. This API will not be supported in coming release of AWV since it's discontinued in Chromium. Thanks.