Date limite soumission SDK 7

NiClou · novembre 2014

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.

Joanna Carter · novembre 2014

https://developer.apple.com/news/?id=10202014a

Draken · novembre 2014

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

NiClou · novembre 2014

Super !

Merci.

chatonSauvage · décembre 2014

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

Geoffrey · décembre 2014

faut rajouter arm64 dans les architectures supportées

chatonSauvage · décembre 2014

??? 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 ? Moi qui m'inquiétais d'avoir des centaines de lignes de code à modifier me voila rassurée

Geoffrey · décembre 2014

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).

AliGator · décembre 2014

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 !

Geoffrey · décembre 2014



CGSize size = CGSizeMake(200, 60);

size += 40;

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

jpimbert · décembre 2014

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 ...

Geoffrey · décembre 2014

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

jpimbert · décembre 2014

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

Alf1996 · décembre 2014

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.

AliGator · décembre 2014

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.

chatonSauvage · décembre 2014

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)

AliGator · décembre 2014

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...)

chatonSauvage · décembre 2014

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 )

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

chatonSauvage · décembre 2014

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')

AliGator · décembre 2014

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 )

Heu c'est pas une librairie, c'est intégré dans le SDK depuis iOS 5 (donc ça fait un bail quand même) !

chatonSauvage · décembre 2014

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

Date limite soumission SDK 7

Réponses