The UI can also be invoked without interaction from the connectivity library. In such cases the 'Select connection' dialog is requesting ICd to provide it with and updated view of available networks. ICd will provide the UI with an up to date view of the networks. It is up to the UI design wheter service level ("hotspot") connections are shown with the associated physical networks or wheter the service level connections are collapsed into one entry only. From the displayed connnections the user selects one which the UI requests ICd to try to establish. The connection request to ICd is done using the same methods as are available for the connectivity library.
The request is passed to the policy API (TBD) that will add one or more candidate IAPs to the request data structure. When the policy has been satisfied, the candidate IAPs are tried one after another with the first successfully established IAP getting selected and any other IAPs removed from the candidate list.
When the IAP has been disconnected, the request data structure is deleted.
See also Connection request.
The status callback functions for each icd_nw_api level can report success in two ways, either with ICD_NW_SUCCESS or ICD_NW_SUCCESS_NEXT_LAYER. ICD_NW_SUCCESS allows ICd to search for another network module with lower priority that also provides an *_up function for the same layer as the callback. With ICD_NW_SUCCESS_NEXT_LAYER the module can force ICd to go directly to the next layer above the one whose callback just got called. When ICD_NW_RESTART is reported, the IAP will close down and then immediately created again.
Disconnecting an IAP happens when the status callback reports error or when the network module spontaneously needs to bring down a connection using icd_nw_close_fn(). The latter case is reserved for a connected IAP; while the IAP is being connected the callback is the preferred method for reporting an error event leading to disconnection. When disconnecting, link_down, link_pre_down and link_down icd_nw_api functions are called in reverse order for those modules whose respective _up functions got called on connect. Has the module not yet called the given callback when disconnect is started, the _down function for the respective level and module will be called.
See also IAP connection abstraction.
See also Network scan and scan result handling.