SignalR je knihovna pro ASP.NET Core, která umožňuje jednoduše přidat funkcionalitu pro reálnou komunikaci mezi servery a klienty v aplikacích. Tato technologie je ideální pro aplikace, kde je potřeba okamžitě aktualizovat informace na webových stránkách, jako jsou aplikace pro chatování, systém notifikací nebo informační panely, které zobrazuji data v reálném čase, například akciové ceny.

Abychom pochopili výhody SignalR, je potřeba se podívat na historii protokolu HTTP a na to, jak byly vyvinuty technologie pro zlepšení komunikace mezi klienty a servery. V 90. letech, kdy web začínal, musely prohlížeče odesílat plné HTTP GET požadavky na server, aby získaly čerstvé informace pro zobrazení. Tento způsob komunikace byl poměrně neefektivní, což vedlo k potřebě nových řešení.

V roce 1999 Microsoft představil Internet Explorer 5.0, který obsahoval komponentu XMLHttpRequest, která umožnila asynchronní HTTP volání na pozadí. Tento přístup, známý jako AJAX, umožnil stránkám hladce aktualizovat jejich obsah bez nutnosti načítání celé stránky. Tento způsob, i když velmi užitečný, má však své limity: HTTP je protokol request-response, což znamená, že server nemůže klientovi posílat data, dokud o ně klient nepožádá.

Vzhledem k těmto limitům se objevila technologie WebSocket, která umožňuje obousměrnou komunikaci mezi klientem a serverem přes jedno TCP spojení. WebSocket je efektivní, protože používá minimální množství dat a umožňuje okamžitou výměnu informací. I když je WebSocket silným nástrojem pro real-time komunikaci, není podporován všemi klienty a může být obtížné jej implementovat napříč různými platformami.

Právě tady přichází na scénu SignalR, což je open-source knihovna pro ASP.NET Core, která abstrahuje různé technologie pro komunikaci v reálném čase a automaticky přepíná mezi nimi podle toho, co je podporováno prohlížečem návštěvníka. SignalR využívá WebSocket, pokud je to možné, a v případě potřeby přechází na jinou technologii, jako je AJAX long polling.

SignalR usnadňuje přidání real-time funkcionality do webových aplikací. Pomocí SignalR mohou vývojáři snadno implementovat server-to-client RPC (remote procedure calls), které zavolají JavaScriptové funkce na klientech ze serverového kódu .NET. K tomu slouží "hubs", které automaticky spravují rozesílání zpráv mezi servery a klienty. SignalR podporuje různé klientské platformy, včetně JavaScriptových klientů pro moderní prohlížeče, .NET klienty (např. Blazor, Xamarin pro mobilní aplikace), a dokonce i Java klienty od verze 8.

Pro praktické nasazení a škálování SignalR ve větších aplikacích je doporučeno oddělit SignalR hosting od samotné webové aplikace. To znamená, že SignalR může běžet na samostatném serveru, což výrazně zjednoduší škálování a umožní lepší správu zátěže. Zde přichází na scénu Azure SignalR Service, která poskytuje globální pokrytí, škálovatelnost a bezpečnostní vlastnosti potřebné pro aplikace, které vyžadují vysokou úroveň spolehlivosti a výkonu.

Důležitým principem při návrhu metod pro SignalR služby je dodržování zásady používání jednoho parametru zprávy místo více jednoduchých parametrů. Tento přístup je flexibilnější, umožňuje snadné přidávání nových vlastností do zpráv bez narušení stávajících klientů, což je udržitelné i pro budoucí změny.

Pokud chcete implementovat jednoduchou aplikaci pro chat pomocí SignalR, doporučuje se oddělit serverový SignalR hub od webového projektu. Vytvoření samostatného SignalR projektu vám umožní škálování a lepší kontrolu nad výkonností. Příkladem je chatová aplikace, kde mohou uživatelé posílat zprávy jak všem návštěvníkům stránky, tak konkrétním uživatelům nebo dynamickým skupinám.

Pro vývoj aplikace s reálnou komunikací je klíčové pochopit rozdíl mezi různými komunikačními technologiemi, jako je WebSocket a AJAX, a mít na paměti, jak SignalR tyto technologie využívá k dosažení optimálního výsledku.

Pokud jde o dobrou praxi při navrhování metod pro SignalR, vždy se doporučuje použít jeden složený objekt místo několika parametrů. Tento přístup nejen usnadňuje budoucí úpravy, ale také zajišťuje zpětnou kompatibilitu, což je důležité pro dlouhodobou stabilitu aplikace. Příklad ukazuje, jak je lepší definovat třídu pro zprávu, která zahrnuje všechny její vlastnosti, než použít několik jednoduchých parametrů.

Endtext

Jak vytvořit moderní aplikace na platformě Windows: od WPF až po .NET MAUI a cross-platformní vývoj

Vytváření aplikací pro Windows s využitím WPF (Windows Presentation Foundation) a .NET je oblíbeným způsobem vývoje pro mnoho profesionálních vývojářů. WPF umožňuje tvorbu aplikací, kde se logika a uživatelské rozhraní kombinují pomocí jazyka C# a XAML (eXtensible Application Markup Language), což poskytuje vysokou flexibilitu a přehlednost. Tento přístup je známý svou schopností usnadnit jak tvorbu uživatelského rozhraní, tak jeho údržbu a rozšiřování. Navíc, aplikace vytvořené pomocí WPF jsou známé svou stabilitou a schopností plně využívat sílu Windows desktopových technologií.

V roce 2012 Microsoft představil Windows 8, které přineslo koncept aplikací v Windows Store. Tyto aplikace běžely v chráněném sandboxu a měly omezený přístup k systémovým prostředkům. V roce 2015, s příchodem Windows 10, byla představena platforma Universal Windows Platform (UWP). Aplikace UWP mají širší možnosti, ale zároveň i omezený rozsah, pokud jde o dostupnost na různých verzích Windows, přičemž podporují pouze Windows 10 a novější verze. Kromě toho mohou běžet na dalších zařízeních, jako je Xbox nebo headsety pro Windows Mixed Reality.

Vývojáři, kteří se orientovali na tradiční WPF a Windows Forms aplikace, se dlouho potýkali s problémem udržitelnosti a rozšíření těchto starších platforem v moderním světě. Aplikace na platformě .NET Framework, který je dnes považován za zastaralý, byly omezeny ve své funkčnosti. S příchodem .NET Core a moderního .NET však mohou nyní tyto aplikace využívat plné možnosti moderního prostředí, což přináší nové možnosti pro jejich další rozvoj.

Microsoft reagoval na výzvy, které vývojáři čelili, iniciativou známou jako Project Reunion a nástrojem WinUI 3, které byly později začleněny do Windows App SDK. Tento nástroj umožňuje přenést některé výhody moderního vývoje aplikací do starších WPF aplikací, čímž umožňuje jejich integraci do širšího ekosystému Windows, včetně funkcí dostupných v UWP aplikacích.

Při vývoji aplikací, které mají běžet na více platformách, se ukázalo, že stále existují čtyři hlavní platformy: iOS, Android, macOS a Windows, přičemž každá z nich má své specifické nástroje a programovací jazyky. Pro iOS je to Objective C nebo Swift a UIKit, pro Android Java nebo Kotlin a Android API, pro macOS Objective C nebo Swift a AppKit nebo Catalyst, a pro Windows C, C++ a Win32 API nebo Windows App SDK.

Pro vývoj multiplatformních mobilních a desktopových aplikací dnes existuje .NET MAUI, který umožňuje vývoj jediné aplikace, která běží na více platformách. Tento rámec podporuje jak sdílení uživatelských rozhraní, tak obchodní logiky napříč různými platformami. .NET MAUI navazuje na starší vzory, jako je MVVM, ale také plánuje integraci novějšího přístupu Model-View-Update (MVU), který se podobá SwiftUI od Apple. Tento nástroj umožňuje nejen snadný vývoj, ale i flexibilitu při přizpůsobování aplikací různým zařízením.

Než byl .NET MAUI vytvořen, existovaly již alternativy třetích stran pro vývoj multiplatformních aplikací. Mezi nejznámější patří Uno a Avalonia. Platforma Uno se zaměřuje na využívání C# a XAML pro tvorbu multiplatformních aplikací, přičemž je plně otevřeným a zdarma dostupným nástrojem. Umožňuje opětovné využití logiky a uživatelského rozhraní na nativních mobilních, webových a desktopových platformách, včetně podpory pro WebAssembly a Linux.

Na druhé straně Avalonia, která je považována za duchovního nástupce WPF, umožňuje vytvářet plně nativní aplikace pro různé platformy a je ideální pro složitější aplikace. Tento nástroj používá podobný přístup jako WPF, což znamená, že vývojáři, kteří již mají zkušenosti s WPF, mohou snadno přejít na Avalonia a využít svou stávající znalost. Kromě toho se Avalonia používá například při modernizaci nástrojů JetBrains, což podtrhuje její robustnost a univerzálnost.

Při výběru vhodného nástroje pro vývoj aplikací je klíčové zaměřit se na platformu a technologii, která nejlépe odpovídá potřebám projektu. Pro vývoj aplikací v C# existuje několik vývojových nástrojů, včetně Visual Studio 2022 pro Windows a Mac, Visual Studio Code pro různé operační systémy a JetBrains Rider. Pro vývoj multiplatformních aplikací, jako jsou mobilní a desktopové aplikace pomocí .NET MAUI, je ideální využít Visual Studio 2022, které má lepší podporu pro tuto technologii než Visual Studio Code. Visual Studio Code je však velmi populární pro webový vývoj a díky své nízké hmotnosti a podpoře pro různé operační systémy je oblíbený u vývojářů zaměřených na multiplatformní aplikace.

Výběr nástroje pro vývoj závisí na konkrétním projektu a požadavcích vývojáře. Bez ohledu na to, zda jde o .NET MAUI nebo WPF, správný nástroj dokáže výrazně usnadnit proces vývoje a přinést požadovaný výsledek.

Jak vytvořit funkce Azure pro zpracování front a BLOBů s využitím ImageSharp

Vytváření serverless funkcí v Azure je účinný způsob, jak spravovat složité procesy bez nutnosti správy serverů. Tento proces zahrnuje používání Azure Functions pro zpracování front, ukládání souborů do BLOB úložiště a generování obrázků. V tomto článku si ukážeme, jak vytvořit funkci pro generování obrázku s šekem, jeho následné uložení do BLOB úložiště a integraci s frontami pro spouštění těchto operací na základě zpráv v queue.

Pro tento účel je použita knihovna ImageSharp, která umožňuje efektivní manipulaci s obrázky v aplikacích .NET. Následující kód demonstruje základní způsob, jakým je možné vytvořit obrázek šeku, uložit jej do paměti a nakonec nahrát na BLOB úložiště v Azure.

Kód nejprve definuje možnosti pro vykreslování textu na obrázek, včetně písma, umístění textu a zarovnání. Poté se obrázek vytváří a ukládá jako soubor PNG. Pokud je aplikace spuštěna lokálně, obrázek se uloží do souborového systému, pokud naopak běží v cloudu, uloží se do BLOB úložiště.

Dalším důležitým aspektem je správné používání časových značek pro generování názvů souborů, aby se předešlo konfliktům při ukládání souborů do BLOB úložiště. Tato metoda využívá aktuální UTC čas pro tvorbu unikátního názvu souboru.

Pokud běží funkce v lokálním prostředí, je obrázek uložen do složky blobs ve vaší aktuální pracovní složce. Pokud běží na serveru Azure, obrázek je uložen přímo do BLOB kontejneru, který je dostupný prostřednictvím služby Azure Blob Storage. Tato funkce může být navázána na frontu, kde zpráva ve frontě vyvolá generování a uložení obrázku.

Při práci s Azure Functions je klíčové mít správně nastavené spojení na Azure Storage. To je dosaženo pomocí atributu [StorageAccount("AzureWebJobsStorage")], který umožňuje aplikaci připojit se k úložišti, jak v lokálním prostředí, tak po nasazení na cloud.

Další součástí implementace je integrace s QueueTrigger, což je mechanismus, který spouští funkci při přidání nové zprávy do fronty. Tento trigger zajišťuje, že funkce bude automaticky spuštěna, když je ve frontě nová zpráva. Parametr [QueueTrigger("checksQueue")] specifikuje název fronty, která tuto funkci vyvolá. Funkce tedy nejprve zpracuje zprávu v queue a následně vytvoří obrázek a uloží jej.

Pro testování této funkce v lokálním vývojovém prostředí je nutné nastartovat projekt, který poskytuje prostředí pro testování Azure Functions. Pomocí Visual Studio Code nebo jiného vývojového nástroje lze spustit lokální server, který simuluje Azure prostředí. K tomu slouží například nástroj Azurite, který je emulátorem BLOB úložiště.

Po úspěšném spuštění funkce se v systému vytvoří soubor, který bude uložen jak v místním souborovém systému, tak v Azure Blob Storage. To umožňuje ověřit správnou funkčnost aplikace, aniž by bylo nutné nasadit ji do skutečného cloudového prostředí.

Testování a nasazení

Pro testování je možné spustit funkci přes HTTP, kde například zavolání endpointu NumbersToWordsFunction vrátí textovou odpověď ve formě číselného slova. Tento test nejen ukáže správnost fungování samotné funkce, ale také spustí generování šeku na základě zprávy přidané do fronty.

Po úspěšném otestování funkcí je možné přistoupit k publikování funkce do cloudu. Použití Visual Studio 2022 umožňuje snadné nasazení funkcí do Azure prostředí, kde se vytvoří instance funkce a následně se nakonfigurují potřebné prostředky jako Storage účet a plán pro spotřebu.

Co je důležité si uvědomit?

  • Správné používání prostředí: Je zásadní si uvědomit, že při práci s Azure Functions je třeba správně nastavit prostředí, včetně parametrů pro připojení k úložišti a triggerům. Použití environmentálních proměnných, jako je IS_LOCAL, umožňuje efektivně testovat a spouštět aplikace jak v lokálním prostředí, tak v cloudu.

  • Optimalizace pro cloudové prostředí: V produkčním prostředí na Azure je nutné brát v úvahu optimalizaci výkonu a efektivitu. Použití GUIDs pro generování názvů souborů nebo zajištění správného nastavení pro vysoce dostupné BLOB úložiště je klíčové pro zajištění dlouhodobé udržitelnosti a spolehlivosti systému.

  • Bezpečnost: Při práci s Azure a s citlivými údaji, jako jsou generované šeky nebo osobní informace, je nezbytné dbát na bezpečnostní aspekty, jako je šifrování dat a správná správa přístupových práv. Důležité je také správné nastavení oprávnění pro přístup k BLOB úložištím a frontám.

Jak nakonfigurovat připojení k webové službě v .NET MAUI

Při vývoji multiplatformní mobilní aplikace v .NET MAUI je často nezbytné, aby aplikace mohla komunikovat s externími webovými službami. V tomto případě se zaměříme na to, jak nakonfigurovat aplikaci pro připojení k těmto službám, a to jak pro iOS, tak pro Android. Tento proces zahrnuje nastavení pro povolení nezabezpečených připojení a zajištění správného fungování aplikace na různých platformách.

Na začátku je nutné správně nastavit konfigurace pro obě platformy. U iOS je důležité upravit soubor Info.plist, aby bylo povoleno připojení k webovým službám přes nezabezpečený protokol (HTTP). V případě Androidu, konkrétně verze 9 (API level 28) a novějších, je podpora pro "cleartext" (tedy nezabezpečené HTTP připojení) vypnuta, což znamená, že je nutné provést příslušné změny, aby aplikace mohla fungovat i s nezabezpečenými protokoly.

Pro Android je potřeba upravit soubor AndroidManifest.xml a přidat konfiguraci pro povolení nezabezpečených připojení. K tomu je třeba vytvořit nový soubor XML ve složce xml a upravit manifest tak, aby tento soubor odkazoval na nově vytvořenou konfiguraci. Tento krok je klíčový pro to, aby aplikace mohla komunikovat s webovou službou na specifické IP adrese, kterou běžně používáme pro localhost.

Pro připojení k webové službě pak stačí upravit konstruktor stránky, která načítá seznam zákazníků. V případě, že dojde k chybě při získávání dat z webové služby, aplikace místo toho použije ukázková data. Tento postup umožňuje aplikaci správně fungovat i v případě, že webová služba není dostupná.

Pro připojení k webové službě je potřeba správně nastavit HttpClient, který bude komunikovat s odpovídajícím koncovým bodem služby. Je nutné zajistit, že požadavky budou správně formátovány jako JSON, což je dnes běžně používaný formát pro výměnu dat mezi aplikacemi a webovými službami. V případě úspěšného připojení a načtení dat aplikace zobrazuje seznam zákazníků na stránce.

Pokud aplikace načte data úspěšně, měl by být tento seznam zobrazen na stránce. Na druhou stranu, pokud dojde k chybě při připojení, zobrazí se uživateli chybová zpráva a místo reálných dat budou použita data ukázková.

Důležitým krokem v celém procesu je nejen správné nastavení připojení, ale i zajištění, že aplikace bude schopna správně fungovat na různých zařízeních, ať už na Androidu, nebo na iOS. Je nutné si být vědom toho, že simulátory na Windows pro iOS aplikace ve skutečnosti běží na připojeném Macu, což může mít vliv na schopnost připojit se k místním webovým službám.

Kromě samotné konfigurace připojení je důležité věnovat pozornost také správnému ošetření chyb a implementaci mechanismu, který umožní aplikaci reagovat na různé scénáře. Tímto způsobem zajišťujeme stabilitu aplikace a uživatelský komfort.


Endtext