GameListItem was clearing its summary when kicking off a replacement
load. Instead keep the old around in case somebody wants it (e.g. to
figure out what menus to enable) until the reload finishes.
Also add logging of how long loading takes. I think a cache might be
called for.
Darned thing was dropping packets, failing to connect games built in
response to invitations, and otherwise misbehaving. First was due to not
resheduling when exited with outbound packets in queue; second to not
overriding relayNoConnProc() (due to signature change.) Though it still
happens occasionally.... Also added timestamps to track how long it
takes a packet to be sent and ACK'd.
Not sure why I was doing this, but it's not worth the
trouble (e.g. stopping updates of other data to fix an android bug
sending too many reregistration messages.) So now just use the first
element of arrays, replacing what's there instead of prepending. Ideally
those columns would not be arrays, but that's a harder change.
It's too useful to live without. So: tap into the static list of live
Delegates, and if any of them has an Activity available use it to run
Toast on UI thread. Otherwise there will be no display.
There's likely a bug in Android now where I'm registering over and
over though the fcm id hasn't been changed. That's wrong, but it's
also wrong (and filling up the db) to register a duplicate as if it
were new. So stop that.
My VSIZE is no longer legal, and apparently there's no workaround (no
way to safely figure the length of an array whose size is known at
compile time.) To avoid the risk of duplicating little constants, added
macros that define length in a way a new VSIZE can pick it up. Couldn't
make that work for struct field arrays, however, so there I'm using
constants.
Looks like certain launches that went through DispatchNotify could
create a second "instance" of the app. Giving that Activity a launchMode
of singleTask fixes this (singleTop does not.)
