Add HTA-side implementation of sync-interrupted scenario (HT-508). Also replace deprecated AsyncTask.

[wmergenthal]

Formerly HT sent HTA "sync_success" regardless of whether 'mergeCompleted' was True. Now the False case leads to HTA receiving sync status "sync_interrupted". HTA parses the HttpRequest from HT to extract the status, then informs the user. One new string is added to HTA for the interrupt-or-cancelled case.
Also, deprecated class 'AsyncTask' is replaced with 'Executors' and 'Handlers'.

---

This change is 

---

[tombogle]

@tombogle reviewed 3 of 3 files at r1, all commit messages.
Reviewable status: all files reviewed, 4 unresolved discussions (waiting on @wmergenthal)

---

app/src/main/java/org/sil/hearthis/AcceptNotificationHandler.java line 43 at r1 (raw file):

        //
        // NOTE: like several things in HearThisAndroid, HttpRequest is deprecated. It will be
        // replaced with something more appropriate, hopefully soon.

Options:

• Use HttpURLConnection (built-in JDK/Android)
  → Standard replacement for most simple request/response work.

  • Pros: No external dependency.

  • Cons: Verbose API; no built-in high-level features.

• Use OkHttp (square.github.io/okhttp)
  → De facto standard for Android networking.

  • Pros: Clean API, better performance, supports HTTP/2, widely adopted.

  • Cons: Adds dependency, but well worth it in most apps.

---

app/src/main/java/org/sil/hearthis/AcceptNotificationHandler.java line 49 at r1 (raw file):

        String s2 = s1.substring(s1.indexOf(' ') + 1, s1.lastIndexOf(' '));
        String status = s2.substring(s2.indexOf('=') + 1);

This logic could be done in a less cryptic way:
String s1 = request.getRequestLine().getUri(); // avoid toString() if possible
URI uri = new URI(s1);
String query = uri.getQuery(); // e.g., "status=123&foo=bar"

String status = null;
for (String param : query.split("&")) {
String[] pair = param.split("=");
if (pair.length == 2 && pair[0].equals("status")) {
status = pair[1];
break;
}
}

Alternatively, it could be done very simply with a regular expression. But using URI is probably safer and makes the intent clear.

---

app/src/main/java/org/sil/hearthis/SyncActivity.java line 166 at r1 (raw file):

                                                              socket.send(packet);
                                                          } catch (UnknownHostException e) {
                                                              e.printStackTrace();

In the case of an exception, is there anything else we need to do to give feedback to the user and/or prevent the HTA app from getting stuck in a bad state?

---

app/src/main/java/org/sil/hearthis/SyncActivity.java line 280 at r1 (raw file):

            setProgress(getString(R.string.sync_interrupted));
        } else {
            // Should never happen. Not sure what to do here, if anything...

For the sake of future proofing, we should probably handle any unexpected message by letting the use know that they are probably using a version of HTA that is not fully compatible with HT desktop. Then probably we should treat it similar to the "interrupted" case, since we probably can't safely assume it was completed successfully.

[wmergenthal]

Re comment 1: thanks for suggesting some options. OkHttp certainly looks compelling.
Re comment 2: addressed in 3727d83.
Re comment 3: currently working on this one.
Re comment 4: addressed in 399e532.

[tombogle]

I wonder if we should display a different message in the case where we get an unexpected status message. I assume the processing should be the same (since we can't possibly know how else to interpret the unexpected message), but if this ever happens, we could give the user some indication that we got an unexpected message and suggest they check for an update. We could even include in the query (from HT) an indication of the minimum version of HTA known to handle the particular status message. Then if we ever get an unexpected status and it includes a version number as well, we could tell the user the minimum version of HTA that is compatible with the version of HT they are using. The HTA code would then look something like this:

String status = null;
String minHtaVersion = null;
try {
    String s1 = request.getRequestLine().getUri();
    URI uri = new URI(s1);
    String query = uri.getQuery();
    if (query != null) {
        for (String param : query.split("&")) {
            String[] pair = param.split("=", 2); // limit=2 in case value contains '='
            if (pair.length == 2) {
                if (pair[0].equals("message")) {
                    status = pair[1];
                } else if (pair[0].equals("minHtaVersion")) {
                    minHtaVersion = pair[1];
                }
            }
        }
    }
} catch (Exception e) {
    e.printStackTrace();
}

if (status == null || isUnexpectedStatus(status)) {
    if (minHtaVersion != null) {
        showError("Unexpected sync status received. This version of HearThis for Android appears to be incompatible with your version of HearThis. Please update HearThis for Android to at least version " + minHtaVersion + ".");
    } else {
        showError("Unexpected sync status received. Please check for updates.");
    }
    status = "sync_interrupted"; // Or possibly a distinct status
}

[tombogle]

app/src/main/java/org/sil/hearthis/AcceptNotificationHandler.java line 85 at r3 (raw file):

        if (status == null) {
            // We got something but it wasn't "status". Make sure the user sees an error message.
            status = "sync_error";

From an error handling/reporting standpoint, if we did get a query, it might be a good idea to display and/or log it in a way that it could be reported to us so we could try to figure out what happened.

[tombogle]

@tombogle reviewed 2 files and all commit messages.
Reviewable status: 2 of 7 files reviewed, 6 unresolved discussions (waiting on @wmergenthal).

[andrew-polk]

I hope this is helpful and doesn't just add more noise, but I now trust devin review more than a human to do reviews.
We don't have things hooked up to make it automatic to report easily, but it found these. If you would like more detail on any of them, let me know.

https://app.devin.ai/review/sillsdev/HearThisAndroid/pull/13#issuecomment-3910931106

[devin-ai-integration]

Devin Review found 4 potential issues.

View 6 additional findings in Devin Review.

[devin-ai-integration]

🔴 Watchdog timer never starts its initial countdown after construction

The Watchdog is constructed at SyncActivity.java:178 but pet() is never called to kick off the initial timer countdown. The Watchdog constructor only stores parameters — it does not schedule anything. The pet() method is the only way to start the timer, and it is only called from receivingFile() (line 342) and sendingFile() (line 354).

Root Cause and Impact

If the sync operation stalls before any files are transferred (e.g., the PC receives the UDP packet but fails before sending/requesting any files), neither receivingFile() nor sendingFile() will ever be called, so pet() is never invoked, the watchdog timer never starts, and the timeout callback never fires. The app will be stuck indefinitely with no error message and no way for the user to proceed (the Continue button is never enabled).

The Watchdog's own documentation says "Once instantiated and started, it counts down from its timeout value" but the constructor doesn't start anything. A pet() call is needed right after construction at line 184 to start the initial countdown.

Prompt for agents

In app/src/main/java/org/sil/hearthis/SyncActivity.java, after the Watchdog is constructed at line 178-184, add a call to watchdog.pet() to start the initial countdown timer. This should be placed right after the Watchdog constructor call (around line 184, after the closing parenthesis and semicolon of the Watchdog construction). Alternatively, modify the Watchdog constructor in app/src/main/java/org/sil/hearthis/Watchdog.java at lines 25-29 to automatically schedule the first timeout by calling pet() at the end of the constructor.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🔴 NullPointerException on watchdog.shutdown() when watchdog has not been initialized

At SyncActivity.java:299, watchdog.shutdown() is called unconditionally in onNotification(), but watchdog may be null if the notification arrives before the QR code scanning and executor task assigns the watchdog field.

Root Cause and Impact

The watchdog field is only assigned inside a background executor task at line 178, which runs after a QR code is scanned. However, onNotification() can be called in several scenarios where watchdog is still null:

1. If the AcceptNotificationHandler receives a notification with a status parameter from the PC before the user has scanned a QR code (e.g., from a stale/leftover request).
2. If the old HearThis PC (without the new minHtaVersion/status protocol) sends a plain /notify request — AcceptNotificationHandler will set status = "sync_error" and call onNotification("sync_error"), which reaches SyncActivity.onNotification() while watchdog is still null.

In any of these cases, watchdog.shutdown() at line 299 will throw a NullPointerException, crashing the app.

Suggested change

	watchdog.shutdown();
	if (watchdog != null) {
	watchdog.shutdown();
	}

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🔴 NullPointerException on watchdog.pet() when watchdog has not been initialized

At SyncActivity.java:342 and SyncActivity.java:354, watchdog.pet() is called unconditionally in receivingFile() and sendingFile(). However, watchdog can be null if file transfer callbacks arrive before the watchdog is created.

Root Cause and Impact

The watchdog field is assigned inside a background executor task at line 178. The receivingFile() and sendingFile() callbacks are triggered by the HTTP server handlers (AcceptFileHandler and RequestFileHandler) which use a static listener field set in onResume() at lines 91-92. Since the listener is registered in onResume() (which runs before any QR code scan), it's possible for file transfer requests to arrive and trigger these callbacks before the watchdog is initialized — for example, if the PC initiates file transfers from a previous session or if there's a race between the executor creating the watchdog and the server receiving file requests.

Calling pet() on a null watchdog will throw a NullPointerException, crashing the app.

Suggested change

	watchdog.pet();
	if (watchdog != null) {
	watchdog.pet();
	}

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🟡 AcceptNotificationHandler early return for minHtaVersion sends no HTTP response

At AcceptNotificationHandler.java:70, when the handler receives a minHtaVersion query parameter, it does return without setting any response entity on the HttpResponse object.

Root Cause and Impact

When HearThis PC sends POST /notify?minHtaVersion=1.0 HTTP/1.1, the handler stores the version and returns immediately at line 70 without calling response.setEntity(...). The other code paths (lines 85-88) always set a response entity. The HTTP server (HttpService.handleRequest) will send back a response with no body, which may cause the HearThis PC client to fail or behave unexpectedly if it expects a response body. At minimum, a response entity should be set before returning to maintain the API contract.

Suggested change

	} else if (pair[0].equals("minHtaVersion")) {
	minHtaVersion = pair[1];
	return;
	} else if (pair[0].equals("minHtaVersion")) {
	minHtaVersion = pair[1];
	response.setEntity(new StringEntity("ok"));
	return;

---

Was this helpful? React with 👍 or 👎 to provide feedback.