I have been developing one Windows Store app for Win 8.1. Is there a way to access the user's OneDrive which is already synced on the hard drive? I need to access it as a StorageFolder. Similarly to KnownFolders and all the libraries. The reason behind that is that I am doing something like a gallery app that displays thumbnails of videos and pictures. When the users decides the app shows the media in full size and if it is a video, it is played. The app counts on the fact that OneDrive automatically syncs all the data, so it does need to be retrieved via the Live SDK API. If I use REST, it will be just too slow. Do you know if there is a way to achieve the mentioned approach effectively or maybe some alternative?
I have been researching extensively, but with no avail.
Thank you!
All the best,
Rosko
As Nate mentioned, you gain access to the folder through the FolderPicker API. There's no direct way to obtain the StorageFolder for that location.
Once you get that StorageFolder and enumerate contents, the extra piece you want to know about is the StorageFile.isAvailable API, as well as StorageFile.getThumbnailAsync/getScaledImageAsThumbnailAsync. The isAvailable flag is what tells you whether a file has actually been downloaded/synced, because the user might have indicated "online only" for any files.
I write about this a bit in Chapter 11 of my free ebook Programming Windows Store Apps with HTML, CSS, and JavaScript, 2nd Edition (page 575, pages 593-597), including a table about how OneDrive availability works with metered networks. This includes using thumbnails.
There's also a talk from //build 2013 on this, "What New in Working with Files" by Marc Wautier, http://channel9.msdn.com/events/Build/2013/2-119. Should answer your OneDrive questions.
Related
I'm a voice-over artist. I am creating a web app in which the client can make orders & upload video/sound/image/text files, I download these files to edit them then i upload the edited files & allow the client to download them.
Which is better for this purpose?
Taking in consideration
I want to allow the client to preview the edited file (video) in the
browser
Security
File privacy [I mean no one can reach the file except the client who made the order]
Performance
Price
There is no definitive answer to your question.
It confuses many customers that two, such seemingly functionally similar services, are available.
That said -- generally -- for applications where a service (your web app) is the intermediary, Google Cloud Storage (GCS) is the more appropriate solution.
GCS is a lower-level service than Drive and so you'll have a little more work to do to integrate it but it provides richer functionality too particularly with regards authorization and being able to provide more specificity about who can do what. Lastly, GCS enables so-called "Signed URLs" that would e.g. permit you to provide your customers with a secure and time-bound URL where they may upload content.
One possibly determining feature is that a Google Drive account is oriented around an individual (generally human) user (e.g. you) and your Google Drive does not permit other users to upload files; only you can create files in your Drive account although you can then share these with others.
I hope this helps you decide which service is best-suited to your needs. GCS is a very widely used service and is well-documented. You should be able to find plenty of guidance to help you develop a solution using it.
I've been thinking about a project I'd like to start using the Google Drive API. My idea was to make a webpage (using Laravel) to let guests download files. I'd have 3 different types of users: the guests, that would be able to download files, the logged in users, that would be able to upload files, and the admins, which would be able to do all of that plus delete files (these files would be PDFs only).
Also, the server it would run on wouldn't have a lot of hard drive space for storing the files, it would just host the page and maybe keep some of the most important files. But the thing is, I have no experience whatsoever with this API. And I would hate to go through all of this trouble just to discover that it can't be done. I've tried reading the documentation but I still don't know if this is doable, and I can't find reliable tutorials (also, I don't know what is reliable, I've never worked with it).
So, for anyone who has already done something with the API, is this doable? Will the download speeds be too slow? Will users without accounts be able to download? Also, do you know any tutorials that are reliable and do it the right way? Or is the documentation the only thing I'll find/need?
Thanks in advance.
Yes,
All three cases can be handled with google drive sdk. You need to explore API in depth. Creation and downloads are easy and upload is tricky.
I recently used google drive api in a chrome extension that uploads images directly to drive here
You can ask questions regarding api usages here.
To start with, I would suggest going through one of the given Quickstarts in Google Drive REST API Overview.
Secondly, please note of the Requirements and Best Practices that a Drive API integration must adopt.
As mentioned:
Requirements
Following an "open with" action, applications must check that the user is authorized to read/write the document to which the passed document ID refers.
Best practices
In the "create new" flow, Google Drive provides your application with an authorization code. This code should be upgraded to an access token as soon as possible before applications take other actions.
Lastly, this SO post - Good tutorial on Google Drive SDK and OAuth might also help.
Is there a technical reason, why a Google Drive application must be installed through the Chrome Web Store (which severely limits the number of potential users)?
The reason that installation is required is to give users the ability to access applications from within the Google Drive user interface. Without installation, users would have no starting point for most applications, as they would not be able to start at a specific file, and then choose an application.
That said, I realize it can be difficult to work with in early development. We (the Google Drive team) are evaluating if we should remove this requirement or not. I suspect we'll have a final answer/solution in the next few weeks.
Update: We have removed the installation requirement. Chrome Web Store installation is no longer required for an app to work with a user's Drive transparently, but it is still required to take advantage of Google Drive UI integrations.
To provide the create->xxx behaviour that makes a new application document from the drive interface, and to be able to open existing documents from links, there must be some kind of manifest registered with Google's systems and some kind of agreement from the user that an application can access your documents and work with specific file types. There's little way around this when you think about the effects of not doing this.
That said, there are two high level issues that make for compatibility problems.
As the poster says, the requirement to install in the chrome store
severely limits the number of potential users.
But why? Why do the majority of Chrome Web Store applications say that they only work on Chrome? Most of these are wrappers to web applications that work on a range of browsers, yet you click through a selection and most display "works on chrome", aka only installs on chrome.
Before we launched our application on chrome we found that someone had created "xxxxxxx launcher" in the store, that simply forwards to our web app page. We're still wondering why it only "works on chrome". I suspect that some default template for the web store has:
"container" : "CHROME",
in it, which is the configuration option to say chrome only. That said, I can't find one, so I'm very confused why this is. It would be healthier if people picked Chrome because it's the better browser (which it is in a number of regards), not because their choice is limited if they don't. People can always write to the application vendor and ask if this limitation is really necessary.
The second thought is that a standardised manifest format across cloud storage providers would mean a much higher take up in web app vendors. Although, it isn't hugely complex to integrate, for example, with Google Drive, the back-end and ironing out the the details took over a week in total. Multiply that lots of storage providers and you have you lose an engineer for 2 months + the maintenance afterwards. The more than is common across vendor integration, the more likely it is to happen.
And while I'm on it, a JavaScript widget for opening and saving (I know Google have opening) by each cloud storage provider would improve integration by web app vendors. We should be using one storage providers across multiple applications, not one web application across multiple storage providers, the file UI should be common to the storage provider.
In order to sync with the local file system, one would need to install a browser plug-in in order to bridge the Web with the local computer. By default, Web applications don't have file I/O permissions on the user's hard drive for security reasons. Browser extensions, on the other hand, do not suffer from this limitation as it's assumed that when you, the user, give an application permission to be installed on your computer, you give it permissions to access more resources on the local computer.
Considering the add-on architectures for different browsers are different, Google first decided to build this application for their platform first. You can also find Google Drive in the Android/Play marketplace, one of Google's other app marketplaces.
In the future, if Google Drive is successful, there may very well be add-ons created for Firefox and Internet Explorer, but this of course has yet to be done and depends on whether or not Google either releases the API's to the public or internally makes a decision to develop add-ons for other browsers as well.
For storing data offline WebApp can use:
session storage, "advanced version of cookies"
key/value based Web Storage (AKA local/global/offline/DOM storage)
sql-based Web SQL Database (deprecated) and Indexed Database API
FileReader and FileWriter API (requires user to select files each time the application loads)
But apparently there is no File Storage. Of course, there is a manifest-based caching, but it's just a cache and is not supposed to be used as a user data storage.
Does it mean that the user of WebApp is forced to use some sort of a cloud file storage?
Is there any way to save large files on user's local machine? Or maybe some way to select a local folder web application can use to store user data?
Edit. Security. HTML5 already has the ability to write big portions of data to user's local machine. I don't see any security issues if a browser will provide another, file-based abstraction to store data. It can be some virtual machine, virtual filesystem, whatever.
Hm, I think, it is possible to write JS filesystem and store it as a blob in SQL...
Similar questions.
Update:
Hm... recently I've found this and this. Maybe it is what I'm looking for... Yes, it is! See the answer below.
At last, I've found it! Here's the answer:
I’ll have the DOMFileSystem with a side of read/write access please wrote:
Eric Uhrhane of Google has been
working on the working draft of the
File API: Directories and System specification which defines a set of
APIs to create a sandboxed filesystem
where a web app can read and write
data to.
Wow! I'm so excited!
Why not use localStorage while the user is editing a document and the FileWriter API when they want to save it to disk? Most people are used to seeing a save dialog pop up when saving a document.
The only scenario I can think of that warrants userless access to the FileWriter API is an autosave feature, but autosaving to localStorage can be just as good.
There is a way to save relatively large files to a users hard drive if you are willing to use Flash. Look into Downloadify:
http://www.bitrepository.com/downloadify-client-side-file-generation.html
Downloadify allows you to send data to a SWF and have that SWF create a file on the users machine. My recommendation would be to store the data via one of the methods you listed, Webstorage, sqlite database, etc. Put all your assets, including the SWF in the manifest file so everything is cached locally to the browser. You can then pull information from your db or webstorage and use the SWF to create the files you need.
I'm not sure if you will be able to read these files back into your web application.
Another option to save data is by using link tags with the data URI scheme. However, I'm not sure if it is supported in all the major browsers at the moment.
For security reasons you can't write files to a user's local filesystem in case it gets used for nefarious purposes by evil people.
That's not likely to change, and that's a good thing.
The HTML5 FileSystem API started landing in Chrome 8 and is fairly complete as of now (Chrome 11).
There's a nice tutorial on it here: http://www.html5rocks.com/tutorials/file/filesystem/
http://fsojs.com wraps the FileSystem API effectively, if you want an easy solution
As mentioned by others here, the FileWriter and FileSystem APIs can be used to store files on a client's machine from the context of a browser tab/window.
However, there are several things pertaining to these APIs which you should be aware of:
Implementations of the APIs currently exist only in Chromium-based browsers (Chrome & Opera)
Both of the APIs were taken off of the W3C standards track on April 24, 2014, and as of now are proprietary
Removal of the (now proprietary) APIs from implementing browsers in the future is a possibility
A sandbox (a location on disk outside of which files can produce no effect) is used to store the files created with the APIs
A virtual file system (a directory structure which does not necessarily exist on disk in the same form that it does when accessed from within the browser) is used represent the files created with the APIs
IsolatedStorage, which hasn't been mentioned as of yet, also allows for file i/o from a tab/window context, but it is made available through solely through Silverlight and requires the use of managed code to access. It, like FileSystem, also exists in a sandbox and makes use of a virtual file system.
Given the high market penetration of both Chromium-based browsers and Silverlight (support for which, interestingly enough has been dropped by such browsers), you may find a solution which uses the first of the above approaches available on a client machine satisfactory.
BakedGoods, a Javascript library that establishes a uniform interface that can be used to conduct common storage operations in all native (including FileSystem), and some non-native (including IsolatedStorage) storage facilities, is an example of such a solution:
//Write file to first of either FileSystem or IsolatedStorage
bakedGoods.set({
data: [{key: "testFile", value: "Hello world!", dataFormat: "text/plain"}],
storageTypes: ["fileSystem", "silverlight"],
options: {fileSystem:{storageType: Window.PERSISTENT}},
complete: function(byStorageTypeStoredItemRangeDataObj, byStorageTypeErrorObj){}
});
Just for the sake of complete transparency, BakedGoods is maintained by this guy right here :) .
I have what seems like a typical usage scenario for users downloading, editing and uploading a document from a web page.
User clicks a link to download a document
User edits downloaded file
User saves the file
User goes back to the web page and uploads the new file with the changes
The problem is that downloaded files are typically saved in a temporary directory, so it can be difficult to find the file after it is saved. The application is for very non-technical users, and I can already imagine the problems with saved files being lost or the wrong versions being uploaded.
Is there a better way? Things I've thought about:
Using Google Docs or something similar.
Problems: forcing users to use new
application with less features,
importing legacy content, setting up
accounts for everyone to edit a
file.
Using WebDAV to serve the files. Not sure how this would work exactly, but seems like it should be possible
Some kind of Flash or Java app that manages downloads and uploads. Not sure if these even exist.
User education :)
If it matters, the files will be mostly Word and Powerpoint documents.
Actually, despite the fact that you have more flexibility with AJAX in developing application, the problem of uploading multiple files is not solved yet.
To the thoughts you've mentioned in your question:
Google Docs:
Online apps like Google docs are certainly appealing for certain use cases. However, if you'd like to upload Word and Powerpoint slides, you don't want the content to be changed once you've uploaded the document. The problem is that Google Docs uses its own data format and therefore changes some of the formats. If you go for an online app, I'd go for a Document Management Solution. I'm sure there are plenty (even free ones) out there; however, I didn't use any on them yet.
WebDAV It is possible and seems to me like the best solution. You can embed WebDav like any directory. Documents are locked until a user releases the document. Unfortunately, you don't have a web front end to manage the files or administer access restrictions.
It
Flash or Java app They do exist, for sure. I'd prefer Flash over Java since Flash Apps still run smoother within a browser. I would definitely not use a rich application, even if it is a Java Web Start app that can be downloaded and opens in a separate window. More and more, users seem to accept browser based web applications. Which brings me to point 4:
User education You can educate them, sure. But in the end you want them to want to use the system. Most often, users get easily used to a tool. However, if they don't like the tool, they're not going to use it.
Clear instructions to save to their desktop is a start. Then clear instructions to go to the desktop to re-up it. I've not run across an online MSWord viewer/editor or whatever format the file is, but I'm sure they exist, now that Google Docs and a few other online versions of MSOffice exist.
I would make sure that there are easy to follow instructions, plus a tutorial somewhere else (perhaps with a video too) to guide users through the process.