alex-spataru/qsimpleupdater

QSimpleUpdater is a Qt-based reusable library, not an application. Its purpose is to let a host Qt app check a remote update manifest, compare versions, download an installer or package, and optionally hand control back to the host app for custom install logic.

Public API boundary

• The library’s public surface is concentrated in include/QSimpleUpdater.h.

• Consumers integrate it either through CMake (CMakeLists.txt, QSimpleUpdaterConfig.cmake.in) or qmake (QSimpleUpdater.pro, QSimpleUpdater.pri).

• The README’s examples indicate the main entry point is a singleton-style manager accessed by update-definition URL.

Core orchestration layer

• src/QSimpleUpdater.cpp is the top-level façade that application code talks to.

• It appears responsible for per-update-definition configuration such as enabling notifications, downloader behavior, module names/versions, and custom install procedures.

• Architecturally, this is the boundary between host application code and the update subsystem.

Per-update state and business logic

• src/Updater.cpp / src/Updater.h are the main stateful engine for a single update stream.

• The README’s “multiple modules” model strongly suggests each update manifest URL maps to one updater instance holding its own module metadata, version, and policy flags.

• This layer is where manifest parsing, version comparison, and update decision-making live.

Network-driven update flow

• The update flow is: fetch JSON manifest → read platform-specific entry → compare remote vs local version → decide whether to notify, download, or open a URL.

• The manifest schema in the README is the primary data contract with the server.

• Network transport is constrained to HTTP/HTTPS only, so the update subsystem is centered around remote file retrieval rather than general-purpose protocol handling.

Downloader and install path

• src/Downloader.cpp / src/Downloader.h plus src/Downloader.ui implement the built-in download UI and progress experience.

• This is the component that turns a remote download-url into a local file and signals completion.

• It is also the main handoff point for either automatic install behavior or custom install handling from the host application.

Authentication and access control

• src/AuthenticateDialog.cpp / .h / .ui provide a dedicated UI for authenticated downloads.

• This indicates the downloader supports protected endpoints and user credential entry, which is a separate concern from update logic itself.

Versioning subsystem

• Version comparison is a distinct concern and is explicitly covered by tests/Test_Versioning.h.

• The README shows semantic-version-aware behavior, including pre-release ordering and optional v prefix handling.

• This is important for architecture because “update available” is derived from version semantics, not just string comparison.

Platform-specific manifest routing

• The update definition file contains keys like windows, osx, linux, ios, and android, with support for custom platform keys.

• That means one manifest can serve multiple platforms while keeping platform-specific download URLs, open URLs, and changelogs.

• The platform-selection logic is a key decision point inside the updater engine.

Resource and packaging layer

• etc/resources/qsimpleupdater.qrc bundles library assets; etc/resources/version.rc.in suggests Windows version metadata integration.

• These files are part of the distribution/branding layer rather than the update algorithm itself.

Tutorial as reference host application

• tutorial/ is a sample Qt app that demonstrates integration and end-to-end behavior.

• It has its own UI (tutorial/src/Window.ui) and update manifest example (tutorial/definitions/updates.json).

• Architecturally, this is the consumer-side reference, showing how the library is embedded in a real application.

Tests and verification

• tests/ contains unit-style coverage for downloader behavior, updater behavior, public API behavior, and versioning.

• This suggests the repository treats the library as a set of independently testable subsystems rather than only integration-tested UI.

• tests/main.cpp and Tests.pro indicate a separate test executable.

Build, CI, and repository boundaries

• The repo supports both CMake and qmake, which matters for how the library is consumed and packaged.

• GitHub Actions (.github/workflows/main.yml) provides CI build validation.

• The project is structured as a library with optional tutorial/tests, not as a single monolithic executable.

Overall, the architecture is: host Qt app → public QSimpleUpdater API → per-URL Updater state and version logic → network fetch of JSON manifest → optional Downloader/AuthenticateDialog UI → downloaded file or custom install callback.