Date limite soumission SDK 7

Bonjour à  tous,


J'aimerais savoir si il y a des limitations (de temps) concernant la soumission d'applis compilés avec Xcode 5.


 


Si oui, ou peut on trouver l'info? 


Merci d'avance.


Réponses

  • 1 février 2015 .. outch c'est dans 2 mois !
  • Super ! 


    Merci.


  • J'ai publié une application la semaine dernière et Apple signale bien que les modifications vont être obligatoire :


     


  • faut rajouter arm64 dans les architectures supportées


  • ???  c'est tout ?


    bon ben : valid Architectures : armv6, armv7, armv7s, armv64, i386 (le dernier j'ai jamais vraiment compris à  quoi il servait)


     


     


    Pas d'autre modification à  faire  :o ? Moi qui m'inquiétais d'avoir des centaines de lignes de code à  modifier me voila rassurée  :lol:

  • Pour certaines app, le passage au 64 bits de l'ensemble pose soucis (surtout quand t'as des dépendances vers des libs externes qui elles aussi doivent être compilées en 64 bits).


  • AliGatorAliGator Membre, Modérateur
    Changer juste le Build Setting ne suffit pas à  magiquement "rendre une application compatible 64-bits". Il faut vérifier que ton code ne fait pas des choses qui dépendent de l'architecture.

    Un bug assez costaud qu'on a eu sur une vielle application dont on a repris le code d'un ancien prestataire : quand on testait sur iPhone 5 sous iOS7, tout marchait bien, mais en passant en iPhone 6 et iOS8, tout à  coup les cellules des UITableViews étaient toutes de hauteur nulle.

    On a cherché pendant longtemps, on a regardé l'implémentation de "heightForRowAtIndexPath:", la méthode était bien appelée, et valeur de la variable qu'on retourne dans cette méthode était bien non-nulle (= 60), mais pourtant, rien n'y faisait, toutes les cells étaient de hauteur nulle.

    On a pensé à  un bug iOS8 pendant longtemps, puisque quand on testais sous notre iPhone 5 sous iOS7 ça marchait mais sur le iPhone 6 sous iOS8 ça cassait.

    Voici l'implémentation de la méthode qui avait été faite par le prestataire :
    -(float)tableView: (UITableView*)tableView heightForRowAtIndexPath: (NSIndexPath*)indexPath
    {
    CGSize size = CGSizeMake(200, 60);
    ModelObject* obj = self.model[indexPath.row];
    if (obj.isLarge == YES)
    {
    size += 40;
    }
    // Je vous passe quelques autres calculs intermédiaires
    return size.height;
    }
    Celui qui trouve quelle est l'erreur gagne un point !

  • CGSize size = CGSizeMake(200, 60);
    size += 40;

    Ca ca marche pas déjà , mais ca devait pas être ca l'erreur ;)

  • La méthode de délégué rend un CGFloat en principe.


    CGFloat est float en architecture 32 bits et double en architecture 64 bits.


    Comme ici, la méthode de délégué est forcée de type float, elle ne fonctionne qu'en 32 bits.


    ça doit être un sacré merdouilloux dans la pile en 64 bits ...


  • Oui remplacer les int par des NSInteger et les float par des CGFloat pour éviter ces problèmes c'est un bon début.


  • Oui, ça facilite le portage du code que tu peux recompiler. ça ne résoud pas le problème des bibliothèques externes.


  • Alf1996Alf1996 Membre
    décembre 2014 modifié #14


    Celui qui trouve quelle est l'erreur gagne un point !


     




     


     


    Et combien de points pour avoir une image un chat ?


     


    Sinon, j'arrive un peu tard... mais la réponse est ici... çà  me déçoit que le spécialiste de la doc n'ait pas commencé par là  !  :-*


     


    Edit : voir aussi ici.


  • AliGatorAliGator Membre, Modérateur
    Bravo Alf... dans 4 points t'as un chat offert !

    En effet, le prestataire précédent, au lieu d'utiliser l'auto-completion et de mettre la bonne signature de méthode, a mis un type de retour "float" au lieu de "CGFloat".

    Résultat, le compilateur, voyant que le type de retour attendu était "float" dans l'implémentation de la méthode, a fait un cast implicite de la valeur qu'on retournait (pourtant un CGFloat à  la base) en float.
    - En architecture 32 bits, aucun problème, car CGFloat et float sont synonymes.
    - Mais en architecture 64 bits, un CGFloat c'est un double. Résultat, quand la UITableView, après avoir appelé cette méthode de delegate, utilise la valeur retournée, elle s'attend à  avoir un CGFloat (donc un double), donc l'interprète en tant que tel sans se poser de question, car pour elle la bonne signature attendue du @protocol UITableViewDelegate lui dit que le type de retour est sensé être CGFloat = double. Résultat, il interprète un float, donc un nombre décimal représenté sur 32 bits... comme un double, sur 64 bits... avec les 32 bits de poids fort à  0 et les 32 bits de poids faible non-nuls (représentant le float qu'on a retourné), mais qui sont du coup tellement peu significatifs dans la représentation IEEE754 des nombres décimaux dans ce cas, que c'est tout comme si c'était zéro...

    En bref, rien que parce que le précédent développeur avait mis un "float" au lieu de "CGFloat", comme en 32 c'est équivalent, ça passait mais en 64 bits, la valeur était interprétée différemment et devenait tellement ridicule que ça donnait une hauteur de cellule nulle.

    Je vous dis pas le temps que le développeur qui a repris le code a passé avant de réaliser que le problème de ses hauteurs de UITableViewCells venait effectivement de là , surtout qu'à  l'origine c'était dans le cadre d'un portage de l'application de iOS7 vers iOS8 et que tout lui laissait penser que c'est un problème qui intervenait du fait du passage iOS7 -> iOS8 (et non pas comme en fait c'est le cas du passage 32 bits -> 64 bits).

    --

    Comme quoi, il suffit pas d'activer le flag "arm64" dans les Build Settings, faut quand même vérifier qu'on a pas codé comme les pieds... ou que les développeurs qui sont passés avant nous, ou les développeurs des librairies tierces qu'on utilise, n'ont pas codé comme les pieds, faisant un code qui marche "par chance" en 32 bits mais n'est pas portable.
  • chatonSauvagechatonSauvage Membre
    décembre 2014 modifié #16

    Merci pour ces conseils à  suivre :) il y a effectivement beaucoup plus a faire qu'un simple ajout de "arm64"


     


    Je rencontre cependant quelque petit souci de conversion comme par exemple sur :



    // takes @#123456
    + (UIColor *)colorWithHexString:(NSString *)str {
    const char *cStr = [str cStringUsingEncoding:NSASCIIStringEncoding];
    long x = strtol(cStr+1, NULL, 16);
    return [UIColor colorWithHex:x];
    }

    // takes 0x123456
    + (UIColor *)colorWithHex:(UInt32)col {
    unsigned char r, g, b;
    b = col & 0xFF;
    g = (col >> 8) & 0xFF;
    r = (col >> 16) & 0xFF;
    return [UIColor colorWithRed:(float)r/255.0f green:(float)g/255.0f blue:(float)b/255.0f alpha:1];
    }

    source : http://stackoverflow.com/questions/4265161/how-to-convert-hexadecimal-to-rgb


     


    Sans m'arrêter sur les 3 "float" qui sont maintenant des "CGFloat", le programme n'aime pas le "long x" (qui de toute façon est ensuite transformé en UInt32)


     


    Une idée ?


     


     


    Par ailleurs cette fonction là  aussi semble lui poser problème :


    http://stackoverflow.com/questions/652300/using-md5-hash-on-a-string-in-cocoa



    NSString *md5(NSString *str) {
    const char *cStr = [str UTF8String];
    unsigned char result[CC_MD5_DIGEST_LENGTH];
    CC_MD5( cStr, strlen(cStr), result );
    return [NSString stringWithFormat:@%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X,
    result[0], result[1],
    result[2], result[3],
    result[4], result[5],
    result[6], result[7],
    result[8], result[9],
    result[10], result[11],
    result[12], result[13],
    result[14], result[15]
    ];
    }

    Et je ne parle même pas du JSONKit qui n'a pas été mis a jour depuis bien longtemps (https://github.com/johnezang/JSONKit)


  • AliGatorAliGator Membre, Modérateur
    décembre 2014 modifié #17
    Pour le code du colorWithHex, ça ne m'étonne pas, dès que tu fais des masques et des décalages bits à  bits, il faut forcément faire gaffe étant donné qu'en 32 ou 64 bits tes variables n'ont pas la même taille par définition, donc si justement tu travailles sur la représentation binaire de ta variable (puisque tu fais des opérations bits à  bits), faut faire gaffe...

    Quelle erreur il te met sur le code du MD5 ?

    Pour JSONKit, il me semble qu'il est déprécié et a été abandonné depuis pas mal de temps (en même temps avec NSJSONSerialization on devrait avoir tout ce qu'il faut...)
  • Sur le code du MD5 :



    CC_MD5( cStr, strlen(cStr), result );

    strlen : Implicit conversion loses integer precision : 'unsigned long' to 'CC_LONG' (aka 'unsigned int')


     


     


     


    Merci pour le nom de la librairie pour le JSON (il faut juste que je l'installe a la place de l'autre :D


    Y'a plus qu'a coder le colorWithHex pour le 64  xd


     


    Je continuerais de faire des remontées de problèmes rencontrés au cas ou ça puisse aider d'autre personnes  :P


  • Et voila d'autres retour :


     


    Les fonctions prédéfini 



    -(BOOL)fieldIsMandatoryForRow:(int)rowIndex;
    - (NSString *)fieldTextForRow:(int)rowIndex;
    - (NSString *)fieldPlaceholderForRow:(int)rowIndex;

    Ne veulent pas passer en NSInteger  ( Conflicting parameter types in implementation of 'fieldPlaceholderFowRow': 'int' vs 'NSInteger' (aka 'long')


  • AliGatorAliGator Membre, Modérateur

    Sur le code du MD5 :


    CC_MD5( cStr, strlen(cStr), result );
    strlen : Implicit conversion loses integer precision : 'unsigned long' to 'CC_LONG' (aka 'unsigned int')

    Bon bah donc t'as ta réponse. Le type retourné est "CC_LONG" et pas "long". (CC_LONG doit certainement être un "typedef" défini différemment en 32 ou 64 bits).
    Donc il faut que tu types ta variable en conséquence. L'erreur est suffisamment explicite, non ?
     

    Merci pour le nom de la librairie pour le JSON (il faut juste que je l'installe a la place de l'autre :D )

    Heu c'est pas une librairie, c'est intégré dans le SDK depuis iOS 5 (donc ça fait un bail quand même) !
  • oups  ::)  c'est pas forcement un avantage d'utilisé ses acquis sans voir qu'il y a de nouvelles possibilités 


     


    retourne lire la doc 


Connectez-vous ou Inscrivez-vous pour répondre.