I've got quite a developed app that I feel is getting close to being too big for managing in App Inventor, but it's still working. For reference, this is the scale of the blocks:
I've just amended one of the core functions of the app with some snippets I've developed separately. The new code is working well and appears to have integrated properly. However, in that process, I've obviously stuffed something up. Problem is I'm pulling my hair out trying to find it. Maybe a lack of sleep.
On app startup i'm getting this list/index size error:
If I click away from this box, the app resumes and runs as expected. That's the first part I don't get.
The second part is trying to find what's causing this error. I pretty sure I don't index "11" specifically, so I'm presuming it's a programmatic "11". I've tried disabling sections of code that might have anything to do with lists, including some Bluetooth functions, but I can't seem to narrow down where this error is being generated.
Because of the external hardware connections (to ESP32), my testing is all done by building the app and running in the actual phone.
Could I get some guidance on how to narrow this down? I'd thought of inserting a blocking code function at various places to narrow down the function/call section. Or perhaps there's a way I can review the code outside of App Inventor.
You seriously can't get your head around the question I asked?
I didn't ask for a specific solution to the issue. I explained this. I asked for guidance on strategies to narrow down my search for the error - suggesting at least one possibility that may or may not be of use.
Strategies are not the same as solutions. They can be completely independent of the framework in which we're working here.
Because you don't want to show your (relevant) blocks, we should work out strategies where possible causes for a certain error could lie. A bit much to ask and also more than unnecessary for my taste.
Okay, so here's where my question about strategies starts making sense.
I have no idea of where I need to be looking. I've explained that I've looked in obvious places, but nothing stands out.
One of the first strategies I'd typically enlist is to narrow things down a bit. If I can do that, I'll be avoiding th need to share with you 100's if not 1000's of blocks. You probably also get a bit upset by that also.
I had suggested a simple form of blocking code so I could at least time-out what portion of the initial code might be the culprit. That's one strategy I thought of, but someone might have a view on that or a better idea.
Appreciate that solving people's problems directly by critiquing and supplying code/blocks to solve their issues might be where you get the most reward. Maybe you are not the right person to help in this instance.
Thank you again @Anke and @ABG for your input here.
I have tried the adb logccat approach. I'm not sure i'm seeing anything that gives me a clue as to what is going on. i.e. I'm not really sure what i'm looking at.
I've tried checking all the clock timers being enabled - nothing that I can see. I did play with the timing of one timer and I can't be certain, but I think it created an intermittent error. Sometimes the app would load without error and sometimes not. I would "close all" apps from android in-between.
What I have done is what I originally suggested and used a naughty code block. I call a procedure on the very first line of Screen1.Initalize to block the initiation of the main code:
This "fixes" the problem, but it doesn't help me understand why.
I still suspect it may have something to do with clock timers or timing. I recall earlier in the process of developing this app that I had a problem with timing: Slider Position on Startup - #14 by foetusmachine
I wonder if there's something about the way the app compiles and is executing my sequence of blocks that isn't ideal.
Thank you @ABG. With me going over my blocks and simplifying everything and then implementing some list length checks (as you so humorously, repeatedly, but appropriately suggested), I've been able to resolve the issue.
Looking back, however, I still can't quite understand the error I was getting in the first instance - I suspect the problem was my TinyDB took its time to load data into the problematic list. The 2-second delay I'd implemented was enough for the system to sort this out - ultimately though, not a very nice solution.
The error checking i've implemented checks each of the lists for correct length before allowing code to proceed to utilise the lists. The real offending list was global "decData" that was being referenced in the "LatLongLookup" procedure. Now I only call "LatLongLookup" if all lists are of the correct size:
The tests for globals "LongList" and "LatList" are perhaps superfluous because I define these as "constants" for want of a better term, but hey, to be sure, to be sure.
