Why iOS Devs Should Consider Using Core Data iCloud sync • Hacker News Board

Re: Why iOS Devs Should Consider Using Core Data iCloud sync

#31

Post by zulfishah » Mon, Apr 01, 2013, 12:34 AM UTC

potatolicious wrote: post #30

zulfishah wrote: post #25

Earlier quoted context omitted.

> I simply have not seen this attitude at all on the internet. Everybody wants the promise of CDIS. All of the anger, frustration, and vitriol is around the broken promise of it, not the concept. - I referenced the Brent Simmons article and the Marco / Siracusa podcast early on in my post. They're all highly-visible and prominent members of the Apple dev community, and this was clearly their stance that I was challen…

> "- nuke their container from Settings" This is the part that's news to me - I've observed myself and corroborated with many other devs that nuking a container prevents the container from being recreated by that app ID ever again. This really is the one big sticking point - if nuking containers actually worked properly the scope of the problem is greatly reduced. Sure, potential data loss, but at least your devices…

Nuking a store works great; always has, even with iOS5 actually. And 'nuking' I mean specifically going into settings and doing a Delete All. If you delete the root ubiquity folder in Mobile Documents using Finder, then yes, you're never going to be able to use that ubiquity container again.

After nuking a store and waiting a few minutes (ideally restarting your device as well), the container is just as good as new. You can try it out with a basic CDIS app yourself and see.

Re: Why iOS Devs Should Consider Using Core Data iCloud sync

#32

Post by potatolicious » Mon, Apr 01, 2013, 6:30 PM UTC

zulfishah wrote: post #31

potatolicious wrote: post #30

Earlier quoted context omitted.

> "- nuke their container from Settings" This is the part that's news to me - I've observed myself and corroborated with many other devs that nuking a container prevents the container from being recreated by that app ID ever again. This really is the one big sticking point - if nuking containers actually worked properly the scope of the problem is greatly reduced. Sure, potential data loss, but at least your devices…

Nuking a store works great; always has, even with iOS5 actually. And 'nuking' I mean specifically going into settings and doing a Delete All. If you delete the root ubiquity folder in Mobile Documents using Finder, then yes, you're never going to be able to use that ubiquity container again. After nuking a store and waiting a few minutes (ideally restarting your device as well), the container is just as good as new.…

That's the news part - I'm not talking about deleting the ubiquity container. Ever since iOS5, and even in iOS6, my experience - and the experience of every developer I've ever run into using CDIS - is that deleting a container via Settings -> iCloud -> Manage -> {appname} -> Delete All results in a permanent breakage.

I'm not calling you a liar - I'm quite confident it works fine for you, but I'm wondering how our experiences can be so different. This isn't just me, this is literally confirmed by entire room fulls of people who've been wrestling CDIS for months.

I'm baffled.

Re: Why iOS Devs Should Consider Using Core Data iCloud sync

#33

Post by zulfishah » Mon, Apr 01, 2013, 7:03 PM UTC

potatolicious wrote: post #32

zulfishah wrote: post #31

Earlier quoted context omitted.

Nuking a store works great; always has, even with iOS5 actually. And 'nuking' I mean specifically going into settings and doing a Delete All. If you delete the root ubiquity folder in Mobile Documents using Finder, then yes, you're never going to be able to use that ubiquity container again. After nuking a store and waiting a few minutes (ideally restarting your device as well), the container is just as good as new.…

That's the news part - I'm not talking about deleting the ubiquity container. Ever since iOS5, and even in iOS6, my experience - and the experience of every developer I've ever run into using CDIS - is that deleting a container via Settings -> iCloud -> Manage -> {appname} -> Delete All results in a permanent breakage. I'm not calling you a liar - I'm quite confident it works fine for you, but I'm wondering how our e…

It's not just me. You can go through a lot of the threads on devforums.apple.com, in the iCloud section, and you'll hear the same thing. The solution to almost all problems is using the Delete All hammer. It's just an unpleasant solution, but definitely fixes the problem and lets you start fresh.

Re: Why iOS Devs Should Consider Using Core Data iCloud sync

#34

Post by ejdyksen » Fri, Apr 05, 2013, 7:09 PM UTC

potatolicious wrote: post #32

zulfishah wrote: post #31

Earlier quoted context omitted.

Nuking a store works great; always has, even with iOS5 actually. And 'nuking' I mean specifically going into settings and doing a Delete All. If you delete the root ubiquity folder in Mobile Documents using Finder, then yes, you're never going to be able to use that ubiquity container again. After nuking a store and waiting a few minutes (ideally restarting your device as well), the container is just as good as new.…

That's the news part - I'm not talking about deleting the ubiquity container. Ever since iOS5, and even in iOS6, my experience - and the experience of every developer I've ever run into using CDIS - is that deleting a container via Settings -> iCloud -> Manage -> {appname} -> Delete All results in a permanent breakage. I'm not calling you a liar - I'm quite confident it works fine for you, but I'm wondering how our e…

Just to chime in: I use this all the time in testing, and it's never failed on me. You have to do the right thing in your app to watch for these changes and gracefully reset and all, but I've nuked the container (from Settings->iCloud, on Mac and iOS) dozens of times now and never had permanent breakage of any kind.

Occasionally, after doing this, it'll appear to take much longer to provision a new ubiquity store (sometimes minutes, which is unacceptable), but never actually broken.