Usually, if not always, the connection stored in the SIM object never exists
when disposing it, as we clear the connection property in the Modem object
before destroying it, and both properties are bound. But just in case, in order
to avoid ending up with a zombie object in DBus, we make sure we unexport it.
Make a tight connection between the action of sending AT commands, either single
or in a sequence, with the MMBaseModem object owning the port. This direct
relation allows sending commands without specifying which port to use, so that
the modem object can get the best port at each time, and handling all that in a
single common place.
The original mm-at API has also been modified so that when a single command is
sent, a constant string is returned. We are allowed to return constant strings
in mm_base_modem_at_command_finish() because the string itself is owned by the
GSimpleAsyncResult, and hence, alive enough time. The GSimpleAsyncResult is
completely disposed only after the async call is fully completed.
Same reasoning behind the GVariant returned in the AT sequences; it should not
be owned by the caller, it's a transfer-none in introspection terms.
We provide the result of the +COPS=? parsing in a GList of MM3gppNetworkInfo
structures. We avoid the previous hash table, or using a dictionary, as a
list of structs with a predefined set of elements, which should be easier for
plugins wanting to make their own version
Running a CS/PS registration check may not return any direct result (this is, no
MMModem3gppRegistrationStatus returned), as usually replies to +CREG? and
+CGREG? are parsed as unsolicited messages.
The 3GPP registration state will always be set from outside the 3GPP interface,
for example when parsing unsolicited registration messages, on when the
interface requests manual checking of registration state.
We'll also update the State property in the Modem interface when we switch to a
connected state, so we also set the Modem interface as a prerrequisite of the
3GPP interface.
Some states need to be set from outside the scope of the Modem interface, like
Registration-related ones (REGISTERED, SEARCHING, ...) or Connection-related
ones (CONNECTED, ...).
When the port is grabbed, we setup NULL callbacks for all unsolicited
registration message handlers. If we do enable 3GPP registrations
afterwards, we'll set proper callbacks.
Existing unsolicited message handlers can be overwritten at any time now. This
allows initializing the port with all possible message handlers configured with
a NULL callback, and then setup the proper handlers when we go on enabling the
different interfaces.
