You may find this interesting regarding HashMaps that I think are used to store all Maps in HE's state fields. (Never knew there where so many map types in Java/Groovy)
You will need to use a different container. The very nature of a hashmap implementation all but guarantees that the original order will not be preserved
As the documentation clearly states, HashMaps are unordered.
The enumeration order is determined by the hascodes of the keys.
If you want to preserve insertion order when enumerating the map, use LinkedHashMap. If you want enumeration order to follow the natural ordering of the keys, use TreeMap
So that brings me to requesting support for TreeMaps in State. LinkedHashMaps would also work since the map is built in sorted order.
I don't fully comprehend how state is handled in HE other than state itself is a hashMap and is stored in the HE database when the task completes.
You mention maps are converted to a string in state. So if that string includes the original Groovy/Java map type versus saying it was a generic Map, it should be trivial to create the original map type rather than make all returned maps, HashMaps.
Should none of this be possible, please allow Hub Variables to be > 255 bytes. That's what got me down this rabbit hole in the first place
Assuming I have a very large collection, hundreds each perhaps a hundred bytes long, of named data codes that are stored in state, I simply wanted to view them on the device page state fields in some rational ordered manner.
Also wanted to share the codes as a cache in a non parent app child device situation, but hub variables are limited to 255 bytes.
I understand the device interface and page was not designed to be a visual interface for the stored data, but the page does function as a visual interface.
I'm assisting someone who is writing the app and devices. It's easy enough to get the codes from a device to a non parent app by defining the device to the app, but I don't know how to have a device get data from a non-parent app other than perhaps using a hub variable or file.
We gave up on hub variables (too small) and files (no system provided interface), and having the non child devices use a app based cache. So to make things easier for our testing and debugging we decided to sort the device's codes to make it easier to see what was going on, then we bumped into all state stored maps become HashMaps.
Well I learned a lot more about maps than I expected, so that's a good thing.
About sorting state based maps: That is done for UI purposes at the point where the map is presented, presumably in an enum or a table of some sort. That being said, there really is no reason to need to keep a map sorted in state.
App to app is easy, and app to child is easy, and child to parent app is easy. You can use location variables as a means of app to app communication. So device makes a request of its parent app, and that makes a request of the other app...
I understand this was mainly for visual confirmation when looking at the large lump of data on the device page. So we sorted it, and honestly were surprised when the order changed after it was stored then viewed the next time. It has no impact on the function. Creating a HashMap explains why it happens.