Hi,

1. That advice might have been old, the current default value is false. Depending on the Android environment the decoding of the Value tags within NodeSet XMLs (loaded on the server side) might not work, that flag that flag skips parsing of them. This is explained in the README-android.txt, copied below:

“NOTE: In the Server side, when NodeSet XMLs are parsed, the Value tags are parsed using com.prosysopc.ua.stack.encoding.xml.XmlDecoder that uses javax.xml.stream.XMLStreamReader.
Android has XML library limitations, you might need to call ModelParserBase.setSkipValuesOnAndroid(true) (the Value(s) are skipped) or somehow provide that
javax.xml.stream.XMLInputFactory.newInstance() works and javax.xml.stream.XMLInputFactory.createXMLStreamReader(Reader) returns a XMLStreamReader. If you use the ModelParserBase.setSkipValuesOnAndroid(true)
and the Values are skipped note that this includes the InputArguments and OutputArguments of OPC UA Methods defined in the model and thus they wouldn’t work for Clients.”

2. Both are related to support for custom Structures. We need to read a lot of metadata from the server in order to support them. Since we are already reading a lot, it will read the rest of the Types as well, since doing it in connect can be optimized (Read/Browse can be done in bulk).

So, basically you would set those 2 to false, if you know for sure that you do not need support for custom structures. It would skip reading the Types part. Though, an additional side-effect is that once you do anything with UaNodes we will make about 100 calls to the server to read the types part anyway (which is not needed if we managed to already get it during connect). This is inverse-Browse due to how it works and cannot be bulk (but the requests are small).

In the past com.prosysopc.ua.typedictionary.TypeDictionary had to be used manually, but starting 4.0.0 it happens by default automatically, client.setInitTypeDictionaryAutoUsage(false); would retain previous functionality. This must be set before calling connect(), after that it only happens if you would call disconnect and then connect again. In technical terms, this sets (in 5.0.0, skipping older explanations) com.prosysopc.ua.stack.encoding.EncoderContext.setDynamicDataTypeSpecificationProvider(Function) to ask the TypeDictionary if it is not found within the context.

The client.setInitTypeDictionaryOnConnect toggles is com.prosysopc.ua.typedictionary.TypeDictionary.init() called as part of the connect. IMPORTANT! If false, then it only inits on the first (manual call to) TypeDictionary.decode/binaryEncode (and .refresh). That doesn’t happen automatically, i.e. it doesn’t init itself when a unknown Structure is encountered. WARNING, doing the init outside of the connect can potentially be dangerous, because depending on the server you could see an equivalent stop in communication you saw during connect if set to true. For example, any Subscription might not get data, or might end up being deleted by the server depending on the implementation. Servers made with our SDK are most likely ok, assuming beefy enough hardware, as it processes requests in parallel, but some servers might not do that and might be blocked the init (and if that lasts longer than the lifetime of a subscription, the server might end up deleting it itself before it interacts with it).

If client.setInitTypeDictionaryAutoUsage(true) and client.setInitTypeDictionaryOnConnect(false), note that com.prosysopc.ua.stack.encoding.EncoderContext.getDataTypeSpecification(UaNodeId) for custom structures will only work for 1.04 Servers supporting DataTypeDefinition Attribute until the TypeDictionary is initialized manually.

So basically what the TypeDictionary.init() does it read/browse(s) all Types. Then it checks can it resolve all non-Codegen-unknown DataTypes into UaDataTypeSpecification via the 1.04 DataTypeDefinition Attribute. If not, it will read the older pre-1.04-DataTypeDictionary system and resolves them that way into UaDataTypeSpecification. The latter part is not very optimal, the old dictionary format is a complicated XML document combined with info from the nodes, and it is basically not possible to do it individually to a type, you must read all of them at once. Also, it is impossible to figure out does a server support 1.04 DataTypeDefinition for everything as far as I’m aware, other than reading all DataTypes and see if it had that for everything, in which case the dictionaries can be skipped.

Skipping some of the other details, but that is the short explanation.