Vývoj programu
Dobrý den,
nedávno jsem přišel na zajímavou chybu v trhu, kde by se hodil program, který doposud ještě není. Dlouho jsem nad tím přemýšlel a různě promýšlel, jak bych ho udělal. Jsem sice v IT oboru, ale programováním zatím doposud nedotčený. Měl jsem C# na střední, ale jen chvíli a špatného učitele, takže jako kdybych nic neměl. Pohybuji se spíš v oblasti SAPu a integrací.
Každopádně, rád bych se hecnul a začal se učit nějaký jazyk s tím, že bych měl jako cíl vytvořit ten mnou vymyšlený program. Potřebuji ale pomoct při začátku. Možná je toto špatný dotaz, ale rád bych se Vás zeptal, v jakém jazyce začít ? V jakém jazyce pak budu schopný napsat ten program ? C# ?
Vím že to nebude vůbec nic lehkého a nepočítám s tím, že do toho skočím a hned začnu dělat vlastní program. Samozřejmě do toho jdu s tím, že se to budu dlouho dobu učit. DĚKUJI ZA RADU :)
A co to bude za aplikaci? Desktopová, mobilní, webová? Pokud desktopová či mobilní, jakou platformu, či jaké platformy budeš podporovat? Na tom výběr jazyka dost záleží.
Díky za odpověď :) Měla by to být desktopová aplikace (windows), do budoucna zvažuji i nějakou lehčí mobilní verzi přímo pro uživatele, né pro firmu. Abych popsal přesněji a v nějaké příkladu tu appku-
(Bude mít dva vstupy, řekněme že je xxx druhů palet a např. 6 druhů kontejneru. Do appky člověk zadá jaké má všechny palety tzn. přesně nějaké druhy.. a appka už si podle druhu vytáhne z databáze palet její rozměry a váhu. Poté zadá jaký má kontejner, zase se vytáhne z databáze rozměry přimo toho kontejneru. A potém mu appka řekne jako výstup jestli se tam všechny palety co zadal vejdou, či ne a jestli to nepřesáhne povolenou hmotnost. V další fázi bych chtěl, aby appka řekla, jak přesně má palety poskládat tak, aby se to tam vešlo.
Ještě jednou díky za rady :)
Začni aplikací pro PC a tam klidně použij C#, který asi trochu znáš a budeš se v tom orientovat.
MS ale nemá multiplatformní jazyk, který by z jednoho kódu zkompiloval aplikaci pro Desktop i mobil.
Na druhou stranu budeš mít všechny algoritmy i práci s DB vyřešenou, takže pro mobil to pak přepíšeš do něčeho pro mobil. Tam pak musíš řešit i rozložení formulářů pro různá zobrazení (na výšku, na šířku), pro tablet...
Lazarus je multiplatformní, ale není to od MS. To snad není vada.
To stejné může použít Delphi community edition - multiplatformní a taky zdarma.
Ale on zná C# a potřebuje si ujasnit, co vlastně chce. Tak ať to klidně napíše v C#. Pokud se to chytí na Windows (a jestli to dotáhne do konce), pak může přemýšlet o dalších platformách.
C# je už pár rokov tak multiplatformný, že už viac sa asi ani nedá. Vieš v ňom robiť aplikácie pre desktop, pre web, pre mobily, prakticky všade. Každopádne ale riešiť multiplatformnosť, keď je platforma jasne daná, asi nemá veľký zmysel.
Takže napíšu program, upravim rozložení formuláře pro ruzna rozlišení a jen řeknu "zkompiluj mi to pro desktop" nebo "pro Android" a z jednoho zdroje mam exe nebo apk?
https://dotnet.microsoft.com/apps/xamarin/cross-platform
Když se tak koukám, tak to není úplně vizuální návrh formuláře, ale musím ručně editovat layout v XAML.
Myslel jsem standardní C# aplikaci, včetně design time návrhu formulářů, eventů atd. - třeba i pomocí nějaké vizuální multiplatformní knihovny
To pak vezmu a zkompiluju pro Windows, Android nebo MAC.
Takto to funguje?
To jde o to, čemu říkáš standardní C# aplikace. Návrh GUI pomocí XAML je v .netu standard už nějakých 10 možná 15 let.
WindowsForms, na které asi narážíš, je sice stále podporována varianta, ale už je trochu "legacy".
C# jsem teď dlouho nesledoval. Takže prostě s nějakou vizuální knihovnou navrhnu UI (formuláře) bez psaní kódu - nahážu controls na form a ten samý formulář pak můžu to použít jak pro Windows, tak i pro Android nebo MAC?
Tak to pokud vím není. XAML má sice (minimálně ve WPF) nějaký vizuální návrh, ale co jsem pozoroval, tak ho stejně většina lidí nepoužívá a píše rovnou XAML. Web se taky obvykle píše přímo v HTML i když existují nějaké vizuální nástroje.
Takže formy pro Windows, včetně obsluhy událostí atd. dělám zvlášť (vizuálně) formy pro android, včetně napojovani událostí píšu ručně, protože je to lepší. Pochopil jsem to správně?
Použiju jen aplikační kód, který je společný a vizuální část tvořím nezavisle pro kazdou platformu.
No pokud použiješ ty Xamarin.Forms tak je ani nezávisle tvořit nemusíš. Můžeš najednou vytvářet aplikaci schopnou běžet na Androidu, iOSu i Windows 10.
Ale formy musím psát ručně, protože je to lepší, než je tvořit vizuálně.
U komplikovanějšího UI se to pak docela blbě udržuje. Dělat změny UI ve stovky řádek velkém XML zdrojáku není nic pohodlného.
Robiť UI v textovom jazyku je dnes už de facto štandard, viď XAML alebo aj HTML. Robiť zmeny v takom UI nie je nič, čo by malo niekoho od toho odradiť. Ja si naopak neviem predstaviť robiť takéto veci vizuálne, kde sa musím myškou triafať na presné miesto, ale asi to je vec zvyku.
Každopádne, začiatočníkovi by som určite neodporúčal, aby začínal tvorením multiplatformných GUI aplikácií.
Počkej, ty mluvíš o HTML stránce, kde je GUI poměrně jednoduché - žádné složité vrstvení komponent na sebe, dockování atd.
Ony ani ty mobilní aplikace nemají složité UI, protože tam často řešíš různé formáty displeje a potřebuješ, aby se ti tam vše vešlo.
Když si vezmu zdroj definice složitějšího formuláře, tak se dostávám na tisíce řádků - a to je jen opravdu rozložení komponent a nastavení jejich vlastností bez vlastního kódu. Tohle si zase já nedovedu představit - vrátit se 15 let zpět zpět a psát to všechno ručně.
Ale to bude tím, že každý z nás dělá jiný typ aplikací.
Tisíc riadkov len na rozloženie komponentov? To by muselo byť niečo veľmi zle, aby niekto taký formulár napísal. Textový formát má oproti vizuálnemu svoje výhody, ale to už je mimo túto diskusiu.
Proč myslíš "velmi zlé"?
Někdy je výhodnější mít na formuláři page control, uživatel si přepíná pohledy a dotahují se mu data k dokladu než pro každý pohled otevírat nový formulář (v HTML novou stránku) a pak to zase zavírat a vracet se. Šlo by to řešit 20 malými formuláři a 20 tlačítky, které je budou volat, ale na úkor uživatelského komfortu.
Já samozřejmě můžu pracovat v textové formě, pokud potřebuju něco hromadně změnit na všech, tak klidně přes hledat/nahradit, ale mám i možnost to dělat vizuálně. Když dostaneš formulář, který jsi nedělal a chceš najít událost nějakého prvku, tak to určitě budu mít nalezené dřív.
Je to tím, že každý děláme odlišný typ aplikací.
V ERP potřebuje uživatel rychle pořídit doklad, často i bez koukání na obrazovku, nemůže pro každou kravinu klikat na tlačítka, otevírat a zavírat nové a nové formuláře a čekat na ně. Na webu s tím počítáš - klikneš a víš, že může trvat, než se načte další stránka, počítáš s tím, že na všechno potřebuješ myš. Na mobilu zase klikáš prstem, kam potřebuješ. To se vše přenáší v poslední době na desktop, takže roste generace klikačů, kteří místo stisknutí Enter chytnou myš a kliknou na tlačítko.
Pretože toto všetko vieš rozdeliť na menšie komponenty. To, že je niečo samostatný komponent, neznamená, že sa to musí otvárať v novom okne. Z pohľadu toho, čo vieš dosiahnuť jedným alebo druhým spôsobom, sú obidva spôsoby ekvivalentné - určite tam nie je nič na úkor používateľského komfortu.
V čom je ale podstatný rozdiel, je vygenerovaný kód pri vizuálnom editovaní. Z vygenerovaného kódu netušíš, ako formulár vyzerá, takže vizuálny editor je nutnosť, nie pomôcka. Identifikátory vygenerovaných prvkov sú nič nehovoriace textbox1, textbox2, a tak ďalej. Udalosti sú potom neraz pomenované ako button1_Click, button2_Click, a tak ďalej - to prehľadnosti neprispieva. Ak tam máš nebodaj vnorené panely s takými názvami že panel1, panel2, panel3, tak veľa zábavy pri vizuálnom editovaní, ale tej si užiješ aj pri normálnejšie pomenovaných paneloch. Alebo ďalšia vec, už len tým, že pridáš nové tlačidlo doprostred nejakého formulára, úplne rozbiješ navigáciu pomocou Tab klávesy a musíš to znova ponastavovať, ak si vôbec všimneš, že si niečo rozbil. A na záver úplná čerešnička, stráviš kopec času upravovaním formulára a zrazu zistíš, že kolega medzitým posunul niektoré prvky o pár pixelov vedľa, takže môžeš robiť všetko znova, lebo merge z toho spravíš ťažko.
Možno sa niektoré veci z toho, čo som napísal, za posledných 15 rokov zmenili, ale veľmi silno pochybujem, pretože to nemá normálne riešenie. Rád sa ale nechám vyviesť z omylu.
To, že to někdo nechá pojmenované vygenerovanými jmény je stejná čuňárna, jako bys to takto psal ručně v návrhu. Ty to neuděláš a já taky ne.
Pokud ty jsi schopný z napsaného kódu vidět, jak formulář vypadá, tak já taky - potřebuješ na to hodně představivosti. Já to řešit nepotřebuju, protože se mezi popisem a vizuální formou jednoduše přepnu.
Rozdělit to na menší komponenty myslíš, že třeba oddělíš panel a prvky na něm do zvláštního souboru? To pak máš formulář, který se skládá z 20 souborů a pokud se chceš dopracovat ke změně nějakého prvku, pak musíš prolézt několik souborů. V tom nevidím velkou výhodu. Já tohle můžu udělat taky. Máme své komponenty/bloky komponent včetně funkčnosti, které jen položíš na formulář a máš zajištěnu kompletní funkčnost (vizuální stránku, zapouzdření objektem, kód, práci s DB). Tohle ale nemá smysl dělat se vším jen proto, abych neměl velký soubor s popisem formuláře, ale v případě, kdy chci mít funkční blok, který upravuji a udržuji na jednom místě.
A ano, za 15 let se toho hodně změnilo. Pokud jsi se pohyboval v MS světě, tak tam první pořádné IDE a vizuální návrh formulářů dělali lidi od Borlandu, které MS přetáhnul.
Nechme to, až se uvidíme, pak si to můžeme ukázat na nějakém příkladu v reálu a můžeme se rovnou pohádat
Ja viem, že vygenerované názvy sa majú vždy nastaviť, ale k tomu ťa ten vizuálny editor nevedie, je to jeho vlastnosť a zároveň chyba. Každý, kto s vizuálnym editorom začne, sa k disciplíne s pomenovaním dopracuje až postupne (niekto nikdy), takže to považujem za problém vizuálneho editovania, ktorý v textovom formáte jednoducho neexistuje. Čo sa týka textového formátu, tak predstavivosť nie je ani potrebná, vizuálny náhľad sa dokáže zobrazovať počas písania.
Delenie na komponenty je základný princíp každého dobrého GUI frameworku, takže neverím, že v tom nevidíš veľkú výhodu, ale to je jedno, lebo toto majú spoločné obidva prístupy. Ale zaujímalo by ma, ktorá z tých zopár základných problémových vecí sa za tých 15 rokov zmenila k lepšiemu, asi žiadna. A to som ani nezašiel do väčších problémov, ktoré nastanú vtedy, keď si chceš vyrobiť nejaký trochu serióznejší komponent sám.