Help needed, app exits when displaying a new screen

[DanMacLeod]

I have a published app 'Scuba Buddy' that seems to be acting up ever since my ionic's firmware was updated to OS 3.0. The app runs fine on the simulator but fails on my ionic. I already did a factory reset on the ionic but that didn't help.

For some reason the app exits when I try to change screens.

1. Open app to display a panorama view
2. Swipe screen to display second panorama view image "ACTL"
3. Tap image on screen, this should show a Virtual Tile list, but app exits instead

When the image on the screen is tapped, the actlImage.onclick() function, shown below, is called which calls the showActlScreen() function, shown below. The showActlScreen() builds a Virtual Tile List, then hides the panorama view and displays the actlScreen that contains the Virtual Tile List.

Looking at the attached log, the first time I run the app the log displays my log messages: 'A' ''1' '2'. If I restart the app the log displays my log messages: 'A' '1' '2' '3' '4' 'B'. This seems to be consistent. The only thing I can think of is I have an issue the way I'm hiding/showing screens but the log doesn't show any exceptions.

Any suggestions on how to troubleshoot this or the possible reason for the issue?

actlImage.onclick = function (evt) {
  console.log("A");
   showActlScreen();
  console.log("B");
}

function showActlScreen() {
  console.log("1");
  buildActlGasTable();
  console.log("2");
  panoramaScreen.style.display = "none";
  console.log("3");
  actlScreen.style.display = "inline";
  console.log("4");
}

[9:32:02 AM]Launch complete - durations: foregrounding(4807ms), first paint(25ms), total(4835ms).app/index.js:381,1
[9:32:09 AM]A app/index.js:142,1
[9:32:09 AM]1 app/index.js:144,1
[9:32:09 AM]2[HOST]
[9:32:10 AM]App closed on device, unloading companion in 3 seconds…[HOST]
[9:32:13 AM]Unloading companion…[HOST]
[9:32:15 AM]Companion unloaded[HOST]
[9:32:19 AM]Loaded and evaluated: file:///android_asset/bootstrap.js[HOST][9:32:19 AM]App Startedapp/index.js:72,1
[9:32:19 AM]Error: Couldn't open file: app/index.js:82,1
[9:32:19 AM]Error: Couldn't open file: [HOST]
[9:32:19 AM]Launch complete - durations: foregrounding(974ms), first paint(26ms), total(1011ms).[HOST]
[9:32:19 AM]Loaded and evaluated: file:///data/user/0/com.fitbit.FitbitMobile/app_companions/4310fe3d-657a-492d-bc18-16b1d95de37d/0x0f12f84e88637d37/companion.js[HOST]
[9:32:19 AM]Companion launched by [launchedOnTracker]app/index.js:381,1
[9:32:24 AM]A app/index.js:142,1
[9:32:25 AM]1 app/index.js:144,1
[9:32:24 AM]2 app/index.js:146,1
[9:32:24 AM]3 app/index.js:148,1
[9:32:24 AM]4 app/index.js:383,1
[9:32:24 AM]B app/index.js:385,1
[9:32:24 AM]App closed on device, unloading companion in 3 seconds…[HOST]
[9:32:27 AM]Unloading companion…
[HOST][9:32:33 AM]Companion unloaded

[DanMacLeod]

UPDATE:

After doing more research, the problem seems to be in the Virtual Tile List delegate. My virtual tile list contains 21 items but the configureTile function is only called for a portion of them.

You can see in the log that the dataSet has a size of 21, but the log also shows the 'configureTile' function was only called for 9 tiles.

The other thing I noticed is the list seems to work the first time the app is side loaded on my device, then does not work after restarting the app. I'm sure it's something I'm not doing correctly but at this point I'm lost.

DELEGATE FUNCTION

function updateActlTileList( data ) {
  console.log("DataSet size: " + data.length );
  actlTileList.delegate = {
    getTileInfo: (index) => {
      //console.log("RRR " + index);
      const poolType = (data[index].type === "header") ? "actl-header-pool" : "actl-item-pool";
      return {
        type: poolType,
        data: data[index],
      };
    },
    configureTile: (tile, info) => {
      if ( info.data.type === "header" ) {
        console.log("HEADER");
        tile.getElementById("actl-header-1").text = info.data.text1;
        tile.getElementById("actl-header-2").text = info.data.text2;
      } else {
        console.log("ITEM");
        tile.getElementById("actl-item-1").text = info.data.key;
        tile.getElementById("actl-item-2").text = info.data.val;
      }
    }
  };

  if ( actlTileList.length != data.length ) {
    actlTileList.length = data.length;
  }
}

LOG SNIPPET

[9:23:05 AM]Launch complete - durations: foregrounding(4754ms), first paint(27ms), total(4798ms).app/index.js:321,1
[9:23:12 AM]DataSet size: 21  app/index.js:333,1
[9:23:12 AM]HEADER app/index.js:337,1
[9:23:12 AM]ITEM   app/index.js:337,1
[9:23:12 AM]ITEM   app/index.js:337,1
[9:23:12 AM]ITEM   app/index.js:337,1
[9:23:12 AM]ITEM   app/index.js:337,1
[9:23:12 AM]ITEM   app/index.js:337,1
[9:23:12 AM]ITEM   app/index.js:337,1
[9:23:12 AM]ITEM   app/index.js:337,1
[9:23:12 AM]ITEM   [HOST]
[9:23:12 AM]App closed on device, unloading companion in 3 seconds…

[Gondwana]

I'm experiencing something that could be related.

App was working fine on all devices prior to OS 3.0.

Now, TileListItem.hide() causes an app crash (with no error messages) on a physical device, but is fine in simulator.

Note that I'm using a TileList and not a VirtualTileList, but the parallels are still spooky.

My TileList has 24 items. I'll drop it back to 9 and see if it behaves better...

[DanMacLeod]

My app also worked on a prior OS version, it was using a ScrollView with 90 items. I originally thought it might be the ScrollView so I changed to a Virtual Tile list hoping it would fix the issue, but it didn't. The problem is no exceptions are thrown so it's very hard to find the actual cause.

[Gondwana]

I managed to narrow the problem down to TileListItem.hide(). The only thing I could be doing wrong there is by calling the function with an invalid TileListItem; I'll investigate this possibility today. Based on your findings, I'll also experiment with a shorter TileList and targeting an earlier OS version.

I realise that you're not necessarily using .hide(), but the problem could be in some common code used internally by .hide() and whatever's causing the problem for you.

[DanMacLeod]

In order for me to get around the issue I had to hardcode my list instead of building it dynamically. So, now I'm using a ScrollView with a hardcoded list instead of building a VirtualTileList.

[ObSkewer]

Yes, I was seeing this a few nights before your post - https://community.fitbit.com/t5/SDK-Development/Example-for-VirtualTileList/m-p/3141914/highlight/tr... and the couple of replies to myself higher up in that thread.

I had to make the pool larger in my own app before the whole vlist would be configured - I kept being limited to the number of tiles I had defined in the pool. Strangely, I could make a sample I cobbled together work perfectly with only a few pool tiles, but my own app refused to work properly until I increased the pool size (and I have had to increase it slightly more since then, as I have added more vtiles...).

[Gondwana]

I've given up trying to salvage my problem child. However, I'll throw in a few things I've learnt along the way...

console.log() output doesn't always appear. When in a tight loop, it doesn't seem to keep up and some lines of output can go missing. Ergo, you can't always rely on it to follow the flow of execution.

File IO on .json-formatted files consumes way more memory than the size of the file (presumably due to buffering). .cbor is much more efficient.

getElementById() consumes a fair bit of memory (approx 150-200 bytes). In a tight loop (eg, when populating tiles), this can add up rapidly. Garbage collection tries to kick in when required to release some of this memory: you can get a pattern of gradual free mem reduction, then a step increase, then further gradual reduction, etc. However, sometimes garbage collection doesn't kick in fast enough, and the app dies from OUT_OF_MEMORY (although sometimes this isn't announced: the app just closes).

Garbage collection can be 'encouraged' by using a function to whittle down memory in a setInterval() loop. The interval seems to allow the OS/Jerryscript more opportunities to do its thing, which it doesn't get in a tight loop. (This is a bit conjectural/anecdotal.)