J'espère ne pas trop vous ennuyer avec mes questions (un peu basiques semble-t-il ?
Souvent personne ne pose ce genre de question de peur de se faire bâcher, Merci encore a vous deux.
Je partage votre point vue sur le coté compliqué de Sandy, je ne suis pas encore assez compétent pour comprendre dans le code la différence entre du pur Swift et du Swift/ObjC. Je ne comprends pas forcément vos réponses en profondeur mais le principe quand même et ça m'aide beaucoup.
@Draken - Si tu trouves par hasard ce tuto sur CoreData réécrit en pur Swift je suis preneur bien entendu. Je trouve Sandy un peu compliquée avec tout ces aller et retour d'une classe a l'autre, sans parler des oublis. A demeurant je trouve qu'elle s'exprime très bien.
Je pense que ce tuto était fait précédemment en ObjC pour ça qu'il y a des restes ?
Une closure est un bloc d'instructions qui ne sont pas destinés à être exécutés tout de suite, mais plus tard. C'est une sorte de processus multi-tâche, indépendant du reste de l'application. Cela permet de manipuler des séquences de code comme des variables.
Je vais juste revenir là -dessus. Les block ou closures (cela dépend de ton language) sont en effet très utiles en mode asynchrone, et sont un concept à assimiler puisqu'il est souvent utilisé.
Cependant, une petite nuance, un block/closure ne signifie pas forcément que c'est asynchrone. Par exemple, les nombreux blocks d'itérations de (NS)Array, NSAttributedString, etc, sont synchrone eux.
Cependant, une petite nuance, un block/closure ne signifie pas forcément que c'est asynchrone. Par exemple, les nombreux blocks d'itérations de (NS)Array, NSAttributedString, etc, sont synchrone eux.
J'espère ne pas trop vous ennuyer avec mes questions (un peu basiques semble-t-il ?
Bah non, en plus je comprend mieux les choses après les avoir expliqués. Répondre à des questions m'aide à progresser.
Je partage votre point vue sur le coté compliqué de Sandy, je ne suis pas encore assez compétent pour comprendre dans le code la différence entre du pur Swift et du Swift/ObjC. Je ne comprends pas forcément vos réponses en profondeur mais le principe quand même et ça m'aide beaucoup.
Un code pur Swift est un code sans les objets NSQuelqueChose. Ce sont de vénérables ancêtres provenant d'un lointain passé (NS = Next Step, le système d'exploitation des ordinateurs que Jobs avait développé après s'être fait viré d'Apple). Au début le Swift fonctionnais avec les NSTruc, puis il a été réécrit avec de nouvelles classes similaires dans le principe, avec une syntaxe plus simple et des fonctionnalités améliorées.
Avoir des NSArrays et des NSDictionnary dans un code Swift c'est comme voir une locomotive à vapeur sur une ligne de TGV. ça marche mais c'est plus compliqué, moins efficace et .. étrange.
Un code pur Swift est un code sans les objets NSQuelqueChose. Ce sont de vénérables ancêtres provenant d'un lointain passé (NS = Next Step, le système d'exploitation des ordinateurs que Jobs avait développé après s'être fait viré d'Apple). Au début le Swift fonctionnais avec les NSTruc, puis il a été réécrit avec de nouvelles classes similaires dans le principe, avec une syntaxe plus simple et des fonctionnalités améliorées.
Prefix disparu qui est dommage je trouve. Pas le fait de perdre NS, mais de ne pas le remplacer, par SW par exemple.
Car au final, à expliquer, cela peut prêter à confusion, car on dit souvent "un NSString" pour dire "un objet de classe NSString", mais "data", c'est un mot très très commun, et cela peut tout mélanger dans la tête d'un débutant, si on parle de données, de la classe Data, ou d'une instance de Data. Et quand tu veux faire des recherches sur ton SE préféré, rechercher Data, String, tu seras plombé par des résultats liés à d'autres langages, alors qu'un NSString, c'est propre au monde d'Apple.
quand tu veux faire des recherches sur ton SE préféré, rechercher Data, String, tu seras plombé par des résultats liés à d'autres langages, alors qu'un NSString, c'est propre au monde d'Apple.
Oui, c'est assez casse-pied de voir tous ces liens sur Windows et Android alors que tu cherches de l'info pour iOS. Même en ajoutant iOS ou Swift dans la recherche on tombe sur une foultitude de liens sans intéret.
De mon avis, juste en lisant les petits bouts de code ici, c'est évident qu'elle n'a maà®trisé ni les principes de programmation Swift, ni les APIs UIKit.
Je vois que le cours est actuellement en offre à 95% de réduction mais, même a ce prix, il ne le vaut.
Effectivement, il y a des commentaires meurtriers, notamment sur la partie CoreData.
J'ai aussi repéré des choses curieuses dans d'autres tutos, comme par exemple le jeu de casino. Elle positionne ces contraintes pour le mode portrait, sans penser à ce qui se passe en orientation portrait. Cela ne serait pas gênant si elle bloquait le terminal en portrait, mais non justement. C'est un petit détail, mais choquant pour une démonstration destiné à des novices.
Je pense que Sandy est une bonne formatrice, mais qu'elle ne pratique pas couramment le développement iOS. Pour moi, le cours a probablement été écrit à la vas-vite, pour répondre à une demande éditoriale dans l'urgence.
EDIT : Je viens de regarder la première application développée par Sandy, dans son cours : un minuteur de cuisine. Elle n'y gère pas non plus les contraintes en mode paysage, et ne bloque pas ce mode dans l'application. Cela me conforte dans l'idée qu'elle a rédigée le cours sans une grande expérience pratique du développement iOS.
Je pense que Sandy est une bonne formatrice, mais qu'elle ne pratique pas couramment le développement iOS. Pour moi, le cours a probablement été écrit à la vas-vite, pour répondre à une demande éditoriale dans l'urgence.
Elle se décrit, tout d'abord, comme développeuse Web. De mon avis et de mon expérience comme consultante, c'est vachement différent qu'un développeur "natif".
EDIT : Je viens de regarder la première application développée par Sandy, dans son cours : un minuteur de cuisine. Elle n'y gère pas non plus les contraintes en mode paysage, et ne bloque pas ce mode dans l'application. Cela me conforte dans l'idée qu'elle a rédigée le cours sans une grande expérience pratique du développement iOS.
C'est comme les gens qui font les vidéos avec leurs iPhones en mode portrait que l'on puisse voir à la télé. "Oh ! on ne m'a pas dit que j'aurais pu faire la rotation" ::)
@Daken : J'avais un peu capté l'histoire de Classes NS...
sur ton dernier post ces exemples n'ont pas la prétention d'être complet et ne propose pas des applications abouties
@Larme : Je capte mal tes remarques sur les classes NS ou des classes dont le nom est courant, c'est tout de même bien le compilateur qui se débrouille avec tout ça ?
@Joanna Carter : Les cours de Sandy sont vraiment abordable et propose des tutos simples correspondants souvent a des applications courantes et nécessaires et permettent de créer sa propre application.
Et puis bon les Trucs efficaces justes et en français avec Swift 3 sont plus que rares.
Le MOOC c'est bien mais carrément théorique et prévu pour des étudiants informatiques. Il se plaint que Storyboard fait clicodrome mais ses cours sont très genre pisseur de code. Il est évident qu'Apple se dirige vers du vrai RAD. Voir l'application playground destinée a des enfants et en Français en plus (pas encore sur Mac pourquoi ?). Pour ma part je trouve plus facile de pister une erreur dans le Storyboard que dans du code.
J'ai opté pour ce cours rapport au prix bien sûr et que ça avait l'air assez complet, probablement l'arriver de Swift 4, j'aimerais terminer l'ensemble avant d'aborder Swift 4.
@Joanna Carter : Les cours de Sandy sont vraiment abordable et propose des tutos simples correspondants souvent a des applications courantes et nécessaires et permettent de créer sa propre application.
Mais les exemples sont très mal écrits ; ce qui pourrait donner l'impression d'avoir entendu comment coder mais, en effet, on n'a appris que les mauvaises pratiques.
Et puis bon les Trucs efficaces justes et en français avec Swift 3 sont plus que rares.
De mon avis, on peut apprendre mieux les trucs ici qu'avec Sandy. Ici, on peut trouver les gens qui sont très sympas, qui parlent français et qui donnent leurs temps et leurs expertises gratuitement. Il ne faut que demander.
Le MOOC c'est bien mais carrément théorique et prévu pour des étudiants informatiques. Il se plaint que Storyboard fait clicodrome mais ses cours sont très genre pisseur de code. Il est évident qu'Apple se dirige vers du vrai RAD. Voir l'application playground destinée a des enfants et en Français en plus (pas encore sur Mac pourquoi ?). Pour ma part je trouve plus facile de pister une erreur dans le Storyboard que dans du code.
Et tu as raison de préférer les storyboards. Bien que l'on puisse faire les même choses en code, les storyboards servent à faciliter le design et le débogage. Mais il faut apprendre les deux (code et storyboard) et savoir comment les bien intégrer.
Moi, j'écris pas mal de code, mais c'est souvent pour créer les composants que l'on puisse mettre dans les storyboards.
Désolée que c'est en anglais mais, si tu voulais voir comment créer un composant pour valider les touches de clavier (comme pour les UITextField et les nombres décimals) que l'on puisse mettre dans un UIViewController, tu pourrais cliquer sur https://joannamacdev.github.io/Interactors-Part-2/ .
Peut-être c'est un peut trop compliqué pour un débutant, mais ça montre les principes de bon code (au moins, j'espère) et on trouvera dans les articles liés comment utiliser bien les closures. N'hésites pas a poser des questions si tu y allais :-*
Au niveau plus bas, si tu n'as bien compris le code de Sandy, continues de poser les questions ici
sur ton dernier post ces exemples n'ont pas la prétention d'être complet et ne propose pas des applications abouties
Gercofis, bloquer l'orientation d'une application se fait en 10 secondes avec Storyboard.
@Joanna Carter : Les cours de Sandy sont vraiment abordable et propose des tutos simples correspondants souvent a des applications courantes et nécessaires et permettent de créer sa propre application.
Et puis bon les Trucs efficaces justes et en français avec Swift 3 sont plus que rares.
J'ai opté pour ce cours rapport au prix bien sûr et que ça avait l'air assez complet, probablement l'arriver de Swift 4, j'aimerais terminer l'ensemble avant d'aborder Swift 4.
Oui, les cours de Sandy ne sont pas mauvais pour un débutant. Il vaut mieux une formation incomplète que pas de formation du tout, du moins au prix actuel de 15 euros. Au prix théorique de 150 € c'est carrément du vol.
Sandy aurait mieux fait d'éviter de traiter les sujets qu'elle ne domine pas pour se concentrer sur la base.
Dans l'état actuel c'est un mauvais "cours complet sur Swift 3 " (pour reprendre le marketing d'Udemy). Et un cours d'introduction acceptable (à condition de zapper les chapitres trop techniques comme CoreData).
Prefix disparu qui est dommage je trouve. Pas le fait de perdre NS, mais de ne pas le remplacer, par SW par exemple.
Car au final, à expliquer, cela peut prêter à confusion, car on dit souvent "un NSString" pour dire "un objet de classe NSString", mais "data", c'est un mot très très commun, et cela peut tout mélanger dans la tête d'un débutant, si on parle de données, de la classe Data, ou d'une instance de Data. Et quand tu veux faire des recherches sur ton SE préféré, rechercher Data, String, tu seras plombé par des résultats liés à d'autres langages, alors qu'un NSString, c'est propre au monde d'Apple.
J'entends ce que tu dis mais les préfixes ne se trouve que rarement avec les autres langues. Auparavant, c'était conçu pour différencier entre les classes d'Apple et ceux des autres développeurs.
Avec Swift ce n'est plus nécessaire parce qu'on peut utiliser les noms des modules.
public class Command : CommandProtocol, NotifyPropertyChangedProtocol
{
// MARK: nested types
enum Error : Swift.Error
{
case notPermitted
case commandDisabled
}
...
}
ça me permet de faire les trucs, comme ci-dessus, d'avoir mon propre enum Error qui est spécifique à ma classe Command.
@Larme : Je capte mal tes remarques sur les classes NS ou des classes dont le nom est courant, c'est tout de même bien le compilateur qui se débrouille avec tout ça ?
Je parle d'explications et d'abus de langages.
Je suis en train d'écrire quelques articles sur des sujets qui m'intéresse, et c'est parfois gênant d'être forcé de dire que lorsque je parle de "data", il s'agit de la classe, ou si je fais un abus de langage, que je dis que c'est une instance de la classe Data, ou alors de la récupérations de données (qui même si elle en récup' en des objects Data, je veux parler une fois serializée).
En ce moment, j'en écris un sur les Dates, et NSDateFormatter, et c'est un mic mac pas possible. J'suis obligé de ne pas commencer mes phrase par Dates, car la majuscule est censée dire que c'est le classe, mais ça peut être juste le mot en anglais ou en français et pas la partie "code". Du coup, j'ai abandonné, et dit que je ne parlerais des classes/objets qu'en utilisant NS ou SW pour du Swift (car elles ne sont pas 100% réflectives, y'a quelques nuances possibles).
Ensuite, prendre le nom tel quel en anglais et le transformer en classe, c'est pas forcément évident pour les recherches et ne limite plus les recherches à Swift ou à Objective-C sur Google.
"NSData to NSString", c'est explicite, "Data to String", il faut que je rajoute "Swift" derrière pour espérer avoir des résultats concrets et pas des réponses concernant Java, Python ou autre dont je n'ai absolument rien à carrer car je m'intéresse à Swift. Disons que c'était un p'tit plus.
@Joanna : En fait je trouvais ces prefixes pratiques. Un p'tit plus de 2 lettres qui en plus me rappelait le framework d'origine (si c'était un truc UIKit, MapKit, etc.).
Et oui, c'est aussi parce qu'en Objective-C, on ne peut pas avoir deux classes du même nom, même si y'a des modules/levels différents, une histoire de namespace je crois.
Pour reprendre l'exemple de UIView.animate, la complétion est le morceau de code que iOS exécute à la fin de l'animation, juste avant de rendre la main.
Progressif, bien entendu, mais surtout le feedback du formateur est excellent ; rien à voir avec celui de Sandy qui, parfois, me semble pour le moins étrange...
Absolument fanfan, ce cours est bien meilleur, mais il coûte 145 €, c'est une somme quand même.. Et son auteur n'a pas l'air d'apprécier les promotions. Je l'ai acheté lors d'une rare promotion à 30-40 €. A 145 € je ne l'aurais jamais pris.
Surtout que tu ne dois pas en avoir énormément besoin
Et pourtant si ! Je suis un autodidacte avec un réel blocage envers l'anglais ( >:( ), et de grosses lacunes dans certains sujets. Je cherche à combler mes manques en suivant des cours structurés. Par exemple, je n'avais jamais touché à CoreData avant de lire le post de Gercofis et de tenter d'y répondre.
Structurer les choses dans mon esprit pour les expliquer, m'aide à les comprendre. C'est pour cela que je répond à de nombreux posts et rédige de petits tutos sur le forum.
@Daken pour ce qui est de l'anglais j'en suis au même point, par contre je joue avec Duolingo sur l'iPad ou l'iPhone, sans que ce soit parfait même au bout de 2 ans je capte quand même beaucoup mieux !!
2017-06-05 16:34:02.688 ListeTodos[24518:4574373] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'UILabel: the use of CGColor for color properties or inside attributed strings is not supported.'
Pour le reste c'est correct. Enfin disons que c'est une copie presque correcte du code de Sandy. Je n'aime pas ce code, parce qu'il fait plusieurs choses à la fois.
Moi j'aurais écrit une fonction indépendante pour formater le texte avant affichage. Quelque chose comme :
func miseEnFormeTexteBarre(texte:String) -> NSAttributedString {
// UIFont() retourne un optional.
// On le force en non-optional en postulant
// que la création d'une police réussit toujours.
// Une erreur dans le nom de police => gros plantage !
let font = UIFont(name: "Arial", size: 17)!
let attributs = [
NSFontAttributeName: font,
NSForegroundColorAttributeName: UIColor.green,
NSStrikethroughStyleAttributeName:
NSNumber(value: NSUnderlineStyle.styleSingle.rawValue)
]
let attrStr = NSAttributedString(string: texte, attributes: attributs)
return attrStr
}
Pour débuger une application, il est préférable d'avoir un code bien structuré, avec des briques bien distinctes. Combiner la mise en forme d'un texte et son affichage dans un label n'est pas une bonne idée.
J'ai refait la même chose, avec 3 étapes :
- récupération du texte
- création d'un NSAttributedString contenant le texte formaté
- affichage dans un label
let strTexte = toto.quelqueChose
let attrTexte = miseEnFormeTexteBarre(texte: strTexte)
label.attributedText = attrTexte
Problème : il y a une bug plantante dans ce code, dont je ne connais pas l'origine.
La stratégie de base pour localiser la source de l'erreur, est d'insérer des print() un peu partout pour voir ce qui se passe.
Label : <UILabel: 0x7a04c1f0; frame = (16 94; 288 39); text = 'Acheter le wasabi pour le...'; opaque = NO; autoresize = RM+BM; userInteractionEnabled = NO; layer = <_UILabelLayer: 0x7a04c590>>
J'introduis une minuscule erreur dans le code et je relance. Cela se passe moins bien :
Etape 1
texte brut : Acheter le wasabi pour les sushis
---
fatal error: unexpectedly found nil while unwrapping an Optional value
L'étape 1 s'est déroulé normalement, l'erreur vient donc de l'étape 2. Après 2 nanos-secondes de réflexion (normal j'ai fait l'erreur sciemment), je découvre que j'ai tenté de créer une font avec la police "zArial" qui n'existe pas !
Voilà , c'est la démarche de base pour débuger. Utiliser des print() pour voir où se produit l'erreur, et afficher le contenu des variables importantes.
2017-06-05 16:34:02.688 ListeTodos[24518:4574373] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'UILabel: the use of CGColor for color properties or inside attributed strings is not supported.'
c'est UIColor.green qui est utilisé mais bon
C'est donc l'autre raison :
reason: 'UILabel: the use of CGColor for color properties or inside attributed strings is not supported.'
Il y a vraisemblablement un problème avec ton NSAttributedString.
Essaie d'afficher son contenu, ou d'en construire une version sans attribut, juste une chaà®ne brute pour voir.
let attrStr = NSAttributedString(string: "Un texte quelconque")
Je n'ai pas trouvé le Bug, j'ai copié code et ça marche, c'est vrai que j'aime bien comprendre, mais bon rien de bien important.
En cherchant j'ai trouvé un Tuto, même s'il est Anglais c'est très compréhensible et ça me semble une bonne base pour refaire cette application carrément plus propre question code.
Réponses
J'espère ne pas trop vous ennuyer avec mes questions (un peu basiques semble-t-il ?
Souvent personne ne pose ce genre de question de peur de se faire bâcher, Merci encore a vous deux.
Je partage votre point vue sur le coté compliqué de Sandy, je ne suis pas encore assez compétent pour comprendre dans le code la différence entre du pur Swift et du Swift/ObjC. Je ne comprends pas forcément vos réponses en profondeur mais le principe quand même et ça m'aide beaucoup.
@Draken - Si tu trouves par hasard ce tuto sur CoreData réécrit en pur Swift je suis preneur bien entendu. Je trouve Sandy un peu compliquée avec tout ces aller et retour d'une classe a l'autre, sans parler des oublis. A demeurant je trouve qu'elle s'exprime très bien.
Je pense que ce tuto était fait précédemment en ObjC pour ça qu'il y a des restes ?
Je vais juste revenir là -dessus. Les block ou closures (cela dépend de ton language) sont en effet très utiles en mode asynchrone, et sont un concept à assimiler puisqu'il est souvent utilisé.
Cependant, une petite nuance, un block/closure ne signifie pas forcément que c'est asynchrone. Par exemple, les nombreux blocks d'itérations de (NS)Array, NSAttributedString, etc, sont synchrone eux.
Qui peut le plus, peut le moins ..
Bah non, en plus je comprend mieux les choses après les avoir expliqués. Répondre à des questions m'aide à progresser.
Un code pur Swift est un code sans les objets NSQuelqueChose. Ce sont de vénérables ancêtres provenant d'un lointain passé (NS = Next Step, le système d'exploitation des ordinateurs que Jobs avait développé après s'être fait viré d'Apple). Au début le Swift fonctionnais avec les NSTruc, puis il a été réécrit avec de nouvelles classes similaires dans le principe, avec une syntaxe plus simple et des fonctionnalités améliorées.
Avoir des NSArrays et des NSDictionnary dans un code Swift c'est comme voir une locomotive à vapeur sur une ligne de TGV. ça marche mais c'est plus compliqué, moins efficace et .. étrange.
Prefix disparu qui est dommage je trouve. Pas le fait de perdre NS, mais de ne pas le remplacer, par SW par exemple.
Car au final, à expliquer, cela peut prêter à confusion, car on dit souvent "un NSString" pour dire "un objet de classe NSString", mais "data", c'est un mot très très commun, et cela peut tout mélanger dans la tête d'un débutant, si on parle de données, de la classe Data, ou d'une instance de Data. Et quand tu veux faire des recherches sur ton SE préféré, rechercher Data, String, tu seras plombé par des résultats liés à d'autres langages, alors qu'un NSString, c'est propre au monde d'Apple.
Oui, c'est assez casse-pied de voir tous ces liens sur Windows et Android alors que tu cherches de l'info pour iOS. Même en ajoutant iOS ou Swift dans la recherche on tombe sur une foultitude de liens sans intéret.
À propos les cours de Sandy, il ne faut que lire les mauvaises notes https://www.udemy.com/cours-complet-ios10-swift-3-creez-15-applications/(Avis des participants) pour trouver mon avis sur son code.
De mon avis, juste en lisant les petits bouts de code ici, c'est évident qu'elle n'a maà®trisé ni les principes de programmation Swift, ni les APIs UIKit.
Je vois que le cours est actuellement en offre à 95% de réduction mais, même a ce prix, il ne le vaut.
En plus, j'ai vu cette "exigence"
Conseiller quelqu'un d'utiliser un Hackintosh ? Quoi ! Surtout qu'elle parle de soumettre les applis dans l'AppStore ::)
Effectivement, il y a des commentaires meurtriers, notamment sur la partie CoreData.
J'ai aussi repéré des choses curieuses dans d'autres tutos, comme par exemple le jeu de casino. Elle positionne ces contraintes pour le mode portrait, sans penser à ce qui se passe en orientation portrait. Cela ne serait pas gênant si elle bloquait le terminal en portrait, mais non justement. C'est un petit détail, mais choquant pour une démonstration destiné à des novices.
Je pense que Sandy est une bonne formatrice, mais qu'elle ne pratique pas couramment le développement iOS. Pour moi, le cours a probablement été écrit à la vas-vite, pour répondre à une demande éditoriale dans l'urgence.
EDIT : Je viens de regarder la première application développée par Sandy, dans son cours : un minuteur de cuisine. Elle n'y gère pas non plus les contraintes en mode paysage, et ne bloque pas ce mode dans l'application. Cela me conforte dans l'idée qu'elle a rédigée le cours sans une grande expérience pratique du développement iOS.
Elle se décrit, tout d'abord, comme développeuse Web. De mon avis et de mon expérience comme consultante, c'est vachement différent qu'un développeur "natif".
C'est comme les gens qui font les vidéos avec leurs iPhones en mode portrait que l'on puisse voir à la télé. "Oh ! on ne m'a pas dit que j'aurais pu faire la rotation" ::)
Pour vous répondre a tous les 3 :
@Daken : J'avais un peu capté l'histoire de Classes NS...
sur ton dernier post ces exemples n'ont pas la prétention d'être complet et ne propose pas des applications abouties
@Larme : Je capte mal tes remarques sur les classes NS ou des classes dont le nom est courant, c'est tout de même bien le compilateur qui se débrouille avec tout ça ?
@Joanna Carter : Les cours de Sandy sont vraiment abordable et propose des tutos simples correspondants souvent a des applications courantes et nécessaires et permettent de créer sa propre application.
Et puis bon les Trucs efficaces justes et en français avec Swift 3 sont plus que rares.
Le MOOC c'est bien mais carrément théorique et prévu pour des étudiants informatiques. Il se plaint que Storyboard fait clicodrome mais ses cours sont très genre pisseur de code. Il est évident qu'Apple se dirige vers du vrai RAD. Voir l'application playground destinée a des enfants et en Français en plus (pas encore sur Mac pourquoi ?). Pour ma part je trouve plus facile de pister une erreur dans le Storyboard que dans du code.
J'ai opté pour ce cours rapport au prix bien sûr et que ça avait l'air assez complet, probablement l'arriver de Swift 4, j'aimerais terminer l'ensemble avant d'aborder Swift 4.
Mais les exemples sont très mal écrits ; ce qui pourrait donner l'impression d'avoir entendu comment coder mais, en effet, on n'a appris que les mauvaises pratiques.
De mon avis, on peut apprendre mieux les trucs ici qu'avec Sandy. Ici, on peut trouver les gens qui sont très sympas, qui parlent français et qui donnent leurs temps et leurs expertises gratuitement. Il ne faut que demander.
Et tu as raison de préférer les storyboards. Bien que l'on puisse faire les même choses en code, les storyboards servent à faciliter le design et le débogage. Mais il faut apprendre les deux (code et storyboard) et savoir comment les bien intégrer.
Moi, j'écris pas mal de code, mais c'est souvent pour créer les composants que l'on puisse mettre dans les storyboards.
Désolée que c'est en anglais mais, si tu voulais voir comment créer un composant pour valider les touches de clavier (comme pour les UITextField et les nombres décimals) que l'on puisse mettre dans un UIViewController, tu pourrais cliquer sur https://joannamacdev.github.io/Interactors-Part-2/ .
Peut-être c'est un peut trop compliqué pour un débutant, mais ça montre les principes de bon code (au moins, j'espère) et on trouvera dans les articles liés comment utiliser bien les closures. N'hésites pas a poser des questions si tu y allais :-*
Au niveau plus bas, si tu n'as bien compris le code de Sandy, continues de poser les questions ici
Gercofis, bloquer l'orientation d'une application se fait en 10 secondes avec Storyboard.
Oui, les cours de Sandy ne sont pas mauvais pour un débutant. Il vaut mieux une formation incomplète que pas de formation du tout, du moins au prix actuel de 15 euros. Au prix théorique de 150 € c'est carrément du vol.
Sandy aurait mieux fait d'éviter de traiter les sujets qu'elle ne domine pas pour se concentrer sur la base.
Dans l'état actuel c'est un mauvais "cours complet sur Swift 3 " (pour reprendre le marketing d'Udemy). Et un cours d'introduction acceptable (à condition de zapper les chapitres trop techniques comme CoreData).
J'entends ce que tu dis mais les préfixes ne se trouve que rarement avec les autres langues. Auparavant, c'était conçu pour différencier entre les classes d'Apple et ceux des autres développeurs.
Avec Swift ce n'est plus nécessaire parce qu'on peut utiliser les noms des modules.
ça me permet de faire les trucs, comme ci-dessus, d'avoir mon propre enum Error qui est spécifique à ma classe Command.
Je parle d'explications et d'abus de langages.
Je suis en train d'écrire quelques articles sur des sujets qui m'intéresse, et c'est parfois gênant d'être forcé de dire que lorsque je parle de "data", il s'agit de la classe, ou si je fais un abus de langage, que je dis que c'est une instance de la classe Data, ou alors de la récupérations de données (qui même si elle en récup' en des objects Data, je veux parler une fois serializée).
En ce moment, j'en écris un sur les Dates, et NSDateFormatter, et c'est un mic mac pas possible. J'suis obligé de ne pas commencer mes phrase par Dates, car la majuscule est censée dire que c'est le classe, mais ça peut être juste le mot en anglais ou en français et pas la partie "code". Du coup, j'ai abandonné, et dit que je ne parlerais des classes/objets qu'en utilisant NS ou SW pour du Swift (car elles ne sont pas 100% réflectives, y'a quelques nuances possibles).
Ensuite, prendre le nom tel quel en anglais et le transformer en classe, c'est pas forcément évident pour les recherches et ne limite plus les recherches à Swift ou à Objective-C sur Google.
"NSData to NSString", c'est explicite, "Data to String", il faut que je rajoute "Swift" derrière pour espérer avoir des résultats concrets et pas des réponses concernant Java, Python ou autre dont je n'ai absolument rien à carrer car je m'intéresse à Swift. Disons que c'était un p'tit plus.
@Joanna : En fait je trouvais ces prefixes pratiques. Un p'tit plus de 2 lettres qui en plus me rappelait le framework d'origine (si c'était un truc UIKit, MapKit, etc.).
Et oui, c'est aussi parce qu'en Objective-C, on ne peut pas avoir deux classes du même nom, même si y'a des modules/levels différents, une histoire de namespace je crois.
N'oubliant pas que on n'avait que les classes un Objective-C alors qu'avec Swift on a plus de structs :
NSString (classe) - String (struct)
NSDictionary (classe) - Dictionary (struct)
NSData (classe) - Data (struct)
...
De mon avis, avoir les préfixes (comme SW) me souviendrait trop que c'est une classe, à la place d'une struct.
Puisqu'on m'invite a poser des questions que signifie le mot clé "complétion" ?
Ne serait-ce pas une bonne idée que de faire le programme de Sandy en Swift pur et dur Daken en a déjà fait un bout ?
complétion, complétude, terminer par ..
bloc de code a exécuter à la fin d'un traitement.
Pour reprendre l'exemple de UIView.animate, la complétion est le morceau de code que iOS exécute à la fin de l'animation, juste avant de rendre la main.
Le bon cours sur Udemy, c'est celui de Maxime Britto :
https://www.udemy.com/ios-10-et-swift-3-le-cours-complet/learn/v4/overview
Progressif, bien entendu, mais surtout le feedback du formateur est excellent ; rien à voir avec celui de Sandy qui, parfois, me semble pour le moins étrange...
Absolument fanfan, ce cours est bien meilleur, mais il coûte 145 €, c'est une somme quand même.. Et son auteur n'a pas l'air d'apprécier les promotions. Je l'ai acheté lors d'une rare promotion à 30-40 €. A 145 € je ne l'aurais jamais pris.
Surtout que tu ne dois pas en avoir énormément besoin
Promo aussi il y a quelques semaines...
Et pourtant si ! Je suis un autodidacte avec un réel blocage envers l'anglais ( >:( ), et de grosses lacunes dans certains sujets. Je cherche à combler mes manques en suivant des cours structurés. Par exemple, je n'avais jamais touché à CoreData avant de lire le post de Gercofis et de tenter d'y répondre.
Structurer les choses dans mon esprit pour les expliquer, m'aide à les comprendre. C'est pour cela que je répond à de nombreux posts et rédige de petits tutos sur le forum.
@Daken pour ce qui est de l'anglais j'en suis au même point, par contre je joue avec Duolingo sur l'iPad ou l'iPhone, sans que ce soit parfait même au bout de 2 ans je capte quand même beaucoup mieux !!
session 76 > 6'06" j'ai rajouté le code suivant :
@Gercofis. S'il te plaà®t utiliser les balises code !
Peux-tu nous en dire plus sur ton erreur ?
Il faut apprendre à débugguer :
Regarder si dans la console, il n'y a pas un message d'erreur qui donne souvent de très grandes indications.
Trouver la ligne posant problème.
Regarder les valeurs de chaque variables, regarder si elles ne sont pas nil et que leur classe est correct.
Est-ce que todo est nil ?
Par exemple, si todo est nil, tu verras dans la console :
Ce qui explique bien l'erreur.
Ou alors une histoire d'optional value et de wrapping/unwrapping, et cell est nil. Mais là , appeler un UILabel cell, c'est pas évident à la relecture.
c'est UIColor.green qui est utilisé mais bon
Pour commencer tu t'es trompé en recopiant le source. Tu n'arriveras pas à barrer ton texte avec ça.
Tu as recopié la section de code affichant le texte en normal. Pour le barrer, il faut procéder comme ça :
Au lieu de :
Pour le reste c'est correct. Enfin disons que c'est une copie presque correcte du code de Sandy. Je n'aime pas ce code, parce qu'il fait plusieurs choses à la fois.
Moi j'aurais écrit une fonction indépendante pour formater le texte avant affichage. Quelque chose comme :
Pour débuger une application, il est préférable d'avoir un code bien structuré, avec des briques bien distinctes. Combiner la mise en forme d'un texte et son affichage dans un label n'est pas une bonne idée.
J'ai refait la même chose, avec 3 étapes :
- récupération du texte
- création d'un NSAttributedString contenant le texte formaté
- affichage dans un label
Problème : il y a une bug plantante dans ce code, dont je ne connais pas l'origine.
La stratégie de base pour localiser la source de l'erreur, est d'insérer des print() un peu partout pour voir ce qui se passe.
Dans mon exemple, tout se déroule correctement. L'affichage ressemble à celui-ci :
J'introduis une minuscule erreur dans le code et je relance. Cela se passe moins bien :
L'étape 1 s'est déroulé normalement, l'erreur vient donc de l'étape 2. Après 2 nanos-secondes de réflexion (normal j'ai fait l'erreur sciemment), je découvre que j'ai tenté de créer une font avec la police "zArial" qui n'existe pas !
Voilà , c'est la démarche de base pour débuger. Utiliser des print() pour voir où se produit l'erreur, et afficher le contenu des variables importantes.
Alors t'as trouvé ta bug, Gercofis ?
C'est donc l'autre raison :
Il y a vraisemblablement un problème avec ton NSAttributedString.
Essaie d'afficher son contenu, ou d'en construire une version sans attribut, juste une chaà®ne brute pour voir.
Je n'ai pas trouvé le Bug, j'ai copié code et ça marche, c'est vrai que j'aime bien comprendre, mais bon rien de bien important.
En cherchant j'ai trouvé un Tuto, même s'il est Anglais c'est très compréhensible et ça me semble une bonne base pour refaire cette application carrément plus propre question code.
https://revs.runtime-revolution.com/core-data-on-ios-10-a-brief-overview-with-an-example-dc6e0ce844a5
en plus c'est la même sujet.
Je voudrais refaire ce tuto avec comme thème une sorte de chek-liste de chose a faire, mais pour différent thèmes donc une hiérarchie de plus.
Par exemple thème: la pèche : les cannes, l'épuisette, les leurres, etc...
Casto: mitigeur, colle, peinture, tournevis, etc...
on est tout a fait dans ce schéma là .
J'ai fait ce dernier Tuto , que je tente d'adapter
PS: en plus je suis en plein travaux de bricolage, même si je gamberge un peu la dessus je n'y suis pas tout le temps forcément.