What is rskibbe.I18n.Winforms?

rskibbe.I18n.Winforms is a sub-package that helps you translate your Windows Forms apps easily. It extends the other rskibbe.I18n packages to provide specialized help with the Winforms technology. Keep in mind, that there is another package for WPF as well and that you can refer to the base package for more information.

💡 In a hurry?: No problem, just navigate to the points of interest by using the table of contents from above, or watch the provided setup video down below.

Video guide

How to get started?

To begin with the easy translation of Windows Forms Apps, you first need to install the desired and essential packages. You can do so, by visiting the NuGet Package Manager of your Visual Studio installation. For sure, you can use the NuGet console as well, just as you wish. Search for the term „rskibbe.I18n“ and you will get all available packages.

What we are going to do

In this quick example, we are going to create a json file based translation for our Windows Forms App. For this, we need to install the following „rskibbe.I18n“-packages:

// install the base package first
Install-Package rskibbe.I18n

// then execute this as well, to install the JSON sub-package
Install-Package rskibbe.I18n.Json

// in the last step, get the package for the Windows Forms stack
Install-Package rskibbe.I18n.Winforms

Namespaces

After you have completed installing the needed / desired packages, you can now go ahead and import the essential namespaces. With doing so, you are able to create the translator instance of your needs and translate your forms. Please refer to the base package documentation, if you need more information corresponding to it.

// don't forget the imports
using rskibbe.I18n.Models;
using rskibbe.I18n.Winforms;

' don't forget the imports
Imports rskibbe.I18n.Models
Imports rskibbe.I18n.Winforms

Setup

To setup your custom translator, you can just use this easy and quick method:

// before like the first Form InitializeComponent
Translator.Builder
    .WithAutoFormTranslation()
    .Build()
    .StoreInstance();

' before like the first Form InitializeComponent
Translator.Builder _
    .WithAutoFormTranslation() _
    .Build() _
    .StoreInstance()

An important note

In this case I’m using the autodetection feature, that means, I don’t need to explicitly define the used format like JSON or INI. It will see, which package we’ve installed, so it will pick it right away. In this case we are using the JSON package. Now it will automatically translate and update corresponding controls like Labels, Buttons and Forms. You don’t need to configure much more from the coding side – isn’t this nice?

Remember to do this „bestly“ before any UI going on, the Bootstrapping point Program.cs/Program.vb or like the first Form Constructor could be the best place (but make sure it doesn’t get called multiple times).

Marking controls as translatable

Away from the coding side, we are now going to configure the UI to actually take those translations. For this, you need to tell the translator: „Hey, I want this translation, to go over here„. You can do so, by just specifying its tag property inside the designer!

Currently supported Controls

At this moment, the package supports auto-translation for the following types of controls:

• Buttons
• CheckBoxes
• GroupBoxes
• Labels
• LinkLabels

Full Example

Step 1 – Install packages from NuGet

The base package is always necessary rskibbe.I18n. Depending on the translation style you want to use (InMemory, file-based like Json or Ini, etc.), install the next package like rskibbe.I18n.Json. Now you can install the last helper package for Windows Forms (this one you are looking at right now..) rskibbe.I18n.Winforms.

Step 2 – Create a „Form“

Go on like your first form – usually Form1 – and put a button on top of it. Name it as you wish, but specify the Tag property as „i18n:myTranslationKey“. The translator will search for the i18n prefix and will know, that it has to translate it with the corresponding translation key (the thing after the colon).

Step 3 – Create the necessary files

Please take a look at the corresponding package like rskibbe.I18n.Json or rskibbe.I18n.Ini for file and folder / content structures. More packages for loading from web APIs and like SQL are planned.

Step 4 – Specify the code

To let the translator handle its work, go ahead and use (for example) this code:

public partial class Form1 : Form
{
    public Form1()
    {
        Translator.Builder
            .WithAutoFormTranslation()
            .Build()
            .StoreInstance();
        InitializeComponent();
    }

    private async void Form1_Load(object sender, EventArgs e)
    {
        await Translator.Instance.LoadLanguagesAsync();
        if (Translator.Instance.HasLanguages)
        {
            var language = Translator.Instance.Languages.SingleOrDefault(x => x.Iso == "en-US");
            await Translator.Instance.ChangeLanguageAsync(language);
        }
    }

    private async void btnSetGerman_Click(object sender, EventArgs e)
    {
        await Translator.Instance.ChangeLanguageAsync("de-DE");
    }

    private async void btnSetEnglish_Click(object sender, EventArgs e)
    {
        await Translator.Instance.ChangeLanguageAsync("en-US");
    }
}

Public Partial Class Form1
    Inherits Form

    Public Sub New()
        Translator.Builder _
            .WithAutoFormTranslation() _
            .Build() _
            .StoreInstance()
        InitializeComponent()
    End Sub

    Private Async Sub Form1_Load(ByVal sender As Object, ByVal e As EventArgs)
        Await Translator.Instance.LoadLanguagesAsync()

        If Translator.Instance.HasLanguages Then
            Dim language = Translator.Instance.Languages.SingleOrDefault(Function(x) x.Iso = "en-US")
            Await Translator.Instance.ChangeLanguageAsync(language)
        End If
    End Sub

    Private Async Sub btnSetGerman_Click(ByVal sender As Object, ByVal e As EventArgs)
        Await Translator.Instance.ChangeLanguageAsync("de-DE")
    End Sub

    Private Async Sub btnSetEnglish_Click(ByVal sender As Object, ByVal e As EventArgs)
        Await Translator.Instance.ChangeLanguageAsync("en-US")
    End Sub
End Class

Please take a look at the base package for more information like getting the available languages, changing the language, etc.

Der Beitrag rskibbe.I18n.Winforms – Translate your Windows forms apps – but easy erschien zuerst auf Robert Skibbe.

What is rskibbe.I18n.Json?

This is a sub-package of rskibbe.I18n to provide you with basic implementations for JSON file based translations. Now, go ahead and translate Windows Forms, WPF and Console applications – but easy. Multi-Language / internationalized apps – let’s go!

In the next few paragraphs, I’m going to show you, how to get started. As you’ve probably already seen, this package is a sub-package of rskibbe.I18n, so don’t forget to install that base package as well. As the name already suggests, rskibbe.I18n.Json focusses on file based translations using the JSON format.

💡 In a hurry?: No problem, just navigate to the points of interest by using the table of contents from above.

How to get started?

You can use the NuGet Package Manager from Visual Studio to install this package. If you are in Visual Studio, just click the „Extra“ menu button on top and navigate to the corresponding item. You could also do a right click on your project (inside the project explorer on the right side) and click „manage NuGet packages“ next. Now, just search for „rskibbe.I18n“ and you should be able to see every matching package – and there will be some 😉.

Or you could just use the following NuGet console commands:

// install the base package first
Install-Package rskibbe.I18n

// then execute this as well, to install the sub-package
Install-Package rskibbe.I18n.Json

Namespaces

After you have successfully installed both packages, go ahead and import the namespaces to get started. This will make the builder available, so you can get going fast. I won’t go to deep on the details of the base package, please refer to its own documentation for that.

using rskibbe.I18n.Models;
using rskibbe.I18n.Json;

Imports rskibbe.I18n.Models
Imports rskibbe.I18n.Json

Now you are ready to build your custom Translator fitting your individual Windows Forms, WPF, or Console App.

Setup

Creating the folder structure

Inside your output directory (where the finished exe resides, like bin/debug..), create this folder structure: The „i18n“ base folder at first, then the additional subfolder „json“. Inside of that „json“ folder, create the listed files:

• bin
  • debug
    • i18n
      • json
        • languages.json
        • en-US_English.json
        • de-DE_Deutsch.json

languages.json

This file represents/contains all available languages for your application – remember, in JSON format. Matching example contents to the example from above could look like this:

[{"iso": "de-DE", "name": "Deutsch"},{"iso": "en-US", "name": "English"}]

I specified the german and english language over here. Each one with a name and an iso „property“.

Translation files

Next, we will take a look at the translation files like „en-US_English.json“ from above. As you can see, you need to first mention the iso code (should correspond to your language file of course!). Then you just append an underscore with the specific language name.

The corresponding files from above would look like this:

Simple

en-US_English.json

{"key1": "Actions", "greeting": "Hello!"}

de-DE_Deutsch.json

{"key1": "Aktionen", "greeting": "Hallo!"}

The corresponding translation key would be „key1“, which would result in „Actions“ or „Aktionen“ depending on the language.

Namespaces / nested

en-US_English.json

{"frmMain": {"tsmiActions": "Actions"}}

de-DE_Deutsch.json

{"frmMain": {"tsmiActions": "Aktionen"}}

The corresponding translation key would be „frmMain.tsmiActions“, which is a „namespaced“ / nested one.

Code

Don’t forget to take a look at the base package setup, if you need more information. Here’s just an easy setup using the installed JSON implementations of ILanguagesLoader & ITranslationTablesLoader. Setting up the translator should be done as early as possible.

In the next step, we are telling the TranslatorBuilder to actually use the provided loaders from the package. It will then know „how do I load the languages“ and „how do I load the corresponding translations“. Don’t forget the imports mentioned above!

// don't forget the imports somewhere above..
using rskibbe.I18n.Models;
using rskibbe.I18n.Json;

// create and save the instance for later, DI, etc.
var translator = Translator.Builder
     .WithLanguagesLoader<JsonLanguagesLoader>()
     .WithTranslationTableLoader<JsonTranslationTableLoader>()
     .Build()
     .StoreInstance();

' don't forget the imports somewhere above..
Imports rskibbe.I18n.Models
Imports rskibbe.I18n.Json

' create and save the instance for later, DI, etc.
Dim translator = Translator.Builder _
     .WithLanguagesLoader(Of JsonLanguagesLoader)() _
     .WithTranslationTableLoader(Of JsonTranslationTableLoader)() _
     .Build() _
     .StoreInstance()

Full Code example

This is how a full code example could look like (don’t forget to install all needed packages and import the namespaces):

using rskibbe.I18n.Json;
using rskibbe.I18n.Models;

namespace <YourProjectName>;

public partial class Form1 : Form
{
    public Form1()
    {
        var translator = Translator.Builder
            .WithLanguagesLoader<JsonLanguagesLoader>()
            .WithTranslationTableLoader<JsonTranslationTableLoader>()
            .Build()
            .StoreInstance();
        InitializeComponent();
        Load += Form1_Load;
    }

    private async void Form1_Load(object? sender, EventArgs e)
    {
        await Translator.Instance.LoadLanguagesAsync();
        // after the languages have been loaded, the translator
        // set the language automatically, if WithLanguage("en-US")
        // has been used during initialization
        // if not, you could just trigger the initial language
        // change/set now
        // await Translator.Instance.ChangeLanguageAsync("en-US");

        // you could now get a specific translation by
        // (keep in mind, that on using WithLanguage, you
        // would actually need to like listen to the initial
        // LanguageChanged event, to get the translation)
        ITranslation translation = Translator.Instance.Translate("key1");
        // translation.Value -> Actions in en-US, Aktionen in de-DE
    }
}

Der Beitrag rskibbe.I18n.Json – A JSON file based translation sub-package erschien zuerst auf Robert Skibbe.

VB NET Web API – Web API Konsum von Grund auf erklärt

Heute erwartet Dich ein ganz besonderer und von vielen Abonnenten gewünschter Beitrag – die Implementierung einer VB NET Web API.

Es handelt sich genauer genommen um die Erstellung eines Clients, Welcher gewünschte Daten aus einer Web-Schnittstelle abrufen kann.

Die Web-API arbeitet dabei nach dem üblichen Standard, Sie gibt JSON-Daten zurück, Welche wir dann noch clientseitig verarbeiten müssen.

Letztendlich ist der Client natürlich nichts anderes als eine VB NET Klasse, bzw. eher gesagt eine Instanz davon.

Auf YouTube ansehen – VB NET Web API

Falls Du die visuelle Darstellung, bzw. Erklärung des Beitrages bevorzugst, kannst Du natürlich auch das dementsprechende Video anschauen.

Ursprung und Idee zum Beitrag – VB NET Web API

Den ursprünglichen Anreiz zum Video habe ich – wie fast immer – durch den eigenen Bedarf dazu gehabt.

Ich baue mir aktuell ein kleines Tool, Welches mir bei meiner Arbeit mit dem Staking von Kryptowährungen helfen soll.

Hier zeige ich Dir mal einen kleinen Ausschnitt, beachte jedoch, dass das Tool hier nicht weiter aufgegriffen wird:

Bisher musst ich bei Bedarf immer die einzelnen Werte und Positionen selbst errechnen, nun habe ich dafür letztendlich ein Mini-Tool gebaut.

Bewusst in der unteren, rechten Ecke positioniert, sollte es als eine Art Widget im Hintergrund funktionieren.

Bei Bedarf sollte es mir dann die gesammelten/verarbeiteten Informationen aufbereitet darstellen.

Gedanken zum Start

Bei den initialen Gedanken bezüglich des Projektstarts, kann man natürlich einiges einbeziehen.

Ich spreche hier unter anderem von Konzepten wie z. B. die Dependency-Injection, bzw. auch kurz DI genannt.

Als nächstes sollte man sich vermutlich über die restliche Infrastruktur der App Gedanken machen.

Hast Du eventuell das MVVM-Entwurfsmuster für Deine Anwendung eingeplant, oder möchtest Du „quick and dirty“ durchstarten?

In meinem Beitrag über das MVVM-Entwurfsmuster kannst Du mehr darüber erfahren und detailliert nachlesen.

Möchtest Du eventuell grafisch ansprechender arbeiten und ein GUI-Framework wie Mahapps-Metro verwenden?

Dann schaue Dir ggf. folgende Beiträge über Mahapps Metro an: Mahapps Metro Projekt aufsetzen.

Wegfallendes & Veränderungen

Viele Entwickler arbeiten bei einem Projekt zuerst einmal an einem „Minimum Viable Product“, kurz MVP.

Die Welt der Programmierung befindet sich in einem permanenten Wandel und nicht anders geht es Deinem Projekt.

Man möchte Kunden, Investoren, oder auch einfach Vorgesetzten ein schnelles und praxisnahes Beispiel des Projektes vorzeigen können.

Oftmals resultiert dies aus bestehendem Projektdruck, anderen wartenden Projekten, ungeduldigen Kunden, usw.

Da es sich hierbei allerdings um ein privates Projekt handelt, habe ich mich für eine hybride, bzw. einfache Lösung entschieden.

Ich habe daher als Basis ein kleines Interface erstellt, wovon sich dann Implementierungen ergeben können.

Man weiß nie, welche Webseiten, bzw. Schnittstellen irgendwann ihren Dienst quittieren.

Ebenso weiß man häufig nicht, inwiefern sich Preismodelle verändern, da sich auch kostenlose Modelle der Wirtschaftlichkeit anpassen müssen.

Besonders ehemals kostenlose „Subsciption-Plans“ werden irgendwann kostenpflichtig und bestehende Pläne werden teurer.

Wenn solche Veränderungen eintreten muss bestehende Software im Optimalfall natürlich gut gebaut sein.

Sie muss über eine gute Infrastruktur und Planung verfolgen, um auf eventuelle Änderungen reagieren zu können.

Dabei sollte Sie effizient und einfach umgestellt werden können und erfolgte Änderungen sollten einfach getestet werden können.

Vorbereitungen für die VB NET Web API

Um dieses Tutorial erfolgreich abschließen zu können, musst Du vorher noch einige Vorbereitungen treffen.

Du brauchst im ersten Schritt einen Account für den verwenden Web-Service namens „exchangeratesapi„.

Besuche dafür einfach die Website namens exchangeratesapi.io und erstelle Dir einen kostenlosen Account im „Free Subscription Plan“.

Der kostenlose Plan von exchangeratesapi.io bietet Dir die Möglichkeit 250 Anfragen im Monat kostenlos zu nutzen.

Wenn Du die Registrierung abgeschlossen und Deinen API-Key erhalten hast, können wir fortfahren.

Los geht’s

Hier starten wir mit der Basis des Codes und setzen die ersten Überlegungen um.

Wie oben schon erwähnt wird es ein Interface als kleine Basis geben:

Public Interface IExchangeRateService

    Function GetExchangeRateAsync(baseCurrency As String, targetCurrency As String) As Task(Of Double)

End Interface

Dieses stellt in der absoluten „easy-to-go“-Version nur eine einzige Funktion bereit – „GetExchangeRateAsync“.

Die Funktion soll uns den Wechselkurs der jeweiligen Basis-Währung in die angegebene Ziel–Währung liefern.

Wie Du in der Deklaration erkennen kannst, übergeben wir die beiden Währungen als Parameter vom Typ String.

Des Weiteren gibt die Funktion keinen simplen Double-Wert, sondern eine Task mit einem generischen Parameter vom Typ Double zurück.

Ich bevorzuge die asynchrone Arbeitsweise, daher wird die Funktion beispielhaft wie folgt aufgerufen:

Private Async Task LoadExampleDataAsync()
    Dim exchangeRate As Double = Await theService.GetExchangeRateAsync("EUR", "USD")
End Sub

Auch bei der Bezeichnung der Variante sollte man natürlich auf die „Asynchronität“ eingehen.

In der VB NET Welt hat es sich eingebürgert, asynchrone Funktionalitäten mit einem „Async„-Postfix zu kennzeichnen.

Möchte man stattdessen die synchrone Variante verwenden, kann man dafür natürlich auch einfach folgenden Code verwenden:

Private LoadExampleDataSync()
    Dim exchangeRate As Double = theService.GetExchangeRateAsync("EUR", "USD").Wait()
End Sub

Die oben genannte Schnittstelle wird dann von jeweiligen ExchangeRateServices implementiert – vorerst jedoch nur von Einem.

Konkrete Implementierung des Services

Mit dem Status quo gibt es nur eine „Service-Möglichkeit„, also eine konkrete Implementierung des Interfaces.

Dabei handelt es sich um die Web-Dienstleistung der oben genannten Seite, Welche uns als Daten-Lieferant dient.

Selbstverständlich könnten wir auch genauso gut mehrere Anbieter heraussuchen und Diese dann in eigenen Services implementieren.

Im folgenden Bild versuche ich diese Gegebenheit ein wenig besser darzustellen:

Klasse erstellen – Für ExchangeRatesApi.io

Erstelle also im nächsten Schritt eine eigene Klasse, in der wir dann beginnen, den Web-Dienst und unser Interface zu implementieren.

Die Bezeichnung bleibt hier natürlich Dir überlassen, man könnte hier den Hersteller des Web-Dienstes in irgendeiner Form einbringen.

Damit würde man ggf. klarer darstellen, dass es sich um die konkrete Implementierung für diese eine Website handelt.

Der Einfachheit halber und mangels anderer Implementierungen belasse ich es bei einem simplen Namen.

Implementiere anschließend das oben gezeigte Interface und Du solltest den gleich folgenden Stand haben.

Tippe dazu einfach „Implements“ in die nächstfolgende Zeile nach dem Klassennamen und gebe den Namen des Interfaces ein.

Danach kannst Du das gewünschte Interface ggf. schon durch Autokorrektur bestätigen.

Public Class ExchangeRateService
    Implements IExchangeRateService

    Public Function GetExchangeRateAsync(baseCurrency As String, targetCurrency As String) As Task(Of Double)
       
    End Function

End Class

Mit dem S aus „SOLID“ im Kopf

Mit dem „Single Responsibility“-Prinzip, Welches sich bei dem Akronym „SOLID“ hinter dem Buchstaben „S“ verbirgt im Kopf, arbeiten wir weiter an der Klasse.

Die Bedeutung des Prinzips ist letztendlich grob gesagt, dass eine Klasse jeweils nur einen Zweck haben sollte.

Inwiefern viele Entwickler diesen Interpretations-Raum ausschöpfen, oder regulieren, mag erstmal dahingestellt sein.

In unserem Fall hat die Klasse ja z. B. einen API-Key, Welchen Sie verwenden muss, um bei der Web-Schnittstelle authentifiziert zu werden.

Diesen API-Key zu laden, ist allerdings eigentlich nicht die Aufgabe der Klasse selbst, sondern eher einer „Configuration“-like Klasse.

Die „Configuration„-Klasse könnte natürlich auch wieder ein Interface mit „Get“- und „Set“-Methoden implementieren.

Man könnte die Konfiguration im ersten Schritt durch die NET Settings realisieren, danach vielleicht auf Datenbank-, oder gar auf Web-Ebene.

So würde alles schön sauber, separat und wart-, bzw. testbar sein – schön!

Basis-Daten festlegen

Statt der eigenen Konfigurations-Klasse verwenden wir der Einfachheit halber einfach konstante Strings.

Diese definieren dann die benötigten Daten, wie z. B. den API-Schlüssel und die Basis-URL an Welche die Anfragen gesendet werden müssen.

Die Daten selbst verwenden wir dann später, um korrekt formatierte/aufgebaute Anfragen zu erstellen.

Public Const API_KEY As String = "<myApiKey>"
Public Const BASE_URL As String = "https://api.exchangeratesapi.io/v1"

Ein Singleton, Welcher keiner ist – lol

In Vielen verschiedenen Sprachen sollte man Singletons für Zugriffe auf das Web, also durch GET-, POST-, etc. Methoden erstellen.

Es macht keinen Sinn, für jede einzelne Anfrage einen weiteren „HttpClient“ zu erzeugen, sondern eher den Selben erneut zu benutzen.

Soweit ich mich erinnern kann, steht das sogar in der Dokumentation zum Client drin.

Als ich damals mit Java für die Android-Entwicklung gearbeitet habe, war es dort übrigens auch so.

Mittlerweile hat Google glaube ich selbst die Steuerung übernommen, damit man dies praktisch nicht mehr selbst realisieren muss.

Schnell und einfach habe ich hier einfach folgenden Code verwendet:

Imports System.Net.Http

Public Class Http
  
  Public Shared <ReadOnly> Client As HttpClient = New HttpClient()

End Class

Dieser Code sorgt zwar nicht dafür, dass der Client nicht einfach neu gesetzt werden könnte, macht aber denke ich den Part der Wiederverwendung klar.

Setze ggf. einfach einen Readonly-Modifizierer vor den Namen des Clients.

Den Request zusammenbauen – VB NET Web API

Wir können natürlich nicht einfach irgendwelche Anfragen an irgendwelche URLs schicken, sondern müssen uns irgendwo an den korrekten Aufbau halten.

Die oben definierte Basis-URL dient schonmal wie der Name sagt als Basis für das Ganze.

Im nächsten Schritt müssen wir in der Dokumentation herausfinden, welchen sogenannten Endpunkt wir verwenden müssen.

In unserem Fall ist der korrekte Endpunkt der „/latest„-Endpunkt, Welcher natürlich noch zusätzliche Daten übermittelt bekommen möchte.

Unsere Funktion muss also nun einen GET-Request an den genannten Endpunkt senden.

Aus der Dokumentation geht hervor, dass jeder (gesicherte) Endpunkt unseren API-Key in Form eines Query–Parameters übergeben bekommen möchte.

Des Weiteren braucht der Endpunkt die Information, welche Basis-Währung verwendet werden soll.

Standardmäßig kann man im Free-Plan leider nur Euro verwenden, ich werde die Implementierung des Services natürlich trotzdem korrekt gestalten.

Behalte allerdings deshalb im Kopf, dass Du nur „EUR“ als Basis-Währung übermitteln kannst und Du sonst vermutlich einen Fehler bekommen wirst.

Alternativ könntest Du den Parameter auch eventuell weglassen und die Web-Schnittstelle würde so automatisch „EUR“ ziehen.

Gleich findest Du einen möglichen Aufruf, bzw. eine mögliche Verwendung der bekannten Aspekte.

Zuerst wandle ich die übergebenen Währungen (wie Sie üblich benötigt werden) in Großbuchstaben um (eur -> EUR).

Query-Parameter

Danach mache ich mir den Rückgabewert der ParseQueryString-Funktion der HttpUtility-Klasse zu Nutze.

Daraus bekommen wir eine Art NameValueCollection, ich sage deshalb „Art“, weil es wohl eine davon erbende Variante sein muss.

In Visual Studio selbst, sagt die Dokumentation leider im Tooltip dazu nicht mehr.

Vielleicht übersehe ich auch etwas, aber probiere mal die manuelle Erstellung einer „NameValueCollection“.

Füge anschließend 2-3 Einträge hinzu und gebe Diese dann als String aus und Du wirst einen Unterschied feststellen.

Dim myNVC = new NameValueCollection()
myNVC.Add("entry1", "value1")
myNVC.Add("entry2", "value2")
myNVC.Add("entry3", "value3")
' "normal"
Dim str = myNVC.ToString()
' or with Interpolation
' Dim str = $"{myNVC}"

Im obigen Beispiel bekommst Du folgendes Ergebnis (wenn Du es ausgibst..):

Man bekommt also praktisch nur den vollständigen Pfad der Klasse inkl. Namespace zurück.

Wenn Du Dir allerdings den „ToString“-Wert des folgenden Beispiels anschaust, wird die Situation klarer:

Dim API_KEY = "BLA"
Dim baseCurrency = "EUR"
Dim targetCurrency = "USD"

Dim query = HttpUtility.ParseQueryString(String.Empty)
query.Add("access_key", API_KEY)
query.Add("base", baseCurrency)
query.Add("symbols", targetCurrency)

Dim str = query.ToString()
Console.WriteLine(str)
Console.ReadKey()

Hier bekommen wir nun die einzelnen Schlüssel- und Wert-Paare wie wir Sie für die URL benötigen zurück.

Die von der „NameValueCollection“ erbende Klasse, Welche wir vermutlich von „HttpUtility.ParseQueryString“ zurückbekommen, wird also die „ToString„-Funktion überschreiben.

Somit sieht also unser erster API aufrufender Code so aus:

Public Function GetExchangeRateAsync(baseCurrency As String, targetCurrency As String) As Task(Of Double)
    baseCurrency = baseCurrency.ToUpper()
    targetCurrency = targetCurrency.ToUpper()

    Dim query = HttpUtility.ParseQueryString(String.Empty)
    query.Add("access_key", API_KEY)
    query.Add("base", baseCurrency)
    query.Add("symbols", targetCurrency)

    Dim apiUrl = $"{BASE_URL}/latest?{query}"
    Dim response = Await Http.Client.GetAsync(apiUrl)
    Dim responseContent = Await response.Content.ReadAsStringAsync()

    ' parsing..

    Return 0
End Function

Setze Dir gerne mal einen Haltepunkt auf den „responseContent“ und schaue Dir das Ergebnis an:

{"success":true,"timestamp":1632925144,"base":"EUR","date":"2021-09-29","rates":{"JPY":129.884571}}

API-Antwort verarbeiten – VB NET Web API

Einige werden das obige Format, Welches als Antwort von der API kommt vermutlich bereits kennen und verstehen.

Für andere noch nicht so in der Entwicklung tief verankerte Personen, ist es ggf. ein kryptisches Gebilde.

Bei dem kryptischen Text handelt es sich aber um nichts Geringeres, als die „JavaScript Object Notation“ – kurz JSON.

Sie sieht im Vergleich zum ebenfalls sehr bekannten, aber zugegebenermaßen bereits in die Jahre gekommenen XML-Standard kryptischer aus.

Allerdings ist JSON wesentlich kompakter und für das geschulte Auge auch nicht wesentlich schwieriger zu lesen.

JSON in Objekt umwandeln

Um nun mit unserer Arbeit an der API fortfahren zu können, müssen wir den obigen JSON-String in ein NET-Objekt umwandeln.

Nur so ermöglichen wir uns eine einfache und saubere Arbeit damit, denn wer möchte hier schon manuelle Arbeit mit Funktionen wie z. B. Substring, etc. leisten.

Für die Umwandlung selbst benötigen wir im ersten Schritt erstmal eine Klasse, Welche das in JSON formulierte Objekt auf NET-Ebene widerspiegelt.

Dazu könnten wir einerseits händisch loslegen und die einzelnen Eigenschaften definieren:

Public Class ApiResponse

  Public Property success As Boolean

  Public Property timestamp As Integer

  ' ...

End Class

Oder uns andererseits durch moderne Hilfsmittel in Visual Studio helfen lassen.

Visual Studio besitzt die Funktionalität, einen JSON-String gar automatisiert in passende Klassen umzuwandeln:

JSON String mit Visual Studio in NET Objekt umwandeln

Auch wenn es mit dem aktuellen Stand schon funktionieren würde, den String in ein Objekt (mit Sub-Objekten) umzuwandeln.

Leider kann die API ja mit dynamischen „symbols“ aufgerufen werden, weshalb ggf. unterschiedliche und nie fixe „Properties“ in dem „Rate“-Objekt zurückkommen.

Wenn Dich das nicht weiter stört, könntest Du natürlich die „Rate„-Klasse so ausbauen, dass sämtliche Währungen dort drinnen vertreten wären.

Ich persönlich fände das allerdings nicht so prickelnd, daher bauen wir die „RootObject„-Klasse noch ein wenig um und lassen die „Rates„-Klasse verschwinden.

JSON Parser installieren

Als nächstes installieren wir das bekannte Newtonsoft Json NuGet-Paket, um eine einfache Handhabung mit JSON-Objekten zu erhalten.

Danach passen wir die „RootObject„-Klasse an, indem wir Sie zuerst einmal sinnvoller benennen, also etwa „ExchangeRatesApiResponse„.

Anschließend ändern wir den Rückgabetyp der „rates„-Eigenschaft in „JObject“ um, Welches es uns die Arbeit erleichtert.

Nun können wir die „responseContent„-Variable, worin unser JSON-String steckt endlich umwandeln.

Im gleichen Schritt können wir auch noch die „exchangeRate“, also den Wechselkurs, typisiert aus der „rates„-Eigenschaft ziehen.

Die Umwandlung selbst – VB NET Web API

Dazu rufe ich im ersten Schritt die „DeserializeObject„-Funktion der „JsonConvert„-Klasse auf, Welche wir uns mit dem NuGet-Package installiert haben.

Dabei übergebe ich den generischen Parameter „ExchangeRatesApiResponse“, Welcher unseren Ziel-Datentyp für die „Antwort-Klasse“ widerspiegelt.

Schon haben wir den letztendlichen Wechselkurs vorliegen!

Dim apiResponse = JsonConvert.DeserializeObject(Of ExchangeRatesApiResponse)(responseContent)
Dim exchangeRate = apiResponse.rates.Value(Of Double)(targetCurrency)

Ein beispielhafter Aufruf unseres Services innerhalb einer Konsolenanwendung könnte nun final so aussehen:

Module Program

    Sub Main(args As String())
        Dim service = New ExchangeRateService()
        Dim exchangeRate = service.GetExchangeRateAsync("EUR", "JPY").Wait()
        ' do something with exchangeRate..
    End Sub

End Module

Weiterführende Links

• VB NET MouseClick simulieren – mit AutoIt3
• VB NET ImageSearch – Bilder in Spielen, Desktop und Co. suchen

Downloads

Hier findest Du wie immer die zugehörigen Downloads zum Beitrag.

Der Beitrag VB NET Web API – Währungskurs Service Konsum von Grund auf erklärt erschien zuerst auf Robert Skibbe.