Live data from Hacker News

Frustrated with iCloud, Apple’s developer community speaks up

arstechnica.com

101–110 of 192 posts

Re: Frustrated with iCloud, Apple’s developer community speaks up

#101

Earlier quoted context omitted.

I think there's a good argument for it being broken: 1) Core Data objects are not NSObject objects. You can't treat them remotely like normal objects: https://developer.apple.com/library/mac/documentation/Cocoa/... 2) Core Data requires making your model mutable, and spreading dependencies on Core Data's abnormal objects throughout your entire code base. 3) Since the abnormal objects are spread throughout your code,…

Adding on to your #3, concurrency became MUCH, MUCH easier in iOS 5. Core Data gained the concept of a background/main thread context and the two methods -performBlock: and -performBlockAndWait:. See: https://developer.apple.com/library/mac/ipad/#documentation/... and http://www.cocoanetics.com/2012/07/multi-context-coredata/

Bingo. Core Data concurrency pretty much works these days.

Re: Frustrated with iCloud, Apple’s developer community speaks up

#102

Earlier quoted context omitted.

I think there's a good argument for it being broken: 1) Core Data objects are not NSObject objects. You can't treat them remotely like normal objects: https://developer.apple.com/library/mac/documentation/Cocoa/... 2) Core Data requires making your model mutable, and spreading dependencies on Core Data's abnormal objects throughout your entire code base. 3) Since the abnormal objects are spread throughout your code,…

Adding on to your #3, concurrency became MUCH, MUCH easier in iOS 5. Core Data gained the concept of a background/main thread context and the two methods -performBlock: and -performBlockAndWait:. See: https://developer.apple.com/library/mac/ipad/#documentation/... and http://www.cocoanetics.com/2012/07/multi-context-coredata/

This requires performing all mutation on dedicated code paths. If you require non-asynchronous completion, you have to use the 'wait' variant, but this introduces deadlock risk between threads.

This in turn litters your code with Core Data isms, and means that one can not simply make use of their model as a standard in-memory model.

Compare to SQLite, where one can simply open and commit a transaction synchronously on any thread.

Re: Frustrated with iCloud, Apple’s developer community speaks up

#103
post #36

Earlier quoted context omitted.

I just hope people can differentiate between Core Data and iCloud from both your comment and the article.Core Data isn't broken. It might be somewhat magical, but it's not broken.

I think there's a good argument for it being broken: 1) Core Data objects are not NSObject objects. You can't treat them remotely like normal objects: https://developer.apple.com/library/mac/documentation/Cocoa/... 2) Core Data requires making your model mutable, and spreading dependencies on Core Data's abnormal objects throughout your entire code base. 3) Since the abnormal objects are spread throughout your code,…

1) How is this a problem?

2) I don't get this. Your model is tied to a context manager, even if they are mutable, you don't need to merge context throughout your base unless you want to.

3) They are not thread safe, the same way UIView isn't thread safe. Why would multiple managed context become out of sync unless you allow it? It's not difficult to deal with. Create a context in the queue you are in. Merge it when you're done.

4) You can use Core Data without persistent store and make it fully in memory and everything will work fine. You can even separate your memory context with multiple context managers. Separating your creates and your deletes and etc.

5) Fud. Write a wrapper, use existing wrappers.

6) Agree.

I am actually kinda curious what problems you've gotten into recently. I've seen Core Data be improved ever since I started using it in 4. I wish it had Cocoa bindings on iOS... but ah well. I've never had any concerns here.

I don't use it for complex stuff. Ironically I didn't use it for a graph though I was told it would be a perfect fit, i wasn't really sure how to traverse without pulling everything into memory. So ended up just using NSObjects and keyedarchiver. But I would be curious to see if someone more familiar with Core Data would have solved it with CD.

Re: Frustrated with iCloud, Apple’s developer community speaks up

#104

I've worked with iCloud in conjunction with Core Data. It's as broken as the article describes, and in fact has gotten worse over time. No one really fully knows WTF is going with iCloud - documentation is basically nonexistent, support unavailable, implementation broken in trivial ways, and error messages inscrutable. I was at an Mac/iOS conference recently where the Core Data iCloud talk morphed from a standard tal…

Core Data is barely functional locally, requiring an enormous amount of invasive runtime hooks to create the appearance of a "transparent" (it's anything but) object store on top of Objective-C objects. The fact that anyone, anywhere (including Apple), actually expected Core Data to work as a distributed object store is totally beyond my comprehension.

Never had any issues. I guess what I build is not complex enough.

Re: Frustrated with iCloud, Apple’s developer community speaks up

#105

Earlier quoted context omitted.

With my much less polished Android UI, at least I can use my phone.

Someone can't use an iPhone because they're juggling Apple IDs? First, it supports multiple IDs, the limit is one ID per storefront or sync. Second, if this isn't about multiple IDs but about multiple addresses for a single ID, and if you don't like it supporting the old addresses, go to http://appleid.apple.com and manage them. You can update, edit, and remove old email addresses, decide what your primary one is, et…

She doesn't use multiple IDs. She only uses one. But in order to make things work, she has tried everything in the book, including trying to sign into her old account when this stupid bug pops up.

And no, she can't use the phone as it was advertised. She has multiple apps that use iCloud for storage, and every time this happens, she just stops using the apps, as it can literally take hours of trying before she can successfully sign into iCloud.

Re: Frustrated with iCloud, Apple’s developer community speaks up

#106
post #70

Earlier quoted context omitted.

I'm very interested in this, in fact I'm planning on rolling an iOS based couchDB solution for a company sometime this summer. Could you comment on some key differences between pouchDB and touchDB? Did you also try to simply run ARM compiled couchDB on iOS? If yes, how was the performance there? I've read that initializing takes about 10 seconds - I'd be willing to swallow that if the subsequent interactions are smoo…

The key differences between touchDB and pouchDB is that touch is written for ios and pouch is written for web browsers, if you are building for ios and not using phonegap then I suggest using touchdb. It is also the more mature of the 2 but hopefully we arent too far behind with pouch. I used to work for Couchbase on the arm compiled couchdb mobile versions, mainly android but either way I wouldnt hugely recommend us…

Thanks for the great info, very helpful!

Re: Frustrated with iCloud, Apple’s developer community speaks up

#107
I went to disabled iCloud on one of my Macs and I got this warning:

"If you turn off Documents and Data, all documents stored in iCloud will be deleted from this Mac"

Let's get past the jaw-to-the-floor, how-dare-you, !!!$$%#$## moment. They are morons and don't respect your data.

So, how do you figure out just what is in iCloud? I don't see an easy iCloud viewing option in Finder.

Doing some digging this is what I found:

  - Open Finder
  - Fire-up "Go To Tolder"
  - Enter ~/Library/
  - Go into "Mobile Documents"
That's what's on iCloud. You have to manually dig through it all and figure out what's there.

If you delete anything there it will be deleted from all of your sync'ed devices, including your local Mac. It will also end-up in the trash folder.

You could copy it all to a USB drive, memory stick, or, better yet, Dropbox. Then you can completely disable iCloud knowing your data is safe and iCloud will never cause you further grief.

Re: Frustrated with iCloud, Apple’s developer community speaks up

#108

Earlier quoted context omitted.

I don't need to qualify it at all. A wife rejecting the iPhone 5 over AppleID frustration is going to have to use something else. There are things that spec higher, are more hackable, or more "open", etc., but nothing with the iPhone's level of wholistic user experience polish. So if the corner case of swapping user IDs for purchased items is enough to dump a phone, she's going to be desperately unhappy with the othe…

You seem to have bought into the marketing, as an owner of a Nexus 4 I am unfamiliar with the "UX annoyances" that you are referring to. Could you be specific?

As an owner of a Galaxy Nexus (TMobile) running the latest Jellybean, I suspect you've forgotten what it's like to pick the device up for the first time, if you claim the user experience is as polished for "normal" (non-tech) people. You also would be alone among the crowd of Android journalists who love the OS and talk about how each release is more polished, closing the UX gap. Skim any honest pro Android site for a catalog of annoyances remaining.

Here's one for a new user: Let's say I'm looking at apps on my home screen, swipe left or right to see more apps. Great. I install something new. Not on the home screen. Swipe left or right. Not there either. This is an actual problem for normal users.

I also don't like having to pull out the battery every few weeks because the phone is frozen when I picked it up off the dock. This can happen from any background app. In the most recent case, turns out it was the foreground app, a clock called "Alarm" that I had coming up when docked in the landscape dock. Switched to Daydream, that problem went away, at least. But having to unplug the battery before I can make a call, definitely an annoyance. Glad it has a removable battery though, disassembling and reassembling the battery saves me having to press Home + Power for 10 seconds.

Ha, here's another one, as I'm writing this.

I just took a picture to talk about the UX of finding and sending that picture, but when I went into Apps and swiped left to look for Gallery (seriously, we can't just call it Photos?), the phone froze. Now I'm looking at the first page of icons half off the left of the screen, above a dimmed set of the second page icons. It's still stuck there as I type this. But the phone isn't frozen, I was able to take a screenshot of the built-in Apps browser being stuck halfway between two pages:

https://www.dropbox.com/s/z04qqbn4a93sxlb/Screenshot_2013-03...

As I'm finishing this paragraph, it's still stuck. By contrast, I haven't seen an iOS device crash swiping between the app icon pages.

While finishing describing the above, the phone dimmed, and then locked, as it should. I unlocked using face recognition, and was looking at home screen. Tapped to browse apps, and ... still frozen halfway between two apps pages.

This is native core functionality, simply not working. And like now, these things happen when trying to do something useful. That's a user experience annoyance.

Re: Frustrated with iCloud, Apple’s developer community speaks up

#109
post #36

Earlier quoted context omitted.

I just hope people can differentiate between Core Data and iCloud from both your comment and the article.Core Data isn't broken. It might be somewhat magical, but it's not broken.

I think there's a good argument for it being broken: 1) Core Data objects are not NSObject objects. You can't treat them remotely like normal objects: https://developer.apple.com/library/mac/documentation/Cocoa/... 2) Core Data requires making your model mutable, and spreading dependencies on Core Data's abnormal objects throughout your entire code base. 3) Since the abnormal objects are spread throughout your code,…

That's a pretty carefully thought out list of grievances.

What do you mean by 1), though? The link shows a list of methods you can't override on NSManagedObject, but they're things like -class and -isEqual:, which seems pretty reasonable for a system that needs to inspect and compare its objects.

Core Data does solve a few tough problems well. Faulting, uniquing, and cross-context change merging are probably the top three. Yes, it can be much simpler to just query SQLite, but I've never seen somebody do that and abstract away updating stale copies of objects.

Re: Frustrated with iCloud, Apple’s developer community speaks up

#110

Anyone care to speculate as to why apple can't seem to do web services with even a modicum of success? (Remember ping?)

My theory is that the culture of internal secrecy at Apple prevents the teams from collaborating. So you get products that work fine in isolation. Also a factor would be date-driven-development. Steve would want to demo a new offering at WWDC, so everything was driven by making that date.

My hope is that now that one person (Jonathan Ive) has been put in charge of product development, things might get better.

Post reply on HN