n0tst3v3andClaude Opus 5
f16efce66e
Yes, the scanner was duplicating. refreshCategoryOptions(), updateRadar() and pairedAdapter.notifyDataSetChanged() ran from acceptSignal on every advertisement AND from pruneTask once a second - the same three calls either way. Worse, the whole persist path ran per advertisement, and ScanCallback is delivered on the main looper: a hex dump of the advertisement, lookupCompany(), get(), lookupOui(), then telemetry(), setDetectedCategory(), recordObservation() and setVendor(). Eight database operations on the UI thread per beacon, at SCAN_MODE_LOW_LATENCY, times every transmitter in range. The radar sweep re-posts itself every 33ms and was competing for that thread, which is why it dragged. A device already on the radar now only gets its RSSI and last-seen stamp refreshed until PERSIST_INTERVAL_MS (3s) is up. A device's first sighting still takes the full path and refreshes at once. The radar view also allocated per frame at 30fps: a six-stop RadialGradient plus two arrays, and a fresh ArrayList and Comparator for the target sort. Both reused now. setTargets no longer invalidates while scanning, since onDraw already re-posts itself. Left setLayerType(SOFTWARE) alone - setShadowLayer only works on text under hardware acceleration, so removing it would drop the ring glow. Separately, history points now say why they exist. location_history had no event column, so schema 16 adds one; connected() and disconnected() stamp it and a plain position refresh leaves it null. The popup shows a linked or broken-link line for the two states and stays quiet for older rows that predate the column. History points also render as the device's own marker at half size rather than a plain circle, sharing one divIcon per device so a long trail does not build a DOM node per point. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
