UnityEngine.Windows seems entirely undocumented but also not useful. Should developers be using it yet?
It doesn’t exist for Android builds, so I still need to preprocess out either System.IO or UnityEngine.Windows. Since I’m already preprocessing things, why would I use UnityEngine.Windows for a WinRT build rather that the WinRT ones?
Well, partly because the interfaces for the System.IO and UnityEngine.Windows API match - the only place you’d have to use the preprocessor would be at start of the file:
#if UNITY_WINRT
using File = UnityEngine.Windows.File; #else
using File = System.IO.File; #endif
You can always use WinRT APIs if you want to, but it will not be as straightforward as using the ones Unity provides.
As for the documentation, they are fully documented:
I guess by undocumented, I meant example use cases or what is gained by using it. Also, does the documentation point out that it only exists for some platforms?
Had this similar discussion about the MD5 support… I personally thing it would be better if Unity would actually just use the same namespaces and class names as long as the interfaces match. Why not just use System.IO.File? I suppose it may be to provent future breaks if for some reason Microsoft added support, but then again it would allow developers to code once (without the pre-processor directives) and not have to use two different implementations.
Well, actually we do that in WinRTLegacy.dll, but we haven’t implemented everything yet. The UnityEngine.Windows was added for those methods that many people already used in their code and we needed a quick solution. And since by adding it we modified public API, we cannot remove it that easily.
I still don’t understand why System.IO is supported except on one of the platforms where it should work best.
ps
I’m replying now because this undocumented (as in ‘why does this exist at all’) Unity quirk just cost me more time and while searching for help, I hit upon my own thread.