API or not API, that is the question…

API _ Application programming interface

Sous ce titre un peu… provocateur (la chaleur de ce mois d’août y est peut-être pour quelque chose 🙂 ), j’ai décidé de vous partager différentes ressources en ce qui concerne les APIs que j’utilise ou suis susceptible d’utiliser pour mes développement d’applications mobiles.

 

Cet article est bien sûr destiné à être mis à jour régulièrement, donc n’hésitez pas à (re)venir y jeter un oeil de temps en temps !

Achats :

SwiftyStoreKit : pour les achats in apps : https://github.com/bizz84/SwiftyStoreKit

 

Interface :

ActiveLabel : remplacement de UILabel qui supporte les hashtags, les mentions, les urls : https://github.com/optonaut/ActiveLabel.swift

IQKeyboardManager : pour le problème de recouvrement des textes par le clavier : https://github.com/hackiftekhar/IQKeyboardManager

MarqueeLabel : remplacement de UILabel, ajoute un scroll automatique lorsque le texte dépasse le label : https://github.com/cbpowell/MarqueeLabel

NotificationBanner : des bannières de notification : https://github.com/Daltron/NotificationBanner

PKHUD : pour l’affichage de logo de chargement, sons… https://github.com/pkluz/PKHUD

PureLayout : extension pour UIView, NSView, NSArray et NSLayoutConstrain : https://github.com/PureLayout/PureLayout

RMessage : de jolis messages d’alerte / d’informations : https://github.com/donileo/RMessage

SCAlertView : de jolies popup d’alerte : https://github.com/vikmeup/SCLAlertView-Swift

SideMenu : un simple SideMenu en Swift : https://github.com/jonkykong/SideMenu

SlideMenuController : pour un menu « Hamburger » : https://github.com/dekatotoro/SlideMenuControllerSwift

Snapkit : pour l’autolayout : http://snapkit.io/

 

Debug :

https://api.randomuser.me/ : API pour test : génère des données d’utilisateurs (JSON…)

Crashlytics : analyse de crash : https://try.crashlytics.com/

https://jsonplaceholder.typicode.com/https://github.com/typicode/jsonplaceholder : REST API gratuite pour tests, supporte les requêtes standartd GET, POST…

 

Divers :

https://api.gouv.fr/apis : les api du gouvernement Français : niveaux d’eau…

https://api.nasa.gov/ : la Nasa…

Bolts-Swift : framework de bas niveau développé par Facebook : https://github.com/BoltsFramework/Bolts-Swift

https://cloudconvert.com/ : pour convertir un fichier d’un format vers un autre

LevelDB : système de stockage key-value par Google permettant un meilleur tri : https://github.com/google/leveldb

https://market.mashape.com/ : tout un tas d’api’s, gratuites ou non

https://www.programmableweb.com/category/all/apis?data_format=21173 : beaucoup d’api’s également

http://restcountries.eu/ : permet d’avoir des infos sur les pays : capitale, monnaie, population

 

Films :

http://www.themoviedb.org/ : api concernant les films

 

Images :

DMSwipeCards : pour créer un effet « incliné » sur des « cartes » (images), par exemple lorsque l’on veut effacer une image : https://github.com/D-32/DMSwipeCards

HexColors : extension pour UIColor et NSColor qui permet de créer des couleurs depuis leur code hexadecimal : https://github.com/mRs-/HexColors

IGRPhotoTweaks : pour autoriser l’utilisateur à recouper, faire tourner… des photos : https://github.com/IGRSoft/IGRPhotoTweaks

https://imagga.com/ : reconnaissance d’images

Nuke : pour la mise en cache d’images : https://github.com/kean/Nuke

 

Maps :

Cluster : pour faciliter les annotations sur les maps : https://github.com/efremidze/Cluster

 

Météo :

https://darksky.net/dev : api météo

https://openweathermap.org/api : api météo

https://openweathermap.org/api : API pour une appli météo

Réseau :

Alamofire, Moya et swiftyJSON : parsing d’url et gestion du json (REST) :

https://github.com/Alamofire/Alamofire

https://github.com/SwiftyJSON/SwiftyJSON

https://github.com/Moya/Moya

GoogleToolboxForMac : différents projets Google : https://github.com/google/google-toolbox-for-mac

Gtm-session-fetcher : GoogleToolboxForMac – pour les opérations http : https://github.com/google/gtm-session-fetcher

NanoPb : système de protocol buffer : https://github.com/nanopb/nanopb

Protobuf : Google, envoi de données : https://github.com/google/protobuf

ObjectMapper : conversion JSON : https://github.com/Hearst-DD/ObjectMapper

Reachability : ré-écriture de Apple Reachabilyty pour connaître l’état du réseau Attention : possibilité de rejet par Apple : voir le site : https://github.com/ashleymills/Reachability.swift

 

Sons :

JSQSystemSoundPlayer : pour ajouter des sons : https://github.com/jessesquires/JSQSystemSoundPlayer

 

 

 

 

La Cathédrale et le Bazar

cathedral_bazaar

Je profite du relâchement (relatif) du mois d’août pour me remettre un peu à la lecture… de livres ayant trait à l’informatique vous vous doutez bien 😉

Premier de la liste : La Cathédrale et le Bazar, d’E.Raymond.

C’est impressionnant comme un essai paru en 1999 peut être par beaucoup de cotés à la fois précurseur et d’actualité !

Voici le résumé tiré du site verbiage.fr :

 »

Eric Steven Raymond est un informaticien américain oeuvrant dans le monde du logiciel libre à qui l’on attribue la création du terme « open source ». En 1999, il diffuse un essai devenu depuis une référence dans le monde du logiciel libre « The Cathedral and the Bazaar » (La cathédrale et le bazar).

Eric Raymond y oppose les modèles de développement des logiciels libres à ceux appliqués aux logiciels propriétaires.

Rédigé par un informaticien, évoquant le développement d’outils informatique, il n’est que peu souvent cité comme ouvrage de référence de Management. Pourtant, Eric Raymond développe sans prétention une analyse mettant en évidence la supériorité d’un modèle d’organisation basé sur la transparence et la collaboration.

C’est ici qu’apparaît, à mon sens, le principal point commun avec l’ouvrage de Vineet Nayar. Ils posent tous les deux les principes d’une organisation déstructurée favorisant l’initiative, l’efficacité et la créativité.

Par opposition aux organisations managériales traditionnelles dits de « type cathédrale » marquées par une hiérarchie, une structure forte, Eric Raymond présente le modèle du logiciel libre basé sur le collaboratif, le volontariat, la transparence. Tout est ouvert, tout est accessible, tout est transparent, une organisation à la fois horizontale et verticale : un bazar. Ici le responsable se fait davantage coordonnateur.

Contrairement aux apparences le modèle bazar n’est pas l’anarchie. Il est au contraire structuré par ses propres règles de fonctionnement, basées sur la souplesse, la rapidité et les échanges permanents entre contributeurs.

Au delà de l’éloge d’un type de management différent, que l’on pourrait juger plus où moins adapté à tel ou tel type d’entreprise, sont évoqués ici les thèmes essentiels dans la gestion de projet et dans la gestion des hommes que sont la motivation et la créativité.

L’organisation doit permettre de ne pas perdre de vue l’objectif visé, de mettre en cohérence les travaux de chacun, sans être un carcan limitant l’initiative et la créativité.

Les axe essentiels sont la motivation « tout bon logiciel commence par gratter un développeur là où ça le démange », la compétence (ici des développeurs), la transparence, mais aussi enfin et surtout une relation permanente avec les utilisateurs « traiter vos utilisateurs en tant que co-développeurs est le chemin le moins semé d’embûches vers une amélioration rapide … ».

Une démarche itérative de correction des bugs orientée client qui, en définitive, donne au bazar la charpente nécessaire à sa réussite, son but ultime : satisfaire l’utilisateur final.

Les succès de Linux, Wikipedia, la fondation Mozilla et son célèbre navigateur Firefox, l’émergence de start up devenues depuis des multinationales (Google…), sont les signes qu’un management différent est en train de s’imposer. De plus en plus d’entreprises « cathédrales » se laissent en effet peu à peu tenter par l’esprit « bazar ».

 »

A lire ou à relire, sur la plage ou ailleurs…

Ayant eu quelques difficultés à trouver la version epub pour ma liseuse, je vous mets en téléchargement les fichiers pdf et epub :

cathedrale-bazar.pdf

cathedrale-bazar.epub

Bonne lecture à tous, et si vous avez des suggestions pour le blog, n’hésitez pas à les mettre en commentaires !

Programmation Swift : le mot-clé guard

GuardOrIf

Je ne sais pas pour vous, mais il m’a fallu un moment pour comprendre à quel moment il était préférable d’utiliser le mot clé « guard » à la place du couple « if / else » en programmation Swift.

En fait, c’est comme tout, lorsque l’on à compris… c’est hyper simple ! Mais avant 😦

Donc, la différence entre « if » et « guard » est un peu subtile, mais la voici : « guard » doit être utilisé lorsque une donnée doit être présente pour la bonne exécution de la fonction.

Bon, dit comme cela, c’est encore un peu flou, alors voici un petit exemple :

guard.png

Ici, il est nécessaire que les champs « name », « address » et « phone » soient remplis pour pouvoir exécuter la fonction « sendToServer ». Sinon, on affiche un message et on sort de la fonction (return). On aurait bien sûr pu faire la même chose avec des « if/else », mais avouez que cela aurait certainement eu un impact négatif sur la taille et la lisibilité du code !

En fait, on s’aperçoit vite qu’une grande partie des « if / else » peuvent êtres avantageusement remplacés par des « guard » ! Cela nécessite un peu d’entrainement au début (il faut réfléchir « à l’envers »), mais cela améliore nettement la lisibilité du code !

Donc, maintenant, plus de prétexte pour planter (dans vos codes…) des forêts d’Ifs !

 

 

A propos de… moi !

IMG_5270Carre

Vincent Barousse, développeur d’applications Apple iOS / swift (entre autres…)

J’aime les ordinateurs sous toutes leurs formes, j’aime le code et j’aime la nouveauté. Cette passion m’a poussé à m’orienter du développement web et de la maintenance informatique au développement iOS et watchOS en 2015.

Je mets maintenant mon expertise dans ce domaine au service de mes clients.

Cette page est là pour résumer mes différentes réalisations.

Lire la suite

Mémo : utilisation de NSLocalizedString en Swift

Cet article n’est pas un tutoriel en temps que tel, mais plutôt un mémo sur l’utilisation de fichiers « string » pour gérer les traductions dans une application iOS.

Pour cet exemple, nous allons créer une application très simple : 1 vue, 1 champ de texte : voir les captures d’écran ci dessus.

Le champ texte sera localisé, c’est à dire qu’il sera automatiquement traduit en fonction de la langue du device.

Donc, pour réaliser ce « miracle », il faut commencer par créer un fichier « Localizable.strings » (cliquez sur les images pour agrandir) :

On crée donc simplement un nouveau fichier de type « Strings File ».

On rajoute les langues désirées dans les paramètres de l’appli :

AddLocalization

Et on ajoute également les langues pour le fichier Localizable.strings :

AddLocalization2

2 fichiers sont alors créés : Localizable.strings(French) et Localizable.strings(English).

Ces fichiers contiendront les traductions sous forme de « Clé » = « Valeur ».

Voici donc le contenu des fichiers English et French (cliquez pour agrandir) :

Enfin, pour utiliser nos traductions, il suffit de les appeler sous la forme NSLocalizedString(key : «  », comment : «  ») ex :

let myString = NSLocalizedString(key : « Hello », comment : «  »)

Appliqué à notre view controller, cela donne :

carbon(4)

Tout simplement…

Maintenant, plus de prétexte pour ne pas gérer correctement ses traductions !

Des commentaires, des questions ? Commentez !