Skip to content

Implement World Radio League contact logging #800

Description

@patrickrb

Overview

Add World Radio League (WRL) contact logging integration similar to the existing Cloudlog and QRZ implementations.

Implementation Pattern

Follow the existing Cloudlog/Wavelog/Nextlog pattern:

  • Settings UI with server configuration
  • API key authentication
  • Test connection button
  • Auto-upload QSOs after successful contacts
  • Station profile management (if applicable)

Required Information from WRL Documentation

Before implementation, confirm from WRL API documentation:

  • Server Model: Fixed cloud endpoint or user-hosted instance?
  • Station Profiles: Multiple station profiles per account?
  • API Authentication:
    • Header format (e.g., Authorization: Bearer {key}, X-API-Key: {key}, or path segment?)
    • Exact header/parameter name
  • API Endpoints:
    • Station list endpoint (if applicable)
    • QSO upload endpoint
    • Test/ping endpoint
  • Deduplication Logic: QSO dedup by callsign + date + time (like Cloudlog/QRZ)?
  • Additional Requirements:
    • Rate limiting?
    • Required HTTP headers (User-Agent, Content-Type)?
    • ADIF format requirements?

Configuration Fields Needed

Settings Storage (GeneralVariables.java)

  • wrlServerAddress — Server URL (required if self-hosted; optional if cloud)
  • wrlApiKey — API key for authentication (required)
  • wrlStationID — Station profile ID (optional; fetch via API if multi-station support exists)
  • enableWRL — Enable/disable WRL sync toggle

Settings UI (LoggingSettings.kt)

Follow the CloudlogSettingsDialog pattern:

  1. Server address input (if applicable)
  2. API key input field
  3. Station ID selector (dropdown populated from API query, if applicable)
  4. Test Connection button
  5. Enable toggle in main logging settings

Implementation Tasks

1. Core Authentication & Connection

  • Add WRL configuration fields to GeneralVariables.java
  • Implement ThirdPartyService.CheckWrlConnection() — test server connectivity with API key
  • Implement ThirdPartyService.FetchWrlStations() — retrieve station profiles (if applicable)
  • Determine correct HTTP auth headers and API endpoint patterns

2. Settings UI

  • Create WrlSettingsDialog() in LoggingSettings.kt
  • Add WRL enable toggle and config UI following Cloudlog pattern
  • Wire test connection button to CheckWrlConnection()
  • Persist config via mainViewModel.databaseOpr.writeConfig()

3. QSO Upload

  • Implement ThirdPartyService.UploadToWrl(QSLRecord)
  • Use ADIF format (existing ThirdPartyService.QSLRecordToADIF())
  • Add sync tracking (synced_wrl column in QSLTable if not present)
  • Integrate into post-QSO auto-upload flow (MainViewModel.java onTransmitSuccess callback)

4. Sync Management

  • Add synced_wrl boolean column to QSLTable schema (if not present)
  • Update ThirdPartyService.syncAllQSOs() to include WRL
  • Update QsoAutoSync to include WRL in retry/reconnect logic
  • Display sync status in logbook UI (existing SyncChips in LogbookScreen.kt)

5. Testing

  • Test connection with valid API key
  • Test QSO upload on successful contact
  • Test offline scenario → auto-sync on reconnect
  • Test with multiple WRL instances (if applicable)
  • Verify ADIF mode/submode mapping for FT2/FT4/FT8

Code References

Existing implementations to reference:

  • ft8af/app/src/main/kotlin/radio/ks3ckc/ft8af/ui/settings/LoggingSettings.kt — Settings UI pattern (CloudlogSettingsDialog)
  • ft8af/app/src/main/java/com/k1af/ft8af/log/ThirdPartyService.java — Service upload & connection logic
  • ft8af/app/src/main/kotlin/radio/ks3ckc/ft8af/sync/QsoAutoSync.kt — Auto-sync on connectivity restore
  • ft8af/app/src/main/kotlin/radio/ks3ckc/ft8af/ui/logbook/LogbookScreen.kt — Sync status display (SyncChips)

Notes

  • Keep WRL auth minimal: API key in settings (no username/password needed if key-based)
  • Match the deduplication strategy of Cloudlog/QRZ (services handle repeat uploads safely)
  • Use same ADIF mode mappings (FT2/FT4 → MFSK submode; FT8 → standalone mode)
  • Follow existing threading patterns: uploads happen on background thread post-QSO

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions