Contacts Kit, Quarter-term

Blog post by Barrett on Tue, 2011-06-14 22:46

These weeks were prolific in terms of design and experiments but due to university commitments i am a bit late with the expected goals.
At this point i have an implementation of BContact / BRawContact and i'm working to get the VCard translator functional. In these hours my focus is the communication part between the raw contacts and translators.

One of the latest design decisions was to make BRawContact own a translator that is suitable for writing the format specified by the user, otherwise it will use the default B_CONTACT_FORMAT (a flattened BMessage) for the final file. The passage of the data between the object and the translator will be done every time the programmer want via the Commit() method. If a path is not passed, the BRawContact will be virtual and stored in memory.

An example of how the api will look approximately :

	BContact contact = BContact(new BRawContact(B_VCARD_FORMAT, "/boot/home/"));
	status_t ret = contact.InitCheck();
	BContactField* field = new BContactField();
	field->Add(new BPhoneNumber(..));
        ...
        contact.AddData(field);
        ...
	ret = contact.Commit();

Most of you probably already know that one of my major inspiration sources was the Android's ContactsContract API. It is already giving some ideas, like the BContactField object. In fact they use a class named ContentValues, that is similar for some aspects to BMessage as a generic data container, i'm thinking to make a wrapper for BMessage in order to provide an object (BContactField) that makes comfortable passing data fields to BContact / BRawContact. It will help also internally, since as said a flattened BMessage is the common translation format (B_CONTACT_FORMAT).

In the immediate future i'm also planning to implement a set of functions in TranslationUtils.h able to convert a BPositionIO or a file into a BContact in a similar manner as the already existent functions for BBitmap and other formats but using the provided Contact API.

There is a new osdrawer project at http://dev.osdrawer.net/projects/contacts-kit, i'm planning to update here some code during the next days.

At this point i expect to get a first working version of both translators in 7 days, in order to begin working on the services_server part. The first goal will be getting the BContactRoster class up, then to add some functions like unique ids for translator (only BContactRoster will be able to edit the id of a BContact because the first goal of the class will be to provide a centralized management of the contacts) and then focusing on the implementation of the services add-on hosting server including an add-on API. My major idea about that is to implement it using a BMessage protocol and some basic hook functions for the services server -> add-on communication.

Comments

Re: Contacts Kit, Quarter-term

Hi,
will "People" delate and a new contacts file format make ? and a new GUI ?

I like http://afaikblog.wordpress.com/2011/06/09/presenting-gnome-contacts/

Other Question:

BContact contact = BContact(new BRawContact(B_VCARD_FORMAT, "/boot/home/"));

why will not make the folder place to a Constante eg: B_USER_DIRECTORY

and why not make "status_t ret = contact.InitCheck();" automatly

eg:

BContact contact = BContact(new BRawContact(B_VCARD_FORMAT, B_USER_DIRECTORY));
BContactField* field = new BContactField();
field->Add(new BPhoneNumber(..));
...
contact.AddData(field);
...
contact.Commit();

And Why .Commit() i read the BFile API , why not make simultan with this API?
BFile
A BFile lets you read and write the data portion of a file. It does this by implementing the Read() / Write() and ReadAt() / WriteAt() functions that are declared by the BPositionIO class.

Thanks stargater

Re: Contacts Kit, Quarter-term

Hi Stargater,
For the first question the answer is no...People will remain the preferred format (thanks to their integration with the fs and queries) and will be called B_PEOPLE_FORMAT...B_CONTACT_FORMAT instead will be an exchange format but nothing will prevent you to save it on the disk (using a translator or BContact::Archive()). About the GUI...i have not a precise idea at the moment, surely will be easy to do something like the gnome one when the api will be functional.

For the path question...consider that "/boot/home" is a wrong example, you have to specify a name for the raw contact...i prefer to use the usual find_directory() method and BPath sincerely : ).

What do you mean for "and why not make "status_t ret = contact.InitCheck();" automatly" ?

Commit in low-level terms, will make sure that we have a translator_id and a preferred format (if the user doesn't specify a format B_CONTACT_FORMAT will be used) and pass the internal BMessage to a translator that will write all to the final BPositionIO (BFile etc..), i'm also thinking to an alternative constructor that will make the user able to specify a BPositionIO instead of a path.