Discussion Gestion:Tâches/Liste/245/1

À propos de ce flux de discussion

Non modifiable

Antoine Mercier-Linteau (discussioncontributions)
Antoine Mercier-Linteau (discussioncontributions)

Est-ce que l'app pourrait être facilement reconfigurée pour utiliser un MediaWiki arbitraire?

Charles-Éric Noël Laflamme (discussioncontributions)

J'ai trouvé cet thread en recherchant s'il était possible de reconfigurer l'application vers un autre MediaWiki.

https://phabricator.wikimedia.org/T107042

Le thread semble être fermé puisque l'application utilise désormais une API REST qui est propre à Wikipedia lui-même et donc n'est plus commun à tous les wikis MediaWiki. J'ai tenté de mon côté de faire pointer l'application vers wikimedi.ca et j'ai vu également pu apercevoir que l'application utilisait cet API.

Reste à savoir s'il est possible de contourner ce problème.

Charles-Éric Noël Laflamme (discussioncontributions)

J'essaie présentement de voir s'il y aurait une correspondance entre l'API de mediawiki et celui rest_v1 utilisé dans l'application de Wikipedia.

Charles-Éric Noël Laflamme (discussioncontributions)

Les API ne sont pas vraiment les mêmes. Par exemple, l'application Wikipedia utilise "api/rest_v1/page/summary/{title}" ce qui n'a pas vraiment d'équivalent pour l'API MediaWiki.

C'est selon moi certainement possible de réorganiser le JSON émis par l'API MediaWiki pour le rendre compatible avec ce que l'application s'attend à recevoir.

Le seul hic c'est que c'est j'ignore si cette simple modification suffirait à résoudre ce problème ou s'il faudrait plutôt résoudre à la fois une panoplie d'autres bugs similaires.

Antoine Mercier-Linteau (discussioncontributions)

J'ai trouvé ici un billet qui expliquer comment (en 2016) quelqu'un est parvenu à faire fonctionner l'app de Wikipédia sur un wiki arbitraire. Deux ans plus tard, le support est abandonné car la popularité de son app ne justifiait pas l'effort de la mettre à jour.

Dans la tâche phabricator que tu mentionnes, il est spécifié que l'app utilise maintenant extensivement RESTBase. J'étais parvenu à installer RESTBase sur Wikimedica en mode local et tout semblait bien fonctionner. Reste à voir ensuite quels services spécifiquement l'app de Wikipédia utilise.

En lisant les différents post sur le sujet, j'ai bien l'impression qu'il y a un peu de mise en échec des développeurs de Wikimedia sur le sujet. D'adapter l'app à n'importe quelle installation de MediaWiki est techniquement largement à leur portée. Les ressources pour leur faire ne leur sont malheureusement pas disponibles et ça on le comprend.

Dans l'éventualité où on ne serait pas capable de faire fonctionner RESTBase avec Wikimedica. Est-ce que l'utilisation de RESTBase est super tentaculaire dans le code ou est-ce que c'est bien encapsulé dans une composante? Le cas échéant, on pourrait la remplacer par la composante de la version de l'app pré-RESTBase (circa 2017-2018) si ce n'est pas trop compliqué.

De plus, il y a énormément de services que l'on va désactiver sur l'app, comme les suggestions, WikiData, les métriques de suivi du comportement des utilisateurs, etc. Au final il ne devrait pas rester grand chose d'autre que:

  • Permettre aux utilisateurs de se logger (pas de création de comptes vu que ça passe par le CMQ)
  • Récupérer des pages
  • Sauvegarder des pages qu'on a édité.

C'est sûr que ce sera un effort conséquent pour nous, mais je pense qu'on pourra rapidement trouver d'autres développeurs intéressés par le projet.

Charles-Éric Noël Laflamme (discussioncontributions)

Ça m'a l'air assez bien encapsulé. Si je comprends bien les options qu'on a sont les suivantes:

  • Installer RESTBase sur Wikimedica et utiliser la version actuelle de l'application
  • Utiliser une version pré-RESTBase de l'application
  • Modifier la version actuelle de l'application de manière à la faire fonctionner avec l'API de mediaWiki, où il serait d'ailleurs possible de s'inspirer du code source des versions pré-RESTBase de l'application
Antoine Mercier-Linteau (discussioncontributions)

Exact. L'options d'installation de RESTBase est définitivement la plus simple. Or, c'est celle qui garantira le moins de compatibilité avec d'autres instances de MediaWiki, car RESTBase est quand même compliqué à déployer et inutile pour les petites instances de MediaWiki.

Antoine Mercier-Linteau (discussioncontributions)

Cette discussion concerne l'évaluation du support JS + HTML (afin de pouvoir soumettre des formulaires [comme ici]) de l'app.

Antoine Mercier-Linteau (discussioncontributions)

Sur le README du service mobileapps (un service utilisé par les applications pour faire du pre-processing server-side lors des requêtes de pages) Il est dit:

taking advantage of streaming by being able to use WebView.loadUrl() instead of piping every page section by section over the JS bridge.

Ce qui semble vraiment inférer que c'est WebView qui est utilisé pour afficher les articles.

Ici, il est dit:

Wikipedia for Android makes extensive use of WebViews. To debug WebView activity, navigate Google Chrome to chrome://inspect/#devices, then click on the topmost “inspect” link under “WebView in org.wikipedia.” From there you can debug the WebView like any other web site in Chrome.

Je crois que c'est donc confirmé, du moins pour la version Android. iOS ne devrait pas être très différent.

Charles-Éric Noël Laflamme (discussioncontributions)

Je confirme le support JS/HTML pour Android.

CommunicationsBridge.java

/**
 * Two-way communications bridge between JS in a WebView and Java.
 *
 * Messages TO the WebView are sent by calling loadUrl() with the Javascript payload in it.
 *
 * Messages FROM the WebView are received by leveraging @JavascriptInterface methods.
 *
 */

...

@SuppressLint({"AddJavascriptInterface", "SetJavaScriptEnabled"})
public CommunicationBridge(CommunicationBridgeListener communicationBridgeListener) {
    this.communicationBridgeListener = communicationBridgeListener;
    this.communicationBridgeListener.getWebView().getSettings().setJavaScriptEnabled(true);
    this.communicationBridgeListener.getWebView().getSettings().setAllowUniversalAccessFromFileURLs(true);
    this.communicationBridgeListener.getWebView().getSettings().setMediaPlaybackRequiresUserGesture(false);
    this.communicationBridgeListener.getWebView().setWebChromeClient(new CommunicatingChrome());
    this.communicationBridgeListener.getWebView().addJavascriptInterface(new PcsClientJavascriptInterface(), "pcsClient");
    eventListeners = new HashMap<>();
}

Pour ce qui est de d'iOS, je vais essayer de rechercher explicitement le support javascript aussi, car en raison de l'hétérogénité des deux codebases, ce n'est pas nécessairement garantit.

Charles-Éric Noël Laflamme (discussioncontributions)

L'application iOS a l'air de fonctionner de manière similaire, mais avec VKWebView au lieu de webView, qui support lui aussi javascript.

Antoine Mercier-Linteau (discussioncontributions)

Excellente nouvelle de ce côté!

Correspondance iOS / Android

2
Antoine Mercier-Linteau (discussioncontributions)

Est-ce que l'architecture des deux versions est similaire? Ou il faudra doubler les efforts de développement?

Charles-Éric Noël Laflamme (discussioncontributions)

Pour ce qui est de la correspondance iOS/Android, elle semble très limitée voire absente. Je crois même que chacune des applications ont en soi des fonctionnalités un peu différentes. Par contre, chacune des codebases semble bien entretenues et assez modulaires.

Il n’y a aucun sujet plus ancien