Implement Address

[HaukeRa]

Is your feature request related to a problem? Please describe.
All Addresses are represented as byte[] arrays. They are converted to int, whenever a comparision is needed. This can get a little anoying, especially when using the address as a key in a map, as byte[] can't be used as a key.

Describe the solution you'd like
A new type for addresses that implements equals() and hashCode() correctly.
Having a type not only makes handling of addresses easier, one can also add beneficial helper methods (e.g. isGroupAddress, isBroadcastAddress (0xFFFF), toString(--> AB CD), Parcelable, Database table for used group addresses)

[HaukeRa]

Great to see progress here!

Two comments:

1. While a single Integer is definitely more usable than a byte array, it still is prone to errors. An int is easily mistaken for something else and basically needs a consistency check (i.e. valid ranges, reserved values group vs unicast etc.) in every place where it is finally used. When converting it to an own type you only have to check in one place (during construction) and get fail-fast behaviour (also during construction and not when actually using the address, probably somewhere else in the code with no direct execution path between declaration and use). Also it increases readability, compare: Map<Int, MeshModel> vs. Map<MeshAddress, MeshModel>

2. Your practice of deprecating the functions implies that they are still usable. But here most of the methods using an byte array are not used anymore. Simply deprecating the methods could lead a developer into thinking they are still supported. The generated warning is easy to miss. I think in such a case it would be more helpful to actually delete them, as the use of them is effectively broken code. A compile error would be the right hint instead of "silently" compile.

[roshanrajaratnam]

Thanks

1. This was my initial plan, I defined types for each address types etc, however I ended up reverting because it was quite a big change and also considering the data migration required for this. Right now, all the checking is done (Hoping i haven't missed any) within the library just to make easier for the ones using the lib as a whole. I do not disagree with you on this.

2. Well the idea to deprecate things over time is not to break anything overnight for the users whose upgrading and providing time to switch to the non-deprecated functions and as a practice using deprecated functions are never recommended (Although trying to keep things backward compatible). Also all deprecated functions will be removed pretty soon from the lib

[HaukeRa]

1. The changes needed spread through the whole code, true. Maybe its something that can be done in the future nonetheless. Still, not having to deal with byte arrays is a big win already.

2. First I thought you did not implement any compatibility for Deprecated methods, but I figured out for some (most) of them you did. I need to check if I still find the methods that had no compatibility built in to still support the usage of them.

Anyhow: Data migration & deprecation is always tricky ;)