Is it possible to recreate a scenario like itunes match with iCloud APIs available to-date (i am writing/editing this in april 2012) .. specifically..I mean something like this>
A user creates a media document (audio or video) in my app...and it is automatically uploaded to (his) iCloud space. Then user decides to delete his local copy. But the app still shows the document in let say a table view...and if the user presses play..it begins to stream from iCloud..The user also is able to recreate (download) a local copy of the document. (Just to be sure, I understand the difference between the document I describe here and the concept of UIDocument).
If yes..how would I implement the transfer of the file ..let say a recording of 1 minute video..to the cloud? What folder would it be?
Apple docs state that there shouldnt be a distinction between where the data is stored. No sense of local copy of cloud copy. I think it is possible to do what you ask, but you're likely to get rejected. Use something like amazon AWS for hosting instead. You'd have more control over the files and unless you're going to have tons of users, you'll also qualify for the free tier.
Related
Is there a way to do this easily? Keep version history of the document on the document? As a .gdoc or .whatever-format or am I resigned in having to download, separately, all the revisions made in the past on said document?
For context: I have a document I've been editing and revising over the years for my own medical history and list of meds, history, etc. etc. and have been using Google Docs to do this, because it was convenient and I didn't have to pay for Microsoft Office and additionally install a good word processor on my PC. Now recently I've purchased Dropbox Personal for cloud storage needs.
I want to do the following: Take the Google Doc and save it as a .gdoc (which isn't an option in the File menu??) and take it over to Dropbox's Vault as an editable hardcopy with its revisions history in tact.
Otherwise, what I have done (before I even comprehended revision history was a thing) is just copy pasted its current version, onto a new .gdoc in Dropbox Vault.
So, is that possible? And if so, how and as easily (lazily) as I possibly can? Also, is this even the right place to ask for this? Apologies if it isn't. I didn't see much else about this specific issue anywhere... (also lazy)
Thanks!
EDIT:
I am by no means a coder in any sense. I'm a full time elderly caretaker and I'm just a guy with a specific, niche?, technical, problem and thought this was the first place to ask without having to go through tech support w/ Google chat etc. And it might also help some other people that like seeing how their documents have changed over the years, history fans etc. At the end of the day it's a programming/coding issue, that could be resolved someway some how... Right?
If I can add pictures here for context, LMK.
Thanks :)
The .gdoc file format is only accessible via Google Docs which is on web. Downloading the file to your local storage means you would have to access it on your device using your local apps (word editor) such as Microsoft Office,Libre Office, etc.(other word editor apps on desktop application level) which is why the .gdoc format is not available when you download. This is also why you won't be able to have it openable from your dropbox.
The version/revision history on Google Docs is intact only to that specific file with that unique ID. So when you download the file, the version history won't be available to the physically downloaded file which is stored on web or even when you make a copy of it, the version history does not get copied, therefore that won't be an option too.
It looks like you'll have to stick to manually copying or making a backup of the current version of the file before editing, since the version history is only kept for a period of 30 days or the last 100 versions, unless manually set to "Keep forever" to keep a version forever.
Google drive version history: https://googledrivepro.com/google-drive-version-history/
I have an iOS 7 app, that is using Core Data. Some of the Core Data objects has a related (one to one relationship) images that are > 1MB & < 4MB and are stored in the app’s Document folder. Core Data objects only stores image names as string.
I want to integrate iCloud support for the app so I can sync data between devices. I am planning to use iCloud Core Data storage to sync Core Data objects. But what to do with the images?! After reading different posts, I found a couple of options that are highlighted underneath. I am struggling to pick one, that would suit me best. It would be nice to know someones experience/recommendations. What I should be careful with, or what didn't I think of? I also need to consider migration of the existing data to the option I will pick.
OPTION 1. Store UIImage in the Core Data as Binary Data with External Binary Data option (read here). At this moment is seems to be the easiest solution, but I guess not the best. From Documentation:
It is better, however, if you are able to store BLOBs as resources on
the filesystem, and to maintain links (such as URLs or paths) to those
resources.
Also will the external files be synced? If so, how reliable the sync would be if the user quits on minimises the app, will the sync process resume? From objc.io about External File References:
In our testing, when this occurs, iCloud does not always know how to
resolve the relationship and can throw exceptions. If you plan to use
iCloud syncing, consider unchecking this box in your iCloud entities
OPTION 2. Store images using UIDocument (good tutorial here) and somehow track relation between Core Data entry and UIDocument. From what I understand whatever I put in this directory will be automatically synchronised to the iCloud by a system daemon. So if the user quits the app, the images will still be synced to the iCloud, right?
OPTION 3. Using FileManager(more info here). I haven’t read a lot about this approach, but I think it can also work.
OPTION 4. Any other?
There are similar posts (e.g. Core Data with iCloud design), but unfortunately they don't fully answer my question.
Seems Apple will reject application because of large database iCloud synchronization.
I think the best solution is to store images on a remote host, and keep Image URL in CoreData.
And also Local path of image should be resolvable from remote URL.
So the algorithm will look like this ->
1) Getting Remote URL from CoreData.
2) Resolve local path of image.
3) If local image exists retrieve it, otherwise read it from remote and save it to local storage.
You can have a look to Amazon S3 server here.
I'm a little bit confused over the various types of storage that is available to Windows Store Apps.
Let's say I had a notepad app, where users can view, create, and edit notes. What storage type would I use for storing the notes? Local storage? Write the notes out to files in the user's Documents folder? Also, what if I wanted to sync a user's notes via the cloud? I understand that Roaming Data has a rather low size limit.
Almost all the options you mention are possible for a notepad application. Except the roaming data option, that only allows you to store 100KB of data.
I will try to sum up the options that you have and add a few more:
Localstorage
You can easily add these files to localstorage, you can store it in file format or serialize your object and store that one. Very easy to implement. Con is that only your app can access these files.
Documents folder
Also an option. Made easy by use of different filepickers. For example the FileOpenPicker or the FileSavePicker. Files can be stored in the format you like and can be accessed by other apps or through the file explorer.
Roaming data
No option for files due too the limited space
Skydrive API
If you want to store files in the Cloud and access them anywhere you could consider the skydrive api. Also note that if you use the filepickers you also have the option to save/load these files to skydrive. (Although in that case the user chooses where to store the file.)
Windows Azure Mobile Services
Another option if you want to store data in the cloud. Gives you the ability to store your data in a table/tables. Very easy to implement. More info about mobile services can be found here
SQL Lite
If you need a local database to store your data than SQLLite can be an option. Tim Heuer has wrote a nice blogpost about how to use SQLLite in your windows 8 app. You can find it here
Hopefully this clears up things a bit and gives you some ideas about what to choose for your app?
In an app like this (a notepad style app), the logical place to store you files in in the user's documents folder. That way they are accessible to the user from other apps as well as the current one. There is, of course, the option to roll your own methods to upload the data to SkyDrive as well, but you really shouldn't rely on this as being your only data source - what if the user is offline?
I was wanting to use a file sharing server to keep certain files up-to-date and constant across multiple instances of my application across multiple computers - like (for example) writing a multiplayer game, which stores all the player's positions in a text file, and uses something like Dropbox to keep the text file constant across all the applications, and each application instance can change the file with that application's player's position, and then the rest of the applications can update accordingly. This is only an example, and is not what I intend to do using this technology. What I want to do does not rely on fast sharing of data very quickly - but only periodically downloading and updating the text file.
I was wondering how I might be able to do this using the Dropbox API for Objective-C without prompting the user for any Dropbox username/password - just store a single Dropbox account's login information, log into it automatically and update/download the file stored on it?
From what I have found out from experimenting, Dropbox prompts users for their passwords via a web-broswer, and is designed to accommodate multiple accounts, whereas I only need to accommodate the 'Server' account.
So, is there anyway to do this sort of thing using the Dropbox API, or should I use something else. Or do I need to find out how to write my own server. Using some sort of file sharing API seems a lot easier to me than writing an actual server.
Thanks for any help,
Ben
You might think about using Google App Engine (GAE). I had a similar requirement recently and I'm thinking this is a good option when you want centralized data. Plus you can do the no-browser account login by using your own custom authentication, or I think it's even possible via OAuth? Depends on how sensitive the data is I guess. I just rolled my own.
From my research I found that using Dropbox as a server has some issues with scalability, since you'll be limited to maybe 5,000 calls per day. source It's built on Amazon S3, so you could also look at using that directly.
GAE lifts that limit up to 675,000, but can be increased up to 91 million for free.
https://developers.google.com/appengine/docs/quotas
I did find an open-source project for doing this with Java, alternative you could look at Python example
I've written a daemon that continuously checks for updated files and syncs them. I wrote it for my own file manager iOS app. You can find the implementation here:
https://github.com/H2CO3/MyFile/tree/master/DropboxDaemon
I'm personally not an iOS developer but I came across this question while looking for something else and thought I would offer up another potential solution to the OP's question.
Microsoft just released something called Azure Mobile Services which supports iOS development (among other platforms). It's basically a convenient way to set up a back end system complete with push notifications, authentication, etc. without rolling your own. You don't need to know anything about Azure or servers as the setup process walks you through most of it. It is new so keep that in mind, but it looks promising for situations like this.
Here's a 10 minute video explaining how to use it with an iOS developed app along with links to more documentation:
http://channel9.msdn.com/posts/iOS-Support-in-Windows-Azure-Mobile-Services/
Hope this helps.
Dropbox claims that during syncing only the portion of files that changes are transmitted back to main server, which is obviously a great functionality, but how do they perform changes to files stored in Amazon S3 cloud? So for example, lets say a 30 page document on user's desktop contains changes to only page 4. Dropbox now syncs the blocks representing the changes and what happens on the backend if they files that they store are in the cloud? Does that mean they have to download the 30 page document stored in S3 to their server, then perform replacement of blocks representing page 4, and then uploading back to the cloud? I doubt this would be the case because that would be somewhat inefficient. The other option I could think of is if Amazon S3 provides update of file stored in the cloud based on byte ranges, so for example, make a PUT request to file X from bytes 100-200 which will replace all the bytes from 100 to 200 with value of PUT request. So I was curious how companies that use other cloud services such as Amazon, implement this type of syncing.
Thanks
As S3 and similar storages don't offer filesystem capabilities, anything that pretends to store files and directories needs to emulate a file system. And when doing this files are often split to pages of certain size, where each page is stored in a separate file in the storage. This way the changed block requires uploading only one page (for example) and not the whole file. I should note, that with files like office documents this approach can be faulty if file size is changed - for example, if you insert a page at the beginning or delete a page, then the whole file will be changed and the complete file would need to be re-uploaded. We didn't analyze how Dropbox in particular does his job, and I just described the common scenario. There exist also different "patch algorithms", where a patch can be created locally (if Dropbox has an older local copy in the cache) and then applied to one or more blocks on the server.
There are several synchronizing tools which transfer deltas over the wire like rsync, rdiff, rdiff-backup, etc. For bi-directional synchronising with S3 there are paid services like s3rsync for example. For pure client-side synchronising, tools like zsync can be considered (which is what many people employ to roll-out app updates).
An alternative approach would be to tar-ball a directory, generate a delta file (using rdiff or xdelta3), and upload the delta file by using a timestamp as part of the key. In order to sync, all you need to do is to perform these 2 checks client-side:
You have all the delta files from S3. If not pull them and apply them to generate the latest backup state.
Your last backup state corresponds to your current directory. If not generate a new delta file and push to S3.
The concerning factor here would be the at least 100% additional space utilization, client-side. But this approach will help you revert changes if needed.