Emmanuel CROMBEZ - Développeur

 Depuis IOS14, les droits d'accès à la photothèque ont été renforcés. L'usage sous IOS est de demander l'autorisation de l'utilisateur à la première utilisation. En fait, c'est lié à une lecture "classique" des règlements européens (mais c'est la même chose dans le reste du monde) sur la protection des données personnelles. C'est plus simple d'implémenter une demande d'autorisation, que de se battre juridiquement pour ne pas le faire. Il est pourtant clair que ce type de procédure gène la fluidité des actions de l'utilisateur, et que cela peut entraîner des dysfonctionnements, car les utilisateurs répondent aux demandes. Pour demander l'accès à la photothèque, il faut ; utiliser l'API Photos (donc @import Photos;), on récupère le statut de l'autorisation, si le statut est indéterminé, on fait la demande avec requestAuthorisation:, comme la demande se fait en tâche de fond, il faut explicitement faire les actions sur l'in

Depuis IOS14, les droits d'accès aux appareils photos et à la photothèque ont été renforcés. L'usage sous IOS est de demander l'autorisation de l'utilisateur à la première utilisation. Pour la caméra, on : désactive le bouton de notre interface par défaut, s'il y a au moins une caméra de disponible, on vérifie le statut de l'accès aux caméras, si le statut est indéterminé, on demande l'autorisation, si le statut est déterminé, on active le bouton si on y est autorisé, dans le handler de la demande d'autorisation, si on y est autorisé, on active le bouton.      // Demande l'authorisation pour l'usage de la caméra (s'il y a une camera)     button_camera . enabled = NO ;     if ( [ UIImagePickerController isCameraDeviceAvailable : UIImagePickerControllerCameraDeviceRear ] ||        [ UIImagePickerController isCameraDeviceAvailable : UIImagePickerControllerCameraDeviceFront ]) {         AVAuthorizationStatus status = [ AVCaptureDevice author

On parle d'inclusivité, mais soyons honnête, peu de site web tiennent compte des technologies qui servent à mettre en place cette inclusivité pour les handicapés. L'inclusivité Woke, oui, le LGBT, la représentation des ethnies, oui, les malvoyants, non. Pourquoi ? Parce que cela ne se voit pas, évidemment. Certains malvoyants ont besoin d'un contraste des couleurs élevé, d'autres d'une limitation des animations, d'autres encore que l'on évite les transparences. Tout cela est géré en CSS avec des @media. J'utilisais pas mal le @media, pour modifier la CSS lorsque l'on imprime une page web. On peut par exemple enlever la barre de navigation et le rooter pour gagner du papier. On peut même justifier se travail pour des raisons écologiques. @media print { nav , footer , section.hero , body * .no-print { display : none !important ; } } Avec l'arrivé du mode dark d'Apple (repris partout maintenant), un nouveau @medi

Avec IOS 14, est apparut UIColorPickerViewController qui permet d'avoir une interface système pour la sélection d'une couleur. Il est étonnant que ce controller ne soit pas arriver avant sachant qu'il existait sur les machines NextStep, avant le retour de Steve Jobs chez Apple, il y a plus de vingt ans... Jusqu'à lors, j'utilisais (et j'utilise toujours pour IOS13) un controller personnel dans mes applications. Il était simple et faisait le taf. Mais le controller système est vraiment pas mal. Problème avec UIColorPickerViewController, il y a une gestion de la transparence de la couleur dont je n'ai pas besoin. J'ai dont placé l'attribut supportsAlpha à NO , mais la couleur par défaut est clearColor, et même si l'interface ne permet plus de gérer la transparence, la couleur est tout de même transparente, sauf que l'on ne peut plus la rendre opaque. On doit donc mettre une couleur par défaut. Heureusement l'attribut selectedColor est en l