Debugging Guidance (List Index Error)

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.

Your first block photo is way too blur, please upload a clear one.

I didn't intend to share the full code - that image was to highlight how much code there was.

I'm not really looking for a specific answer to find the solution - more I'm looking for strategies to help me to work though the issues myself.

You can't find the error yourself and expect us to puzzle (without seeing any blocks) as to what the cause could be. Seriously?

1 Like

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.

1 Like

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.

Again, looking for strategies.

So here is my "strategy" for you:

Thank you. This sounds interesting. I'll try tomorrow.

Start with the Clock timers.

Since the error happens at startup, is any clock timer left enabled in the Designer, running before necessary initialization?

Are all list select blocks guarded by list length checks with notifiers?

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:

blocks (56)

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.

Then one of the components does it.
Logcat is best option in this case if you don't have any programming knowledge.

I've been reviewing and cleaning up my code to simplify things as much as possible. In this process I may have narrowed-down the issue.

I have this clock timer enabled and set to 60000ms (60s):

Every minute, I get the error popping up as before:

I've checked the CSV values being returned from the gl1A.html file and these are valid. Refer METRIC RAT AI2 - Location Services with HTML5 GeoLocation

If you'd like to see my glA.html file, please let me know.

These are the blocks that follow:


That's a lot of SELECT blocks with no testing of list length compared to index.

Yes, I've been lucky until now. I think it's time to add a swathe of error testing/checking blocks.

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.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.