I have a web app (sencha/phonegap) that includes a feature allowing users to click on buttons that link to Wikipedia articles. This obviously works fine if the device has internet access, but I get numerous requests to make the app work when the app is offline too. To accomplish this, I'd like to give the user the option to download the linked articles/webpages for offline access. When the device does not have internet access, the app would instead display the saved version (which might be stale/out-of-date, but is better than nothing). What are possible ways to accomplish this task?
My first thought was to somehow use the html manifest to cache the pages in the phone's browser, which sounds possible on the Android browser, but iOS apparently has a 5MB browser cache limit - too small.
My next thought was to save the needed html & associated files and bundle them up inside the app. But this seems a rather cumbersome approach, the app becomes much larger than it needs to be, and the webpages are stale back to the date the app was installed.
Using javascript, is it possible to download webpages, which I could then save (on the sd card, for example) for access later?
Or is there a more elegant approach?
If anyone could point me in the right direction it would be much appreciated.
In pure Javascript you can make an Ajax request to download a page. Then you can use the FileWriter to write the responseText to a file on the file system. However, that won't help you when it comes to images. You'll need to use the FileTransfer.download() command to get the binary image files.
If I were you I'd:
Use AJAX to download the html.
Parse the html looking for images.
Use FileTransfer.download to get the images.
Related
This is an odd use-case and I've tried to steer the users away from this, but I have a request to load locally stored PPT files in an HTML environment.
The idea is to view the PPT in an iframe so that I can "decorate" all around it. Users will be creating playlists, of sorts, so I need to add "next" and "previous" presnetation buttons, etc.
I have an online version of this working using the Office webapp link that many other posts have shared, but there is a concern for poor connectivity so they want it to be available offline.
My instinct was to shape this up as a PWA. I can make them use Chrome, so I have the FileSystem API "caching" the PPT files from the online source. However, I have no way to render the saved files!
Because it's offline, I can't use googledocs or continue to MS web office.
I don't know the AppCache feature well enough, but wondered if I can preload all of the docs in an iframe, will it cache those. My thought is that it won't, because the content is on microsoft (or Google's) site.
All users will have a legal copy of PPT on the computer, if that helps at all.
So far I have tried storing the files using the filesystem API in combination with the Chrome offline viewer extension and alternatively the Native Docs extension. The Chrome one will allow me to open a doc, but directly in edit mode. I need to simulate the behavior of a ppsx file, but neither extension works with ppsx files and I don't see documentation for an API that will allow me to "auto-play" the presentations.
Thanks for any ideas!
Wayne
We are currently looking at porting a enterprise silverlight application over to html5. The major roadblock that we have hit is the ability to open files from the user's local disk. Currently they have a document library which just links to files on their computer that they can open from within the app and view or print out. All that I read is that you can only access the local sandbox of the web app with the html5 file api's. We want to load these files from code.
Does anyone know of any workarounds to this?
Thanks
There is no way for html5 to access local file without user selection. But FSO: FileSystemObject works for IE and MAYBE could be regarded as a work around. But still there are some requirements to meet.
It is possible to use chrome's filesystem API to access files on a users local filesytem. So you'd have to be willing to make this a chrome only application.
Using java you can create a "Signed" applet which has access to the local filesystem. (if the applet is signed you can request filesystm permissions)
then there is a tutorial for accessing methods of your java code directly from javascript here: http://docs.oracle.com/javase/tutorial/deployment/applet/invokingAppletMethodsFromJavaScript.html
you should be able to perform something similar from silverlight.
There is no workaround in pure HTML5/Javascript. You need the use of plugins, such as Java or Silverlight (maybe you shouldn't port it after all). As for workarounds, HTML5 gives you an easy way drag and drop multiple files that you could transfer on the server and then display back to your users. Another workaround would be to install a custom agent (a software with only a tray icon) that would send the information about the current user "document library" to server and then again, you could display it back to the user.
Note: I've heard somewhere that browsers will eventually stop supporting plugins. http://www.howtogeek.com/179213/why-browser-plug-ins-are-going-away-and-whats-replacing-them/
Ya, I agree with Markain. However, if you were to limit your audience solely to chrome users, I daresay, you would most likely use some of your users. If Huazhihao is right, then your number of leaving customers should decrease but users who regularly use firefox won't be happy. Overall, I think that this will not work. Otherwise, there would be too many websites that trashed your hard driver (or at least wherever you have the rights to edit/delete files). I think it would be best if your product was setup to synchronize the file whenever an internet connection was detected and a change was made to the file. That way the user would not need to visit the website whenever the file was uploaded. If this is some kind of an error file, then it would be most beneficial if you were to make a link in the application that when clicked, would upload the file to the website and the website were to do whatever was necessary. If this is a purely online thing, then I don't see what business you would have looking through other peoples' files =-). Hope I helped!
My chrome packaged app contains a PDF, and I would like to let the user view it. If I open it in the current frame I get the error "Chrome PDF Viewer is not Allowed".
Frankly, the chrome PDF viewer is pretty awful, so I'd rather let the user view it in their PDF viewer of choice anyway. If I disable the chrome PDF plugin (just as an experiment) and I try to open the PDF using chrome.app.window.open, it "downloads" the PDF, and then the user could open it. But this has two issues:
I can't realistically make the user go to chrome://plugins and do that disable
There isn't any browser window, so the user has no idea the download happened
Any suggestions? Opening PDFs that are embedded in my app is kind of a must-have feature for this app.
I've looked at this extensively, and have come to the conclusion that there's no way to get a Chrome App to open a PDF that's local. I, too, have tried data URIs.
I don't think the issue is the PDF support in the window, as it's still Chrome, or the size of the PDFs. Rather, I think it's just an engineering problem, one that might get solved someday.
As for me, I build the PDF in my Chrome App. Since I can't display it, and there's no server to upload it to, I write it to a file of the user's choosing and let the user deal with it on his/her own.
I've got this working, but whether it is a solution for you depends a lot on your use case. The solution has three parts:
Use pdfjs to do the actual rendering.
To get this running in a packaged app, you'd need to do some violence to the internationalization support. And even after you do that, you'll find that some PDFs refuse to load for no apparent reason whatsoever. So don't bother trying to make pdfjs work in a packaged app. Just:
Put your entire app into a <webview> with a persist partition, and use a HTML5 cache manifest to get all your files available for offline viewing.
Yeah, yeah, I know that cache manifests are not cool anymore. But if you can list all your files for use in a packaged app, then you are doing the one case where cache manifests actually work great.
Then use a packaged app to distribute a tiny wrapper around your page with the webview in it.
You'll also get the benefit that you don't have to rewrite your app to live within the draconian packaged app rules (eval, sync xhr, 2GB limit, etc.).
You can see a working example at m.kaon.com/c/ka (visit with Chrome to get the desktop app; if you visit that with Firefox, you'll get access to a hosted app that is using the same tricks). PDFs are down in the bottom "Why Choose Kaon" section.
I'm developing a web app that needs some sort of filesystem access. Ideally I'd want to be able to "Open..." a file into the app and then "Save" the file back to local filesystem at the location that the user opened it from.
Currently, we use a java applet to achieve this functionality, but since java is going out of style, we're needing to do this with javascript and html5.
Obviously, this can't be done because of security reasons built into browsers, so I'm trying to somewhat emulate it.
I'm using the html5 file api to successfully import/open the files, so that's half the battle. The hard part is getting the saving feature. I'm getting close using an iframe and content-disposition, but problems arise when browsers are set to automatically download the files to a downloads folder... users may get confused and be unable to locate the file they just downloaded.
So, my question is this: is there some sort of onSave event or some kind of way for the browser's "Save As..." window to return at least the filename that the user saved the file under?
Also, I've looked into the filesystem/fileWriter html5 apis, but from my understanding they're limited to only a sandboxed area of the local filesystem and only available in chrome dev releases.
Any help would be appreciated!
No, there is no way to do that with pure JavaScript. You can manage to trigger a download with data URIs or an iframe with some headers but you can't circumvent the browsers' download managers.
You can either use a Flash or Java applet to handle the saving for you, or ask the user to right click on the link and do save as, then he might be able to choose the destination.
One popular option using Flash is Downloadify.
I have a couple of solutions, but none of them work perfectly.
Platform
ASP.NET / VB.NET / .NET 2.0
IIS 6
IE6 (primarily), with some IE7; Firefox not necessary, but useful
Allowed 3rd Party Options
Flash
ActiveX (would like to avoid)
Java (would like to avoid)
Current Attempts
Gmail Style: You can use javascript to add new Upload elements (input type='file'), then upload them all at once with the click of a button. This works, but still requires a lot of clicks. (I was able to use an invisible ActiveX control to detect things like File Size, which would be useful.)
Flash Uploader: I discovered a couple of Flash Upload controls that use a 1x1 flash file to act as the uploader, callable by javascript. (One such control is FancyUpload, another is Dojo's Multiple File Uploader, yet another is one by darick_c at CodeProject.) These excited me, but I quickly ran into two issues:
Flash 10 will break the functionality that is used to call the multiple file upload dialogue box. The workaround is to use a transparent flash frame, or just use a flash button to call the dialogue box. That's not a huge deal.
The integrated windows authentication used on our intranet is not used when the Flash file attempts to upload the files, prompting the user for credentials. The workaround for this is to use cookieless sessions, which would be a nightmare for our project due to several other reasons.
Java Uploader: I noticed several Java-based multiple-file uploaders, but most of the appear to cost money. If I found one that worked really well, I could arrange to purchase it. I'd just rather not. I also don't like the look of most of them. I liked FancyUpload because it interacted with html/javascript so that I could easily style and manage it any way I want.
ActiveX Uploader: I found an ActiveX solution as well. It appears that ActiveX will work. I would just write my own instead of buying that one. This will be my last resort, I think.
Resolution
I would love to be able to use something like FancyUpload. If I can just get by the credentials prompt some way, it would be perfect. But, from my research, it appears that the only real workaround is cookieless sessions, which I just can't do.
So, the question is: Is there a way to resolve the issues presented above OR is there a different solution that I have not listed which accomplishes the same goal?
I don't think there is any work around for the integrated windows authentication. What you could possibly do is save the files to a generic unprotected folder and, in the case of swfupload, use a handler to move the file when its fully uploaded
You could try SWFUpload as well - it would fit in your Flash Uploader "category".
Our company uses https://ajaxuploader.com which supports this feature.
In Internet Explorer, FileReference.upload (flash upload) will send cookies along as well.
This behavior breaks only when running in other browsers.
#davidinbcn.myopenid.co: That's basically how I solved this issue. But, in an effort to provide a more detailed answer, I'm posting my solution here.
The Solution!
Create two web applications, or websites, or whatever.
Application A is a simple web application. The purpose of this application is to receive file uploads and save them to the proper place. Set this up as an anonymous access allowed. Then make a single ASPX page that accepts posted files and saves them to a given location. (I'm doing this on an intranet. Internet sites may be exposing themselves to security issues by doing this. Take extra precautions if that is the case.) The code behind for this page would look something like this:
Dim uploads As HttpFileCollection = HttpContext.Current.Request.Files
If uploads.Count > 0 Then
UploadFiles(uploads)
Else
result = "error"
err = "File Not Uploaded"
End If
Application B is your primary site that will allow file uploads. Set this up as an authenticated web application that does not allow anonymous access. Then, place the FancyUpload (or similar solution) on a page on this site. Configure it to post its files to Application A's upload ASPX page.