namespace <SI-Namespace>::proxy::fields

In module com of the Adaptive Platform, namespace <SI-Namespace>::proxy::fields encapsulates the generated proxy classes <Field> for each data field defined in a ServiceInterface. Client applications access these field classes via the parent service proxy to query or set remote field values or to process notifications about value changes. Calls on fields are likely handled asynchronously via the communication infrastructure to ensure non-blocking interactions. Question (open) The lifetime of the individual field instances is presumably tied firmly to the lifecycle of the parent proxy object and cannot be managed independently of it.

more ›

Context

In module com of the AUTOSAR Adaptive Platform, the C++ namespace <SI-Namespace>::proxy::fields assumes a clearly demarcated structuring function for service-oriented interfaces. In addition to methods and events, service interfaces (ServiceInterfaces) frequently define data fields that represent a current state. To provide these fields on the client side for service consumers in a type-safe and semantically unambiguous manner, the code generator places the specific field classes into this dedicated sub-namespace. Exactly one proxy field class <Field> is generated for each field modeled in the respective ServiceInterface. This structural encapsulation prevents name conflicts with identically named methods or events within the parent proxy namespace. Interpretation: The generated field classes <Field> typically provide specialized interface functions for get, set, and notification functionalities in order to selectively query values, modify them, or receive subscribed changes. Question Q-f088d0c5052459d3 (open) The direct interaction partner of the field classes is the application logic of the service consumer on the one hand and the underlying communication middleware on the other hand.

Lifecycle

The instantiation and management of objects from <SI-Namespace>::proxy::fields is inextricably linked with the architecture of the service proxy. Application developers generally do not create instances of the generated class <Field> manually as independent variables on the heap or stack. Instead, the lifetime of an instance of <Field> is presumably tied completely to the lifecycle of the parent service proxy, which holds these fields as members. Question Q-4da7e86f88f269b1 (open) With the successful construction of the proxy instance after finding a matching service endpoint, the field objects are initialized and placed into an operational state. During the active phase, the field object manages internal communication resources as well as any registrations for state updates. If the proxy instance is destroyed by the application or leaves its scope, the associated field instances are consequently also properly destructed, releasing linked middleware resources.

Usage Path

The typical usage sequence of the classes in namespace <SI-Namespace>::proxy::fields is divided into a fixed sequence of interaction steps. First, the client application determines the instance of the desired service via the search mechanisms of the Adaptive Platform and instantiates the corresponding service proxy. In the second step, the application accesses the corresponding member instance of the generated class <Field> via the proxy. Depending on the properties of the field defined in the interface model, the application then initiates a read access, a write access, or registers a callback for notifications about value changes. Calls on fields are likely handled asynchronously via ara::core::Future or callback mechanisms of the communication infrastructure to avoid blocking calls in the calling thread. Question Q-33586a48d8777f7f (open) After the response or notification arrives, the caller evaluates the returned result and reacts to the state of the remote field.