›

UUID, uniqueIdentifier et iOS 5

SmySmy Membre
mars 2012 modifié dans API UIKit #1
Bonjour



L'annonce du passage en deprecated de uniqueIdentifier sur iOS 5 avait fait grand bruit l'année dernière, mais les choses se sont calmées quand les développeurs se sont aperçus que la méthode était toujours fonctionnelle.



J'imagine que ce ne sera pas le cas éternellement, et je me pose donc la question de son remplacement par CFUUIDCreate.



Que faites-vous dans vos dev, vous créez un CFUUIDCreate que vous stockez en préférences, vous utilisez une autre méthode, vous ne changez rien ?
«13

Réponses

  • CeetixCeetix Membre
    mars 2012 modifié #2
    Cadeau image/wink.png' class='bbc_emoticon' alt=';)' />

    [url][/url]https://github.com/b...BPXLUUIDHandler
  • KixxxKixxx Membre
    #3
    Hey merci j'en avais besoin en plus image/wink.png' class='bbc_emoticon' alt=';)' />
  • SmySmy Membre
    #4
    'Ceetix' a écrit:


    Cadeau image/wink.png' class='bbc_emoticon' alt=';)' />

    https://github.com/b...BPXLUUIDHandler




    Pas mal en effet, merci
  • AliGatorAliGator Membre, Modérateur
    mars 2012 modifié #5
    Je rebondis ceci dit sur le sujet : quid des notifications Push ?



    Autant j'utilise Flurry Analytics qui utilisait jusqu'à  présent l'UDID pour identifier les devices, mais a fait une mise à  jour il y a quelques temps pour ne plus passer par le "UIDevice.uniqueIdentifier", donc le problème est résolu de ce côté et ça ne pose pas de problème



    Mais pour les notifications Push, j'utilise EasyAPNS (comme énormément de gens d'ailleurs), et lui côté serveur stocke les UDID des utilisateurs pour les relier aux tokens nécessaires pour le push... Du coup de ce côté comment ça se passe ?



    [EDIT]

    A priori le code iPhone de easyapns a été mis à  jour. Je sais pas s'il faut mettre à  jour le côté serveur ?

    Et du coup si on modifie de ce côté, quel impact pour les utilisateurs, devront-ils réaccepter le push ou pas ?
  • SystemSystem
    #6
    Je ne vois pas où est le problème. Côté serveur tu as juste à  faire l'association entre le UIDevice.uniqueIdentifier et ton nouvel identifier généré par ta propre application. Tant que tu peux récupérer "uniqueIdentifier" (-respondsToSelector) tu pourras faire cette association côté serveur (UIDevice.uniqueIdentifier = myNewUniqueIdentifier = pushToken).

    Après quoi qu'il arrive la méthode
    <br />
[color=#000000][font=Courier, Consolas, monospace][size=3]<br />
- (void)application:(UIApplication *)[i]application[/i] didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)[i]deviceToken[/i][/size][/font][/color]<br />


    est appelée systématiquement après un -registerForRemoteNotifications: il me semble. Donc dans cette méthode tu dois renvoyer le token au serveur et ducoup tu peux faire les associations sans problème.



    Et puis, tant que le token est valide, Apple communique avec le device. Donc à  priori je ne vois pas le soucis, même si tu ne fais pas d'association entre l'ancien uniqueIdentifier et le nouveau. C'est juste que côté BDD tu auras le double de données si tu ne fais pas cette association par défaut et tant que cela est possible
  • AliGatorAliGator Membre, Modérateur
    #7
    'ldesroziers' a écrit:


    Je ne vois pas où est le problème. Côté serveur tu as juste à  faire l'association entre le UIDevice.uniqueIdentifier et ton nouvel identifier généré par ta propre application.
    Tu veux dire qu'en plus d'avoir l'association UIDevice.deviceIdentifier <=> APNS Token que easyapns gère déjà  côté serveur dans les tables de sa base de données avec laquelle il se démerde, il faudrait côté serveur rajouter une association UIDevice.deviceIdentifier <=> UUID maison pour garder trace de la correspondance entre les deux si on veut pas tout doubler ?



    Bah si ça pose sacrément problème alors. D'une part surtout parce que je vais pas modifier le code de easyapns, et encore moins la structure de sa base de données avec laquelle il se démerde, j'ai autre chose à  faire et côté maintenabilité c'est zéro (je sais pas si tu as déjà  utilisé easyapns mais en tout cas dans sa BDD ce genre d'association n'est pas prévue), et d'autre part car si tu veux faire l'association... bah faut que le serveur connaisse ton UIDevice.deviceIdentifier... qui est déjà  déprécié iOS5... donc back to square one.



    Mais bon je suis pas sûr d'avoir bien compris ta réponse, ça me semble pas très clair ce que tu tentes d'expliquer en fait
  • SystemSystem
    #8
    À mon avis le problème c'est surtout que tu te poses des questions alors qu'il n'y a pas à  s'en poser..

    Tu renvoies le token avec le nouveau deviceIdentifier et basta.. À moins que tu aies une configuration particulière du genre tel ou tel device ne doit pas recevoir telles ou telles notifications, il n'y a strictement AUCUN soucis à  se faire oO
  • StephSteph Membre
    mars 2012 modifié #9
    En fait si, il y a un souci c'est que EasyAPNS utilise dans la BDD une clé basée sur l'UDID, le Token et la version de l'app, chose qui d'ailleurs posait problème au changement de version à  une époque puisqu'il inscrivait du coup x fois tes users, une fois pour chaque version de ton app, si tu ne faisais pas gaffe au moment de ta requête, l'utilisateur recevait x fois la notif.



    J'ai légèrement modifié la base de données pour prendre ça en compte, du coup j'en ai profité pour virer l'udid de la base et modifié les classes. D'ailleurs, il y'a d'autres souci liés au passage en dernière version de PHP5 ... Il a fallu que je modifie aussi des tests dans une class. Je ne suis pas à  la maison, mais je regarde et mettrai les modifs si ça intéresse quelqu'un image/smile.png' class='bbc_emoticon' alt=':)' />
  • CeetixCeetix Membre
    #10
    Voilà , là  tu sers à  quelque chose Steph ! image/biggrin.png' class='bbc_emoticon' alt=':D' />

    Vas-y balance la sauce !
  • SmySmy Membre
    #11
    'Ceetix' a écrit:


    Cadeau image/wink.png' class='bbc_emoticon' alt=';)' />

    https://github.com/b...BPXLUUIDHandler




    Et le développeur est hyper réactif. J'ai remonté hier un problème qui a été corrigé 5 mn plus tard image/rolleyes.gif' class='bbc_emoticon' alt='::)' />
  • SmySmy Membre
    mars 2012 modifié #12
    Ca bouge visiblement : "iOS: Apple commence à  rejeter les logiciels utilisant l'UUID des appareils"



    http://www.macbidoui...d-des-appareils
  • spin0usspin0us Membre
    #13
    Ca tombe bien, je n'utilise plus que BPXUUIDHandler pour ma part :-)
  • igregigreg Membre
    #14
    hello ! je vous conseille d'utiliser http://openudid.org/ qui risque d'être la nouvelle référence en terme d'identification des devices. Outre-Atlantique, c'est la solution qui semble avoir le plus de succès. Pour l'avoir intégré dans notre application, cela fonctionne très bien. Le seul cas où un nouvel udid sera créé est si l'utilisateur fait une mise à  zéro de son device sans restauration cryptée (cas assez rare).
  • SystemSystem
    avril 2012 modifié #15
    @igreg Hmm tu es sûr que l'UDID n'est pas reset si l'utilisateur désinstalle/réinstalle ton application?



    Edit: après lecture:




    - Provide a reliable proxy and replacement for a universal unique device identifier. That is, persistent and sufficiently unique, on a per device basis.

    - NOT use an obvious other sensitive unique identifier (like the MAC address) to avoid further deprecation and to protect device-level privacy concerns

    - Enable OpenUDID to be accessed by any app




    Il n'empêche que c'est un moyen d'identifier clairement UN utilisateur, et je pensais que c'est justement ce que ne voulait plus Apple...?

    Sur le coup, j'émets donc un gros doute sur ce code source.



    Je vais devoir implémenter du push dans pas longtemps, et j'étais plutôt parti pour utiliser un simple CFUUID comme le préconise clairement Apple:






    Do not use the uniqueIdentifier property. To create a unique identifier specific to your app, you can call the CFUUIDCreate function to create a UUID, and write it to the defaults database using the NSUserDefaults class.

  • SmySmy Membre
    mars 2012 modifié #16
    'ldesroziers' a écrit:


    Je vais devoir implémenter du push dans pas longtemps, et j'étais plutôt parti pour utiliser un simple CFUUID comme le préconise clairement Apple




    BPXUUIDHandler est basé sur CFUUIDCreate, il a juste l'avantage de gérer pour toi la sauvegarde dans la keychain.
  • SystemSystem
    #17
    LE keychain image/biggrin.png' class='bbc_emoticon' alt=':D' />
  • SmySmy Membre
    #18
    'ldesroziers' a écrit:


    LE keychain image/biggrin.png' class='bbc_emoticon' alt=':D' />




    Mhh, un clé, une trousseau ? image/cool.gif' class='bbc_emoticon' alt='8--)' />
  • SystemSystem
    #19
    Toi t'as des problèmes de masculin et de féminin. image/tongue.png' class='bbc_emoticon' alt=':P' />
  • CeetixCeetix Membre
    #20
    Moi je déteste les gens qui me sorte "Ouai tu vois j'ai branché la wifi"
  • SmySmy Membre
    mars 2012 modifié #21
    'ldesroziers' a écrit:


    Toi t'as des problèmes de masculin et de féminin. image/tongue.png' class='bbc_emoticon' alt=':P' />




    Non, de mauvaise foi(e) image/rolleyes.gif' class='bbc_emoticon' alt='::)' />




    'Ceetix' a écrit:


    Moi je déteste les gens qui me sorte "Ouai tu vois j'ai branché la wifi"




    Tu en connais ?
  • igregigreg Membre
    #22
    OK, mais imagine tu as 2 versions de ton appli (free and paid) ce moyen (OpenUDID) te permet de garder le même UDID pour différentes applications, ce qui est plutôt pratique. Et le but n'est pas forcement de pouvoir traquer l'utilisateur comme beaucoup de monde le pense, mais peut très bien servir à  autre chose (sauvegarde des préférences & paramètres dans mon cas sans que l'utilisateur soit obligé de créer un compte)
  • AliGatorAliGator Membre, Modérateur
    #23
    BPXLUUIDHandler le gère aussi ça.
  • CeetixCeetix Membre
    #24
    @Smy : oui oui et même un pote en école d'ingé informatique.
  • DrakenDraken Membre
    #25
    Tu ne confonds pas avec "Ouais, tu vois j'ai branché la wi" ?
  • CeetixCeetix Membre
    #26
    Désolé de te décevoir Draken mais non je ne confonds pas ...
  • JegnuXJegnuX Membre
    #27
    'ldesroziers' a écrit:


    Hmm tu es sûr que l'UDID n'est pas reset si l'utilisateur désinstalle/réinstalle ton application?



    Edit: après lecture:





    Il n'empêche que c'est un moyen d'identifier clairement UN utilisateur, et je pensais que c'est justement ce que ne voulait plus Apple...?

    Sur le coup, j'émets donc un gros doute sur ce code source.



    Je vais devoir implémenter du push dans pas longtemps, et j'étais plutôt parti pour utiliser un simple CFUUID comme le préconise clairement Apple:




    Oh collègue, j'utilise cette classe pour le push dans les deux apps Total ^^
  • SystemSystem
    #28
    Gros flemmard de mes deux image/biggrin.png' class='bbc_emoticon' alt=':D' />
  • KixxxKixxx Membre
    #29
    'Ceetix' a écrit:


    Cadeau image/wink.png' class='bbc_emoticon' alt=';)' />

    https://github.com/b...BPXLUUIDHandler




    J'essaye d'utiliser ce composant et j'ai de grooooosses erreurs... ^^ !

    Quelqu'un pourrait-il m'expliquer la cause de ces erreurs ?

    Dois-je ajouter une librairie ?

    Me manque-t-il une configuration bien précise ?




    Undefined symbols for architecture i386:

    "_SecItemUpdate", referenced from:

    +[BPXLUUIDHandler storeUUID:] in BPXLUUIDHandler.o

    "_SecItemAdd", referenced from:

    +[BPXLUUIDHandler storeUUID:] in BPXLUUIDHandler.o

    "_SecItemCopyMatching", referenced from:

    +[BPXLUUIDHandler UUID] in BPXLUUIDHandler.o

    +[BPXLUUIDHandler reset] in BPXLUUIDHandler.o

    "_SecItemDelete", referenced from:

    +[BPXLUUIDHandler reset] in BPXLUUIDHandler.o

    "_kSecAttrAccount", referenced from:

    _CreateKeychainQueryDictionary in BPXLUUIDHandler.o

    "_kSecAttrService", referenced from:

    _CreateKeychainQueryDictionary in BPXLUUIDHandler.o

    "_kSecClass", referenced from:

    _CreateKeychainQueryDictionary in BPXLUUIDHandler.o

    "_kSecClassGenericPassword", referenced from:

    _CreateKeychainQueryDictionary in BPXLUUIDHandler.o

    "_kSecReturnAttributes", referenced from:

    +[BPXLUUIDHandler UUID] in BPXLUUIDHandler.o

    +[BPXLUUIDHandler reset] in BPXLUUIDHandler.o

    "_kSecReturnData", referenced from:

    +[BPXLUUIDHandler UUID] in BPXLUUIDHandler.o

    "_kSecValueData", referenced from:

    +[BPXLUUIDHandler storeUUID:] in BPXLUUIDHandler.o

    ld: symbol(s) not found for architecture i386

    clang: error: linker command failed with exit code 1 (use -v to see invocation)




    Par avance, merci image/wink.png' class='bbc_emoticon' alt=';)' />
  • BaardeBaarde Membre
    #30
    Le framework Security doit être ajouté au projet.
  • KixxxKixxx Membre
    #31
    Hey!! Merci image/wink.png' class='bbc_emoticon' alt=';)' />
Connectez-vous ou Inscrivez-vous pour répondre.