Importació des de Content Hub i URLdispatcher

"hooks": {
    "openstore": {
        "apparmor": "openstore/openstore.apparmor",
        "desktop": "openstore/openstore.desktop",
        "urls": "openstore/openstore.url-dispatcher",
        "content-hub": "openstore/openstore-contenthub.json"
    }
},

En la guia anterior hem vist una mica sobre com funciona Content Hub. En aquesta guia veurem com funciona URLdispatcher i com gestionar les dades importades des del Content Hub.

Gestiona les dades del Content Hub

Aplicació OpenStore des de open-store.io

Una de les maneres més fàcils de provar una aplicació, és enviar un clic de prova a tu mateix a Telegram, i obrir aquest fitxer de clic amb l’OpenStore a través del Content Hub:

Si toquem a l’app OpenStore, s’obrirà i es preguntarà si volem instal·lar el fitxer de clic. Fem una ullada al thecodi Main.qml de l’aplicació <https://github.com/UbuntuOpenStore/openstore-app/blob/master/openstore/Main.qml#L85> the per veure com es fa:

Connections {
        target: ContentHub

        onImportRequested: {
            var filePath = String(transfer.items[0].url).replace('file://', '')
            print("Should import file", filePath)
            var fileName = filePath.split("/").pop();
            var popup = PopupUtils.open(installQuestion, root, {fileName: fileName});
            popup.accepted.connect(function() {
                contentHubInstallInProgress = true;
                PlatformIntegration.clickInstaller.installPackage(filePath)
            })
        }
}

Veieu que l’element Connexions s’adreça al ContentHub? Quan rebi el senyal onImportRequested, prendrà l’URL de les dades enviades des del Content Hub (transfer.items[0].url és l’URL de les primeres dades enviades) i obrirà un element PopUp per deixar que l’usuari instal·li el clic.

Què passa amb l’URLdispatcher?

El distribuïdor d’URL és una peça de programari, similar al Content Hub, que fa que la nostra vida sigui més fàcil tractant de triar l’aplicació correcta per a un determinat protocol. Per exemple: probablement volem obrir el navegador web en prémer un protocol http. Si toquem en un enllaç de mapa és útil obrir-lo amb uNav o obrir un enllaç de Twitter a l’app de Twitter! Com funciona això?

El URLdispatcher selecciona quina aplicació (segons el seu manifest.json) obrirà un enllaç determinat.

Vegem com es veu la nostra aplicació de navegació a l’interior. El manifest de uNav mostra ganxos especials per al URLdispatcher en el seu codi manifest.json:

1  [
2     {
3         "protocol": "http",
4         "domain-suffix": "map.unav.me"
5     },
6     {
7         "protocol": "http",
8         "domain-suffix": "unav-go.github.io"
9     },
10    {
11        "protocol": "geo"
12    },
13    {
14        "protocol": "http",
15        "domain-suffix": "www.openstreetmap.org"
16    },
17    {
18        "protocol": "http",
19        "domain-suffix": "www.opencyclemap.org"
20    },
21    {
22        "protocol": "https",
23        "domain-suffix": "maps.google.com"
24    }
25 ]

Això vol dir que un enllaç que s’assembla a http://map.unav.me/xxxxx,xxxxx s’obrirà en uNav. I això es defineix en les línies 2 i 3, on busca el protocol http seguit de map.unav.me.

A més, un URI formatat geo:xxx,xxx s’ha d’obrir en uNav, ja que està definit en la línia 11.

I com gestionem la URL rebuda?

Després que el URLdispatcher enviï l’enllaç a l’aplicació corresponsal, hem de gestionar aquest URL o URI a l’aplicació dirigida. Vegem com fer-ho:

En el fitxer qml principal, hem d’afegir algun codi per saber què fer amb l’URL enviat. Vegem com l’aplicació Linphone gestiona aquesta addició d’una connexió al gestor URI amb un paràmetre d’element Connexions UriHandler com a objectiu.

Connections {
    target: UriHandler

    onOpened: {
        console.log('Open from UriHandler')

        if (uris.length > 0) {
            console.log('Incoming call from UriHandler ' + uris[0]);
            showIncomingCall(uris[0]);
        }
    }
}

Aquest codi gestionarà un URI en el formulari linphone://sip:xxx@xxx.xx quan s’obri l’aplicació. Però, què hem de fer per gestionar aquest enllaç quan l’app està tancada?

Hem d’afegir una mica codi extra que cobrirà dos casos: 1) Rebem una URL 2) Rebem més d’una URL

Comprovarem si Qt.application.arguments no està buit i si no, si qualsevol argument coincideix amb el nostre format URI.

Component.onCompleted: {
    //Check if opened the app because we have an incoming call
    if (Qt.application.arguments && Qt.application.arguments.length > 0) {

        for (var i = 0; i < Qt.application.arguments.length; i++) {
            if (Qt.application.arguments[i].match(/^linphone/)) {
                console.log("Incoming Call on Closed App")
                showIncomingCall(Qt.application.arguments[i]);
            }
        }
    }

    //Start timer for Registering Status
    checkStatus.start()
}

Recordeu comprovar que %u (per rebre 1 URL) o %U (per rebre 1 o més URL) està present sota la línia Exec al fitxer desktop de l’aplicació.

Eines

Des de la línia de comandes, l’ordre lomiri-url-dispatcher-dump us donarà la llista completa dels esquemes de protocol registrats i la seva aplicació corresponent.

Una altra eina útil, però no instal·lada per defecte en dispositius és lomiri-url-dispatcher-tools, que permet simular una trucada des d’una aplicació de tercers. P. ex: lomiri-url-dispatcher https://youtu.be/CIX-a-i6B1w llançarà la webapp youtube.

Per instal·lar, fa que la vostra partició es pugui escriure (sudo mount -o rw,remount /) i instal·lar-la a través de sudo apt install lomiri-url-dispatcher-tools

Què passa si més d’una app té el mateix tipus d’URL definit?

Una molt bona pregunta. Què passa si toquem en un enllaç de Twitter? Com es gestiona aquesta URL pel URLdispatcher com a protocol http o el protocol http://twitter?

Què passa si dues aplicacions tenen el mateix protocol definit?

Ara és el moment de fer algunes proves i compartir els resultats en la següent guia.