Thanks to some advice I've now been able to connect Memu Play to AI2 using the companion, to facilitate debugging. However, I'm very confused by what I'm seeing, and the whole aspect of debugging appears to be the weakest element of App Inventor 2, despite it intending to be an easy way to get into programming.
For background, I have been a professional programmer, which was for about 15 years some years back, on IBM AS/400 computers mainly. Ie, not a novice at either programming or debugging, but only newly getting into writing apps for modern devices. There doesn't appear to be a 'watch' equivalent or a 'step-through' function, or even a system for defining breakpoints. These are quite substantial deficiencies in my view, grateful for the system though I am.
So, I'm trying to work out where exactly the code I'm writing doesn't behave in the way I was expecting it to. Something that is not clear to me: At what point in the code execution do the values in the 'do it' boxes get set? Here is an example:
So these lines are the individual field validation of each field of a row before an attempt is made to write the record to the database. The first field must be between 1 and 5 characters long, so there is a '>5' and '<1' OR'd together. But why is the field value box on the first instance of Textbox1 "worktidy", and the second instance of the same field it is "" when it appears I'm directly looking at the value of the field itself? In my understanding, these should both be the same, surely?
1). I selected the option via the emulator so that it would execute that section of code during its normal operation. So I selected to see what was in both fields after the code had completed and returned control to the screen.
OK, I've just realised that you have to re-select 'do it' from the left-button menu to get updated values, and I think I selected one of those fields before the first run and one afterwards, which would explain that one.
The code about doing the comparison my way or your way wouldn't make any different to the end result. It's just as valid to do it my way, and arguably better because I'm specifically testing for errors, not correctness, and also, looking for errors fits better into the 'if..then...else' structure mentally. But it's a minor philsophical point.
The "Do it" values do not change automatically when, for example, the value of the label they are on changes... you need to "reset" the Do It so that it shows the new value...
Yes, and it also appears that when control returns to the screen, the current value of a variable / lable text or whatever is not what it was at that point in the code, but what it was by the time the overall code finished executing, so it is still not a good way of finding out what variables contained within them at the time a particular line was being executed.
Can anyone help advise on how to implement a timer so that I can de-facto step through instructions and do some investigation into the state of variables and decisions between each statement while it's running? There's got to be a better way of finding out how values change and which decisions are made as a program runs than this - I've never encountered any programming environment so unhelpful in this regard. Not knowing why your program isn't working as expected and it being difficult to find out is the kind of thing that drives people away.
