Q-Manager

Uitleg

Ik ga jullie hier meenemen in stukje code. Voornamelijk hoe we de data uitlezen van het bestaande systeem en hoe we die data vervolgens gebruiken om de status van de wachtrij te bepalen en weer te geven in de applicatie.

Code

Eerst controleren we of de URL van het wachtrijsysteem correct is ingesteld. Dit is belangrijk omdat we deze URL nodig hebben om verbinding te maken en data op te halen.

    function checkUrl(url) {
        const regex = /backoffice\.xml$/;
        if (!regex.test(url)) {
            return false;
        }
        else {
            return true;
        }
    }
                

Vervolgens gaan we de data uitlezen van het wachtrijsysteem. We maken een HTTP GET-verzoek naar de opgegeven URL en verwachten een XML-respons terug te krijgen. Deze XML bevat informatie over de huidige status van de wachtrij, zoals het aantal mensen in de rij, wachttijden, en andere relevante gegevens.

    function fetchData(url) {
        if (hasErrorOccurred) return;

        fetch(url)
        .then(response => {
            if (!response.ok) {
                throw new Error('Network response was not ok');
            }
                return response.text();
            })
            .then(str => xml2js.parseStringPromise(str))
            .then(result => {
                loadUrlInMainWindow(result);
                checkThresholds(result);
            })
            .catch(error => {
                if (!hasErrorOccurred) {
                    hasErrorOccurred = true;
                    dialog.showMessageBox({
                        type: 'error',
                        title: 'Er is iets fout gegaan.',
                        message: 'De URL is ongeldig of de server is niet bereikbaar.',
                        buttons: ['Probeer opnieuw', 'OK'],
                        defaultId: 0,
                        cancelId: 1
                    }).then(result => {
                        if (result.response === 0) {
                            hasErrorOccurred = false; 
                            fetchData(url);
                        } else {
                            openPromptWindow();
                        }
                    });
                }
            });
    }

                

Omdat dit een functie is die regelmatig wordt aangeroepen, hebben we een foutafhandelingsmechanisme ingebouwd. Als er een fout optreedt bij het ophalen van de data, zoals een netwerkfout of een ongeldige URL, wordt er een foutmelding weergegeven aan de gebruiker. De gebruiker krijgt dan de optie om het opnieuw te proberen of om terug te gaan naar het instellingenvenster.

Testen

Deze functie is getest door verschillende URL’s te valideren en te controleren of de juiste resultaten worden teruggegeven. Hierbij is bewust gekeken naar zowel geldige als ongeldige inputs om te bevestigen dat de regex correct werkt.

Zo zijn bijvoorbeeld URL’s die eindigen op backoffice.xml als valide gemarkeerd, terwijl afwijkende of onvolledige URL’s correct worden afgekeurd. Dit helpt om te voorkomen dat onjuiste data verder in het systeem terechtkomt.

Tijdens het testen is ook gekeken naar randgevallen, zoals lege strings, onverwachte tekens en variaties in de URL-structuur. Hierdoor is de betrouwbaarheid van de functie binnen de applicatie verder gevalideerd.

Deze applicatie is ook uitvoerig getest door Microsoft. Dit is nodig omdat de applicatie is gepubliceerd in de Microsoft Store en aan strenge kwaliteits- en veiligheidsnormen moet voldoen. Microsoft voert uitgebreide tests uit.

Publicatie

Het publiceren van de applicatie op de Microsoft Store bleek uiteindelijk een stuk intensiever dan verwacht. Wat in eerste instantie even uploaden en klaar leek, veranderde al snel in een volledig proces met veel stappen en verrassingen tussendoor.

Van het aanmaken en verifiëren van een Microsoft Partner-account tot het doorlopen van alle registratie en bedrijfsgegevens: alles moest kloppen voordat je überhaupt verder kon. Elke stap bracht weer nieuwe eisen en controles met zich mee, waardoor het proces behoorlijk tijdrovend werd.

Daarna kwam het technische deel, zoals het voorbereiden van de juiste package, het voldoen aan alle store richtlijnen en het oplossen van validatiefouten die pas tijdens het indienen naar voren kwamen. Dat maakte het soms behoorlijk frustrerend, omdat je telkens net weer iets moest aanpassen voordat je verder kon.

Uiteindelijk moest ook de volledige store-pagina worden ingericht, inclusief beschrijving, screenshots en metadata. Pas toen alles goedgekeurd was, werd de applicatie daadwerkelijk gepubliceerd.

Achteraf gezien was het een proces dat meer werk en geduld kostte dan de ontwikkeling zelf, maar het heeft wel gezorgd voor een beter begrip van hoe distributie en platform eisen in elkaar zitten.

Verbetervoorstellen.

Na de eerste beta build, heb ik feedback verzameld van gebruikers en stakeholders om te kijken waar er nog ruimte was voor verbetering. Op basis van die feedback zijn er een aantal punten naar voren gekomen die uiteindelijk tot verbeteringen hebben geleid.

Hieronder een voorbeeld.

Dit heb ik toen meegenomen in de volgende versie.