Someone else already pointed this out but it bears repeating.
There is a really dumb fight going on in this thread. It is dumber than the typical ones in other threads because the participants are calling out each other for not providing facts or misunderstanding the issue. The fact is the participants are all off the mark. You are looking foolish. Really foolish. There have been some funny, silly fights on this site, but this one takes the cake. Please stop. You know who you are.
So asking for people to provide facts to back up their claims is foolish? Maybe you should read a book about debate.
The fact is that data has been lost and devs do have problems using core data sync via iCloud and it doesn't work as well as advertised to the dev community.
This is well documented and unless you think these devs quoted by Ars and others are incompetent or anti-Apple then you have to accept that the problem is significant for them in the same way you accept the devs reports that say that Android fragmentation is a significant issue for them.
Both can be worked around but both require a lot more developer effort than it should to the point that many devs simply don't use core data sync or simply punt and target the Android 2.x API and forego the 4.x ones.
Core data sync is a technically hard challenge. More timely Android updates is a politically and economically hard challenge.
Both impact uses and developers in the same way: less able apps.
The fact is that data has been lost and devs do have problems using core data sync via iCloud and it doesn't work as well as advertised to the dev community.
This is well documented and unless you think these devs quoted by Ars and others are incompetent or anti-Apple then you have to accept that the problem is significant for them in the same way you accept the devs reports that say that Android fragmentation is a significant issue for them.
Both can be worked around but both require a lot more developer effort than it should to the point that many devs simply don't use core data sync or simply punt and target the Android 2.x API and forego the 4.x ones.
Core data sync is a technically hard challenge. More timely Android updates is a politically and economically hard challenge.
Both impact uses and developers in the same way: less able apps.
Well put, more or less. But there's no workaround. Anyhow, you're wasting your time. Some people's mission is to drown out ant anti-Apple noise because they believe themselves credible enough to protect the stock. On the other hand, those who jump on this as evidence that iCloud doesn't work are equally off base.
The fact is that data has been lost and devs do have problems using core data sync via iCloud and it doesn't work as well as advertised to the dev community.
.
Where's the evidence that data was lost due to CoreData?
You seem to think that simply repeating the same made up statement over and over again will make it true.
More importantly, where is the evidence that it's a significant problem? There are hundreds of millions of iDevices. If it were a serious problem, where are the millions of users picketing Cupertino to complain?
Sure, some developers don't like it. Big deal. Some developers wouldn't like it if Apple created software that would automatically convert their concepts into perfect code. Making every single developer 100% happy is not possible - nor is it Apple's job.
So asking for people to provide facts to back up their claims is foolish? Maybe you should read a book about debate.
You are not debating. You're a kid screaming for candy while adults are talking politics. You're turning this into a sideshow to make it impossible to have a proper discussion - the ultimate concern troll. Shame on you, troll.
Where's the evidence that data was lost due to CoreData?
You seem to think that simply repeating the same made up statement over and over again will make it true.
More importantly, where is the evidence that it's a significant problem? There are hundreds of millions of iDevices. If it were a serious problem, where are the millions of users picketing Cupertino to complain?
Sure, some developers don't like it. Big deal. Some developers wouldn't like it if Apple created software that would automatically convert their concepts into perfect code. Making every single developer 100% happy is not possible - nor is it Apple's job.
There's a fairly long thread here at Apple Support Communities. Several of the posters claim they lost data. Perhaps there's something in there to indicate how it happens if you really wanted to find out for yourself. https://discussions.apple.com/thread/3382799?start=105&tstart=0
You are not debating. You're a kid screaming for candy while adults are talking politics. You're turning this into a sideshow to make it impossible to have a proper discussion - the ultimate concern troll. Shame on you, troll.
So all the people running around screaming "Apple is evil", "Apple is incompetent", "Horrible problem", "End of the World" are rational adults while the person who says "where is the evidence to support your claim?" is a kid screaming for candy?
There's a fairly long thread here at Apple Support Communities. Several of the posters claim they lost data. Perhaps there's something in there to indicate how it happens if you really wanted to find out for yourself. https://discussions.apple.com/thread/3382799?start=105&tstart=0
OK, so someone has finally pointed to a few people who lost data. That does not, however, prove the assertion that CoreData is at fault, nor that it's a serious problem.
There will be 500 posts on the Apple Support forum about any nonsense that someone dreams up. And with hundreds of millions of iDevices, someone will undoubtedly have any problem that you can imagine. Once again, there's no evidence that it's a significant problem, not that the problem is due to deficiencies in CoreData.
Where's the evidence that data was lost due to CoreData?
You seem to think that simply repeating the same made up statement over and over again will make it true.
More importantly, where is the evidence that it's a significant problem? There are hundreds of millions of iDevices. If it were a serious problem, where are the millions of users picketing Cupertino to complain?
Sure, some developers don't like it. Big deal. Some developers wouldn't like it if Apple created software that would automatically convert their concepts into perfect code. Making every single developer 100% happy is not possible - nor is it Apple's job.
If you're going to use this metric then don't be surprised if someone does the same to you the next time you cry Android fragmentation.
However:
"So, it finally happened. The worst case scenario for any independent iPhone developer occurred. Several users are reporting complete data loss after upgrading my app. iCloud Core Data sync is not working. My users are using this app partially to run their businesses. This is a truly catastrophic failure."
People don't bitch to apple. They bitch at app devs and leave them 1 star reviews because from a user perspective it is the app that's failing and losing stuff.
In any case, links have been provide to you with the difficulties regarding Core Data synching via iCloud to the point that I believe that the matter is sufficiently supported that the onus is on you to show that this isn't a problem. Providing links to dev blogs and news articles seems to be producing a LALALALALA I CAN'T HEAR YOU response.
And it's not that they don't like it. It's that it is broken and some developers are removing Core Data iCloud synching from their already approved apps because they don't like 1 star reviews and unhappy users.
If you're going to use this metric then don't be surprised if someone does the same to you the next time you cry Android fragmentation.
However:
"So, it finally happened. The worst case scenario for any independent iPhone developer occurred. Several users are reporting complete <strong style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;border-top-width:0px;border-right-width:0px;border-bottom-width:0px;border-left-width:0px;font-size:14px;vertical-align:baseline;background-color:transparent;font-weight:bold;">data loss</strong>
after upgrading my app. iCloud Core Data sync is not working. My users are using this app partially to run their businesses. This is a truly <em style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;border-top-width:0px;border-right-width:0px;border-bottom-width:0px;border-left-width:0px;font-size:14px;vertical-align:baseline;background-color:transparent;font-style:italic;">catastrophic failure</em>
."
People don't bitch to apple. They bitch at app devs and leave them 1 star reviews because from a user perspective it is the app that's failing and losing stuff.
In any case, links have been provide to you with the difficulties regarding Core Data synching via iCloud to the point that I believe that the matter is sufficiently supported that the onus is on you to show that this isn't a problem. Providing links to dev blogs and news articles seems to be producing a LALALALALA I CAN'T HEAR YOU response.
And it's not that they don't like it. It's that it is broken and some developers are removing Core Data iCloud synching from their already approved apps because they don't like 1 star reviews and unhappy users.
Still waiting for your evidence that it's Apple's fault. How do you know it's not just crappy coding?
1. App works fine.
2. Developer changes something in app and issues new version.
3. App stops working.
4. Developer says "it's not my fault - blame Apple".
Not a very convincing argument that Apple's at fault.
If CoreData were so bad, why aren't ALL apps failing? Why is it that the number of complaints can be counted on one hand? If it were the massive disaster that you and this developer claim, wouldn't everyone have problems?
The Google solution is that you need to be connected to the Internet or you can't work. That way there is no syncing to be done because there is only one copy of the data, which is the way it should be.
If you are going to rely on the cloud then you need always on network connections.
That's not correct. Google sync works even if you are not connected to the cloud. I can change contact details on my Android phone with no cell coverage or wifi and the next time, the phone connects, it sync the contact to the cloud. It definitely is a tough problem to solve, but Google has nailed it. Palm had done a pretty good job as well with the Palm Desktop as well. Of course it was on a PC rather than in the cloud and it was one device as opposed to multiple devices. But if the cloud becomes the master, than the same principle that applies that Palm used except that keeping multiple devices in sync is obviously harder.
Now I haven't done really extensive tests where I haven't had connectivity for days and made changes to my phone. But when I got my G1 (Android 1.0), this was the first thing I tried because this was the single biggest think I missed from my Palm days and no intervening device since I stopped using my Palm pilots ever got it right.
Still waiting for your evidence that it's Apple's fault. How do you know it's not just crappy coding?
1. App works fine.
2. Developer changes something in app and issues new version.
3. App stops working.
4. Developer says "it's not my fault - blame Apple".
Not a very convincing argument that Apple's at fault.
If CoreData were so bad, why aren't ALL apps failing? Why is it that the number of complaints can be counted on one hand? If it were the massive disaster that you and this developer claim, wouldn't everyone have problems?
There's nothing wrong with CoreData. It's robust. It's iCloud synching of objects within CoreData that appears problematic.
First, not all apps use CoreData. Simpler apps might not. Some apps that need more complex object persistence and retrieval will opt to use a database directly rather than through the Core Data through something like FMDB. The apps that don't hit the DB directly but have complex object mappings appear to me to be the problematic use cases for Core Data syncing. You can create your own very complex object models with complex relationships in Core Data.
Second, not all apps that use CoreData needs to sync between devices OR is itself already a local CoreData based copy of an enterprise database that is accessed via the web and sync'd manually by the dev. CoreData is one option for us if we did an iOS app but most likely we'll use FMDB to our own enterprise server and locally persist data (probably using CoreData) if we did iOS. Thus the set of apps that would use CoreData sync is a smaller subset of all CoreData apps.
Third, synching federated databases correctly is hard and you have to put in careful thought in your database design. An app designed for local CoreData may or may not be able to maintain integrity in a distributed synching mechanism. You can blame this on the app developer if you like but remember that CoreData is a data abstraction made by Apple for developers to use in a "it just works" way and for objects to sync across devices as if the backend database were magically federated in an asynchronous environment with global serializability. Unfortunately the devil is always in the details and for very simple object graphs this might work well but there appear to be commonly used cases where it's doesn't. App developers that use CoreData in an advanced way have reportedly run into these issues since they are the most demanding CoreData apps with the most complex object graphs.
So you're trying to sync complex object trees across multiple devices in a peer to peer fashion across time. This is hard to do correctly with a known static object structure. This is insanely hard over arbitrary object trees that joe random developer can create. This is why everyone went ohh ahh when Steve announced this.
These apps are your money apps and other apps that store and manipulate more than an average amount of data. These are the apps where losing data or invalid syncs are the most damaging. There are fewer of these apps but they are of significant importance in the ecosystem. This is why not "all" apps are failing. Not all apps are demanding in the same way. This should be obvious.
I am not a current iOS dev and I'm not up to speed on CoreData (as in I've read about it but written no code) but it's powerful and allows you to very easily build a MVC app with very little code if you use controller classes and widgets provided by Apple. It's the standard object persistence layer for Cocoa and you get an assload of functionality for free.
But based on actual dev reports not bulletproof synching.
Tl;DR:
The devs I've read seem to think there's a significant issue and they aren't writing trivial apps. They are not idiots and are well respected in the community and when they explain the issues to the wider dev community other devs nod their heads and get it. The problem is insanely hard to solve correctly for an arbitrary set of use cases.
So who the hell are you to gainsay them? I wrote all that crap above because I can't prove to you I'm a dev but I can show I understand the issue. I'm sure you'll just blow that off and ask for more "proof" regardless of what is provided.
Seriously, when devs say this is broken and other devs like Marco Arment and heavyweight tech guys like John Siracusa say "yah, that's pretty borked" WTF other "proof" do you need?
1. Comparing to Drop Box or Google online services is meaningless. Both of those do not sync databases, unless you represent them as a plain file or a simple key-value set. Maybe iCloud is the only db syncing service out there, maybe not. I don’t know. Would be great to see another example that does the same thing.
IBM had DB2Sync which would sync a SQL database on the Palm with DB2. Used to work quite well back in the day.
That's not correct. Google sync works even if you are not connected to the cloud. I can change contact details on my Android phone with no cell coverage or wifi and the next time, the phone connects, it sync the contact to the cloud. It definitely is a tough problem to solve, but Google has nailed it. Palm had done a pretty good job as well with the Palm Desktop as well. Of course it was on a PC rather than in the cloud and it was one device as opposed to multiple devices. But if the cloud becomes the master, than the same principle that applies that Palm used except that keeping multiple devices in sync is obviously harder.
Now I haven't done really extensive tests where I haven't had connectivity for days and made changes to my phone. But when I got my G1 (Android 1.0), this was the first thing I tried because this was the single biggest think I missed from my Palm days and no intervening device since I stopped using my Palm pilots ever got it right.
The problem is harder. Imagine you have 4 android devices which all make changes to contacts. 1 deletes it. The other decides to change the addresses. Another changes the address to a different address. One renames the contact to something else. They all happen around the same time offline but now you have 4 object trees with conflicting results in them.
Now sync in a matter that makes sense to the user so they don't "lose" data despite the fact they just told you to do 4 conflicting things. I'm sure that you can deterministically resolve to a record but probably it wont be the answer the user expects because what the user was thinking is "I renamed Jane C to Jane D because she got married on my iphone" then "my wife changed her address on the ipad we share to her husbands address" then "I deleted the Jane C contact on my mac because it was old...she's Jane D now" and "then I replaced Jane's old address on my iPod Touch with the work address she gave me while at the party". Then internet came back on in my home.
What the user expects is Jane D with both addresses on all devices even though the user screwed up at least 2 steps in this process. And I'm not sure the App developer has visibility on what the hell happened in the iCloud.
And now imagine it's not an object as easy to understand for a user as a "contact" but an underlying data object the app uses as part of doing things for the user. And it's not a data object created by Google or Palm but some randomly complex object the developer needed to persist.
I'm amazed that there is even a debate on the inviolateness of data. This is Rule#1, #2 and #3 of enterprise software. When I first started programming, I was astonished when told that I could yank the power plug on the mainframe and if it was running DB2, no data would be lost. Relational databases that support ACID jump through hoops, using mechanisms like rewrite logs to ensure that after it returns a successful commit of data, you are 100% certain that the data is not lost. It adds to the overhead and is much slower than databases that don't provide that or tools to manage backups and restores. No serious enterprise data is stored without failovers, offsite backup tapes etc.
The problem is harder. Imagine you have 4 android devices which all make changes to contacts. 1 deletes it. The other decides to change the addresses. Another changes the address to a different address. One renames the contact to something else. They all happen around the same time offline but now you have 4 object trees with conflicting results in them.
Now sync in a matter that makes sense to the user so they don't "lose" data despite the fact they just told you to do 4 conflicting things. I'm sure that you can deterministically resolve to a record but probably it wont be the answer the user expects because what the user was thinking is "I renamed Jane C to Jane D because she got married on my iphone" then "my wife changed her address on the ipad we share to her husbands address" then "I deleted the Jane C contact on my mac because it was old...she's Jane D now" and "then I replaced Jane's old address on my iPod Touch with the work address she gave me while at the party". Then internet came back on in my home.
What the user expects is Jane D with both addresses on all devices even though the user screwed up at least 2 steps in this process. And I'm not sure the App developer has visibility on what the hell happened in the iCloud.
And now imagine it's not an object as easy to understand for a user as a "contact" but an underlying data object the app uses as part of doing things for the user. And it's not a data object created by Google or Palm but some randomly complex object the developer needed to persist.
Oh, I totally get the problem. Palm resolved it by creating conflicted records that you had to manually resolve. I just did enough testing for the common scenarios that I would typically experience. Creating a record with the same name on the cloud and a disconnected Android phone. Changing different fields (address, phone number) on different devices, changing the same field (the last write won - as I'd expect). But I should try some of these scenarios and see what happens with Contacts. I never tried deleting a contact and making changes at the same time. Will be interesting to see what happens.
Anyway, this has been a good discussion (barring some unhelpful comments).
You are not debating. You're a kid screaming for candy while adults are talking politics. You're turning this into a sideshow to make it impossible to have a proper discussion - the ultimate concern troll. Shame on you, troll.
So all the people running around screaming "Apple is evil", "Apple is incompetent", "Horrible problem", "End of the World" are rational adults while the person who says "where is the evidence to support your claim?" is a kid screaming for candy?
Stop with your conspiratorial rants. Nobody has made the assertions you claim they made. Anyone who legitimately criticizes Apple you call "Apple-basher". Apple is not beyond reproach, it's not a holy entity. Anyone who's too immature to recognize this should be called fanboy (with emphasis on BOY, as in "little, immature, child") or Apple worshiper.
You simply chose to ignore evidence presented and then ask for it again. That's like John McCain who wanted hearings on the shooting at the Libyan consulate in Bengasi, while not partaking at that very hearing about the shooting at the Libyan consulate, because he was too busy with a press conference in which he called for a hearing on the shooting on the Libyan embassy (which doesn't exist in Bengasi). Are you a Republican, per chance? That would explain some of your behavior.
Quote:
Quote:
Originally Posted by Gatorguy
There's a fairly long thread here at Apple Support Communities. Several of the posters claim they lost data. Perhaps there's something in there to indicate how it happens if you really wanted to find out for yourself.
OK, so someone has finally pointed to a few people who lost data. That does not, however, prove the assertion that CoreData is at fault, nor that it's a serious problem.
There will be 500 posts on the Apple Support forum about any nonsense that someone dreams up. And with hundreds of millions of iDevices, someone will undoubtedly have any problem that you can imagine. Once again, there's no evidence that it's a significant problem, not that the problem is due to deficiencies in CoreData.
CoreData likely isn't at fault anyway, this is a matter of the Ubiquity framework, which works in tandem with CoreData to sync over iCloud. CoreData predates iCloud by a fair amount of time and is widely used and reasonably robust, even though it's likely not bug-free. But again, the ability to understand that distinction is beyond your comprehension of Apple's technologies.
That said, if developers have to stop, cancel or massively delay their products, because in the state the frameworks are in, no reliable sync is possible, then that is a serious problem. No, you won't see users losing data, because the users don't get to use these products, because developers don't release them because they don't want their reputation ruined for a bug that's out of their control.
No user will swallow a useless product that keeps losing data and for which they just paid money in the AppStore and then hear from a developer: "Hey, we programmed it by the specs, we have no bug, so call up Apple to fix their frameworks and backend, then our app will magically start working properly. Until then, you're SOL."
So your smoke and mirrors argument just won't fly, even more so, the introduction of the word "significant" is a joke. Either something is a problem, or it's not. For something to be a "insignificant" problem, it only means: it's a real problem, but I want to ignore it for whatever reason, so I call it insignificant.
Much like 4000 killed troops are a real problem, but 130'000 killed civilians are an insignificant problem called collateral damage...
It's soccer hooligan mentality: usually losers who try to make themselves feel good by attaching themselves to a victorious team so they can say "we won" (even though they were just drinking and screaming and being obnoxious), and who consequently cannot deal with any criticism of the team, regardless of how badly they played and how deservedly they lost, because anything negative is taking away from their self-esteem by proxy. Even funnier to watch though: the stupid fans spend their little hard earned money on sports fan merchandise, while the players swap teams like underwear, and simply play for money, regardless what color jersey they are wearing. The marks are loyal to an artificial brand entity and have their pockets emptied in the process.
The problem is harder. Imagine you have 4 android devices which all make changes to contacts. 1 deletes it. The other decides to change the addresses. Another changes the address to a different address. One renames the contact to something else. They all happen around the same time offline but now you have 4 object trees with conflicting results in them.
Now sync in a matter that makes sense to the user so they don't "lose" data despite the fact they just told you to do 4 conflicting things. I'm sure that you can deterministically resolve to a record but probably it wont be the answer the user expects because what the user was thinking is "I renamed Jane C to Jane D because she got married on my iphone" then "my wife changed her address on the ipad we share to her husbands address" then "I deleted the Jane C contact on my mac because it was old...she's Jane D now" and "then I replaced Jane's old address on my iPod Touch with the work address she gave me while at the party". Then internet came back on in my home.
What the user expects is Jane D with both addresses on all devices even though the user screwed up at least 2 steps in this process. And I'm not sure the App developer has visibility on what the hell happened in the iCloud.
And now imagine it's not an object as easy to understand for a user as a "contact" but an underlying data object the app uses as part of doing things for the user. And it's not a data object created by Google or Palm but some randomly complex object the developer needed to persist.
Oh, I totally get the problem. Palm resolved it by creating conflicted records that you had to manually resolve. I just did enough testing for the common scenarios that I would typically experience. Creating a record with the same name on the cloud and a disconnected Android phone. Changing different fields (address, phone number) on different devices, changing the same field (the last write won - as I'd expect). But I should try some of these scenarios and see what happens with Contacts. I never tried deleting a contact and making changes at the same time. Will be interesting to see what happens.
Anyway, this has been a good discussion (barring some unhelpful comments).
First, Contacts are synced with CardDAV, AFAIK, not CoreData.
Second Addresses and generally any record being synced needs a UUID to indentify the indenty of the record, such that a name is not what makes it unique, and multiple Jack Smiths in your address book can be kept apart, because they have different UUIDs
Unfortunately iCloud is even screwed up there, where mobileMe was not.
Example: I have several "Chris" in my address book. No last name, because I don't know them or don't care about them. iCloud on more than one occasion has simply merged them into one record without me asking. mobileMe would at least throw a sync error or something that allowed you to intervene before such destructive changes happen. So if I have a Chris (girl) with a mobile phone number and a SkypeID and a Chris with a home phone number and an e-mail address, all of a sudden I notice there's just one Chris with a home phone, mobile phone, e-mail and Skype ID. I was never asked if I wanted these merged, nor would I have approved of such merges.
Example 2: You have two AppleIDs, e.g. home@icloud.com and office@icloud.com. So that means you have two address books, which Contacts theoretically can handle just fine. Now you have a contact called Chris in the home account, and add a Chris to the office account. Suddenly Contacts on the Mac shows only one entry, with a little greyed out notice "you have two cards for this contact". Hell, no, I have not. I have two contacts. Never told it to merge, never told it that these are the same Chris. So now I have to make some random exercises like disabling one account, adding a fake last name to the card that's still visible, dragging the vCard to the desktop, deleting the entry, enabling both accounts again, dragging the card into Contacts. Ah, oh magic, now it notices one is called "Chris" and the other is called "Chris X", and they are different people. Now I can rename "Chris X" back to "Chris" and they are recognized as two people. At least until iCloud thinks it has to merge them again...
It's that sort of arrogant attitude of "the cloud knows" and "we make it simple" that actually is anything but simple and horribly annoying. If the cloud thinks these might be the same people at the very least I should get an alert like "Two cards with the same name detected: are they the same person? [yes] [no]" but instead that decision is simply made behind the user's back.
Anyway, that's not part of the issue this thread is discussing, because Contacts use a different sync mechanism, but that mechanism is broken, too.
Yes it is apples fault, quoting an email I received from Apple DTS:
"Thanks for mailing to Apple's developer technical support, I am responding your inquiry about Core Data iCloud integration
Unfortunately, you are running into a bug. For some reason, the ubiquity importer ignores the update from iPad 2 if both devices are running 6.1.x. And currently I don't see any workaround for this."
Using Apple's code from WWDC 2012, you get the SAME bug.
Still waiting for your evidence that it's Apple's fault. How do you know it's not just crappy coding?
1. App works fine.
2. Developer changes something in app and issues new version.
3. App stops working.
4. Developer says "it's not my fault - blame Apple".
Not a very convincing argument that Apple's at fault.
If CoreData were so bad, why aren't ALL apps failing? Why is it that the number of complaints can be counted on one hand? If it were the massive disaster that you and this developer claim, wouldn't everyone have problems?
I quoted you and called you dumb and clueless because thats what you are. Read my post above.
Comments
So asking for people to provide facts to back up their claims is foolish? Maybe you should read a book about debate.
Perhaps you should learn to pick your battles.
The fact is that data has been lost and devs do have problems using core data sync via iCloud and it doesn't work as well as advertised to the dev community.
This is well documented and unless you think these devs quoted by Ars and others are incompetent or anti-Apple then you have to accept that the problem is significant for them in the same way you accept the devs reports that say that Android fragmentation is a significant issue for them.
Both can be worked around but both require a lot more developer effort than it should to the point that many devs simply don't use core data sync or simply punt and target the Android 2.x API and forego the 4.x ones.
Core data sync is a technically hard challenge. More timely Android updates is a politically and economically hard challenge.
Both impact uses and developers in the same way: less able apps.
Well put, more or less. But there's no workaround. Anyhow, you're wasting your time. Some people's mission is to drown out ant anti-Apple noise because they believe themselves credible enough to protect the stock. On the other hand, those who jump on this as evidence that iCloud doesn't work are equally off base.
Where's the evidence that data was lost due to CoreData?
You seem to think that simply repeating the same made up statement over and over again will make it true.
More importantly, where is the evidence that it's a significant problem? There are hundreds of millions of iDevices. If it were a serious problem, where are the millions of users picketing Cupertino to complain?
Sure, some developers don't like it. Big deal. Some developers wouldn't like it if Apple created software that would automatically convert their concepts into perfect code. Making every single developer 100% happy is not possible - nor is it Apple's job.
You are not debating. You're a kid screaming for candy while adults are talking politics. You're turning this into a sideshow to make it impossible to have a proper discussion - the ultimate concern troll. Shame on you, troll.
There's a fairly long thread here at Apple Support Communities. Several of the posters claim they lost data. Perhaps there's something in there to indicate how it happens if you really wanted to find out for yourself.
https://discussions.apple.com/thread/3382799?start=105&tstart=0
So all the people running around screaming "Apple is evil", "Apple is incompetent", "Horrible problem", "End of the World" are rational adults while the person who says "where is the evidence to support your claim?" is a kid screaming for candy?
Is it opposite day already?
OK, so someone has finally pointed to a few people who lost data. That does not, however, prove the assertion that CoreData is at fault, nor that it's a serious problem.
There will be 500 posts on the Apple Support forum about any nonsense that someone dreams up. And with hundreds of millions of iDevices, someone will undoubtedly have any problem that you can imagine. Once again, there's no evidence that it's a significant problem, not that the problem is due to deficiencies in CoreData.
Originally Posted by jragosta
Is it opposite day already?
April Fool's Day, at least.
There will be 500 posts on the Apple Support forum about any nonsense that someone dreams up.
Bingo. It's just conversion disorder.
Quote:
Originally Posted by jragosta
Where's the evidence that data was lost due to CoreData?
You seem to think that simply repeating the same made up statement over and over again will make it true.
More importantly, where is the evidence that it's a significant problem? There are hundreds of millions of iDevices. If it were a serious problem, where are the millions of users picketing Cupertino to complain?
Sure, some developers don't like it. Big deal. Some developers wouldn't like it if Apple created software that would automatically convert their concepts into perfect code. Making every single developer 100% happy is not possible - nor is it Apple's job.
If you're going to use this metric then don't be surprised if someone does the same to you the next time you cry Android fragmentation.
However:
"So, it finally happened. The worst case scenario for any independent iPhone developer occurred. Several users are reporting complete data loss after upgrading my app. iCloud Core Data sync is not working. My users are using this app partially to run their businesses. This is a truly catastrophic failure."
(emphasis by the original poster)
http://stackoverflow.com/questions/14478517/more-icloud-core-data-synching-woes
People don't bitch to apple. They bitch at app devs and leave them 1 star reviews because from a user perspective it is the app that's failing and losing stuff.
In any case, links have been provide to you with the difficulties regarding Core Data synching via iCloud to the point that I believe that the matter is sufficiently supported that the onus is on you to show that this isn't a problem. Providing links to dev blogs and news articles seems to be producing a LALALALALA I CAN'T HEAR YOU response.
And it's not that they don't like it. It's that it is broken and some developers are removing Core Data iCloud synching from their already approved apps because they don't like 1 star reviews and unhappy users.
Still waiting for your evidence that it's Apple's fault. How do you know it's not just crappy coding?
1. App works fine.
2. Developer changes something in app and issues new version.
3. App stops working.
4. Developer says "it's not my fault - blame Apple".
Not a very convincing argument that Apple's at fault.
If CoreData were so bad, why aren't ALL apps failing? Why is it that the number of complaints can be counted on one hand? If it were the massive disaster that you and this developer claim, wouldn't everyone have problems?
Quote:
Originally Posted by mstone
The Google solution is that you need to be connected to the Internet or you can't work. That way there is no syncing to be done because there is only one copy of the data, which is the way it should be.
If you are going to rely on the cloud then you need always on network connections.
That's not correct. Google sync works even if you are not connected to the cloud. I can change contact details on my Android phone with no cell coverage or wifi and the next time, the phone connects, it sync the contact to the cloud. It definitely is a tough problem to solve, but Google has nailed it. Palm had done a pretty good job as well with the Palm Desktop as well. Of course it was on a PC rather than in the cloud and it was one device as opposed to multiple devices. But if the cloud becomes the master, than the same principle that applies that Palm used except that keeping multiple devices in sync is obviously harder.
Now I haven't done really extensive tests where I haven't had connectivity for days and made changes to my phone. But when I got my G1 (Android 1.0), this was the first thing I tried because this was the single biggest think I missed from my Palm days and no intervening device since I stopped using my Palm pilots ever got it right.
Quote:
Originally Posted by jragosta
Still waiting for your evidence that it's Apple's fault. How do you know it's not just crappy coding?
1. App works fine.
2. Developer changes something in app and issues new version.
3. App stops working.
4. Developer says "it's not my fault - blame Apple".
Not a very convincing argument that Apple's at fault.
If CoreData were so bad, why aren't ALL apps failing? Why is it that the number of complaints can be counted on one hand? If it were the massive disaster that you and this developer claim, wouldn't everyone have problems?
There's nothing wrong with CoreData. It's robust. It's iCloud synching of objects within CoreData that appears problematic.
First, not all apps use CoreData. Simpler apps might not. Some apps that need more complex object persistence and retrieval will opt to use a database directly rather than through the Core Data through something like FMDB. The apps that don't hit the DB directly but have complex object mappings appear to me to be the problematic use cases for Core Data syncing. You can create your own very complex object models with complex relationships in Core Data.
Second, not all apps that use CoreData needs to sync between devices OR is itself already a local CoreData based copy of an enterprise database that is accessed via the web and sync'd manually by the dev. CoreData is one option for us if we did an iOS app but most likely we'll use FMDB to our own enterprise server and locally persist data (probably using CoreData) if we did iOS. Thus the set of apps that would use CoreData sync is a smaller subset of all CoreData apps.
Third, synching federated databases correctly is hard and you have to put in careful thought in your database design. An app designed for local CoreData may or may not be able to maintain integrity in a distributed synching mechanism. You can blame this on the app developer if you like but remember that CoreData is a data abstraction made by Apple for developers to use in a "it just works" way and for objects to sync across devices as if the backend database were magically federated in an asynchronous environment with global serializability. Unfortunately the devil is always in the details and for very simple object graphs this might work well but there appear to be commonly used cases where it's doesn't. App developers that use CoreData in an advanced way have reportedly run into these issues since they are the most demanding CoreData apps with the most complex object graphs.
So you're trying to sync complex object trees across multiple devices in a peer to peer fashion across time. This is hard to do correctly with a known static object structure. This is insanely hard over arbitrary object trees that joe random developer can create. This is why everyone went ohh ahh when Steve announced this.
These apps are your money apps and other apps that store and manipulate more than an average amount of data. These are the apps where losing data or invalid syncs are the most damaging. There are fewer of these apps but they are of significant importance in the ecosystem. This is why not "all" apps are failing. Not all apps are demanding in the same way. This should be obvious.
I am not a current iOS dev and I'm not up to speed on CoreData (as in I've read about it but written no code) but it's powerful and allows you to very easily build a MVC app with very little code if you use controller classes and widgets provided by Apple. It's the standard object persistence layer for Cocoa and you get an assload of functionality for free.
But based on actual dev reports not bulletproof synching.
Tl;DR:
The devs I've read seem to think there's a significant issue and they aren't writing trivial apps. They are not idiots and are well respected in the community and when they explain the issues to the wider dev community other devs nod their heads and get it. The problem is insanely hard to solve correctly for an arbitrary set of use cases.
So who the hell are you to gainsay them? I wrote all that crap above because I can't prove to you I'm a dev but I can show I understand the issue. I'm sure you'll just blow that off and ask for more "proof" regardless of what is provided.
Seriously, when devs say this is broken and other devs like Marco Arment and heavyweight tech guys like John Siracusa say "yah, that's pretty borked" WTF other "proof" do you need?
Quote:
Originally Posted by ViktorCode
1. Comparing to Drop Box or Google online services is meaningless. Both of those do not sync databases, unless you represent them as a plain file or a simple key-value set. Maybe iCloud is the only db syncing service out there, maybe not. I don’t know. Would be great to see another example that does the same thing.
IBM had DB2Sync which would sync a SQL database on the Palm with DB2. Used to work quite well back in the day.
Quote:
Originally Posted by os2baba
That's not correct. Google sync works even if you are not connected to the cloud. I can change contact details on my Android phone with no cell coverage or wifi and the next time, the phone connects, it sync the contact to the cloud. It definitely is a tough problem to solve, but Google has nailed it. Palm had done a pretty good job as well with the Palm Desktop as well. Of course it was on a PC rather than in the cloud and it was one device as opposed to multiple devices. But if the cloud becomes the master, than the same principle that applies that Palm used except that keeping multiple devices in sync is obviously harder.
Now I haven't done really extensive tests where I haven't had connectivity for days and made changes to my phone. But when I got my G1 (Android 1.0), this was the first thing I tried because this was the single biggest think I missed from my Palm days and no intervening device since I stopped using my Palm pilots ever got it right.
The problem is harder. Imagine you have 4 android devices which all make changes to contacts. 1 deletes it. The other decides to change the addresses. Another changes the address to a different address. One renames the contact to something else. They all happen around the same time offline but now you have 4 object trees with conflicting results in them.
Now sync in a matter that makes sense to the user so they don't "lose" data despite the fact they just told you to do 4 conflicting things. I'm sure that you can deterministically resolve to a record but probably it wont be the answer the user expects because what the user was thinking is "I renamed Jane C to Jane D because she got married on my iphone" then "my wife changed her address on the ipad we share to her husbands address" then "I deleted the Jane C contact on my mac because it was old...she's Jane D now" and "then I replaced Jane's old address on my iPod Touch with the work address she gave me while at the party". Then internet came back on in my home.
What the user expects is Jane D with both addresses on all devices even though the user screwed up at least 2 steps in this process. And I'm not sure the App developer has visibility on what the hell happened in the iCloud.
And now imagine it's not an object as easy to understand for a user as a "contact" but an underlying data object the app uses as part of doing things for the user. And it's not a data object created by Google or Palm but some randomly complex object the developer needed to persist.
Quote:
Originally Posted by rcfa
Multiple informative postsI'm amazed that there is even a debate on the inviolateness of data. This is Rule#1, #2 and #3 of enterprise software. When I first started programming, I was astonished when told that I could yank the power plug on the mainframe and if it was running DB2, no data would be lost. Relational databases that support ACID jump through hoops, using mechanisms like rewrite logs to ensure that after it returns a successful commit of data, you are 100% certain that the data is not lost. It adds to the overhead and is much slower than databases that don't provide that or tools to manage backups and restores. No serious enterprise data is stored without failovers, offsite backup tapes etc.
If anyone is inclined, check out the seminal white paper on DyanamoDB, Amazon's cloud NoSQL database. http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf
Quote:
Originally Posted by nht
The problem is harder. Imagine you have 4 android devices which all make changes to contacts. 1 deletes it. The other decides to change the addresses. Another changes the address to a different address. One renames the contact to something else. They all happen around the same time offline but now you have 4 object trees with conflicting results in them.
Now sync in a matter that makes sense to the user so they don't "lose" data despite the fact they just told you to do 4 conflicting things. I'm sure that you can deterministically resolve to a record but probably it wont be the answer the user expects because what the user was thinking is "I renamed Jane C to Jane D because she got married on my iphone" then "my wife changed her address on the ipad we share to her husbands address" then "I deleted the Jane C contact on my mac because it was old...she's Jane D now" and "then I replaced Jane's old address on my iPod Touch with the work address she gave me while at the party". Then internet came back on in my home.
What the user expects is Jane D with both addresses on all devices even though the user screwed up at least 2 steps in this process. And I'm not sure the App developer has visibility on what the hell happened in the iCloud.
And now imagine it's not an object as easy to understand for a user as a "contact" but an underlying data object the app uses as part of doing things for the user. And it's not a data object created by Google or Palm but some randomly complex object the developer needed to persist.
Oh, I totally get the problem. Palm resolved it by creating conflicted records that you had to manually resolve. I just did enough testing for the common scenarios that I would typically experience. Creating a record with the same name on the cloud and a disconnected Android phone. Changing different fields (address, phone number) on different devices, changing the same field (the last write won - as I'd expect). But I should try some of these scenarios and see what happens with Contacts. I never tried deleting a contact and making changes at the same time. Will be interesting to see what happens.
Anyway, this has been a good discussion (barring some unhelpful comments).
Quote:
Originally Posted by jragosta
Quote:
Originally Posted by ankleskater
You are not debating. You're a kid screaming for candy while adults are talking politics. You're turning this into a sideshow to make it impossible to have a proper discussion - the ultimate concern troll. Shame on you, troll.
So all the people running around screaming "Apple is evil", "Apple is incompetent", "Horrible problem", "End of the World" are rational adults while the person who says "where is the evidence to support your claim?" is a kid screaming for candy?
Stop with your conspiratorial rants. Nobody has made the assertions you claim they made. Anyone who legitimately criticizes Apple you call "Apple-basher". Apple is not beyond reproach, it's not a holy entity. Anyone who's too immature to recognize this should be called fanboy (with emphasis on BOY, as in "little, immature, child") or Apple worshiper.
You simply chose to ignore evidence presented and then ask for it again. That's like John McCain who wanted hearings on the shooting at the Libyan consulate in Bengasi, while not partaking at that very hearing about the shooting at the Libyan consulate, because he was too busy with a press conference in which he called for a hearing on the shooting on the Libyan embassy (which doesn't exist in Bengasi). Are you a Republican, per chance? That would explain some of your behavior.
Quote:
Quote:
Originally Posted by Gatorguy
There's a fairly long thread here at Apple Support Communities. Several of the posters claim they lost data. Perhaps there's something in there to indicate how it happens if you really wanted to find out for yourself.
https://discussions.apple.com/thread/3382799?start=105&tstart=0
OK, so someone has finally pointed to a few people who lost data. That does not, however, prove the assertion that CoreData is at fault, nor that it's a serious problem.
There will be 500 posts on the Apple Support forum about any nonsense that someone dreams up. And with hundreds of millions of iDevices, someone will undoubtedly have any problem that you can imagine. Once again, there's no evidence that it's a significant problem, not that the problem is due to deficiencies in CoreData.
CoreData likely isn't at fault anyway, this is a matter of the Ubiquity framework, which works in tandem with CoreData to sync over iCloud. CoreData predates iCloud by a fair amount of time and is widely used and reasonably robust, even though it's likely not bug-free. But again, the ability to understand that distinction is beyond your comprehension of Apple's technologies.
That said, if developers have to stop, cancel or massively delay their products, because in the state the frameworks are in, no reliable sync is possible, then that is a serious problem. No, you won't see users losing data, because the users don't get to use these products, because developers don't release them because they don't want their reputation ruined for a bug that's out of their control.
No user will swallow a useless product that keeps losing data and for which they just paid money in the AppStore and then hear from a developer: "Hey, we programmed it by the specs, we have no bug, so call up Apple to fix their frameworks and backend, then our app will magically start working properly. Until then, you're SOL."
So your smoke and mirrors argument just won't fly, even more so, the introduction of the word "significant" is a joke. Either something is a problem, or it's not. For something to be a "insignificant" problem, it only means: it's a real problem, but I want to ignore it for whatever reason, so I call it insignificant.
Much like 4000 killed troops are a real problem, but 130'000 killed civilians are an insignificant problem called collateral damage...
It's soccer hooligan mentality: usually losers who try to make themselves feel good by attaching themselves to a victorious team so they can say "we won" (even though they were just drinking and screaming and being obnoxious), and who consequently cannot deal with any criticism of the team, regardless of how badly they played and how deservedly they lost, because anything negative is taking away from their self-esteem by proxy. Even funnier to watch though: the stupid fans spend their little hard earned money on sports fan merchandise, while the players swap teams like underwear, and simply play for money, regardless what color jersey they are wearing. The marks are loyal to an artificial brand entity and have their pockets emptied in the process.
Quote:
Originally Posted by os2baba
Quote:
Originally Posted by nht
The problem is harder. Imagine you have 4 android devices which all make changes to contacts. 1 deletes it. The other decides to change the addresses. Another changes the address to a different address. One renames the contact to something else. They all happen around the same time offline but now you have 4 object trees with conflicting results in them.
Now sync in a matter that makes sense to the user so they don't "lose" data despite the fact they just told you to do 4 conflicting things. I'm sure that you can deterministically resolve to a record but probably it wont be the answer the user expects because what the user was thinking is "I renamed Jane C to Jane D because she got married on my iphone" then "my wife changed her address on the ipad we share to her husbands address" then "I deleted the Jane C contact on my mac because it was old...she's Jane D now" and "then I replaced Jane's old address on my iPod Touch with the work address she gave me while at the party". Then internet came back on in my home.
What the user expects is Jane D with both addresses on all devices even though the user screwed up at least 2 steps in this process. And I'm not sure the App developer has visibility on what the hell happened in the iCloud.
And now imagine it's not an object as easy to understand for a user as a "contact" but an underlying data object the app uses as part of doing things for the user. And it's not a data object created by Google or Palm but some randomly complex object the developer needed to persist.
Oh, I totally get the problem. Palm resolved it by creating conflicted records that you had to manually resolve. I just did enough testing for the common scenarios that I would typically experience. Creating a record with the same name on the cloud and a disconnected Android phone. Changing different fields (address, phone number) on different devices, changing the same field (the last write won - as I'd expect). But I should try some of these scenarios and see what happens with Contacts. I never tried deleting a contact and making changes at the same time. Will be interesting to see what happens.
Anyway, this has been a good discussion (barring some unhelpful comments).
First, Contacts are synced with CardDAV, AFAIK, not CoreData.
Second Addresses and generally any record being synced needs a UUID to indentify the indenty of the record, such that a name is not what makes it unique, and multiple Jack Smiths in your address book can be kept apart, because they have different UUIDs
Unfortunately iCloud is even screwed up there, where mobileMe was not.
Example: I have several "Chris" in my address book. No last name, because I don't know them or don't care about them. iCloud on more than one occasion has simply merged them into one record without me asking. mobileMe would at least throw a sync error or something that allowed you to intervene before such destructive changes happen. So if I have a Chris (girl) with a mobile phone number and a SkypeID and a Chris with a home phone number and an e-mail address, all of a sudden I notice there's just one Chris with a home phone, mobile phone, e-mail and Skype ID. I was never asked if I wanted these merged, nor would I have approved of such merges.
Example 2: You have two AppleIDs, e.g. home@icloud.com and office@icloud.com. So that means you have two address books, which Contacts theoretically can handle just fine. Now you have a contact called Chris in the home account, and add a Chris to the office account. Suddenly Contacts on the Mac shows only one entry, with a little greyed out notice "you have two cards for this contact". Hell, no, I have not. I have two contacts. Never told it to merge, never told it that these are the same Chris. So now I have to make some random exercises like disabling one account, adding a fake last name to the card that's still visible, dragging the vCard to the desktop, deleting the entry, enabling both accounts again, dragging the card into Contacts. Ah, oh magic, now it notices one is called "Chris" and the other is called "Chris X", and they are different people. Now I can rename "Chris X" back to "Chris" and they are recognized as two people. At least until iCloud thinks it has to merge them again...
It's that sort of arrogant attitude of "the cloud knows" and "we make it simple" that actually is anything but simple and horribly annoying. If the cloud thinks these might be the same people at the very least I should get an alert like "Two cards with the same name detected: are they the same person? [yes] [no]" but instead that decision is simply made behind the user's back.
Anyway, that's not part of the issue this thread is discussing, because Contacts use a different sync mechanism, but that mechanism is broken, too.
Yes it is apples fault, quoting an email I received from Apple DTS:
"Thanks for mailing to Apple's developer technical support, I am responding your inquiry about Core Data iCloud integration
Unfortunately, you are running into a bug. For some reason, the ubiquity importer ignores the update from iPad 2 if both devices are running 6.1.x. And currently I don't see any workaround for this."
Using Apple's code from WWDC 2012, you get the SAME bug.
Quote:
Originally Posted by jragosta
Still waiting for your evidence that it's Apple's fault. How do you know it's not just crappy coding?
1. App works fine.
2. Developer changes something in app and issues new version.
3. App stops working.
4. Developer says "it's not my fault - blame Apple".
Not a very convincing argument that Apple's at fault.
If CoreData were so bad, why aren't ALL apps failing? Why is it that the number of complaints can be counted on one hand? If it were the massive disaster that you and this developer claim, wouldn't everyone have problems?
I quoted you and called you dumb and clueless because thats what you are. Read my post above.
But someone decided to edit my post..... whatever