I am working on In-App-Purchase and downloading data after payment in users /Documents folder. Apple has rejected my application it's says you are not following iOS Data Storage guideline.
Can any one help me how to implement iCloud functionality in my application?
Thank you
According to the iOS Data Storage Guidelines you should probably be storing your purchased data inside the Application_Home/Library/Caches directory. The downloaded data does not belong in the Documents folder.
Apple provides a list of the various directories and what you should put in those in the File System Programming Guide.
The most important includes:
Application_Home/Documents/ Use this directory to store user documents and application data files.
Application_Home/Library/ This directory is the top-level directory for files that are not user data files.
Application_Home/tmp/ Use this directory to write temporary files that do not need to persist between launches of your application.
Generally this means that anything that is not intended to be seen by the user should go into a directory inside the Library directory. Typically you would use one of these, but there is a larger list with more specialized uses in the File System Programming Guide:
Application Support: Use this directory to store all application data files except those associated with the user’s documents.
Caches: Use this directory to write any application-specific support files that your application can recreate easily
The Application Support folder is backed up but the Caches is not.
The answer is spelled out in the iOS Data Storage Guidelines, but it has downsides. It says clearly that the Documents directory is reserved for user-created content, and that the Caches directory is for content that can be downloaded again or regenerated. It's possible also that the size of the data factors into their approval. That answers your question, but it ignores the fact that it can be a burden for the user to re-download your data; argue your case and submit your feedback, but be prepared to change your download destination directory to the Caches directory.
iOS Data Storage Guidelines:
http://developer.apple.com/icloud/documentation/data-storage/
You also asked for info on iCloud functionality... data storage and iCloud APIs are two different things. Read here:
http://developer.apple.com/library/ios/#documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/iCloud/iCloud.html#//apple_ref/doc/uid/TP40007072-CH5-SW1
Related
This question already has an answer here:
Sharing data in between apps in IOS
(1 answer)
Closed 7 years ago.
I've been doing research on how to share data between applications securely. I'd like to get some info on the correct way to handle this before I do a deep dive on implementation using the wrong method. Just cause you can do something does not necessarily mean you should.
User Case: I am working on a suite of language learning apps that have a shared audio file base of several hundred audio files and json files containing important data corresponding to a language. I'd prefer to allow the user to not have to re-download the language bundle when they use another app in our suite.
1. App Extensions - Document Provider Non-UI Variant
According to the documentation:
The File Provider extension grants access to files outside the host app’s sandbox with the open and move actions. This extension (sometimes shortened here to file provider) also allows the host app to download files without presenting a document picker view controller. This feature lets the host app access previously opened documents using secure URL bookmarks, even if those files are no longer stored on the device.
On the surface this seems like a really solid solution. My main concern stems from the last couple lines where it state that the application can download the files no longer stored on the device. I want the files to be stored locally on the device to prevent constant downloading. If the Document Provider does store the files locally and allow the various applications in the group to access the files, then I think this could work.
2. Shared Keychain Access
Allows you to securely store data to a shared keychain that other applications that are part of a suite of applications can access. All applications that share keychain access must use the same app ID prefix. For an example of shared keychain access in action.
I've looked a little into the documentation of this one, and I think this might be the best fit. My major concern with this solution is whether or not there is a size limit to the data uploaded and if mp3/ogg/json file types are allowed. Most the examples/uses I have found with this solution point to sharing strings and small data, I am not sure if it will handle large data like json or audio files.
I also found this repo that apparently makes dealing with Keychain easier:
3. Custom Pasteboards
The custom pasteboard is best for the purpose of semi-privately sharing custom data between two applications. Custom pasteboards are identified using unique names. They can persist data beyond the application that creates them, allowing a pasteboard to hold onto data after the application is terminated or even after rebooting the device.
When writing or reading data to and from a pasteboard, you must specify a pasteboard type. Pasteboard types typically use a uniform type identifier (UTI) to identify the type of data going into and being retrieved from the pasteboard. See Apple’s UIPasteboard Class Reference documentation for additional information.
Above documentation pulled from this post
My main concern with this solution is that perhaps it is a bit of a hack. Logically a pasteboard seems like something that temporarily holds data and allows sharing between apps, whereas the solution I am looking for needs to be more of a permanent solution.
I'd appreciate any info on best practices towards sharing these types of files between apps. I assume there are plenty of other solutions I've omitted here, so if there is a better alternative I'd love some info on it. If it happens one of the listed solutions I have placed here is a good way to solve this problem I'd love to have some more info on your experience with working with them and if my concerns with them are valid, or nothing to worry about.
Thx in advance. As always, well written answers get up-votes ;)
I believe the best approach would be to enable data sharing by setting up an app group. This is Apple's recommended solution for sharing data between applications and extensions, and I believe for sharing data between apps in general.
See the section "Sharing Data with Your Containing App"
Also see "Adding an App to an App Group":
I have an application which is already on app store and it use Sqlite Database. Now i want to make another version, which include iCloud sync, now ,the question is ,IS there any tutorial or third party code of syncing sqlite database with iCloud ,as i searched a lot but didn't get any useable answer??
Thanks in advance.
SQLite and iCloud do not mix well. Although it's possible to use the iCloud file APIs to put a SQLite file in iCloud, doing so is almost guaranteed to corrupt the file. SQLite wasn't designed with this kind of use in mind, and between external journal files, uncommitted transactions, etc, it's not even a question of whether the file gets corrupted, only of when (and the answer is "very soon").
Although Core Data can use both SQLite files and iCloud, it doesn't sync the SQLite file. Instead it has a scheme that uses transaction logs to send changes back and forth.
If you want to use your existing data with iCloud, you'll probably have to do something similar. I don't know of any good reference implementations. Basically, you'll need to export your data to some other format, and detect and import changes from other devices.
I am looking to develop a Chrome Packaged App that will (at a very simple level) provide a dynamic form filling UI - but allow users to attach large attachments to the forms (could be upwards of 10 files of 10MB each). I would like to have the ability to save and share the form data and the attachment via Google Drive. The forms will be completed collaboratively by multiple team members who also need to all see the attachments. Imagine a form front-end/metadata that sits on top of a shared Google Drive folder...
I have read the documentation, and learnt that the syncFileSystem API is not intended for use for general and/or large files to be stored in Google Drive, but rather for small configuration data.
I then looked at the fileSytem API - hoping that I could include the Sandboxed folder for the app in the folders that the Google Drive Client App (so that the files get synced automatically) - but it doesn't look like the sandbox is meant to be accessed externally.
My current thinking is to recreate a windows explorer type UI in the packaged app (can use drag and drop) - then store the files in the sandbox using the fileSystem API. I can reuse the code from the Google Drive sample packaged app to implement cloud syncing. Good idea?
Two questions stem from this:
How persistent is the fileSystem API. The documentation mentions that the user can purge all stored files - is this done through 'clearing all browser history' ? In which case they could very easily accidentally wipe many hundreds of MB of useful information that I am storing in the packaged app.
I have read that you can use a 3rd party authentication services (which I want to do). If I use a non-Google account to authenticate my users, how would the Google Drive authentication work ? Would I be able to use a different Google account to perform the cloud storage (i.e. unrelated to the actual end user, who may or may not have a Google account already - which may already be signed in)
It seems like waiting for this https://code.google.com/p/chromium/issues/detail?id=148486 (getting read access to non-sandbox directories) would be the easiest way forward.
I don't think clearing browser history deletes temporary sandbox filesystem files, they're supposed to be sort of automatically garbage collected when space is required. It would make sense if that were another checkbox in the "Clear browsing data" section of chrome's options. Perhaps that would make the answer to your first question more clear :-)
The second point, I am not sure how to do this, but it looks like you have already figured out something? At least that's what this page https://groups.google.com/a/chromium.org/forum/#!topic/chromium-apps/hOYu75Cv0AE seems to indicate
Basically I want to know if apps work and store data independent of one another or if there is a possibility for one app to modify another. Also...
In what folder are apps and their data saved on a phone?
If I modify data locally in an app, will the data be saved in a public place where other apps have access or is it saved to a folder specific to that app?
iOS is kinda not that mature in inter-app communication.
Data can be shared between apps using the system clipboard and transmitted over the network through mediums such as email and webservices.
iOS devices also provide a straightforward and well defined method for apps to send messages and data via URLs and filetype handlers. These techniques diverge into two categories:
Custom URL prefixes, e.g. someapp://something/somethingelse?somestuff=whatever
Custom file type handlers by file extension (e.g. *.txt) or by MIME type (e.g. text/plain).
Custom URL prefixes are useful for when two apps have established a specific protocol, while custom file type handlers are much more general, and are designed in a way that allows any app to register itself and participate. This article describes the latter: custom file type handlers for chemical data. If you register your app for a certain filetype it will look like so -
Reg. your second part of question - If I modify data locally in an app, will the data be saved in a public place where other apps have access or is it saved to a folder specific to that app?
As such, each application is restricted in terms of where it can store data on the file system of the device. iOS achieves this by allowing applications to read and write only to their own Documents and tmp directories. Within these two directories the corresponding application can create files and also sub-directories to any required level of depth. This area constitutes the application’s sandbox and the application cannot create or modify files or directories outside of these directories. Check this
The general answer to the first part of this question is: "No". Apps are inherently sandboxed and thus can not communicate between each other. There are a number of exceptions to this:
If you have access to a custom URL scheme for the particular app (Facebook Single Sign On makes use of this).
Opening a document type that is handled by multiple apps on the system (like when opening an attachment in Mail)
If both apps are developed by the same publisher, there are options to use UIPasteboard, iCloud shared Key/Value Dictionaries (only small datasets though), or accessing a shared Keychain Store.
UIPasteboard has some odd behavior as you can have system-wide pasteboards or application specific pasteboards, and there's no guarantee when its going to be cleared or not.
The second question - folder structure - is variable dependent on OS version but generally all applications are stored under the /var directory, followed by a subdirectory structure that utilizes UUIDs to denote the application and then the main app bundle, with the standard app bundle structure (including the Documents directory).
As for modifying data and storage, once again, generally "No". Some apps will utilize UIPasteboard for temporary data storage, but generally you won't know about that inside another application unless you've written the original app.
Generally speaking every app has only access to its own working directory and saves all it's data there. So no app does have access to the data of another.
Except a few of Apple's apps like Photos, Address Book, Calendar and so on. App's can use a well defined API to get access to them and do some (controlled) changes. In future iOS versions (beginning with iOS 6) the user will then be asked if a third party application should have access to the data of these few Apple apps.
There's no file-based solution from Apple directly to share data between apps yet (except the clipboard, which is a one-file exception).
I'm developing a reference iPhone app that will contain many photos (ball park estimate of 75-100 photos). All of the photos will be stored locally along with at least one or two other versions of these photos in different image sizes representing the same image.
As a newbie to iPhone (and C) development, I'm unsure as to the best way to store these images for reference in the application. Is it possible to create folders/packages/bundles for them to live in?
FWIW, the app is run from an XML file, although I am considering a SQLite database as it is becoming harder to maintain with XML.
The most obvious solution is to write the image files to your applications' documents folder. You come up with a name for each file (or obtain it from XML), and then you use methods for dealing with image classes to obtain jpgs/pngs and save the files. You maintain references to the filenames strings elsewhere, persisting those in a .plist or archiving them in a dictionary (again, storing that archive in your documents folder).
CoreData now allows you to store files externally (which is better than storing larger images directly in SQLite) but it will manage and track them for you. That'slightly more sophisticated, but since XCode bundles CoreData templates, you can put those together very quickly and easily.
Use The concept of Lazy Loading to download all images and save them in to root directory...All The best!!!