VCF handling

[vv75]

i've created a mini-app that exploits the framewors's BFPhonebookClient and TBFvCard classes.

first, it was quite awkward to discover that TBFvCard.SaveToStream() in fact trites to a TStringList and not to a TStream.

second, a hands-on test with my Siemens CX75 shows that the framework is unable to parse the data sent by the device. particularly, TBFvCard.Identification.FormattedName() returns an empty string. it's probably because the CX75 sends VCF as QuotedPrintable-encoded UTF-8.

Mike, can you please fix this? it would be tremendous if it would indeed write to a TStream, the exact same bytes that came from the device. the status-quo with writing to TStringList can be preserved, but in a method with a different name.

i'm currently evaluating your framework towards using it for mobile devices addressbook handling to one of the top-3 best products in its market.

given that parsing VCFs in that product seems to be better that that of your framework, it'll be reasonable if your framework would just return raw VCF data as taken from the device and let the rest (charset, encoding) be none of your headache as long as the rest of the framework is not entirely Unicode-aware.

[Mike Petrichenko]

Good time of the day!

Actually, BFvCard use UTF-8 and QuotedPrintable for vCard

Here is the code:

Code: [Select]

procedure TBFPropertyParser.SetPropName(const Value: string);
<skipped>
begin
<skipped>
    if Pos('QUOTED-PRINTABLE', AnsiUppercase(Line)) > 0 then
     <skipped>

      if Pos('UTF-8', Names) > 0 then Values := Utf8ToAnsi(Values);
      if Pos('ISO-8859-5', Names) > 0 then begin
        <skipped>
      end;
    <skipped>
  end;
end;
Can you send me to the e-mail (support@btframework.com) any saved VCF. Just save it from the phone to PC and send by e-mail.

And you can use Raw VCF from your phone using TBFSyncClient on wich TBFPhoneBookClient based.

[vv75]

pointless. the VCF that i send from the phone is different from what i receive by your framework: it is sent as a file per se (through the file sending service) and contains plain ascii - no q-p nor utf.

obviously, the device handles differently these two export methods. which seems quite logical, if you take into account the "be liberal in what you receive and conservative in what you send" netiquette principle and the fact that this method (sending a contact as file) should be accepted by older VCF handlers too. hence it reformats it as simple as possible before sending it.

still, how about making SaveToStream() do exactly as suggested by its name?

[vv75]

also, the product in discussion has a whole framework concerning i18n. and, given that it's a end-user widely-available product, it was tested quite seriously for about a year.

hence, i'd rather trust that charset-handling framework instead of yours.

so, please-please-please, give us the exact bytes the devices send you, and let the rest be our headache.

[Mike Petrichenko]

And may be Russian will better here And you can contact with by ICQ (190812766) or MSN (mike@btframework.com) right now. I am inline.

[Mike Petrichenko]

OK. I had delete my post and now I understand what you mean

I see what happens. Rigth. Siemens (My Siemesn S65 too) returns VCF as Ansi encoded. Internally vCard uses with UTF-8 QUOTED-PRINTABLE (because Nokia didn't understan Ansi Encoded characters).

So, you need save vCard file (VCF) as Ansi. Right? OK. I will do it this night Not a problem.

[vv75]

in fact, i woul prefer that SaveToStream() would INDEED SAVE TO A STREAM and it would put there THE EXACT BYTES THE DEVICE SENDS YOU.

and another function, say, SaveToStrings() would save to a TStringList or whatever. and HERE you can do it "Ansi encoded".

[Mike Petrichenko]

OK. Use TBFSyncClient.procedure ReadObject(soPhoneBook, AData: TStringList);
which returns the same information directly from phone to StringList.

But you shlould to know that Nokia phones returns VCF file with UTF-8 encdoing.

Or if you need really RAW data, no problem, use Read method wich returns actual RAW data from the phone. Of course, you should parse it manually in this case.

I am really can't understand what you want to do. Do you want save it to file? OK. No problems. You can do it. You need access to phone book fields? This is not a problem too using vCard objet.

Or you not sure that UTF-8 is a standard? Belive, this is standard.

[Mike Petrichenko]

OK. Seems like my mind was somewhere else but not here Because I had understand what you need

So. I added several methods to work with native TStream. I will publish new version tomorrow.

[vv75]

OK. Seems like my mind was somewhere else but not here Because I had understand what you need

So. I added several methods to work with native TStream. I will publish new version tomorrow.

very nice, thanks. indeed, an amazing troubleshooting speed.

you publish it tomorrow, i will see it on monday.

have a nice weekend!

[Mike Petrichenko]

OK. Fixed version uploaded
http://www.btframework.com/files/demo/bffree.zip

[vv75]

lemmesee...

you'll have my impressions in several hours, i suppose.

[vv75]

unfortunately, i don't see any changes since the previous ver...

1. SaveToStream() still saves to a TStrings and not to a TStream.
2. TBFvCard.Identification.FormattedName() returns an empty string.

i've also noticed that if the contact is located on the SIM and not in the phone's internal phonebook, FormattedName() seems to return the correct value. i'll investigate this a little more, but i don't think the phone is guilty, it's rather your VCF parser...

all in all, main point of my objection - SaveToStream() should save to a TStream - is not satisfied at all...

[Mike Petrichenko]

There are 2 overloaded functions SaveToStream(Stream: TStringList) and SaveTStream(Stream: TSTream). Refere to BTF Developer manual.

Correct. SIM has not any other format then Formatted name.

The phone stores names in differetn fields. First and Last names. Not in formatted. But some phones did it in formatted.

For more details refere to vCard specification.

[vv75]

thanks for pointing out.

the documentation says the same as in the previous version. are you sure you've packaged the new one?

heh. see? you'll get a lot of extra headache if you try to parse a vCard in this framework...

now, back to our streams. does the framework guarantee that ALL of the vCard data which i supply via LoadFromStream will be pushed onto the device the exact way i supply it?

in other words, will it be supplied AS IS, without any intermediate parsing and rebuilding?