Questing about the use of libmm

[Aleksander Morgado]

Hey,

On Mon, Feb 8, 2016 at 9:59 AM, Troels Olesen <to at movis.dk> wrote:
> I have some questions about the how to use the "libmm" library, in an modem
> handler application.
>
> I have read your API wiki, at
> "http://www.freedesktop.org/software/ModemManager/libmm-glib/latest/",
> and i have managed to make an application that like mmcli can get
> information from the ModemManager daemon.
>
> But i have some problems getting updated information from the MM objects i
> create.
>
> The way i understand the MM object structure is that the MMManager* object
> gives a list of MMObject*, and from the MMObject* it is possible to get
> MMModem*, MMModemLocation* and MMModem3gpp* objects witch gives the
> information that i am searching for.
>

Yes. The MMManager object is a "object manager" (i.e. implements the
standard ObjectManager interface in DBus). This MMManager gets you
retrieve a list of MMObjects. These are 1 object per modem. For each
of this MMObject, you'll have one additional object for each interface
it implements. E.g. a modem which has location capabilities will have
a MMModemLocation object that you can get with
mm_object_get_modem_location() (transfer full, gets a full new
reference) or mm_modem_peek_modem_location() (transfer none, doesn't
get a new reference).

> It is also possible for me to generate these pointer objects, but i have
> some problems getting them updated, in such a manner that i can run a loop
> application to check status of the modem.
>

How do you generate these objects? What you would need to do is to
create a new "proxy" object for each of those (e.g. a GDBusProxy).
But... this is already what the libmm-glib API gives you through
g_dbus_object_manager_get_object().

> Especially the function "mm_modem_get_state(MMModem*)", does not seem to
> update its information, when i run it without resetting all above pointer
> objects. it this the correct behavior for this function?
>
> Should i consider all MM object pointers as a snapshot frozen in time, from
> when the MMManager* or MMObject* was generated?
>

If you have created a "proxy" object for each interface, as libmm-glib
does, the proxy itself should automatically update the property values
when they change in the interface; *unless*
G_DBUS_PROXY_FLAGS_DO_NOT_LOAD_PROPERTIES or
G_DBUS_PROXY_FLAGS_DO_NOT_CONNECT_SIGNALS are used when manually
creating a proxy. BUT, and I think here yields the issue, this is only
happening when a glib main loop is running. You need to run a main
loop for async update of the properties; if you're only using sync()
methods, then yes, the interface objects that you get will be
snapshots.

If you're integrating this app into a larger one which doesn't use
glib main loops, you can always create a fully new thread for the MM
management and run a main loop in the separate thread, and then handle
the thread sync and locking yourself.

> Another problem i have, is understanding the correct clearing/unref
> procedure for MMManager*, it does not say in the API wiki, if it should be
> cleared with g_object_unref or NULL, or some other way. an no matter how i
> try to clear this object it seams that i end up with a memory leak or a
> double free pointer error.

MMManager created with mm_manager_new_sync() or
mm_manager_new()/_finish() need to be just unref-ed with
g_object_unref().

-- 
Aleksander
https://aleksander.es