Coucou ! tu veux voir une app iOS?

Hello :slight_smile:

J’ai eu l’occasion de découvrir et discuter de Gladys avec @Aldo, qui m’a fait part du fait qu’une app Android est en cours de développement.

Étant développeur iOS, à la recherche d’un side-project et intéressé par Gladys, je me suis dit que la communauté serait surement intéressée par un sujet d’app iOS Gladys.

Qu’en pensez-vous ? Avez-vous des idées ou des attentes ? Devrait-on dans un premier temps « se conformer » à ce qui est fait sur Android ?

4 Likes

Salut,

pour ma part j’utilise l’appli Android, mais c’est vrai que ma copine est un peu jalouse car il n’y a pas d’app iOS :smiley:
Je trouve l’idée intéressante.

Salut @leloupnicolas! :slight_smile:

Elle est bien plus qu’en court de développement, ça fait plus d’un an qu’elle est sortie je dirais! :slight_smile:

100% d’accord qu’une app iOS serait top, ça fera plaisir à un paquet de monde.

Je pense que dans un premier temps, se rapprocher des features développées sur l’app Android est le mieux. C’est à dire à minima la page d’accueil avec le contrôle des périphériques comme sur Android et la page de configuration.

Je ne sais pas si @Aldo t’as dis, mais je travaille actuellement sur Gladys 4. Pas de panique, au niveau des périphériques beaucoup de choses sont similaires donc ce que tu développe pour Gladys 3 ne sera pas perdu il faudra juste mettre à jour pour Gladys 4 à sa sortie.

Donc complètement c’est avec plaisir :slight_smile: N’hésite pas à poster ici si tu commence à réfléchir à des mockups et que tu veux des retours.

Tu auras probablement besoin de la documentation de l’API REST =>

https://documentation.gladysassistant.com/apidoc/

La requête principale dont tu auras besoin est celle là (aller chercher tous les périphériques par pièce) =>

https://documentation.gladysassistant.com/apidoc/#api-DeviceType-getDeviceTypeInRoom

Et l’autre requête (contrôler un périphérique) =>

https://documentation.gladysassistant.com/apidoc/#api-DeviceType-execDeviceType

Au niveau de l’authentification c’est tout bête tu as un token a récupérer dans l’interface de Gladys que tu passes ensuite en paramètre GET ( ?token=TON_TOKEN )

N’hésite pas si tu as des questions, et merci de ta proposition!

Pour l’app Android, j’avais cru comprendre qu’elle n’était dispo qu’en beta pour le moment et/ou qu’elle n’était pas dispo sur le Play Store, d’où mon raccourci vers “elle est en cours de dev” :wink:

Je vais essayer l’app sur une device Android pour voir comment elle est faite.

Oui, effectivement il m’a parlé de Gladys 4, et je n’étais pas spécialement inquiet pour la migration.

J’ai quelques idées déjà, notamment l’intégration de SiriKit, à voir ce que l’on peut faire avec !

Merci pour les liens vers la doc, je vais étudier tout ça !

Il se posera une question de mise à disposition de l’app qui sera plus complexe que sur Android, l’écosystème d’Apple étant quelque peu plus fermé que celui de Google :wink:

1 Like

Salut,
Bien preneur ici d’une app IOS :slight_smile: !

Carrément! Hâte de voir ça :slight_smile:

Ce qu’on a fait sur l’app Android, j’ai payé la licence et du coup on a un compte pour Gladys.

Je ferais pareil pour iOS :slight_smile: Mais bon en attendant, un test flight suffira tant que c’est du dev!

Ce sera dans un second temps pour SiriKit, mais je pense que ça peut vraiment avoir de la valeur !

Ok on verra pour le compte dev Apple alors, en attendant je vais utiliser le mien. Dans tous les cas pour du Testflight, il faudra un compte dev :wink:

3 Likes

C’est une excellente idée. Beaucoup d’utilisateurs sont sur iOS et veulent piloter leur maison via leur téléphone.
Pour tester l’appli tu pourras la diffuser via TestFlight pour avoir des retours dessus.

Niveau fonction, effectivement Siri c’est intéressant mais on peut attendre. C’est pas la priorité.

En tout cas merci de ton initiative.
Perso je suis débutant dans le langage swift et je me voyais pas faire une application encore !

Oui une distribution en beta via Testflight est envisageable, il faudra juste voir si on fait de la beta “privée” ou “publique”. La privée suppose une limitation en nombre, et la publique suppose une validation du binaire par Apple !

@pierre-gilles j’ai créé un repo github privé sur mon namespace, je garde celui-ci ou tu veux centraliser ?

Pour l’instant tant que c’est les premiers développements reste sur ton repo, plus pratique pour toi pour t’organiser :slight_smile: On verra par la suite pour le déplacer ça sur le namespace Gladys Assistant

@pierre-gilles l’application Android est déjà dispo ? Je ne la trouve pas sur le Play Store.

Elle est dispo en bêta privée depuis Octobre 2018!

Il faut qu’on la release sur le Play Store, mais je crois que @MathieuA est pas mal occupé en ce moment… (c’est lui qui a dev l’app Android)

@MathieuA si tu lis ce message moi je suis chaud pour la release quand tu veux! Si tu pouvais juste publier une version de production sur le store, je m’occupe du reste (logo, bannières, etc…) :stuck_out_tongue:

Salut salut, :slight_smile:

bon perso j’ai pas d’ios mais juste pour dire que c’est franchement top de prendre de votre temps pour amélioré et élargir le potentiel de gladys. :+1::+1::beer:

Hello à tous !

J’ai un peu avancé sur le sujet, et ai maintenant une app clean avec une bonne archi pour commencer, et quelques bons outils configurés et opérationnels à l’intérieur.

Je me posais plusieurs questions, intimement liées :

  • est-il intéressant de développer cette application pour qu’elle communique uniquement avec l’API accessible localement ?
  • est-il prévu dans Gateway de gérer “toutes” les routes aujourd’hui disponibles sur l’API locale ? et si oui, est-ce que les webservices seront iso entre les 2 (Gateway et locale, modulo l’authent peut etre…) ?

Personnellement je pense qu’il serait plus intéressant d’avoir une app qui communique seulement avec Gateway, puisqu’accessible de partout, mais je préfère avoir vos avis et notamment celui de @pierre-gilles pour la faisabilité et les possibilités avec Gateway :slight_smile:

Salut,

Concernant l’app et le fait de communiquer uniquement avec la gateway ça peut poser problème tout simplement à ceux qui n’ont pas de gateway :slight_smile: Je pense qu’il est préférable de taper large c’est mon avis :slight_smile:

En tout cas merci j’attend avec impatience cette application … :slight_smile: Si tu as besoin de beta testeur je suis dispo !

Salut @leloupnicolas!

Alors le Gateway gère bel et bien toutes les routes de l’API locale (les deux sont 100% iso), et ce dès maintenant (oui, oui!). :slight_smile:

:warning:Attention, je ne parle pas de l’Open API qui est une autre chose: l’Open API est une API en claire, optionnelle, qui ouvre des routes spécifique destiné à des clients qui de toute façon sont en clair type Alexa/Google Home/Siri/IFTTT. Cette Open API n’est pas destinée à des apps mobiles Gladys, qui elles peuvent très bien implémenter l’API sécurisée et chiffrée du Gateway :slight_smile:

L’objectif premier du Gateway est de fournir une API chiffrée de bout en bout, donc pour discuter avec c’est un peu plus compliqué que de juste taper dans une API REST conventionnelle, il faut chiffrer les messages avant envoi et déchiffrer les réponses après réception.

La théorie

Le Gateway en soit est une API Websocket qui n’a qu’un seul topic, le topic “message”.

Dans ce topic, tu peux envoyer des JSON chiffré qui contiennent la requête que tu veux effectuer, et de l’autre côté Gladys te répondra avec une réponse chiffrée elle aussi.

Exemple, si tu veux faire un GET /alarm sur une instance Gladys, tu peux envoyer le message suivant en websocket:

{
      "version": "1.0",
      "type": "gladys-api-call",
      "options": {
        "url": "/alarm",
        "method": "GET"
      }
}

et tu recevras une réponse type:

{
   "data": [] // tableau d'alarmes
}

Message qui doit être chiffré avant envoi, et qui chiffré ressemblera en gros ça:

{
   "instance_id": "73f281ef-5875-4542-b3af-05768f4f44d0", // l'ID de ton instance vis a vis du gateway pour que le gateway sache quel Gladys contacter
   "encryptedMessage": {
         "iv": [122, 223, 22, 11, 33 ],
          "wrappedSymetricKey": "SKDFJLKSDJ",
          "encryptedData": "FDSFJKLSDFJK",
          "signature": "SKJFLKSDJF"
    }
}

La pratique

Tout le code est open-source et ne fait que qu’une centaine de ligne je dirais…

Le code JS pour envoyer une requête est dispo ici

Le code JS pour chiffrer/déchiffrer un message est dispo ici

Je peux comprendre que tout ce que je t’ai envoyé ici peut faire peur :sweat_smile: Honnêtement, rien de très compliqué, il faut juste qu’on trouve les bonnes libs iOS pour faire la partie chiffrement.

En fait je pense que la question ne se pose avec la façon dont j’ai implémenté le Gateway, les deux API sont 100% iso, donc si l’app est compatible Gateway, elle est compatible locale sans adaptation. Tu as “juste” à coder un wrapper qui va appeler le Gateway ou l’instance locale.

Je viens de me renseigner, je vois deux possibilités:

Hello le topic me semble très intéressant pour les utilisateurs IOS.
Mais pourquoi ne pas faire une app via flutter ?
Cela serait plus intéressant pour faire évoluer les deux app en même temps.

1 Like

Hello @pierre-gilles !

Merci pour ta réponse précise.

Non ça ne fait pas spécialement peur, tout est clair et bien pensé d’après moi, donc effectivement il suffit de laisser l’utilisateur choisir s’il souhaite s’authentifier sur Gateway ou entrer directement l’IP d’une instance Gladys locale. Cela conditionnera la manière de faire l’appel réseau, simple appel HTTP en local ou wrapping + cryptage du payload pour appel à Gateway et le tour est joué. :slight_smile:

En ce qui concerne ton message suivant et les 2 manières de crypter les données coté app, étant dev natif, je ne suis pas forcément attiré par la solution de la webview (notamment parce qu’utiliser un composant UI pour faire autre chose qu’afficher du contenu ne me semble pas idéal), à voir… :wink:

Comme je le disais juste avant, je suis développeur natif (passé par l’hybride avant ça), et c’est avec convictions que je n’adhère pas spécialement à la philosophie de l’hybride.

Ceci dit, si la communauté estime que c’est un choix plus judicieux, je peux l’entendre et dans ce cas je n’irai pas plus loin :wink: