Typically, for unordered data, CompositeDecoder is used by a serializer withing a decodeElementIndex-based loop that decodes all the required data one-by-one in any order and then terminates by calling endStructure. Please refer to decodeElementIndex for example of such loop.
decode* methods have
serialDescriptor parameters with a strict semantics and constraints:
descriptorargument is always the same as one used in Decoder.beginStructure.
indexof the element being decoded. For sequential decoding, it is always a monotonic sequence from
descriptor.elementsCountand for indexing-loop it is always an index that decodeElementIndex has returned from the last call.
The symmetric interface for the serialization process is CompositeEncoder.
Not stable for inheritance
CompositeDecoder interface is not stable for inheritance in 3rd party libraries, as new methods might be added to this interface or contracts of the existing methods can be changed.
Method to decode collection size that may be called before the collection decoding. Collection type includes Collection, Map and Array (including primitive arrays). Method can return
-1 if the size is not known in advance, though for sequential decoding knowing precise size is a mandatory requirement.
Checks whether the current decoder supports strictly ordered decoding of the data without calling to decodeElementIndex. If the method returns
true, the caller might skip decodeElementIndex calls and start invoking
decode*Element directly, incrementing the index of the element one by one. This method can be called by serializers (either generated or user-defined) as a performance optimization, but there is no guarantee that the method will be ever called. Practically, it means that implementations that may benefit from sequential decoding should also support a regular decodeElementIndex-based decoding as well.