Lots of users of WinDev Mobile complain about the differences in behavior between an execution of their app in the emulator and on the final device (android or iOS or …). We should all in fact marvel at the fact that it’s possible for us to have an emulator at all, and we should certainly understand WHY there are differences and why PCSoft can rarely do anything about them.
Let’s have a look:
The emulator is in fact the wLanguage code being executed inside a WinDev virtual machine under Windows, just like a GO inside WinDev (not mobile). There is no other solution because the emulator is running under Windows and an Intel like processor, and there the WinDev DLL must be used. Of course, these DLLs are C code compiled for Windows, with all the limitations and constraints that come with that.
On another hand, when running on any android hardware, telephone or tablet, that wLanguage is executed by a virtual machine written in JAVA and running on a completely different ARM processor. Clearly, the limitations and constraints of that environment are completely different and WILL cause some things to behave differently.
Of course, the emulator contains specific code trying to make everything behave the same way than on an ARM, but it’s just not possible to close down any differences. One good example is all the different syntax available for an instruction: some are for WinDev, other for WebDev, other for Android or iOS, and generally, the options available are fewer for android than Windows.
So, as a result, if you use one of the syntax working only under windows and PCSoft did not plug that specific hole by adding a control on it, it will work in the emulator, but will generate and error when run on Android. And as this error is an execution time error, you typically get an obscure message coming from java saying “huuuuh? WTF are you trying to do here?”
This is a point that PCSoft could improve by adding a control about that syntax in the compiler (and will probably in the next version). However, considering the number of instructions available in wLanguage and the number of syntax available for each of them, it’s no wonder that some control are and will be missing. So RTFM.
Another big difference is that by default, Windows works in ANSI, while Android works in UNICODE and iOS in UTF8/UNICODE. Why is that a problem?
- Because all the “system” function, like by example a fListFile, or an iniRead, will return a value in a different charset depending if they are executed in the emulator (windows) or the hardware. When you use that value, if you don’t understand that fact, you are in trouble.
- Because when you declare MyString is String, you are declaring an ANSI string in the emulator, and a UNICODE one when running in Android
- Because when you simply use a literal string in a function, by example myFunction(“MyString”), and it doesn’t matter if the function is from the wLanguage or written by you, then “MyString” is an ANSI string in the emulator and a UNICODE one when running on the phone.
- Because when you communicate between an app and a webservice, in the emulator both sides are speaking ANSI, but when running on the phone, one is ANSI and the other UNICODE
This point can be solved easily BY YOU:
- By declaring all string as either ANSI or UNICODE, but NEVER as simply STRING.
- By NEVER using literal strings or directly the result of a function, but instead by always storing your string values in specifically declared strings, either as ANSI or UNICODE, depending on your need.
- And by always understanding what type of data you are dealing with.
Another big difference is of course the presence or not of some hardware component: Clearly, the emulator will NOT be able to end a phone call when it doesn’t have a cell phone component available, the same is true for battery power value, or anything hardware related. There will be NO miracle there.
Finally, not ALL controls that are available in WinDev are available in Mobile, and even if they are available, they are also most of the time LESS powerful, with less options, and sometime with a different behavior specific to the target OS (list or looper behavior are different on Android and IOS that they are on Windows). So something working in the emulator (a WinDev virtual machine) may not work on the phone or tablet simply because this specific set of options is NOT available for that target (and an option can be available for Android but NOT for iOS, due to OS or Processor or compiler differences). Yes, PCSoft could improve the situation here by adding more controls, and they are doing that with each compiler versions, but the sheer number and complexity of options available is working against the possibility that they’ll ever catch them all. So, once again RTFM, as all the options are described in the help and defined as not working here and there.
So, what use is the emulator if we have these restrictions? Simple: let you save time. Look at it as a rapid prototyping tool. Create your windows, test them in the emulator for look, size and placement of fields, and also for a quick functional test of your code.
If you need something that is hardware related, then put it inside a if NOT inTestMode() then… End, with an info message instead.
And as soon as things look good and are working in the emulator, do the REAL testing on your hardware.