Timers Free vs Premium (technique)
Information
Cette page détaille les différences techniques entre les timers « Free
» et « Premium » sur gettickr.app, au-delà des fonctionnalités visibles
(sauvegarde, télécommande, etc.). Elle explique comment la persistance, la
synchronisation et les URLs d’affichage fonctionnent selon le type de compte.
Vue d’ensemble
- Free (sans compte) :
- Timers anonymes, non sauvegardés côté serveur
- La configuration est encodée dans l’URL de l’éditeur
- Chaque modification génère une nouvelle URL
- Pas de persistance ni de contrôle à distance
- Premium (avec compte) :
- Timers sauvegardés dans la Realtime Database (Firebase)
- URL d’affichage stable (renderer) qui ne change pas
- Télécommande (Remote Control) et mises à jour instantanées
- Gestion des timers via un tableau de bord
Différences clés côté architecture
| Aspect | Free | Premium |
|---|---|---|
| Persistance | Aucune (client uniquement) | Sauvegarde côté serveur (Realtime Database) |
| Authentification | Non | Firebase Auth |
| URL d’affichage (renderer) | Change à chaque modification | Stable et permanente |
| Synchronisation | Basée sur la config d’URL (statique) | Timestamps serveur + updates push en temps réel |
| Contrôle à distance | Non | Oui (Start/Pause/Reset, ajustements de durée/target) |
| Sécurité | Basique (aucun état sensible côté serveur) | Règles Firebase (Single Writer: propriétaire uniquement) |
| SEO/Intégration | Bonne (intégration simple) | Excellente (URL stable, CMS/OBS persistants) |
Persistance et état du Timer
- Free :
- L’état (durée cible, design) vit dans l’éditeur et dans l’URL.
- Après modification, l’URL change et il faut mettre à jour les intégrations (OBS, site).
- Aucun « state » serveur, pas de lecture/écriture sécurisée.
- Premium :
- L’état du timer est stocké dans Firebase Realtime Database
(
timers/{uuid}). - Le renderer lit les mises à jour en temps réel.
- Le propriétaire du timer est le seul autorisé à écrire (Single Writer Pattern).
- L’état du timer est stocké dans Firebase Realtime Database
(
Information
Le renderer est toujours en lecture seule. Il ne modifie jamais l’état
du timer; il se contente d’afficher et de suivre les mises à jour.
Synchronisation et calcul du temps
Pour éviter la dérive temporelle (drift), la plateforme suit des principes stricts :
- Calcul basé sur des timestamps (jamais sur une décrémentation naïve du temps)
- Mise à jour du renderer toutes les 100 ms (≈ 10 FPS) pour un affichage fluide
- Premium : utilisation des timestamps serveur Firebase pour les événements critiques (ex. démarrage/arrêt d’un countdown)
Pseudo-logique recommandée pour le calcul d’un CountTo (explicatif) :
- Prendre « maintenant » (Date.now)
- Calculer la différence avec la date cible (UTC ISO 8601)
- Convertir en Duration (jours/heures/minutes/secondes) pour l’affichage
- Éviter toute logique de type « timeLeft = timeLeft - 1000 »
Countdown vs CountTo
- Countdown (durée) :
- Peut démarrer, se mettre en pause, reprendre, se réinitialiser
- La durée peut être ajustée en cours de route (Premium : via télécommande)
- CountTo (date) :
- Toujours en cours jusqu’à atteindre la date cible
- Pas d’état « start/pause »; seule la cible (date/heure) peut être modifiée
- Stocker la cible en UTC ISO 8601; afficher localement selon la langue/fuseau
Tip
Pour CountTo, utilisez des dates en UTC (2025-12-31T22:59:59.000Z) et
laissez l’affichage s’adapter à la locale utilisateur.
URLs : comportement et implications
- Free :
- L’URL encode la configuration; un changement => nouvelle URL
- Implication : il faut mettre à jour les embeds (OBS, site) après édition
- Premium :
- L’URL du renderer ne change pas
- Les modifications (durée/design/target) se reflètent automatiquement
| Action | Free | Premium |
|---|---|---|
| Modifier la durée/design | Nouvelle URL nécessaire | Pas de changement d’URL |
| Mettre à jour un embed OBS/site | Reconfigurer le lien | Aucune action (mise à jour automatique) |
| Passer d’un appareil à un autre | Rééditer via l’URL | Charger le timer depuis le dashboard |
Sécurité et règles d’accès (Premium)
- Single Writer Pattern : seul le propriétaire peut écrire l’état (
state) - Le renderer et les routes de visualisation sont en lecture seule
- Règles Firebase : validation du propriétaire requise pour les écritures
Warning
Ne tentez pas d’écrire depuis un renderer ou une route de
visualisation; ces endpoints doivent rester « read-only ».
Intégration streaming et sites
- OBS/Streamlabs/XSplit : intégrer via Browser Source avec l’URL du renderer
- Sites web :
- iFrame standard
- CMS (WordPress, Shopify, Wix/Squarespace)
- HTML personnalisé
- Premium : idéal pour les intégrations durables (une URL unique, des mises à jour transparents)
Quand choisir Free vs Premium (techniquement)
Choisir Free quand :
- Besoin ponctuel, test rapide, prototype
- Aucune exigence de persistance ni de télécommande
Choisir Premium quand :
- Besoin d’une URL stable et de mises à jour en direct
- Contrôle à distance (start/pause/reset, ajustements)
- Timers utilisés régulièrement (streamings récurrents, pages d’événements)
- Sécurité et contrôle de l’accès (propriétaire unique)
Bonnes pratiques
- Éviter la logique incrémentale pour le temps restant
- Stocker les dates CountTo en UTC ISO 8601
- S’assurer que l’éditeur reste ouvert pour la télécommande (ou utiliser la persistance Premium)
- Nommer clairement les timers (ex. « Pause Stream 10min ») pour le dashboard
- Tester la lisibilité et le cadrage dans OBS avant le live
Limitations et mises en garde
- Free : pas de persistance, et les URL changent après chaque modification
- Premium : la suppression d’un timer est définitive; l’URL cesse immédiatement de fonctionner
- CountTo : ne peut pas être « démarré » ou « mis en pause » (stateless par conception)
Étapes suivantes
- Timer State & Synchronisation — Approfondir la persistance et les mises à jour temps réel
- Sauvegarder & Gérer — Construire une bibliothèque de timers (Premium)
- Télécommande — Piloter les timers en direct (Premium)
- Free vs Premium (Vue générale) — Comparaison fonctionnelle côté utilisateur