Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Muffy 23. 01. 2024, 23:44:08
-
Ahoj, prosím poraďte jaké technologie zvolit pro můj projekt. (.NET MAUI nebo JS nebo oba dohromady + jak pořešit databázi?)
Jakž takž ovládám C#.NET (základ, OOP a ADO.NET, zatím ještě ne ASP.NET) a mám základ v JS. Nicméně vše je naučeno z kurzů, nemám žádnou praxi a nevím tedy jaké technologie se používají pro vývoj mobilních aplikací, přesněji zda se kombinují dva různé jazyky či se vybere jeden a s tím se dělá vše. Chci dělat mobilní appku, kde uživatelé budou moci vidět záznamy ostatních, ale bude možné ji používat i offline s následnou synchronizací hned jak se dostanou k internetu. Aplikace má být jakoby To-Do list formou hry, na to se hodí asi javascript, jen s pomocí C# asi takovou appku neudělám že (minimálně tak, aby to nějak vypadalo)? Nebo dá se celá appka udělat jen za pomocí Javascriptu (asi Reactu?) a použití .NETu je zde zbytečné? Či se vyloženě hodí JS použít pro frontend a na backend použít MAUI (bývalý Xamarin) od .NETu? A jaká technologie se používá pro sdílené ukládání uživatelských dat, používat ADO.NET a dělat kvůli tomu MS SQL server mi přijde padlé na hlavu.
Ráda se naučím nové technologie, ale nechci se učit něco, co se v praxi nakonec nepoužívá, proto tato otázka :) Chci udělat vlastní projekt, který pak bude sloužit i jako ukázka na pohovorech že něco reálně umím udělat.
Předem dík za ujasnění, mějte se mnou prosím trpělivost, děkuji :)
-
c# pouzivam v praci ale jen pro desktopovou aplikaci s c++.
kdyz jsem si hral s androidem tak jsem to radsi delal v jave a kotlinu.
ale v diskuzi probiraji xamarin a maui:
https://www.reddit.com/r/csharp/comments/mmrgnv/net_maui_vs_native_android_development/
-
Předesílám, že jsem backend vývojář a tudíž se v mobilních aplikacích ani frontendu zas tak moc neorientuju.
Ale ta otázka mi zní trochu divně - opravdu chceš dělat mobilní aplikaci ve smyslu "instalovatelná věc stažená z Google Play / App Store), nebo spíš webovou aplikaci, která poběží i na mobilu? Protože opravdový mobilní aplikace se myslím většinou nepíšou ani v Javascriptu, ani v .NET, ale spíš v Kotlinu (Android) nebo Swiftu (iOS). Asi existujou i nějaký způsoby, jak na to použít .NET, ale bude to spíš vzácnost.
Jinak pokud má mít aplikace nějaké sdílení mezi uživateli, tak se nevyhneš provozování vlastního serveru a na něm klidně můžeš použít .NET.
-
Mam pocit, ze to mas dost dopletene MAUI na bakcned?
MAUI je frondend technologia, v ktorej sa da robit mobilna aplikacia.
Dalsia vec, co mas zle je ADO.NET a MS SQL Server, ADO.NET vie pracovat s akukolvek databazou, nie len s nim.
naj skor si pozri na nejake uz existujuce projekty.
A ked chces spravit nejaku mobilnu Apku co sheruje data medzi pouzivatelmi tak asi takto:
Mobilna aplikacia (MAUI - ziaden JS) -(REST)-> ASP.NET Core + swagger + Entity framework Core (alebo ADO.NET ak sa chces naucit SQL) -> Lubovolna databaza
Mozes REST vymenit za gRPC, graphQL, alebo OData.
Webova aplikacia (Blazor Wasm - ziaden JS) -(Rest)-> ASP.NET Core ...
Webova apka (Blazor Server), EF core-> Databaza
alebo
Webova aplikacia s JS -(REST)-> ASP.NET Core ...
-
mobilne apky, to je cesta do pekla. Musim tam brat do uvahy milion veci, ako napr. rozne velkosti displeja, rozne verzie android, ci ho ma vertikalne, alebo horizontalne...
Preto robim backend :)
ak chces offline apku, tak js urcite nie, bud .net, ale ta apka bude mat 20-30MB, alebo nastrojom priamo na to urcenym - java a android studio.
Synchronizacia so servrom - pozor na to, ze to musi byt sifrovane.
ja mam par mobilnych app v .net, ale to su skor len take cisto pre moje domace pouzitie, takze tam nejak neriesim bezpecnost a velkost.
Co sa tyka miesania jazykov, bezne sa to robi, ale rozdelene na logicke casti. Napr. front-end je web (js+php), servisna je .net, ktora moze komunikovat s mikroservismi napisanymi napr. v pythone, databaza...
-
Předně, u desktop/mobilních app neexistuje frontend a backend, ale prezentační vrstva (UI), aplikační vrstva (BI), případně další vrstvy jako datová vrstva, která může být dále dělená, atd. ... viz. https://cs.wikipedia.org/wiki/V%C3%ADcevrstv%C3%A1_architektura (https://cs.wikipedia.org/wiki/V%C3%ADcevrstv%C3%A1_architektura)
MSSQL se jako DB v mobilních aplikacích nepoužívá.
Pokud chceš dělat "To-Do" se synchronizací mezi zařízeními, budeš potřebovat celý projekt roztrhnout na 2 "aplikace".
1) Mobilní
- UI se definuje v Xaml/xml.
- Business logika potom v C# když chceš použít .NET - Tedy Xamarin / MAUI
- DB se používá SQLite - SQL/případně nějaká lehká abstrakce nad, Entity Framework Core je v tomto případě výkonnostní vražda.
2) Server - místo, které zná vše a slouží pro výměnu dat mezi ostatními
- možná Frontend? - jestli není zbytečný, max. můžeš nechat swagger generovat popis API
- backend API - C# - s tímto API se bude spojovat mobilní apka a vyměňovat si data.
- aplikační vrstva - C#
- datová vrstva DB MSSQL/PostgreSQL/Maria Db/My SQL .... čisté SQL+DataTable / EF Core atd.
Jinak co se týče programovacích jazyků, s 1 jazykem si nikdy nevystačíš. Vždy je potřeba umět "základní" jazyk (např. C#, Kotlin, Java, PHP, Python, Rust, atd. atd.), a alespoň základně SQL, Html, JavaScript. Dál je potřeba vědět co je to Xml, Json (případně Bson), API, webové API.
V každé firmě kam potom nastoupíš si tě více či méně "usměrní" do jejich technologických kolejí.
-
ak chces offline apku, tak js urcite nie, bud .net, ale ta apka bude mat 20-30MB, alebo nastrojom priamo na to urcenym
Ja by som len podotkol, ze tych 20-30MB je este OK. Dnesne realne mobilene aplikacie maju tak 10-110MB a to ide o aplikaciu, co ma jedno tlacidlo a dva riadky textu (napr. mobilny token k internetovemu bankovnictvu).
- DB se používá SQLite - SQL/případně nějaká lehká abstrakce nad, Entity Framework Core je v tomto případě výkonnostní vražda.
Ja som pri EF core nikdy nemal problemy ani na razzberry pi Zero, co je ovela menej vykonne ako bezny mobil. Naozapak EF core pridava Sqlite vela featura vlastnosti, v cistom SQL som pri Sqlite vzdy bojoval s tym, ze vsteko je string.
-
Ja som pri EF core nikdy nemal problemy ani na razzberry pi Zero, co je ovela menej vykonne ako bezny mobil. Naozapak EF core pridava Sqlite vela featura vlastnosti, v cistom SQL som pri Sqlite vzdy bojoval s tym, ze vsteko je string.
No, jestli jsi bojoval s tím, že všechno je string, tak to by dost vysvětlovalo. Ono totiž není vše string, ale má to i další typy. Viz. https://www.sqlite.org/lang.html (https://www.sqlite.org/lang.html) a https://learn.microsoft.com/en-us/dotnet/api/microsoft.data.sqlite?view=msdata-sqlite-7.0.0 (https://learn.microsoft.com/en-us/dotnet/api/microsoft.data.sqlite?view=msdata-sqlite-7.0.0)
U EF-C pokud máš jednoduché struktury a malé množství dat, tak se to moc neprojeví, ale při složitějších strukturách je pak hodně znát úbytek výkonu na RPi2Z i "běžném" mobilu.
Dnes mi přijde velký trend nejen u pokusů o programátory, že na jednoduché banální věci tahají spoustu různých nepotřebných knihoven a frameworků, které zbytečně žerou paměť i výkon. Vím, výkonu je dost, ale proč s ním proboha mrhat?
-
Tak technicky ma Sqlite string, blob a integer (ktory je ale interne reprezentovany ako string), protom aj tie operacie tomu zodpovedaju. Ja som neskutocne bojoval pri ADO.NET s datumami a casmi. A prave tieto veci ma EF vyriesnne.
U EF-C pokud máš jednoduché struktury a malé množství dat, tak se to moc neprojeví, ale při složitějších strukturách je pak hodně znát úbytek výkonu na RPi2Z i "běžném" mobilu.
Od .Net 6 s tym zat kay rozdiel nie je, a uz vobec nie po "dotnet ef optimise". Navyse v mobilnej aplikacii sai nebude ukladat zlozitu datovu strukturu, ktora +100 tabuliek.
Dnes mi přijde velký trend nejen u pokusů o programátory, že na jednoduché banální věci tahají spoustu různých nepotřebných knihoven a frameworků, které zbytečně žerou paměť i výkon. Vím, výkonu je dost, ale proč s ním proboha mrhat?
V tomto uplne suhlasim, dokonca mam rad SQL-ko a rad ho pisem, rad pisem vykone aplikacie.
No myslim, ze v pripade ukazkovej aplikacie na pohovor je to asi fuk (pokial nechve preukazat pokrocilu znalost SQL).
-
mobilne apky, to je cesta do pekla. Musim tam brat do uvahy milion veci, ako napr. rozne velkosti displeja, rozne verzie android, ci ho ma vertikalne, alebo horizontalne...
Preto robim backend :)
ak chces offline apku, tak js urcite nie, bud .net, ale ta apka bude mat 20-30MB, alebo nastrojom priamo na to urcenym - java a android studio.
Synchronizacia so servrom - pozor na to, ze to musi byt sifrovane.
ja mam par mobilnych app v .net, ale to su skor len take cisto pre moje domace pouzitie, takze tam nejak neriesim bezpecnost a velkost.
Co sa tyka miesania jazykov, bezne sa to robi, ale rozdelene na logicke casti. Napr. front-end je web (js+php), servisna je .net, ktora moze komunikovat s mikroservismi napisanymi napr. v pythone, databaza...
Asi máš zlú skúsenosť s veľkosťou u JS díky Electron aplikáciám... ale tomu tak fakt nie je, a i v JS je možné vytvoriť veľmi drobné a kvalitné aplikácie. Sú tu lepšie toolkity, ako Tauri (https://tauri.app/), NativeScript (https://nativescript.org/), či NeutralinoJS (https://neutralino.js.org/)... inak vieš o tom že existuje aj experimentálny kompilér z JS do machine kódu, bez VM, GC, a podobne? Vyložene to vygeneruje pár kB executable.
U vývoja mobilných app by som šiel cestou NativeScriptu s VueJS (https://vue-native.io/) alebo Svelte (https://svelte-native.technology/) úplne v pohode.
Prípadne môže ísť cestou Ionicu, ale to už bude aplikácia väčšia. VueJS in Ionic (https://ionicframework.com/docs/vue/overview)
-
U vývoja mobilných app by som šiel cestou NativeScriptu s VueJS (https://vue-native.io/) alebo Svelte (https://svelte-native.technology/) úplne v pohode.
Prípadne môže ísť cestou Ionicu, ale to už bude aplikácia väčšia. VueJS in Ionic (https://ionicframework.com/docs/vue/overview)
Aneb když znám jenom kladivo, všechno vypadá jako hřebík...
Proč by proboha začátečník měl psát mobilní aplikaci v Javascriptu? To si jenom přidá jednu komplikační vrstvu navíc a nijak si nepomůže (nesnaž se prosím argumentovat tím, že je to "jednodušší" nebo tak něco - je to jednoduchý pro tebe, protože to znáš, ale pro začátečníka fakt ne)
-
mobilne apky, to je cesta do pekla. Musim tam brat do uvahy milion veci, ako napr. rozne velkosti displeja, rozne verzie android, ci ho ma vertikalne, alebo horizontalne...
Preto robim backend :)
ak chces offline apku, tak js urcite nie, bud .net, ale ta apka bude mat 20-30MB, alebo nastrojom priamo na to urcenym - java a android studio.
Synchronizacia so servrom - pozor na to, ze to musi byt sifrovane.
ja mam par mobilnych app v .net, ale to su skor len take cisto pre moje domace pouzitie, takze tam nejak neriesim bezpecnost a velkost.
Co sa tyka miesania jazykov, bezne sa to robi, ale rozdelene na logicke casti. Napr. front-end je web (js+php), servisna je .net, ktora moze komunikovat s mikroservismi napisanymi napr. v pythone, databaza...
Asi máš zlú skúsenosť s veľkosťou u JS díky Electron aplikáciám... ale tomu tak fakt nie je, a i v JS je možné vytvoriť veľmi drobné a kvalitné aplikácie. Sú tu lepšie toolkity, ako Tauri (https://tauri.app/), NativeScript (https://nativescript.org/), či NeutralinoJS (https://neutralino.js.org/)... inak vieš o tom že existuje aj experimentálny kompilér z JS do machine kódu, bez VM, GC, a podobne? Vyložene to vygeneruje pár kB executable.
U vývoja mobilných app by som šiel cestou NativeScriptu s VueJS (https://vue-native.io/) alebo Svelte (https://svelte-native.technology/) úplne v pohode.
Prípadne môže ísť cestou Ionicu, ale to už bude aplikácia väčšia. VueJS in Ionic (https://ionicframework.com/docs/vue/overview)
pre boha ziadne javascriptove sprostosti na mobilnu aplikaciu. TO ze nejaka experimentalna sprostost dokaze vygenerovat par kB executable? Pre aku aplikaciu? Pre nejaku blbost co nacita z textaku par riadkov a zapise ich naspat a ma doslova 100 riadkov maximalne? Realne aplikacie maju tisice az desattisice riadkov kodu (a to ako minimum) a x zavislosti na inych knizniciach (dalsie desiatky tisic riadkov kodu, uz zkompilovanych) aby sme nemuseli ako programatory do umoru pisat to iste znovu a znovu. Potom chcem vydiet ako to vygeneruje par kilobajtov.
Velkost execka je nepodstatna, to ci ma aplikacia na nejakom google alebo apple store 50 alebo 150MB dnes nehra rolu. Pri dnesnych rychlostiach internetu (a obrovskych datovych tarifoch) a vykonnosti zariadeni to je doslova nedpostatny rozdiel.
Co je ale dolezite je mat podporu technologiu. Tie experimentalne javascriptove kniznice su casto krat udrziavane par ludmi a ich zivostnost sa dokaze zo dna na den ukoncit. Ked chce niekto pisat aplikaciu na mobil, tak v pripade androidu je to bud Java, Kotlin alebo MAUI (Xamarin uz nepouzivajte, microsoft ho pomaly ale isto prestava podporovat, ak uz aj dokonca neukoncil podporu, nie som si isty). Ako to je v pripade applu neviem povedat co tam je pouzivane.
Suhlasim so snugarom, to ze mas mlocik rad javascript neznamena ze ho musis nanutit kazdemu aj do situacii kam absolutne nepatri. To je ako keby som kazdemu povedal ze najlepsie rodinne auto je Tatra 813, pretoze mam na nu uchylku.
-
Psaní mobilních aplikací není ani tak o jazycích ale o systémových frameworcích daných platforem.
Nejlíp uděláš když je napíšeš v nativně podporovaném prostředí: Android Studio (Kotlin) pro Android a Xcode (Swift) pro iOS. Na vývoj iOS aplikace potřebuješ Mac, jestli ho nemáš tak začnu Androidem.
S MAUI zkušenost nemám, ale Xamarin je zastaralý už nepodporovaný moloch.
-
Děkuji všem za rady, i dohady mezi vámi mi moc pomohly :D Překvapil mě náhled na javascript pro mobilní aplikace, čekala jsem že je preferovanější před MAUI, ale zřejmě jsem se mýlila. Upotřebím co jsem se v diskuzi dozvěděla :)
-
Preferovanejsi je pre ludi, ktori nic ine nevedia.
-
Děkuji všem za rady, i dohady mezi vámi mi moc pomohly :D Překvapil mě náhled na javascript pro mobilní aplikace, čekala jsem že je preferovanější před MAUI, ale zřejmě jsem se mýlila. Upotřebím co jsem se v diskuzi dozvěděla :)
Javascript je zvláštní věc.
Jsou lidi, kteří ho použijou jenom tam, kde musí (což jsou prohlížeče, tam zatím jiná možnost v podstatě není), a na zbytek věcí použijou vhodný jazyk.
A pak jsou lidi, kteří ho chtějí použít úplně všude, i tam, kde se to vůbec nehodí. A tihle lidi jsou poměrně aktivní a někteří z nich i relativně schopní, takže vznikly věci jako node.js (javascript pro backend servery), electron (javascript pro "desktopové aplikace"), mločíkův svelte native (javascript pro mobilní aplikace) a tak dál. Dneska jde v javascriptu psát už v podstatě všechno. Problém je, že je to pořád javascript a psát v něm je utrpení.
-
Problém je, že je to pořád javascript a psát v něm je utrpení.
prosím o rozvedení :)
-
Jsou lidi, kteří ho použijou jenom tam, kde musí (což jsou prohlížeče, tam zatím jiná možnost v podstatě není), a na zbytek věcí použijou vhodný jazyk.
Problem dnesnej doby. Naucim sa jeden jazyk a ten pouzivam vsade, aj tam, kde sa to velmi nehodi. Ale ved staci vykonnejsi hw a bude to ok.
Ja mam par jazykov, ktore mi stacia takmer na vsetko, co robim. C#, JS, PHP, Python. a db mysql a mssql.
-
Děkuji všem za rady, i dohady mezi vámi mi moc pomohly :D Překvapil mě náhled na javascript pro mobilní aplikace, čekala jsem že je preferovanější před MAUI, ale zřejmě jsem se mýlila. Upotřebím co jsem se v diskuzi dozvěděla :)
Javascript je zvláštní věc.
Jsou lidi, kteří ho použijou jenom tam, kde musí (což jsou prohlížeče, tam zatím jiná možnost v podstatě není), a na zbytek věcí použijou vhodný jazyk.
A pak jsou lidi, kteří ho chtějí použít úplně všude, i tam, kde se to vůbec nehodí. A tihle lidi jsou poměrně aktivní a někteří z nich i relativně schopní, takže vznikly věci jako node.js (javascript pro backend servery), electron (javascript pro "desktopové aplikace"), mločíkův svelte native (javascript pro mobilní aplikace) a tak dál. Dneska jde v javascriptu psát už v podstatě všechno. Problém je, že je to pořád javascript a psát v něm je utrpení.
Javascript se uz davno pouziva jenom jako bytecode, pricetny clovek pise v Typescriptu.
A typescript je velice vyspely jazyk, plne srovnatelny s Javou nebo Kotlinem.
Javascript mobilni apliace davaji hlavne smysl pro jednoduche udelatka, typu pozadovaneho TODO listu. Typicky to byva prebalena webova SPA aplikace. Pak mas dafacto stejny codebase na webu i na "nativni" appce. Vselisjake ty vernostni apliakce hypermarketu jsou delane takhle.
Ono u drtive vetsiny programu v mobilu vubec nesejde, jak je to rychle a kolik to zere pameti. Nejdulezitejsi parametr je udrzovatelnost a security - kterou resi upgrade Blink jadra v mobilu plus updaty JS frameworku typu VUE.
Zrovna tuto aplikaci bych delal javascriptem, pro data sahat klasickym RESTem (JS fetch) a lokalni data v lokalnim webovem storu.
-
A typescript je velice vyspely jazyk, plne srovnatelny s Javou nebo Kotlinem.
Ano javascript je tak vyspely jazyk, ze vsetci radsej pisu v typsecripte alebo niecom podobnom.
Ono zas na jednoduche aplikacie je to zas prilis owehead. A co sa tyka bezpenosti javascriptove kniznice nou nie su prave zname.
-
Prekvapuje me, ze tu nepadl Dart / Flutter. To je neco, co bych pouzil ja. Pobezi to na obou platformach a vzdy z toho muzes udelat i webovou ci desktopovou app. Tutorialu na ruzne TODO je spousta a pro zacatecnika, co se mota kolem OOP, to je docela ok volba.
Sqlite je fajn, ale rikala jsi neco o offline praci, nasledne synchronizaci. Neznam presny use case, ale teoreticky by te mohla zajimat CouchDb apod.
-
Javascript je zvláštní věc.
Jsou lidi, kteří ho použijou jenom tam, kde musí (což jsou prohlížeče, tam zatím jiná možnost v podstatě není), a na zbytek věcí použijou vhodný jazyk. [...] A pak jsou lidi, kteří ho chtějí použít úplně všude, i tam, kde se to vůbec nehodí. A tihle lidi jsou poměrně aktivní a někteří z nich i relativně schopní, takže vznikly věci jako node.js (javascript pro backend servery),
I mimo prohlížeče jsou případy užití, pro které je Node.js velmi výhodný. Ono to, že je event-based od začátku by design má něco do sebe. Pro něco. Spousta platforem (spíš většina) se kvůli tomu škrábe různými knihovnami levou rukou za pravým uchem. Na jiné věci se ale zase nehodí vůbec. Váš komentář je stejně nesmyslně černobílý jako tvrzení, že JavaScript je vhodný pouze pro prohlížeče. Uvažujete přesně stejně jako ti, co tak kritizujete.
electron (javascript pro "desktopové aplikace"),
Zkuste se zamyslet, proč se asi používá. Jakkoliv ho nijak zvlášť nehájím. Kvůli obsesi z JavaScriptu to skutečně není.
Problém je, že je to pořád javascript a psát v něm je utrpení.
Utrpení je řešit něco s lidmi, kteří něco neumí a místo toho, aby chápali, že to neumí, vypráví ostatním o tom, jak je to strašné.
-
Neporadím s moderními programovacími prostředími. Mám jenom pár keců v kleci:
Připomíná mi to dobu, kdy databázové aplikace bylo možno provozovat lokálně, s občasným přístupem na centrálu - na požádání se vytočil dial-up a synchronizovala se data tam a zpátky. Říkalo se těmto postupům tuším "disconnected operations" - pobočky měly značnou míru autonomie a data s centrálou si vyměňovaly "líně a pozvolna". Pobočka mívala v zásadě počítač nebo malý server a na něm svoji instanci dbms. (Asi nechci navrhovat, aby na telefonu běžela instance RDBMS :-)
Nápady z tohoto soudku (replikace a tak) tvořily taky část oboru zvaného "distribuované databáze".
Zkuste si schválně ty dva pojmy zagooglit, třeba se dočtete něco relevantního - jak postavit datový model, aby to celé samotížně zaklaplo dohromady apod. Odhadem máte výhodu, že Váš datový model je jednoduchý = nebude tam složitá referenční integrita, snad ani potenciál ke konfliktům mezi offline lokalitami apod.
Pokud něco googlem najdete, připravte se, že to bude značně řídké čtení. Spousta akademického textu a sem tam dobrý nápad.
Pokud Vaše zadání obsahuje možnost, že při nějakém plánování času apod. bude mezi účastníky docházet ke konfliktům, tak tam teprve začíná zajímavá činnost = jak řešit případné věcné konflikty. Jednak na úrovni uložení dat, druhak nad tím na úrovni aplikační logiky.