Re: vCard -> loss of Identity
Re: vCard -> loss of Identity
- Subject: Re: vCard -> loss of Identity
- From: Steve Cronin <email@hidden>
- Date: Tue, 28 Feb 2006 11:01:17 -0600
Greg;
Thanks for the thoughtful response but I guess I didn't make my self
clear enough.
I am not importing anything into AddressBook.
I am merely using AddressBook as a source of data. I am using vCards
as a data source as well!
I do not know what the application source of the vCard is AND I DO
know that not all vCard implementations will have a kABUIDProperty.
However, if the source of the vCard is the local AddressBook, it
would handy indeed to use kABUIDProperty to determine that this vCard
is the same record,
When using the ABPicker I get a consistent value for kABUIDProperty
each time the user accesses a given record.
However, if, instead of using the ABPicker, a user drags the SAME
record out of the local AddressBook and drops it onto my view,
I do NOT get the same value for kABUIDProperty. In fact, on every
drop I get a different value.
The kABUIDProperty appears to change its function to become a sort of
'kvCardUIDProperty'.
This is my core issue, why is the 'ABkey' being corrupted to serve as
a completely different kind of key (vCardKey)?
What I need to do is to be able to determine that that vCard is, in
fact, the same data as a record in MY database (not AB).
So, since the kABUIDProperty is altered by the vCard process, this
seems problematic.
I guess I really don't understand why the kABUIDProperty cannot be
available as a 'SourceID' value and there be a separate UID
associated with the vCard. It really would be handy to use the
kABUIDProperty as a key.
But I grow pessimistic...
Thanks for your time!
Steve
On Feb 28, 2006, at 10:35 AM, Greg Herlihy wrote:
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