Upload local database to SkyDrive as a textfile - database

I havent looked at the samples yet for the SkyDrive.
I have done a application that saves some data in a local database on the phone.
What i want to do is to upload all these to a SkyDrive account as a textfile.
Is this possible?

Might want to start with a blog post I wrote - Adding SkyDrive support to your Windows Phone application. You will need to download the Live SDK (unless you want to use the REST API manually, which I can see no reason for at this point).
Uploading is fairly simple after that, given that you obtained the proper session init:
client = new LiveConnectClient(App.MicrosoftAccountSession);
client.UploadCompleted += MicrosoftAccountClient_UploadCompleted;
client.UploadProgressChanged += MicrosoftAccountClient_UploadProgressChanged;
client.UploadAsync("me/skydrive", Binder.Instance.CurrentlyUploading,
stream, OverwriteOption.Overwrite);
Where stream is a MemoryStream instance.

Related

The name of a created PDF is not transferred from the server to the client (GWT - GAE)

I develope a GWT-application which creates a PDF-file at the server, and then transferres it to the client.
At the client-side, a window appears which allows the user either to
open it with a program assigned to the file name ending, or
save it to disc.
I have read several threads to this topic, such as
How can a user download a file in client side (Google Web Toolkit)
GWT: Showing PDF created as POST response
How can a user download a file in client side (Google Web Toolkit)
and that helped me coding the doGet()-methode in my print-servlet like this:
resp.setContentType("application/octet-stream");
resp.setHeader("Content-Disposition:", "attachment; filename=\"" + fileName + "\"");
This works fine when testing and debugging using the local GWT-developement server.
But my big problem is:
After deploying to GAE and running the code on GAE, the created pdf-name is not transferred to the client...!
Instead of e.g. TestPdf-25072016.pdf, the name only consists of the word print.
This leads to the fact that the standard-program for a PDF is not invoked automatically when I want to open it. And, of course, print is not the name of the PDF I want to have...
Where is my failure? Especially I am confused that everything works fine when using the local developement server?
Thanks a lot for your support!
You could use a tool like Wireshark or Fiddler to capture the actual HTTP header sent to you when you call printing in GAE.
Maybe GAE is adjusting the header or just blocking it.

Browser based file upload to AWS S3 and encode server-client workflow

Im writing a single-page-web-app (angularJs) and a server back-end (node.js). The communication between them is done via REST.
Currently im trying to implement the following scenario:
Upload big files from browser to S3 public bucket.
Copy uploaded file to private bucket on S3
Transcode uploaded file to HTML 5 compatible format (AWS Elastic Transcoder)
Store Meta-Object about the file in DB to access later
I'm racking my brains to get a well working design of the communication/ data-workflow between server and client, but always got stuck at the following questions?
Store file meta-object at the end or at the beginning of the process. If it is at the beginning, i have to store and handle some state information?
Who should start copying uploaded files to private bucket. Server or client? If it is the server, how can the client get informed about the job succeeded?
Who starts the transcoding process? If it is the server, how can the client get informed about the job succeeded?
How would you do this?
there is a pretty good tutorial which describes the use case you are planning to implement: http://www.bitcodin.com/blog/2015/02/create-mpeg-dash-hls-content-for-amazon-s3-and-cloudfront/
If your transcoding system has a RESTfull API (like bitcodin which is used in this tutorial, or any other service) you can do your application also client-side and use the API calls to get the state of your transcodings, etc. However, using the API you can do the same also server-side, whatever fits better for you.
I personally would store the metadata infos at the beginning of the process, as this is the point of time where you generate the "asset" in your database/CMS/etc.

From Drive to Blobstore using Picker

I have the Google picker set up, as well as Blobstore. I'm able to upload files from my local machine to the Blobstore, but now I have the Picker set up, it works, but I don't know know how to use the info (url? fileid?) to then load that selected file into the Blobstore? Any tips on how to do this? I haven't been able to find much of anything on it on Googles resources
There isn't a direct link between the Google Picker and the App Engine Blobstore. They are kind of different tools for different jobs. The Google Picker is designed as an end user tool, to select data from a users Google account. It just so happens that the Picker also provides an upload interface (to Google Drive) as well. The Blobstore on the other hand, is designed as a blob storage mechanism for your App Engine application.
In theory, you could write a script to connect the two, but there are a few considerations:
Your app would need access to the users Google Drive account using OAuth2. This is necessary, as the Picker API is a client side API, whereas the Blobstore API is a server side API. You would need to send the selected document URL to the server, then download the document and finally save it to Blobstore.
Unless you then deleted the data from Drive (very risky due to point 3), your data would be persisted in 2 places
You cannot know for sure if the user selected an existing file, or uploaded a new one
Not a great user experience - the user things they are uploading to Drive
In essence, this sounds like a bad idea! What is your use case?
#Gwyn - I don't have enough reputation to add a comment to your solution, but I had an idea about problem #3: You cannot know for sure if the user selected an existing file, or uploaded a new one
Would it be possible to use Response.VIEW to see what view they were using when the file was selected? If you have one view constructor for Drive files and one for Upload files, something like
var driveView = new google.picker.View(google.picker.ViewId.DOCS);
var uploadView = new google.picker.DocsUploadView();
would that allow you to know whether the file was a new upload (safe to delete) or an existing file (leave it alone)?
Assuming that you want to pick a file from your own Google Drive and move it to the Blobstore.
1)First you have to perform Oauth for Google Drive API
2)Using the picker when you select a file from drive, you need to get it's id
3)Using the id obtained in step 2 you can programmatically download it using Drive API
4)After downloading the file you can use FileService(deprecated though) to upload the file to the
Blobstore.

Open and Save Word files through internet

I have a situation that override my knowledge. Here is situation:
A simple web based system store a Word files. Users create them locally, then upload them to server. After that, another user can download, edit and upload again. All that is okay, but that steps of repeating Download/Upload cause troubles - in case when user forgot to upload after he make changes. The prerequisites is that they want to use only Word, so i can't use any web editors like CKEditor or Google Documents.
So - a question - is there a way to let users open/save that DOC files with Word without setting a VPN?
Server is a Windows 2008, and language is ASP.NET / classicASP. User access system via browsers.
I think you can embed a plugin called aceoffix in your web system, if the customers do not have to download, upload and save back to server. With aceoffix they can edit online and save back to the server directly. It is exactly the same interface as MS Office. Hope this will be helpful.
How about a tiny app (on clients) to act as a syncronizer (using FTP) ?
I think an embedded Word viewer would be something quite complex to pull off - especially if they require the native, proper and exact Word look/menus.
One alternative is to provide a plugin to your users, where they can access/sync documents directly from/to the server. But then you aren't using the a web site but a local plugin, which comes with its own headaches of course.
Creating a Word plugin is a nice way to make it seem like something "in the Office program" when you have actually created it yourself, so that your user don't have to feel like they are using another program. My idea is that you could create a way for users to load a Word file from the server, do changes to it and then upload them back to the server automatically.

Changing permissions on a File from applicationDataDirectory in Titanium Mobile

I'm trying to send a file, as an attachment, via the phone's e-mail client using Titanium Mobile. I've run into a snag where the attachment is sent, but is received as a 0-byte file.
The problem is that the file created in data/data/package/app_appdata is -rw------
From glancing at the Android SDK, this is by design. The app's "private storage" is readable only by the owner of that folder, the running application.
I presume that the Android e-mail client can see that file, but cannot read it.
The full Android SDK mentions a MODE_WORLD_WRITABLE that allows you to keep using the applicationDataDirectory and give all apps permission to read/write that file. Does an equivalent exist in Titanium Mobile?
The other solution is to create a temp file, which unfortunately uses Titanium's own naming scheme (tiXXXXX.txt), or I could write to the "external storage" since it is public (which may not always be available, however.)
This is the call I'm using to get the current file, it can be read within my app just fine, but when I use the addAttachment call of an emailDialog it simply sends a 0 byte file to me.
var f = Ti.Filesystem.getFile(Ti.Filesystem.applicationDataDirectory, "generated_filename.txt")
Have you tried using tempDirectory instead. I'm of course assuming once the file is emailed you don't need to keep it as the applicationDataDirectory is fully backed up and usually used to store data the app retains.
http://developer.appcelerator.com/apidoc/mobile/latest/Titanium.Filesystem.tempDirectory-property.html

Resources