Made WifiDirectService into an actual service in order to better process
incoming packets. Now works for game messages from comms, and posts
notifications when app's in background. The latter requires using the
app context from XWApp since unlike the other transports this one
doesn't involve the OS invoking us with a Context.
Got to the point where I have an open socket for the packet I want to
send! Lots of changes to how discovery works seem to have improved
reliability though I'm still unimpressed. Much to learn.
Grab and store the local device's mac address. Add p2p as a type of
address, represented by the mac address of the recipient. Include the
local device's address in invitations sent when specified by user. Now
the WifiDirectService class is being passed a packet and the address of
the recipient; it will next need to set up sockets with every device it
encounters and map them to their mac addresses so that it can do a send.
Starting with the release of Nougat there have been cases where the
board would not correctly redraw. It's been most evident when using the
hit feature many times in a row, with something going wrong every fifth
time or so (but not that consistently.) It's as if modifications of the
bitmap backing BoardCanvas were being done asynchronously and not
necessarily all completed when I blit the canvas to the screen via
canvas.drawBitmap(). (As evidence of this I confirmed that a tap on a
tile in the tray after a bad draw would cause the screen to correct
itself even though the only additional rendering was to the tray. So by
the time that second drawBitmap() call happened the bitmap data was
correct: all draws that hadn't completed earlier had done so by now.)
The fix is to call Bitmap.createBitmap(bitmap) and to use the copy as
the source of the canvas.drawBitmap() blit operation. I suspect that
createBitmap() waits for any pending draws into its source to complete
before making the copy. Regardless, if this hasn't fixed the problem
it's made it so rare that I'm not seeing it, and since I'm only doing
the copy on Nougat there's little risk in the change. And I can't detect
any problems coming from the considerable additional memory being used
and immediately marked available for gc.
commented-out logging of drawCell, with flags; debug-build checks that
static rects passed to java draw code aren't being used by multiple
threads at once.
Current code is hitting the relay every 60 seconds, at least on
non-google-play installs like f-droid. Switch to using a backoff timer
that maxes out at once per hour. Eventually may want to not run the
timer at all when there aren't any unfinished relay games present.
Now sends and receives a single packet more often than not. Disabled for
non-DEBUG devices, and new permissions that are required are commented
out so I don't accidentally ship before the sdk-23 permissions stuff
makes additions less scary.
Disabled at compile time, and missing permissions required, but if
enabled is able to discover other devices running same app. Next: try to
open a socket.
Crash occurs when creating new game: because there's no turn set yet the
jboolean has no set value (whatever was on the stack). Apparently the
java runtime accepts only 1 and 0 for jbooleans.
Crash occurs when creating new game: because there's no turn set yet the
jboolean has no set value (whatever was on the stack). Apparently the
java runtime accepts only 1 and 0 for jbooleans.
This completes moving to using traditional logging. At least to having
each file provide a TAG. Class rather than TAG is passed in, and format
strings are preferred to contatenation, but now adb can work with the
output.
I think this was related to changing the order in which save operations
happen and that it's no longer valid to insist that there already be a
rowid at this point, but could be wrong....
Fixes problem with list view always being a move behind, since it's
saving not summarizing that was triggering the refresh, but summarizing
that added the data from which refresh/list view drew.
Idea is to have the games list stay in sync, but in fact it stays one
move behind, at least in a typical standalone human-vs-robot game. So
this is incomplete.
There are some screen dimensions, especially with dual-pane mode, where
the board is just bit narrower than the screen. Rather than have narrow
white borders, allow the cells to take up the slack. The API takes an
upper bound on the ratio of width to height so things shouldn't get too
odd looking.
Running into a case where views haven't been added to the layout yet but
I'm searching there for their associated fragments. Fix to NPE stops a
crash, but intents still aren't being handled. I need to try to handle
them later, but am unsure when to start trying.
Mistaken option to gtk_box_pack_start() meant the scrollbar got
allocated space along with the board when the container expands, not
what you want with a scrollbar.
Too-clever double loop had an no-exit path. Now it's simpler: find a
fragment that can handle the intent, pop all fragments to its right
until it becomes top-most (there may be none), and then give it the
intent. Use of popBackStackImmediate() is required so old fragments are
gone before intent handling wants to create new ones.
Since display is now by whose turn it is and how recently there's been a
move in the game, the order can change on every save. So in the listener
for saves, redraw the group the saved game belongs to. The best way to
do this without flicker seems to be to mimic closing then re-expanding
the group, so that's what I'm doing.
