I want to send info between a desktop/laptop/tablet app and Windows Phone. One possibility is to send data to the SkyDrive account and have the other end pick it up from there. Is this feasible? What I have in mind is the "Windows 8" app running on the desktop, laptop, or tablet allowing the Windows Phone app[s] to send data to its account. Is this possible, such as by providing the Windows Phone app with the Skydrive login info, or...???
From all the other questions you've posted around this query, it sounds like you want to put a mechanism in place to communicate between a Windows 8 app and a windows phone app. I would recommend you look at building a service to handle the communication instead of trying to leverage mechanisms that weren't designed for what you want to achieve.
In direct answer to the this question, though, you can probably achieve it in this manner, but what happens if the user deletes the file you create?
So, SkyDrive is unique to a user, not a device. This means if your application is running on more than one device you can use SkyDrive as a shared, unified storage option. Not just for files but also for application settings. There's an SDK for every platform, not just MS.
Here's what you need to consider.
The roaming API in Windows 8 puts information in a protected area of SkyDrive. As a result, the user cannot delete or screw up the files stored there. To that end, using SkyDrive as a shared location (like you are asking) doesn't have this benefit. The user can screw with your files or delete them - and wreck your app. There is no such thing as protecting your app files in SkyDrive (at this time).
Specifically, to your question:
The authorization model for SkyDrive requires a token that cannot be practically cached for any app. Also, you cannot cache credentials because you never get the credentials in the first place - you only get the resulting token. Listen, you would violate every possible best practice if you //asked// the user for their username and password and stored them. Please do not do this.
The final answer is this: an app on multiple devices can use SkyDrive as a shared storage solution for files and settings (like XML files) - but the developer needs to understand the risk and mitigate that (mitigation might be easy for your app). The user, on every device, would need to sign in and grant each application access to it folders. And, that's it.
Related
I developed a desktop application that saves projects locally to disk. Each project is a directory that consists out of many files. If certain files are missing the project is corrupt.
I want to add Google Drive support to my desktop application, so the user can load and save projects directly to the cloud. For clarification, the desktop application talks directly to the users Google Drive. There is no 3rd-party webservice involved.
I want to make the installation process as easy as possible for the user. I know the user can generate an API key for his account, but this is to technical for my target audience.
My question is, can I create a Google Drive App that shows up in the market place, that my desktop application can use to access the files on the users drive? Or is the market place meant to be only for 3rd party web-services that can access someones account?
TLDR; I want my desktop application being able to access Google Drive files. Is it possible to create a 1-2 click installation process that my app can access these files? Setting up an API key is too complicated for my users.
I want to make the installation process as easy as possible for the user. I know the user can generate an API key for his account, but this is to technical for my target audience.
First off an API key is only used to access public data. You will need to have your user authorize your application access their google drive account using Oauth2.
You will need to create a project on google cloud console and create Oauth2 credentials which will allow your application to request access of the user.
I want my desktop application being able to access Google Drive files. Is it possible to create a 1-2 click installation process that my app can access these files? Setting up an API key is too complicated for my users.
Its not exactly one click but a user will have to be signed in to their google account and then click the authorize button.
I am working on a product for Windows 8 that needs to perform some low-level tasks, display some UI, and communicate with an external server. I definitely need a Windows service to accomplish the low-level tasks. At the same time, I would like to use the cool features of Windows App Store apps, like push notifications, live tiles etc... for the UI. In this design, both my service and my app would communicate with my external server.
The flow would be something like: my Windows service sends some information to my server, which then sends a push notification to my App Store app.
I understand that deployment is not pretty in this scenario, but let's put that aside for now. My problem: How does the server know that the service and the app are on the same machine, and consequently linked together? i.e. When my Windows service sends information to the server, how does the server know where to send the push notification? I need is some sort of shared, unique, identifying information.
I have seen lots of discussion (usually frustrated in nature) about the lack of inter-process communication between App Store apps and desktop apps. In my case, I have two options:
Generate the exact same unique identifier in the service and in the app. This seems unlikely because apps don't seem to be able to access very much system-specific information. I'd love to be shown that I am wrong about this.
Generate a unique identifier in the server OR in the app and communicate it to the other component. Potential ways to do this:
Create the identifier in the app, save it to a file, and then access the file from the service.
Some sort of local socket solution (I've read this doesn't work, but have not tried)
Of course, option 2 seems likely to violate the Windows 8 app Certification Requirements, notably:
Windows Store apps must not communicate with local desktop
applications or services via local mechanisms, including via files and
registry keys.
Any advice would be most appreciated.
I'm not a lawyer, but if it says "via local mechanisms" then you could still possibly communicate via a cloud service as long as having both apps installed isn't necessary to have some features in the app or if you don't mean to publish the app in the store.
You could save some sort of a token in the documents folder or if your desktop app can run with appropriate permissions - it could access the local data folder of the Windows Store app to synchronize the token for use in communication with the web service.
Perhaps the user could just be asked to copy and paste a token between the two apps?
I searched everywhere and wondering whether any posible way available for share data among applications within the mobile phone itself. What I basically meant by that is, if there any way that can create a file from one application and allow other applications to access that file.
The problem is, If we save the file in application's isolated storage, then any other application won't be able to access it.
For example a scenario like this. One application produce a file and store it in a public location within the phone and later using the email client application need that file to be sent as an attachment.
Really appreciate any guidance/ help over this task. Thanks in Advance...!!!
Unfortunately, there's currently no way to share data between applications on Windows Phone. For this, you'll have to rely on an external server. Depending on what your apps are doing, you may want to consider using skydrive or dropbox integration to share the files.
I have a desktop application which uses flat files (some xml and small pictures) as data. I want this data to be available on other PCs which have the desktop application installed and usable by a smartphone client (WP7 at the moment) as well.
The user should have it very easy to synchronize this data. He should be able to use accounts he already possesses (Live-Login, Googlemail, Facebook,...).
I thought about using Azure Blob Storage to save the data in Azure, the Sync Framework to perform the actual synchronization and the Access Control Service to handle authentication.
I have not used any of this technologies before so any advice would be great but I'm searching foremost for errors or shortcomings in this strategy I don't see yet. Is this approach viable at all?
Windows Azure is basically a virtualized datacentre. It is elaborate and complicated and is pitched at corporations who don't want to own their server infrastructure or hardware.
If I understand correctly, what you want is a cloud fileserver, not a whole LAN. Windows SkyDrive fulfils this requirement nicely and offers 25GB of storage per member with no charge for membership.
About Hotmail and Windows Live People often confuse Hotmail and
Windows Live, because when you set up a Hotmail account it uses
Windows Live for authentication and therefore you end up with a
Windows Live account and all the associated facilities, including
SkyDrive. However, it is entirely possible to set up a Windows Live
account using any email address as the username.
If you do this, it is important to be aware that the Windows Live
password associated with a given email address is completely
independent of the password required by the mail server that hosts
mail for the account. This can cause a great deal of user confusion.
For Hotmail (or any other mail server that uses Windows Live for
authentication) they are guaranteed to be the same password.
There is no official Microsoft framework support for SkyDrive. There is an open source project called SkyDriveApiClient, but it only works with the full .NET framework. I tried porting it but the author was a bit of an architecture astronaut, and it is absolutely riddled with [Serializable] which is not available on WP7x.
The WP7 guys have said that the WP7 framework will probably include support for SkyDrive but not in Mango (WP7.1) and given that Microsoft's typical release cycle is 18 months and Mango has yet to hit the streets, I'd say it will be two years before you can count on intrinsic cloud file services for WP7.
Roll-your-own wouldn't be hard, WCF services are dead easy to use from WP7. But that's not really cloud since you have to provide and maintain the server infrastructure yourself. For this reason and given the MS timetable, I have put a great deal of effort into producing my own SkyDrive client for WP7. Core functionality is complete and I am now refactoring, improving robustness and adding performance enhancements like local cacheing of tokens (cookies, essentially). I don't intend to release it; I have a number of apps planned that depend on this functionality and it suits me fine that there is a substantial barrier to competition.
I didn't tell you that to tease you. My point is that I'm so sure SkyDrive is the right answer that I put a lot of work into making it happen.
Cloud file storage is a perfect fit for mobile devices.
Azure is not a good answer for the sort of phone apps individuals want because the data store isn't shared in a way that required indexing or supports high levels of concurrency
I can certainly think of corporate phone apps that would benefit from using SQL Server as storage
Azure can do file services but it represents an ongoing expense. Nobody's going to put up with that when Google and Microsoft both give away web based cloud storage.
I can personally attest that if you're determined, it is possible to use SkyDrive from WP7.
Cloud storage is the only way you're going to get programmatically accessible storage that's shared by your user's mobile device and his computer. One of the things I intend to do that depends on shared storage is write a Silverlight app that lets you prepare map routes with multiple waypoints on a desktop computer and a companion app that uses them on WP7.
The Windows Live team has released what they call support for WP7. They supply a sample project showing you how to instantiate a browser object and load their login pages and manipulate them to log in and use their javascript API to manipulate SkyDrive.
This has one big advantage: browser cookies and cached credentials. The disadvantages are obvious; technical shortcomings notwithstanding the Windows Live team seems to think the only thing people want to do with a phone is tag their photos and fiddle with social media.
I have finished my own libraries. They do not support most of the social media twaddle. I have treated SkyDrive as no more or less than a cloud file system, providing
Authenticate(username, password)
CreateFolder(folderpath[, blocking=false])
Delete(fileOrFolderPath[, blocking=false])
SaveString(filepath, value[, blocking=false])
LoadString(filepath)
I could handle binaries but Convert.ToBase64 makes this unnecessary and strings are convenient for XML. CreateFolder, Delete and SaveString are optionally blocking. LoadString is always blocking because it's a function that returns the loaded string. CreateFolder is recursive so you can create an entire path in one call (eg /folder1/folder2/folder3). Calling CreateFolder on a pre-existing path has no effect, and SaveString uses CreateFolder to ensure the path is valid, making it unnecessary to create a filepath in advance. Authenticate loads the file system (except file content) into memory eliminating server chatter. This is asynchronous and a FileSystemReady event announces when the file system is completely loaded. The model is maintained as you add and remove files and folders.
This was a lot of work and no one reponded to my attempt to make it an open source project so I'm not inclined to give the fruits of my labour away, but provided your plans don't compete with mine I could be persuaded to come to an arrangement.
My app is required to upload a csv and convert to Google Sheets. So we are asking this permission "https://www.googleapis.com/auth/drive" from our user. But some of our users complain we are asking too many permissions. Is there any other settings that we can use to avoid asking too much?
Here are the permission list when user authorizes:
Upload, download, update, and delete files in your Google Drive
Create, access, update, and delete native Google documents in your Google Drive
Manage files and documents in your Google Drive (e.g., search, organize, and modify permissions and other metadata, such as title)
What scope or scopes does my app need?
As a general rule, choose the most restrictive scope possible, and avoid requesting scopes that your app does not actually need. Users more readily grant access to limited, clearly described scopes. Conversely, users may hesitate to grant broad access to their files unless they truly trust your app and understand why it needs the information.
The scope https://www.googleapis.com/auth/drive.file strikes this balance in a practical way. Presumably, users only open or create a file with an app that they trust, for reasons they understand.
https://www.googleapis.com/auth/drive.file Per-file access to files created or opened by the app
Requesting full drive scope for an app
Full access to all files in the user's Drive (https://www.googleapis.com/auth/drive) may be necessary for some apps. An app designed to sync files, for instance, needs this level of access to Drive. Apps with special needs related to listing or reorganizing files might need full scope.
Requesting drive-wide read-only scope for an app
Read-only access to all of a user's Drive files (https://www.googleapis.com/auth/drive.readonly) may be useful for certain apps. For instance, a photo browser might need to reorganize image files in a unique presentation order for a slideshow, or a mobile app might have to work around unique display constraints without needing to write anything. For apps that only need to read file metadata for all files in Drive, there's https://www.googleapis.com/auth/drive.metadata.readonly.
Requesting full drive scope during app development
One common and completely valid case for using full scope is iterative development. It may just be easier to avoid authorization-related constraints and use the full scope while testing your app during development. Then before you actually publish your app, you can back off to the file-level scope or whatever scope you really need for production operation.
Conculsion
That text was ripped directly from Google Drive Scopes page which I use as a rule of thumb when developing drive applications. In your case because you need to be able to upload files I would say you should consider testing a little with the https://www.googleapis.com/auth/drive.file scope, I haven't tried this one before but it sounds like it may work in your instance. Unfortunately I think that is your only other option besides full drive access.