Merge lp://staging/~canonical-platform-qa/address-book-app/contacts_dbus_service into lp://staging/address-book-app

Proposed by Brendan Donegan
Status: Work in progress
Proposed branch: lp://staging/~canonical-platform-qa/address-book-app/contacts_dbus_service
Merge into: lp://staging/address-book-app
Diff against target: 268 lines (+207/-4)
4 files modified
debian/control (+3/-0)
debian/rules (+3/-0)
tests/autopilot/address_book_app/__init__.py (+81/-4)
tests/autopilot/unittests/test_contacts_service.py (+120/-0)
To merge this branch: bzr merge lp://staging/~canonical-platform-qa/address-book-app/contacts_dbus_service
Reviewer Review Type Date Requested Status
PS Jenkins bot continuous-integration Needs Fixing
Canonical Platform QA Team Pending
Renato Araujo Oliveira Filho Pending
Review via email: mp+226698@code.staging.launchpad.net

This proposal supersedes a proposal from 2014-07-11.

Description of the change

Add a ContactsDbusService which lets us interact with the actual contacts database of the device and can be useful for some tests that are being written to test integration between address-book-app and other apps.

To post a comment you must log in.
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote : Posted in a previous version of this proposal
review: Needs Fixing (continuous-integration)
Revision history for this message
Renato Araujo Oliveira Filho (renatofilho) wrote : Posted in a previous version of this proposal

Could you explain why are using the DBUS API this is a private API and can change without notice. The correct solution would be use the QtContacts API.

review: Needs Information
Revision history for this message
Brendan Donegan (brendan-donegan) wrote : Posted in a previous version of this proposal

Well the initial motivation is because it's easier to use via python, but I hear your reservations about compatibility. Perhaps adding some functional tests will protect against that? I can do that if needed. Of course I could also make a wrapper or something for the C++ API with python, but it's tricky and not something I'm experienced in.

Revision history for this message
Renato Araujo Oliveira Filho (renatofilho) wrote : Posted in a previous version of this proposal

My concern is that, we should drop the DBUS communication in the future, and I want to avoid to use it.

Do you think you could use the the python EDS instead our server API?

Revision history for this message
Brendan Donegan (brendan-donegan) wrote : Posted in a previous version of this proposal

Do you have a reference for that? I could look at it and see if it fulfils our needs.

Revision history for this message
Renato Araujo Oliveira Filho (renatofilho) wrote : Posted in a previous version of this proposal

Basically the python API is a mirror of glib API[1]

I did not find any documentation about the python API, but it uses the gobject introspection, what you need is these packages:

gir1.2-ebook-1.2
gir1.2-ebookcontacts-1.2
gir1.2-edataserver-1.2

and will import like that: from gi.repository import EBook

I do not have any examples, but I think that should be easy to find in the internet.

[1] https://developer.gnome.org/eds/unstable/

Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
Brendan Donegan (brendan-donegan) wrote :

Back to the drawing board with this one - we may take an entirely different approach in the end anyway.

Unmerged revisions

221. By Brendan Donegan

Add ContactsDbusService and associated tests

220. By Launchpad Translations on behalf of phablet-team

Launchpad automatic translations update.

219. By Launchpad Translations on behalf of phablet-team

Launchpad automatic translations update.

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
The diff is not available at this time. You can reload the page or download it.

Subscribers

People subscribed via source and target branches