›

Gestion version béta

APAP Membre
13:56 modifié dans API AppKit #1
Hello,

Je suis presque prêt à  sortir une version béta de mon application et me demandais quelles étaient les meilleures façon de gérer une expiration après une certaine date dans une application cocoa.

Toute idée est la bienvenue :)

Réponses

  • CéroceCéroce Membre, Modérateur
    13:56 modifié #2
    Le plus simple est de mettre la date en dur dans ton code et de comparer avec la date courante (NSDate).

    Cependant, en pratique, ce qu'on veut n'est pas de bloquer à  partir d'une certaine date (difficile à  établir), mais lorsque une nouvelle version est dispo.
    Ton appli peut faire une simple requête au démarrage vers ton site web pour connaà®tre le n° de version courante.

    Inclus dès le départ la MAJ automatique grâce à  Sparkle. La mise en oe“uvre est très simple et le fonctionnement super-propre: il n'y a aucune bonne raison de ne pas le faire.
  • APAP Membre
    13:56 modifié #3
    Merci pour ton feedback sur Sparkle. J'avais en effet pensé à  l'utiliser mais vu que mon appli s'installe via un installer (obligé car OSAX à  installer, ...) Je me demandais si au final c'était une bonne idée.
  • devulderdevulder Membre
    13:56 modifié #4
    dans 1286177537:

    Le plus simple est de mettre la date en dur dans ton code et de comparer avec la date courante (NSDate).

    Cependant, en pratique, ce qu'on veut n'est pas de bloquer à  partir d'une certaine date (difficile à  établir), mais lorsque une nouvelle version est dispo.
    Ton appli peut faire une simple requête au démarrage vers ton site web pour connaà®tre le n° de version courante.

    Inclus dès le départ la MAJ automatique grâce à  Sparkle. La mise en oe“uvre est très simple et le fonctionnement super-propre: il n'y a aucune bonne raison de ne pas le faire.


    Le souci avec la date c'est que l'utilisateur peut changer la date courante pour toujours pouvoir utiliser l'application.

    Idem pour la requête au démarrage, on peut facilement bloquer avec /etc/hosts.

    Pour ma part, je trouve que le mieux c'est de limiter les entrées dans le logiciel, supposons que tu fais un logiciel

    de base de donnée, tu limites a 15 entrées maximum.


  • Paisible.frPaisible.fr Membre
    13:56 modifié #5
    Une maniere de contourner un peu la bidouille de changement de date systeme, pourrait etre de stocker la date a chaque lancement de l'application.
  • CéroceCéroce Membre, Modérateur
    13:56 modifié #6
    dans 1286178422:

    Merci pour ton feedback sur Sparkle. J'avais en effet pensé à  l'utiliser mais vu que mon appli s'installe via un installer (obligé car OSAX à  installer, ...) Je me demandais si au final c'était une bonne idée.


    Sans doute pas dans ce cas-là . Sparkle est plutôt fait pour mettre à  jour le bundle de l'appli.

    dans 1286178784:

    Idem pour la requête au démarrage, on peut facilement bloquer avec /etc/hosts.


    Si ça bloque, le logiciel refuse de se lancer et basta.
  • APAP Membre
    13:56 modifié #7
    Je cherche qqlch de simple donc une comparaison de date devrait suffire.
    Merci pour votre aide.
  • SystemSystem
    13:56 modifié #8
    dans 1286183237:

    dans 1286178422:

    Merci pour ton feedback sur Sparkle. J'avais en effet pensé à  l'utiliser mais vu que mon appli s'installe via un installer (obligé car OSAX à  installer, ...) Je me demandais si au final c'était une bonne idée.


    Sans doute pas dans ce cas-là . Sparkle est plutôt fait pour mettre à  jour le bundle de l'appli.

    dans 1286178784:

    Idem pour la requête au démarrage, on peut facilement bloquer avec /etc/hosts.


    Si ça bloque, le logiciel refuse de se lancer et basta.


    Tant que c'est pour une bêta, il suffit effectivement de refuser le lancement du logiciel.
    En revanche, pour une version publique, il faut absolument éviter ça.
Connectez-vous ou Inscrivez-vous pour répondre.