Re: vCard -> loss of Identity
Re: vCard -> loss of Identity
- Subject: Re: vCard -> loss of Identity
- From: Greg Herlihy <email@hidden>
- Date: Tue, 28 Feb 2006 08:35:47 -0800
- Thread-topic: vCard -> loss of Identity
The kABUIDProperty is a field that the address book uses to identify its
records. Imported vCards do not have this field, so naturally importing the
same vCard will create a new Address Book record every time.
But importing vCards is not the only way to wind up with redundant
information in an address book. In fact duplicate, or near duplicate entries
are quite common when importing data into an address book. So it makes sense
to solve the problem in a general way, rather than try to prevent every
conceivable means by which a record could be duplicated in the Address Book.
Furthermore, it would be prohibitively inefficient to try to screen each
record as it came in. So finding duplicates in the Address Book
realistically has to wait until an entire batch of records has been
imported.
The last and most important point though is that the user should be the one
to decide whether two records are duplicates or not. There is no function
call that can decide each case on their behalf; more often than not the
decision is simply a preference or a judgment call. So if the user really
wants to import a vCard twice, then they probably have their reasons. And a
piece of software should not overrule them. After all, there is no data
lost, so the action, if unintended, is not anything that cannot be undone.
And in fact the Address Book in its current implementation reflects these
ideas rather well - it finds possible duplicates heuristically and across
the entire set. And the Address Book wisely puts the user in charge of
deciding what is a duplicate record and what is not. And the Address Book
manages to package all of this capability into a single menu item: "Look for
Duplicate Entries..."
So I would say that this type of problem has been already been "addressed"
(pardon the pun).
Greg
On 2/28/06 6:00 AM, "Philip Dow" <email@hidden> wrote:
> Hi Steve,
>
> I have also encountered this exact problem trying to support drag and
> drop from an ABPeoplePicker. I was unable to find a workaround and
> was forced to ignore vCard drops. Instead, I added an Insert button
> at whose click I grab the selected record using [[ABPicker
> selectedRecords] objectAtIndex:i] which I then drop into a
> notification for any objects listening, in my case, the text view
> that should have been able to receive drags from the people picker.
>
> If anyone has a better solution, I'm also interested.
>
> -Phil
>
> On Feb 28, 2006, at 2:08 PM, Steve Cronin wrote:
>
>> Folks;
>>
>> I've implemented an AddressBook ABPeoplePicker and that works fine.
>> I've also registered for drags from vCards and that is working fine.
>> From the user's point of view this is good: dragNdrop or a UI
>> widget, whatever you're in the mood for....
>>
>> But here's the rub: I need to be able to tell that a given record
>> is the same as another.
>>
>> In the ABPerson there is a property: kABUIDProperty
>>
>> When I use [[ABPicker selectedRecords] objectAtIndex:i] to read
>> data I get consistent values for this property for a given record
>> in AddressBook. (I assume that this does not do a
>> 'vCardRepresentation'!)
>>
>> However when I read the kABUIDProperty value from the VERY SAME
>> record dropped as a vCard -> no joy (different values).
>>
>> With a bit of fiddling I've managed to convince myself that any
>> wrapping in a vCard implies that you can never know that a given
>> vCard IS in fact the identical record as some other vCard.
>>
>> I simply cannot be the first person to be bloodied by this. Is
>> there any collective wisdom or am I doomed to writing some
>> home-grown ABRecord coalescer?
>>
>> As always THANK-YOU!
>> Steve
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Cocoa-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden