Windows Store - XmlReader

I have an App that among other things gets information from a central server in XML format. This is working fine on iOs, Android and Windows Standalone. I need a Windows Store version too though. (Windows 8.1)

In Unity 4, I was able to just disable the .net fx core limited api, but this seems no longer possible in Unity 5 (.2.1)

I’ve made a switch based on NETFX_CORE where needed and this works fine, except for XmlReader.

In the manual it says WinRTLegacy.Xml.XmlReader is “compatible” with System.Xml.XmlReader. It’s however not exactly the same it seems and there is no help on WinRTLegacy.Xml.XmlReader at all. Is there anyone that knows anything about the differences between WinRTLegacy.Xml.XmlReader and System.Xml.XmlReader?

You can still disable .NET core and compile everything using Mono, but that won’t make things magically work. Instead of compilation errors you’ll get errors at runtime. So I advise against it.

XmlReader from WinRTLegacy does not have support for DTD, XML Schema and XPath. Other things should work.
You can also try using System.Xml.Linq.XDocument, which has similar API.

With Unity 4 I was able to have it running as Windows Store App using System.Xml.XmlReader. So no runtime errors then.

Our XML’s don’t use DTD, XML Schema or XPath. The difference probably lies in when to move to the next element. I’m not a big fan of the way this works in System.Xml.XmlReader anyway. Too much need to force it to continue to the next element.

For our purpose I’d prefer something like SAXParser in Java. The information just poors in and you use it if you need to.

I’ll have a look at XDocument. Too bad that it will require some rewriting in quite a few places, but at least then it’s the same for all platforms.

I’m done rewriting everything to Linq. But the results are very far from the results in the editor and on other platforms. Are there significant bugs in Windows Store publishing in Unity 5.2.1f1?

Things seem to behave just randomly. One example is the user/password field I have. The user field initializes with:

userTextField = new VMFGUITextField(style, PlayerPrefs.GetString("username"), textHeightMedium, false);

As you see it takes the initial user name from the player preferences. After a successful login I call:

PlayerPrefs.SetString("username", login.email);
PlayerPrefs.Save();

All very simple code which worked fine up to now. The class PlayerPrefs isn’t used anywhere else in the project, but I just had my password appear as the stored username from PlayerPrefs on a Windows Store build. Other parts also seem randomly broken all over the place.

(And before the actual login is attempted it does this, so userTextField and login.email are actually related.)

login.email = userTextField.GetText();

On one occasion it actually combined the username and password separated with a newline and displayed that as the username. Other issues do seem to be fixable, so I’ll zoom in on this later. Since it’s random it sounds like a timing issue, so that will be the focus.

Not that we’re aware of.

Probably the easiest way to find out what’s going on would be to use VS debugger. It’s pretty much impossible for us to tell without having a project and debugging locally.

I understand. It feels unlikely to me that I’m somehow storing the password and username in the same variable, but I’ll have to look into that.

There was some weird camera movement going on too, but I traced that to the xbox controller laying upside down next to my computer. Somehow those inputs were rejected in the editor, but not in the Windows Store build. That made it a bit confusing.

Edit: It was the on screen keyboard. I’ll need to do some final testing with it, but at least in Unity 4 there was a difference between the way to use the on screen keyboard for WSA. You have to explicitly make it visible through keyboard.active = true, while this is not needed (or possible) on Android or iOs. The keyboard input somehow copied the contents from one textfield into the other. (Not that there was a visible keyboard, but that’s probably because I’m on Windows 10 and not running in tablet mode.)

It would be great to have a more uniform approach to the usage of the on screen keyboard. It would also be great to not be able to obtain the bounds of the on screen keyboard, but instead obtain the bounds of the remaining screen space. (So you don’t have to manually determine on which side the keyboard is.) A final thought is that you do want to know whether you are in tablet mode or not on Windows 10 and let your App respond to this. I would post these as feature requests, but they wouldn’t get any votes anyway. These small features rarely do.