The Apple documentations says:
When a user launches your iCloud-enabled app for the first time,
invite them to use iCloud.
Never prompt the user again about
whether they want to use iCloud vs. local storage.
What if the user does not pick iCloud the first time, but decides to use it later?
What if after using iCloud for a few days, the user decides to switch back to local storage?
What if a user runs out of iCloud storage space, but does not want to pay for additional space?
Should an app be designed to allow users to toggle between local and iCloud storage? If yes, what's the best way to deal with this?
Thanks.
Yes, you definitely need to be able to migrate a user between the two storage methods, for the reasons you include above plus more - what if the user signs out of iCloud? And what if that is followed by another iCloud user signing in? You need to handle this stuff and be able to move things when you can and even when you can't do that, save stuff in the right place and where the user expects.
How you handle it will depend on what types of iCloud storage you are using. For the key value store, you should also be caching that stuff locally (it's not an NSUserDefaults substitute).
For document and Core Data, you can sometimes migrate persistent stores back into local stores, and you can sometimes move documents out of iCloud to local storage. I'd recommend reading both the Document Programming on iOS guide and the iCloud guide to get at least a base idea of how to handle this.
One thing that can be tough is detecting some of these changes - the APIs are a bit underbaked in this regard. One technique that is used by some are 'sentinel files' that you place in ubiquity - if they're missing, you know that the iCloud universe as you knew it has changed.
Take a look at how Apple's apps handle this, like iWork. There's an iCloud switch in their settings bundle.
Related
I'm building a website www.example.com. I want to implement an affiliate program: when a non-signed-in user enters https://www.example.com/?af-code=affiliateA in his browser (e.g., Chrome), we plan to write affiliateA in e.g., localStorage of the browser, such that we always know this user comes from affiliateA, no matter which url of our website he visits later.
But it seems that localStorage of Chrome is not accessible to IE on the same machine, and vice versa.
My question is whether there is a mechanism (e.g., localStorage, sessionStorage, cookie) to permit of sharing among all the browsers of a user.
It's quite difficult to proove that something doesn't exist. But if we'll take this for a complete list of Web APIs (which I hope it is), then you'll see there different APIs for dealing with data storage 1, 2, ..., even a File and Directory Entries API, but all of them are local for a browser.
But your task is actually not in sharing data between browsers, but to identify a user. And that can be done. But only with some probability and a lot of effort.
For that you can gather different peaces of information about user's device (like screen size, dpi, network condition, etc.), and they will be more or less the same on the same device in a different browser. Also you can use other peaces of information on the server (client IP, simultaneous sessions, when both browsers are open, action patterns, etc.). But it's not an easy task.
And to add to the complexity of it:
One device can be used by many users.
One user usually has many devices.
And in no way you can identify a user on different devices without resorting to full-blown spying techniques.
But, there are trackers out there, like Google Analytics and you can even fin open-source projects. So setting it up on your site can be (still probabilistic) answer to you question.
Can't recommend any - never used them.
Is this the same as php $_sessions?
Does it use php $_sessions? (edited)
When should I use it?
What are some down sides of using it?
Can or should I use it to store user input and results of forms for later operations?
And is it secure? (edited)
The private temporary storage differs from session storage in very significant ways and it is not intended as a replacement of it.
For logged in users, sessions are completely irrelevant, the data stored in the temporary storage is shared among all sessions of a given user, current and future.
Only for an anonymous user are sessions relevant: should their sessions expire, the contents is not retrievable any more because it is tied to the session ID. But the data is not stored in the session storage for anonymous users either, only the session ID is relevant.
The data expires after a time set on the container parameter called tempstore.expire which has nothing to do with the session cookie lifetime (nor is the latter relevant for logged in users).
There is metadata associated with each piece of data: the owner (either the logged in user id or a session id) and the updated time.
The durability expectations completely differ. Sessions are fundamentally ephemeral. Many places will tie sessions to IP addresses. It is certainly tied to a browser and as such, to a device. As a corollary, if clients can't expect sesssions to last, there's no reason for the server to cling to them heavily: putting the session storage on fast but less durable storage (say, memcached etc) is a completely valid speedup strategy. However, the private temporary storage is durable -- within expire, of course. A typical thing to store in a session is a "flash" message -- the one you set with drupal_set_message. If you set one such and then the session gets lost, oh well. Yeah, informing the user would've been nice but oh well. I certainly wouldn't expect to see a flash message follow me across browsers and devices.
In theory, a typical thing to store in the private temp storage would be a shopping cart. In practice, this is not done because a) carts, if not for the end user but for the back office are valuable, not temporary data b) when a user logs in, their session data is migrated but their private temp storage is not. WHether this is a bug is debateable, at the time of this writeup I can't find a core issue about this. This is a possible downside. So a Views UI like complex edit is one possible use case but note the Views UI itself uses the shared temporary storage facility, not the private one. In fact, the only usage I can find are node previews.
Here a very good articles about Storing Session Data with Drupal 8.
It cover exactly all your questions & more !
Take a look at it, the author give you also a lot of other links to help you.
Here a short summary:
1. Is this the same as php $_sessions?
Roughly equivalent. But (and it's an important but) using Drupal 8 services provides needed abstraction and structure for interacting with a global construct. It's part of an overall architecture that allows developers to build and extend complex applications sustainably.
2. When should I use it?
In past versions of Drupal, I might have just thrown the data in $_SESSION. In Drupal 8 there's a service for that; actually, two services: use user.private_tempstore and user.shared_tempstore for temporarily storing user-specific and non-user-specific data, respectively.
3. What are some down sides of using it?
Knowing POO.
4. Can or should I use it to store user input in forms for later operations?
Should.
If the ubiquity container (iCloud folder) is not available for whatever reason, I add any new documents to the users 'Documents' directory, however, should it become available again I add the documents to the ubiquity container.
My question is, what is the best method to saving documents seen as a ubiquity container is so unreliable?
For example, if a user switches off documents in the cloud, those documents are deleted. Is there a notification to listen out for when this happens so I can transfer them to the local directory?
And vice versa, if a user switches the documents in the cloud on, is there a notification to move documents from local to ubiquitous store?
Thanks
No automatic notification, the files in the ubiquity container either disappear or reappear. Your app logic has to take account of what files need moved into and out of iCloud when they're visible to you, but once they're gone, they're gone!
IMHO, having data disappear is one of the most user-confusing things about iCloud. The user expects it to sync stuff, but it's an all or nothing game at the moment. The only way around this if you really want more 'sync like' behaviour is to have both a local non-ubiquity copy, AND a copy in the local ubiquity container so it gets uploaded to the iCloud servers. That then means you've effectively got two copies of everything on every device. Messy.
Much easier to stick to the Apple mandated method, and assume the user knows what they're doing if they log out of iCloud, or delete your data from iCloud.
I have no other choice but to adopt iCloud right now. In the near future i would like to build my own cloud service. Is there any problem if the app transfers all the data from iCloud to my own cloud?
Only the data related to my app of course.
After user's permission.
Is Apple positive about this?
If you mean, would Apple approve an app for the store that was going to transfer the user's iCloud data to some other online service, as usual all we can do is try and gauge the odds.
None of Apple's guidelines even hint that apps may not use non-iCloud services.
Neither do they hint that there's any issue with moving data from one service to another, even if one of them is iCloud.
Apple does not look kindly on apps that transfer user data to online storage without the user's knowledge. Assuming you make it clear to users what you're doing, this is probably not an issue, but users should have the chance to opt out of your service.
Based on information available right now, what you suggest is probably OK so long as your app makes clear what's happening. It's unwise to try and predict Apple's app-approval actions too closely. They might change their policies tomorrow, or they might decide to reject your app for reasons that had not previously been stated. At the moment though, switching services like that seems likely to be accepted.
I need a way to stash some data that is global to the browser. If I open a new window with a URL from my app, e.g. via a bookmark, I need to access some data that was created in another window and never sent to the server.
As far as I can tell the only thing that is global to the browser and not just a window, (like window.name), is a cookie. The problem I'm running into is if I set a cookie the cookie is then sent with every request to the server, but I don't ever want this data on the wire. Is there any way to set a cookie and just use it purely as a bucket for storing some data and never send that data to the server?
The HTML 5 storage API looks like exactly what you want here, but unfortunately it's only supported by a handful of browsers right now.
Is there any way to set a cookie and just use it purely as a bucket for storing some data and never send that data to the server?
No.
You'll need to look into a plugin that provides dedicated offline storage facility, or use the HTML5 storage API and tell everyone to upgrade their browsers
If you decide to go the plugin route, as far as I am aware you have 3 options:
Google Gears
Flash - it has an offline storage facility - you could write a small flash app to store things using this facility, then interop with it from javascript.
Silverlight also has offline storage - as with flash you could write a small app to do the storage, then interop with it from javascript.
I'd probably look into using flash first, as everyone already has it.
Development would likely be a lot easier if you were to use silverlight. It's not as widely installed, but it is spreading pretty rapidly. Last I heard* something like 30% of browsers had it installed which is pretty impressive.
Google gears would unfortunately be a distant third. People are going to be installing flash and silverlight for other reasons, but nobody has gears.
*This is an entirely unsubstantiated quote, but does seem to fit with what I've seen on various people's computers, etc.
Can you mandate that your users install Google Gears? It's a javascript API that lets you store local info- also lets you persist between sessions, which may be useful for your app.
Why not just read a field in the parent window using window.opener ? Or if you've three windows running - parent and two children which I think you might be implying then read/write to a hidden field in the parent from the children.
Sounds like your app is running 100% local, if that is the case the browser isn't the way to go anyway. Cookies can be easily deleted. If your app isn't local the webserver should be the one supplying information. Cookies are never the correct way to store sensitive information or information that should persist over longer amounts of time.