Bug 104800

Summary:	Notification about sms messages fire up too early
Product:	ModemManager	Reporter:	Andrew <atimonin>
Component:	general	Assignee:	ModemManager bug user <modemmanager>
Status:	RESOLVED NOTABUG	QA Contact:
Severity:	major
Priority:	medium
Version:	1.6
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Andrew 2018-01-26 08:23:23 UTC

I'm developing app daemon listening for SMS from modem (python)
I'm using 'notify::messages' with callback

When I send a message (via separate app),
I get a notification about it and read it's state always 'unknown' and
no other notifications when SMS is sent.
mmcli later shows that SMS is sent.

But if I sleep a little in callback (3s is OK, 1s is not, maybe depends on SMS length) I get state 'sent'.

Is it possible to get notifications about all state changes
(for ex. unknown -> sending -> sent)
or at least when state is somehow settled?

Comment 1 Aleksander Morgado 2018-01-26 09:07:35 UTC

In addition to listening to the "messages" property updates (E.g. notifying new sms addition/removals) you also need to listen to the actual new SMS object property updates. I assume you're doing this development using raw DBus ?

I would definitely suggest you use the libmm-glib GObject Introspection support to develop your python application. This library makes sure the SMS object properties are updated "in real time" in the background, so even if you get notified about a new SMS object, the SMS object would change states in real time as soon as the SMS is e.g. sent.

You can see an example of how to use this G-I support here:
https://cgit.freedesktop.org/ModemManager/ModemManager/tree/examples/sms-python/sms-python

This is not a bug anyway, SMS addition/removals and actual SMS properties are reported independently, they should all need to be monitored.

Comment 2 Andrew 2018-02-07 07:37:27 UTC

Aleksander, thanks a lot for your advise!

May you help a bit more?
There is too small info about notifications and callbacks in interface description.
Moreover, looking through the source I was unable to locate notify::messages nor notify::name-owner
which works and is in examples...

Comment 3 Aleksander Morgado 2018-02-07 08:58:03 UTC

> May you help a bit more?

Sure!

> There is too small info about notifications and callbacks in interface
> description.
> Moreover, looking through the source I was unable to locate notify::messages
> nor notify::name-owner
> which works and is in examples...

Oh! That is just standard logic available when the DBus support is implemented via "GDBus", as in our case: ALL properties defined in the interfaces are updated "in real time" in your application. There is a gdbus 'service thread' that takes care of getting standard org.freedesktop.DBus.Properties "PropertiesChanged" signals and whenever one of the properties changes it would issue a signal that your application can follow via "notify::<PROPERTY>" signal callbacks configured. It's like magic happening in the background.

If you want to take a deeper peek at what is happening underneath, try:
  * Running "sudo dbus-monitor --system" and see how the updates are reported internally.
  * Run d-feet and "browse" through the interfaces implemented by the ModemManager objects.

Those 2 things are a really nice way of understanding how all this works.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.