Aller au contenu

Visualisation du Webview des QuickApps


Lazer

Messages recommandés

Quand on utilise la nouvelle application mobile, le visuel des QuickApps n'est pas rendu par l'application elle-même, mais par la box HC3 au travers d'une "WebView".

C'est à dire que c'est la HC3 qui se charge de générer le rendu visuel du QuickApp, puis l'application mobile se contente de charger et afficher la page telle quelle.

 

L'URL appelée est la suivante :

 

  • http://192.168.0.1/app/webView/devices/ID

 

(remplacer l'adresse IP et l'ID du QuickApp)

 

On peut donc appeler directement cette URL depuis n'importe quel navigateur.

 

Peu d'application pratique pour l'instant, mais j'imagine :

  • en phase de développement, permet de visualiser rapidement le rendu d'un QuickApp sans devoir recharger l'application mobile
  • Fibaro permettra ultérieurement de réaliser des designs avancés des QuickApps par simple mise à jour de firmware de la HC3 (et de nos codes LUA) sans devoir mettre à jour l'application mobile (rien que pour l'affichage d'une jaquette d'album, c'est une grosse avancée)
  • pour ceux qui utilisent une interface externe pour piloter leur domotique, typiquement une tablette murale, on peut récupérer directement la vue du Quickapp sans aucun codage

 

En revanche, l'inconvénient, c'est que ça ralentit l'affichage... car quand on est sur mobile, il est plus long de charger une page Web (protocole http lourd, chargement des balises, etc), qu'une API JSON et de mettre en forme localement.

 

Exemple de rendu WebView :

 

image.png.625c516e874e38cf23c00f461139aa26.png

 

  • Like 5
Lien vers le commentaire
Partager sur d’autres sites

hmmm :15:

 

L'authentification me pose problème pour afficher la page dans un champs HTML...

 

J'ai essayé avec http://user:mdp@ip/app/webView/devices/id et même codé ave urlencode, mais sans résultat !

 

Vous avez une autre idée de comment passer les authentifications dans l'adresse ?

Lien vers le commentaire
Partager sur d’autres sites

ah ben si j'ai trouvé http://ip/app/webView/devices/id?login=xxxxxx&password=xxxxxxxx

avec le login et le password en urlencode

 

dans mon application, un QA affiché donne ça :

 

image.png.44abc20efa9417bc2acd1f8c8f54d158.png

 

Mais c'est vrai que le temps de chargement du QA est peu long...

  • Like 2
Lien vers le commentaire
Partager sur d’autres sites

franchement c'est nickel l'affichage des QA... mais...

 

Dans le cas d'un QA Parent, ce serait top de pouvoir lui envoyer un argument comme l'ID du Child pour l'afficher directement sans avoir à "naviguer" dans le Parent...

 

sais pas si je me suis fait comprendre là...

Lien vers le commentaire
Partager sur d’autres sites

par exemple dans mon cas, j'ai 2 boutons "next" et "previous" dans le Parent, qui permet d'afficher les infos du Child ainsi sélectionné.

J'ai ça sur pas mal de QA Parent, vu que comme tu dis, on peut rien afficher dans un Child.

 

image.png.e55aa9105c1cf5de716eb49d9981abac.png

 

Donc  on a

  • en rouge les boutons de navigation pour choisir le Child
  • en vert le Child sélectionné
  • en bleu les infos du Child sélectionné

 

Et bien le top serait de pouvoir exécuter la commande http://192.168.0.1/app/webView/devices/ID en spécifiant un argument (dans mon cas ce serait l'ID du Child que l'on souhaite afficher... ex &args=576)

Et pouvoir, dans le code du QA, récupérer cet argument. Un peu comme on envoie un argument à une scène...

Pour pouvoir ensuite exécuter une méthode particulière

un truc comme le OnInit() du genre 

function QuickApp:OnDisplay(args)
	--on peut traiter ici l'argument transmit
end

Après on peu bidouiller en créant une méthode spécifique qu'on exécute au moment, ou juste avant, d'afficher le QA.

Il faudrait alors appeler la méthode et ensuite l'affichage du QA... pffff usine à gaz...

 

Bon la je rêve un peu je crois, usage ultra spécifique à mes applications finalement...

Lien vers le commentaire
Partager sur d’autres sites

OK je vois... mais je trouve surprenante ton utilisation des childs

 

Toutes ces infos, elles devraient être dans des child "monofonction", et pas des labels.  Avec le bon type, genre fibaro.multilevelsensor, etc... et la bonne unité

 

Comme ça, c'est exploitable directement dans des scénarios (avec GEA, ou autre peu importe). Chaque child = une mesure de capteur.

Et ça remonterait aussi dans Domocharts (dans la nouvelle version, j'ai supprimé les labels et les variables globales, car toutes les valeurs sont censées être dans des child, autant utiliser la HC3 comme... une HC3... et pas une HC2)

Lien vers le commentaire
Partager sur d’autres sites

Oui je sais, c'est ce qui m'arrive avec l'IPX800 et l'EcoDevice RT2

 

Mais bon, ce n'était pas trop le sujet de ce topic à la base :)

 

Autre chose quand même, je ne sais pas si tu as remarqué, les labels ne sont pas persistants. Leur valeur est perdue après le redémarrage du QuickApp (donc de la box), ce n'est vraiment pas le lieu pour y stocker une valeur, mais juste pour afficher une information pour l'utilisateur.

D'ailleurs dans l'API, Fibaro a bien séparé les properties (valeur par défaut du label qui est repositionnée à chaque redémarrage) et les View (valeur courante du label).

Lien vers le commentaire
Partager sur d’autres sites

  • 1 an après...
  • 5 mois après...
×
×
  • Créer...