AutoLayout et Stackview

• en bas storyboard : on view as qui donne la taille (par défaut iPhone 8) et simulateur par défaut
• élément placé de manière fixe, taille fixe, totalement figé (pas un soucis quand il n'y avait qu'un iPhone)
• rotation on s'en rend compte
• techno depuis un moment : autolayout
• attention auto mais il y a pas mal de choses à faire
• nous qui allons définir des contraintes pour expliquer les relations entre éléments
• combinaison de contraintes
• splitscreen 1/3 ou 2/3 ce ne sera pas grave l'UI va se réadapter
• différents types de contraintes : alignement (centrer dans le parent, aligner bord gauches pour plusieurs éléments ect)

AutoLayout et Stackview

• taille fixe
• accrocher nos éléments au bords gauche et/ou droite
• taille de texte ? contraintes pas obligatoires donc il faut en mettre suffisement pour résoudre ses soucis, mais ne pas en avoir trop de conflits (on va finir par 3 = 2), dans ce cas xcode 
  • champs texte : par défaut trop de text : il va afficher ...
  • On peut gérer avec l'auto shring ou taille minimal max, rapprocher les caractères ect
  • autoriser à allez à la ligne
• exemple keynote : button centré avec taille de texte qui prend plus ou moins de place (taille texte VS bord de l'écran car hello, gouten tag et bonjour ne prennent pas la même taille)

AutoLayout et Stackview

• forcément en mettre pour les positions : sinon bord gauche en haut
• taille donné par le contenu...pas besoin obligatoirement de donner de taille, ça veut pas dire qu'on en met jamais, marge bord droite quand même
• Gérer les textes en arabe : je dis vulgairement à gauche et à droite mais c'est en avant l'élément et après l'élément (RTL : leading et trailling) on peut inverser grace à RTL
• ouverture du panneau des conflits : propose des solutions : choisi celle que tu veux suppr
•  

cas particuliers

• contraintes pas par storyboard
• des fois pas besoin
• mais sinon toujours storyboard car moins on a de code == moins d'erreur, facilité relecture et évolution
• quand tu as bcp d'écran == bcp trop de code
• si 3 à 4 écrans pourquoi pas

Découpage des Storyboard

• bonne pratique !

Safe Area

• mettre infos et controls non visible au user
• je mets mes éléments n'importe où dans ma vue
• bar de status qui prenait 20px...pbl car écran qui ne son plus carré avec des encoche
• pas vulgairement que les vues
• Définir quelles sont les zones dans lesquelles on ne veut pas de problème
• On veut être à X de la safe area
• iPhone 10 et iPhone 8 : certain que l'info
• safe area : contenus toujours utiles
• pas important : appli de carte, boutons actions dans safe area, que la map dépasse de la safe area pas grave
• Donc : gestion des safe area dans les view

Safe Area exemple

• je mets une carte avec de la carte collé à la view
• add missing contraintes == peut apporter des conflits
• panneau contraintes
• il nous dit en fonction du voisin le plus proche : il nous dit lequel est le plus proche
• safe area pas proposé en haut et en bas, que à gauche et à droite, parce que notre mapview à dépassé, si on fait une rotation == encoche sur le coté, on retrouverait nos safe area en haut et en bas
• on peut repositionner la safe area
• présente par défaut pour tout nouveau projet xcode
• avant : ancien system layout guid
• appli de debug propose de mettre à jour le projet, == propose des safe area (avant déjà en haut et en bas, maintenant à gauche et à droite)

Safe Area exemple

• un peu de refacto mais pas trop
• Human interface guideline : à lire absolument
• guide espacement standard entre 2 buttons
• SE, 10 et 8 du plus petit au plus grand qu'il faut adapter les contraintes
• après on fait sur le 8 surtout car le max de device
• résoudre les conflits entre contraintes : message console
• contraintes égalités : pour mettre un rapport entre éléments or moins je veux 50% pas même taille
• Sélectionner 2 éléments et equals width se dégrisent 
• ratio par rapport à la view ! ratio 0.5 de la view qui fait la moitié de l'écran ou safe area

retours

• bouton locate me mal placé : en bas à droite et le bouton record à gauche
• Bullet Three

stack view

• simplifie les contraintes pour les éléments empiler
• à coté ou en dessous
• ajout d'élément au milieu, casser tout, en plus il doit être masqué de temps en temps
• j'aimerai que les éléments en dessous prenne sa place ect, on peut le faire à la main dans le code == complexe
• Elle s'en occupe toute seule mais avec des règles, recalcule tout pour nous == le pilote
• notion alignement, espacement, distribution (proportionnelle, étiré, ratio ect) 
• stack view dans une collectionViewController
• réduit à 4 contraintes au lieu de 10 aines

stack view

• bootstrap like ou materialize ou Grid Flex ou media queries
   
• size classes : regular ou compact
• regular (ipad) regularXregular
• iPhone portrait : hauteur regular x largeur compact
• iPhone paysage : height compact x regular width
• ...trop complexe d'imaginer par device car change selon les iPhones + ou pas, portrait ou non ect
• Donc ne pas résonner forcément en termes d'appareils mais en terme de j'ai de la place ou j'ai pas de place
• iPad avec texte de x width 
• prendre une feuille et réfléchir, si app que portrait +facile

stack view

• Lab calculator
• apparence proxy : tous les éléments de l'application par défaut
• extension de button : faisable
• storyboard == xml sérialisé (désérialisé par le system)
•  

Optionals

• Element assez fondamental
• Exemple : modélisation d'un livre Harry Potter
• struct book et année publication
• si je veux rentrer en avance un livre dans mon système qui n'est pas publié (à la création d'instance année qu'on a pas...on mets 0 ou pire un entier particulier) ou autre possibilité est nil (pas top)
• nil : pas swift du tout car forcément typé donc une année en Int, qu'est ce qu'il se passe Int + nil ? on a un conflit avec le principe forcément type et forcément initialisé
• cas ou notion de nullité est importante : pas 0, pas année en cours mais juste rien (nil), soucis de pas passer un entier donc optional (Int peut être, ou pas == Int? )

Optionals

• Int?
• que deux case possible : int ou nil
• une enum : none et some
   
• specifying type of an optional
• exemple code error
  var mavar: Int? = 404
  permettra d'accepter nil ou Int plus tard
• == attention dangereux car 2 cas à traiter
• on ne teste pas n'importe quoi (null pointer exception) == seul avantage
• il faut tester les 2 cas : s'il y a une valeur ou pas
• Pour récupérer valeur d'un optional :carton avec un int mais pas un int directement
• il va falloir déballer le carton et prendre la valeur, bien évidemment après vérification

Optionals

• any c'est quoi ? == tout type
• on peut avoir du any? == un optional qui est optional
  protocol, peut être n'importe quoi
  equivalent interface, tous les types adhèrent par défaut
• il y a un truc qui contient n'importe quoi
• on ne sait pas ce qu'on reçoit, le caster avant de s'en servir et puis retrouver (mécanisme d'introspection isType()) puis après on peut utiliser, opérateur is pour vérifier ou as pour convertir
• any est un type temporaire
   
• aussi any object == toute classe

Optionals

• déballage == unwrapping == on fait avec !
• exemple : mauvais (force)
• bon exemple :
• if let constName = someOptional {
       tester diff nil directement avec cette syntaxe
       evite les ! à répétition 
• } 
• attention quand on a des méthodes qui ne renvoie rien, init() d'un string en int
  Int(String), soucis resultat va dépendre du parsage
  si int = 23 ok
  si int = seb fonctionne pas
  error d'exe ? non ça va géré en état nil
• au niveau de nos fonctions : un optional en tant que paramètre
   

Optionals

• si url récupérée pas bonne géré le cas ou ça marche pas
• Il existe des mécanismes de gestion d'erreur plus formel
• try catch, des differ dans une instruction, créer nos erreurs
• on peut try ? (génère un nil au cas ou ça marche pas, type de l'erreur ne m'intéresse pas, je veux juste savoir si ça à marché) ou try ! (sur qu'il n'y aura jamais d'erreurs)

Optionals

• tod : un nourrisson non un bambin 
• à 15 ans plus trop un nourrisson
• exemple de struct
• init?() == failable initialization, si moins de ou plus de 36 mois on ne peut pas initialiser
   
• optional chaining
• une personne à peut être une résidence qui a peut être un adresse qui a peut être un numéro rue ou batiment
• optional binding : person.residence?.getAdress?.numAppart
• on peut tout écrire en une même ligne sans imbriquer
• on peut l'utiliser dans la notation de test d'optional
• if let adress  = person.residence?.getAdress {} else ...

Optionals

Si on est sur qu'il y a une residence et une adresse à chaque fois on peut forcer le carrefour .

person.residence!.getAdress?.numAppart

Attention erreur exe donc pas forcément une bonne pratique


! quand on déclare un outlet
un optional implicitement déballé (qui ne s'assume pas)
un optionnel qui se déballe directement
on le fait dans certain cas ou ce sont des optionals pour des raisons techniques
plutôt que mettre ? partout lors de l'utilisation on met ! à la déclaration pour le déballer dès le début

Optionals

! quand on déclare un outlet

un optional implicitement déballé (qui ne s'assume pas)

storybord == désérialisation des éléments d'un coté et branche avec des classes

JS JSOn pas typé

on transforme en swift très typé

on récupère des ?

le parser te donne que des any

tableau ou dico en swift

il y a quoi dans le tableau ? un any

on recolle des types à chaque endroit

Optionals

• Protocol pour passer de swift à JSON
• essaye de faire le mapping
• CODABLE protocol == récent !! Swift4
• ancien NSJsonSerialisation == any
• type de retour
• swift 3.3 == entre le 3 et le 4 ou il y a CODABLE

Title Text

• Bullet One
• Bullet Two
• Bullet Three

Protocols, app multi écran, tableau et list

• mode démo maintenant

App Multi ecran

• suite de view controller ou composition d'ecran qui s'empilent
• stroybord : construire hiérarchie graphique que l'on souhaite
• réglages : trouver le storyboard écran principal et dans ce storyboard flèche = point d'entrée
• différents types de controllers == sous class du UIViewController qui nous simplifieront la vie
• exemple app santé onglets
• commencer app par tabbar == sommaire accessibilité aux autres controllers == controller de la barre d'onglet == liste autres controllers liés
• sélectionner menu editor > embedded in pour 

App Multi ecran

• on peut créer une view controller et l'ajouter au tabbar controller
• on fait un lien avec ctrl+clic et on type la segway
• Définition relation
• manual segue : on déclenche manuellement
• là pas ce qu'on veut
• on veut : relationship segue
• safe area elle passe dessous mais mon bouton remonte car botom contrainte liée à area safe
• tabbar evite les menu hambuger qui cache un manque de travaille sur l'UX
• si 7 éléments : 5 éléments visibles, bouton ... qui apparait pour le 6 et 7eme onglet (en bas à droite, plus simple d'accès)

App Multi ecran

• on peut permettre au user de faire un edit pour réorganiser une tabbar, on peut limiter par le code ou de mettre ses éléments
   
• controller de navigation on peut le sortir de la barre lateral, ne vient pas seul donc il faut effacer et refaire les liens
  sinon on peut faire un embed in navigation controller dans menu edit (il vient avec des tab ou ?? controller)
• barre de navigation en haut
• souvent controller de navigation (pas lourd) c'est un bon endroit pour mettre un titre dans la barre de nav
• homogénéité ? important, souvent on a de la nav dans bcp d'écran

App Multi ecran

• tableView avec prototype cell
• bouton dans la navbar pour tester les différents types de navigation
• piège : UIButton avant, mais ici BarButtonItem (rien à voir avec un button)
• selection segue : si je sélectionne l'élément qu'est ce que je fait ? (2 elements bien dif niveau UI)
• show (== navigation vers)
• ou present ()
  pas une selection segue mais une action segue
• prend le titre de l'écran précédent dans le item button back
• custom le back button 
• bouton + == bypass sans navigation = segue (pas show mais du modal == sans hiérarchie

App Multi ecran

• entre tab bar et navigation il y a 2 différences
• avec ou sans hiérarchisation
  selon notre besoin
• Back au find fond de la hierarchie 4 ou 5 fois
• réflexe : tapper 2 fois sur un élément de la barre, l'élément de nav va revenir au début (top)
• moyen pour savoir ce qui est utilisé par nos Users ?
• 
  si on est dans un double mécanisme de navigation + hamburger
• exemple : app le monde qui tabbar + swipe en même temps
• hamburger (bcp de sections)
• je rentre dans le détail (modal), je n'ai pas naviguer (alerte == modal, contenu == navigation) 

App Multi ecran

• exemple : app le monde qui tabbar + swipe en même temps
• gestes je repars
• là j'ai la croix pour revenir en arrière
• petit glissement pour revenir en arrière : bug on va à un autre article
• on a perdu la notion de hiérarchie == pas bien
• mauvaise app du meme genre : tele7
• == app natives
• detail d'un programme
• modal == moche
• flèche back == marche pas et navigation
• collectionView ou pageView mieux
• à la limite flèche vers le bas pour fermer la modal

App Multi ecran

• cover vertical == je mets devant et puis on reviens
  99%cas
• flip horizontal == pas bcp utilisé
• personnaliser
• en suivant un geste spécial du user
• 1% pour les paramètres == sensation de retourner l'app
  
  modal : ne pas descendre dans la hierachie
• show == descendre
• double tap revenir

func prepare()

• pour gérer les transitions
• ne pas définir les valeurs des outlets de ??? , hors au chargement de l'écran elles sont nil (des any nil encore) == un crash avec un optionnel

Fin

• N'hésitez pas à panacher les 2
• ressources enseignants dans Big App Dev
• et ressources étudiants mieux dans intro app dev
• niveau hétérogène donc plus vous avez de matériaux mieux c'est
• personnaliser votre enseignement
   
• Peer programming + Swift
• intro métier App Developper
• Faire un projet
•  

Fin

• structure ?
  balancer les exos en fonctions des sujets car niveaux avancés
  sujet qui vient se greffer sur un back existant
  Diversification des langages en parallèle ?
• intéresser ? faire participer ?
• premières séances ?
• rythme ?
• mode projet ?
  
  discussion : qu'est ce qui fonctionne ou non ?
• Point difficulté :
  comprendre l'UX VS comprendre swift
  le materiel
  Clarifier apprendre plusieurs langages en parallèle

Fin

• Apprendre par python et algo selon notre materiel
• apprendre à hiérarchiser info
•  
• introduire par
  compétence maquette : mobile first
       pas sur que ce soit vrai pour tout le monde
       allez plus loin dans UX
  tot sur le contrat d'apprendre plusieurs langage et
       l'algo
  Venir valoriser l'aspect rest des applications back et
       BDD, connection système
  Si on a le materiel : peux faire des ateliers iot dans les écoles, par le jeux dans les collèges, teachingbylearning (diversifier scratch, minecraft)

Fin

• Ressources créées par des teachers
• activity cards par email bientot : à télécharger
  Matt Handon (ressources xcode)
  et ???
• né du besoin de faire (playground plus difficile de faire du concret)
   
• Conférence début juin californie
  app wwdc voir même offline des vidéos rapidement après la conférence
• Renvoyer les projets, soumettent leurs app pour le concours l'année prochaine
   
• rester en contact et feedback
• labs pas visuel, working progress, continuer à évoluer
• ARkit

Fin

• écrire : à ???
• demande elever