Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: r233 17. 09. 2016, 08:52:09
-
Lze vyvíje plnohodnotný sw pro Android bez použití javy? S GUI a využitím API systému?
Díky
-
Lze vyvíje plnohodnotný sw pro Android bez použití javy? S GUI a využitím API systému?
Díky
Ano lze
-
Ano dá, ale prakticky to nemá smysl, viz porovnání rychlosti s Javou.
-
Lze vyvíje plnohodnotný sw pro Android bez použití javy? S GUI a využitím API systému?
Díky
Ano lze
Můžeš hodit, pls, nějaký odkaz. Taky by mně to zajímalo.
THX
-
Ivan Nový: V C mám napsáno spoustu věcí, umím umím s ním řekl bych až excelentně. Javu nemám rád, a vůbec nestojím o to se jí zabývat. Navíc většina toho, co dělám se týká DSP, mimo jiné mám zkušenosti s ne10 knihovnou, která by měla být na Androidu taky nasaditelná.
-
Ivan Nový: V C mám napsáno spoustu věcí, umím umím s ním řekl bych až excelentně. Javu nemám rád, a vůbec nestojím o to se jí zabývat. Navíc většina toho, co dělám se týká DSP, mimo jiné mám zkušenosti s ne10 knihovnou, která by měla být na Androidu taky nasaditelná.
pro tyto ucely se hodi Android NDK
https://developer.android.com/ndk/index.html
-
Lze vyvíje plnohodnotný sw pro Android bez použití javy? S GUI a využitím API systému?
Díky
Ano lze
Můžeš hodit, pls, nějaký odkaz. Taky by mně to zajímalo.
THX
Tak jak uz jsem psal tak Android NDK nebo nad tim postavenoe qt pro android
http://doc.qt.io/qt-5/androidgs.html
-
Super, díky! O tom, že se vrhnu na Qt uvažuju už dlouho, tohle bude další motivace.
-
Heh, a je ti doufam jasne, ze pasnim nativniho kodu se locknes na procesorovou architekturu?
Nebo ze budes muset jak debil udrzovat verze pro ARM, MIPS, x86? A ze i na tom ARMu bud pojedes na nejake urovni Armv7, nebo budes muset udrzovat i verze pro novejsi ARMy, laternativne nevyuzijes nove featury novych procesoru?
Psat pro Android nativne mi prijde jako velika blbost. Vubec nevyuzivas jeho vyhody a delas z neho zastaraly crap typu IOS.
-
Heh, a je ti doufam jasne, ze pasnim nativniho kodu se locknes na procesorovou architekturu?
Nebo ze budes muset jak debil udrzovat verze pro ARM, MIPS, x86? A ze i na tom ARMu bud pojedes na nejake urovni Armv7, nebo budes muset udrzovat i verze pro novejsi ARMy, laternativne nevyuzijes nove featury novych procesoru?
Psat pro Android nativne mi prijde jako velika blbost. Vubec nevyuzivas jeho vyhody a delas z neho zastaraly crap typu IOS.
blbost
-
Není GUI Androidu psané v Javě ? Aspoň mám takový pocit, že pro GUI na Androidu je Java stejné nutné zlo jako Objective C (nebo dnes Swift) na Mac OS X.
-
Není GUI Androidu psané v Javě ? Aspoň mám takový pocit, že pro GUI na Androidu je Java stejné nutné zlo jako Objective C (nebo dnes Swift) na Mac OS X.
Žádný jazyk není zlo, zlo činí jeho uživatelé :-)))
-
Není GUI Androidu psané v Javě ? Aspoň mám takový pocit, že pro GUI na Androidu je Java stejné nutné zlo jako Objective C (nebo dnes Swift) na Mac OS X.
Tak napriklad prave to Qt pro android neni v jave a je to GUI ;), takze ne neni to nutnost
-
Není GUI Androidu psané v Javě ? Aspoň mám takový pocit, že pro GUI na Androidu je Java stejné nutné zlo jako Objective C (nebo dnes Swift) na Mac OS X.
Žádný jazyk není zlo, zlo činí jeho uživatelé :-)))
A ty činíš zlo z těhle diskusí. Běž už s těma pseudointelektuálskýma moudrostma do míst, kde se záda dělí vejpůl.
-
Youda: Upřímně, je mi jedno, že to bude jen na některé procesory.
Aplikace budou primárně pro moje použití, případně zájemce, kteří si ten telefon koupí, pokud tu apky budou chtít použít.
už jenom tím, že se využije ta ne10 knihovna to principiálně omezuje.
Navíc užit se Javu je pro mě naprosto neperspektivní, kdežto Qt využiji i jinak.
-
To je jasný. Kdo by chtěl pořádný peníze, když může dělat C++ za pár šlupek :D
-
s javou by som neopovrhoval, pokial si tak schopny C expert , prepisat / prelozit C kod do Javy mi pride ako vec na par hodin.
eventualne to narvat vsetko do jednej triedy a namiesto goto metody bez argumentov a vsetky premenne public static.
vybavene
-
lopata2: Proč bych to dělal? Učit se Qt pro mě má smysl, Javu ne.
Pokud nějaká moje aplikace vznikne, a pokud by i byla zveřejněna, bude to tak specifická věc, že ji využijí max. jednotky lidí. Nejde mi o to psát nějakou masovku, ale napsat si utilitu, tool a pod. která mě, nebo zákazníkovi nějak pomůže.
-
lopata2: Proč bych to dělal? Učit se Qt pro mě má smysl, Javu ne.
Pokud nějaká moje aplikace vznikne, a pokud by i byla zveřejněna, bude to tak specifická věc, že ji využijí max. jednotky lidí. Nejde mi o to psát nějakou masovku, ale napsat si utilitu, tool a pod. která mě, nebo zákazníkovi nějak pomůže.
Lopata2 je troll. V jave sa tak neprogramuje, ako opisal. To mal byt akoze "vtipny" prispevok zosmiesnujuci javistov. Mala by byt na roote, po odpovedani prispevku moznost diskusiu locknut zakladatelom, inac sa tu len pisu kktinty,
-
troll? a ako si myslis ze v jave vznikli kniznice ako BLAS LAPACK. napoviem prelozili to z fortranu. ty co to robili tiez nezaujima nejake design patterny a chujoviny, proste co funkcia to metoda a navalili tam tie for cykly. a hotovo.
to iste OP. ked ma vyvynute nejake hotove C kody tak to nebude valit do javy ak sa tomu da vyhnut.
obzvlast ak tam ma vela datovych struktur tak nebude robit co ****** to trieda. potom mu to pre**be na androide limit 64K tried alebo 64K metod a bude muset pouzit multidex alebo mu to nepojde na starych telefonoch.
-
Není GUI Androidu psané v Javě ? Aspoň mám takový pocit, že pro GUI na Androidu je Java stejné nutné zlo jako Objective C (nebo dnes Swift) na Mac OS X.
Žádný jazyk není zlo, zlo činí jeho uživatelé :-)))
Visual Basic!
-
troll? a ako si myslis ze v jave vznikli kniznice ako BLAS LAPACK. napoviem prelozili to z fortranu. ty co to robili tiez nezaujima nejake design patterny a chujoviny, proste co funkcia to metoda a navalili tam tie for cykly. a hotovo.
to iste OP. ked ma vyvynute nejake hotove C kody tak to nebude valit do javy ak sa tomu da vyhnut.
obzvlast ak tam ma vela datovych struktur tak nebude robit co ****** to trieda. potom mu to pre**be na androide limit 64K tried alebo 64K metod a bude muset pouzit multidex alebo mu to nepojde na starych telefonoch.
Je to hnus, velebnosti. Mam s podobnym docinenia, kodili to nejaki sietari a mam si pri debugovani chut vypichnut oci dratom.
-
s javou by som neopovrhoval, pokial si tak schopny C expert , prepisat / prelozit C kod do Javy mi pride ako vec na par hodin.
to snad nemyslíš vážně, je sice pravda že má C a java "podobnou" syntaxy, ale pro efektivní využití každého jazyka je třeba úplně jiný způsob myšlení, Já když píšu v C a píšu toho v C opravdu hodně, poslední dobou nečekaně i pro databázové aplikace, tak mám při psaní neustále v mysli obraz konkrétní vnitřní reprezentace dat se kterými pracuji, bez toho nemá smysl v C vůbec psát, často se ti podaří využít jedno vykonání jedné operace k více účelům součastně a z kontextu víš kde má a kde nemá cenu dělat kontroly, například zda nelezeš z pole, což ti kód v javě v konečném důsledku dělá furt, zatím co Java je ideální pro abstraktní přístup a línější programování ;-)
Jsem ochotný připtustit že průměrný programátor v Javě, napíše stejně efektivní kód jako průměrný programátor v C, kazdý z těch programů bude fungobat úplně jinak i přesto, že budou dělat totéž a stejně efektivně. Ale trvám na tom, že dobrý programátor v C napíše řádově efektivnější kód než ten nejlepší programágor v Javě, a pokud vše správně pokryje testama a nebude mu nějaký manager optimalizovat dojivost tak bude ten výsledek v C i daleko spolehlivjejší, třeba už jen proto že bude závislý na méně subdodavatelých :-) i když zrovna v případě Androidu je tento argument směšný :-)
IMHO ta komerční "porovnání" mi připadají určena pro NEprogramující managment :-)
A přenos mezi procesory, se stejnou šíří zběrnice s ideální efekivitou, ti na úrovni zdrojů, zajistí správné nastavení překladače.
Dalo by se říct že Java je výborná k tomu, aby produkty neschopných programátorů byli použitelné ;-) Nejvíc mě baví sledovat jak všude cpou ORM a pak se diví jak je databáze pomalá :-D
-
Není GUI Androidu psané v Javě ? Aspoň mám takový pocit, že pro GUI na Androidu je Java stejné nutné zlo jako Objective C (nebo dnes Swift) na Mac OS X.
Žádný jazyk není zlo, zlo činí jeho uživatelé :-)))
Visual Basic!
Visual Basic neni zlo, plati to co psal kolega predemnou, zlo jsou ti co v nem programuji :)
-
Není GUI Androidu psané v Javě ? Aspoň mám takový pocit, že pro GUI na Androidu je Java stejné nutné zlo jako Objective C (nebo dnes Swift) na Mac OS X.
Žádný jazyk není zlo, zlo činí jeho uživatelé :-)))
Visual Basic!
Visual Basic neni zlo, plati to co psal kolega predemnou, zlo jsou ti co v nem programuji :)
+1
-
Dalo by se říct že Java je výborná k tomu, aby produkty neschopných programátorů byli použitelné ;-) Nejvíc mě baví sledovat jak všude cpou ORM a pak se diví jak je databáze pomalá :-D
ORM tam cpu architekti. K ostatnemu sa nevyjadrujem, je to obycajny C/C++ rant cloveka, co nevie ani o com hovori. Len by som sa zbytocne jedoval.
-
to snad nemyslíš vážně, je sice pravda že má C a java "podobnou" syntaxy, ale pro efektivní využití každého jazyka je třeba úplně jiný způsob myšlení, Já když píšu v C a píšu toho v C opravdu hodně, poslední dobou nečekaně i pro databázové aplikace, tak mám při psaní neustále v mysli obraz konkrétní vnitřní reprezentace dat se kterými pracuji, bez toho nemá smysl v C vůbec psát, často se ti podaří využít jedno vykonání jedné operace k více účelům součastně a z kontextu víš kde má a kde nemá cenu dělat kontroly, například zda nelezeš z pole, což ti kód v javě v konečném důsledku dělá furt, zatím co Java je ideální pro abstraktní přístup a línější programování ;-)
Jsem ochotný připtustit že průměrný programátor v Javě, napíše stejně efektivní kód jako průměrný programátor v C, kazdý z těch programů bude fungobat úplně jinak i přesto, že budou dělat totéž a stejně efektivně. Ale trvám na tom, že dobrý programátor v C napíše řádově efektivnější kód než ten nejlepší programágor v Javě, a pokud vše správně pokryje testama a nebude mu nějaký manager optimalizovat dojivost tak bude ten výsledek v C i daleko spolehlivjejší, třeba už jen proto že bude závislý na méně subdodavatelých :-) i když zrovna v případě Androidu je tento argument směšný :-)
IMHO ta komerční "porovnání" mi připadají určena pro NEprogramující managment :-)
A přenos mezi procesory, se stejnou šíří zběrnice s ideální efekivitou, ti na úrovni zdrojů, zajistí správné nastavení překladače.
Dalo by se říct že Java je výborná k tomu, aby produkty neschopných programátorů byli použitelné ;-) Nejvíc mě baví sledovat jak všude cpou ORM a pak se diví jak je databáze pomalá :-D
To jsou komedialni kecy.
Psat DB aplikaci v C, to uz chce opravdoveho cloveka, co neni schopen se podivat po cemkoliv jinem...
V jave, ve Spring Boot ti napisu DB aplikaci s REST rozhranim za dopoledne, co si ani nestihnes rozplanovat praci v C... A samozrejme s vyuzitim ORM, konkretne ja pouzivam Hibernate s nativnimi SQL dotazy, na DB independence si nehraju. ORM znamena Object Relational Mapping - JSQL opravdu neni povinne. A odpadne ten nebetycny opruz pri praci s jednotlivymi columny resultsetu.
V hibernatu napisu nativni sql dotaz select id, name, surname from XXX where .... a vysledek je set naplnenych java beanu. A primo ten set se oanotuje @RestService a je to vystavene na rest api. Cela aplikace bez logiky zpracovani dat na baj voko 100 radek kodu - pokud staci default konfigurace spring boot a ta obvykle staci.
Primo v spring bootu zadratovany caching engine, pomoci ktereho se nacachuji casto pouzivane DB dotazy a selecty se znova neprovadeji - opet plne automaticke, staci zapnout podporu anotaci @Cacheable a casto pouzivane dotazy se vubec nebudou posilat do DB ale vysledek to vyplivne z cache.
A samozrejme DB konektivita pres connection pool, ktery reusuje connections a zabranuje pomalemu a drahemu navazovani spojeni - opet funguje out of box.
Na ten REST se posadi angular, pripadne se beany pouzijou jako backing beans pro primefaces a luxusni GUI je na svete.
V mavenu target na spring boot JAR, ktery je mozno spoustet z ruky (embedded Tomcat na RESTy included), pripadne jak lezi a bezi pouzit jako LSB compliant init.d service (podporuje star/stop/restart) nebo systemd servicu.
Nebo si nastavim target do WARu.
JUnit testy v zakladnim baliku, stejne tak Mockito testy.
Babrat se v databazich za pomoci C muze dneska jenom clovek, co nema tuseni o novych vecech.
Ve spring boot to same napises za zlomek casu a bude to robustnejsi, rychlejsi a spravovatelnejsi.
-
Multiplatformě jde programovat v JUCE - viz. www.juce.com (Komerční licence, ale není zadarmo)
-
to snad nemyslíš vážně, je sice pravda že má C a java "podobnou" syntaxy, ale pro efektivní využití každého jazyka je třeba úplně jiný způsob myšlení, Já když píšu v C a píšu toho v C opravdu hodně, poslední dobou nečekaně i pro databázové aplikace, tak mám při psaní neustále v mysli obraz konkrétní vnitřní reprezentace dat se kterými pracuji, bez toho nemá smysl v C vůbec psát, často se ti podaří využít jedno vykonání jedné operace k více účelům součastně a z kontextu víš kde má a kde nemá cenu dělat kontroly, například zda nelezeš z pole, což ti kód v javě v konečném důsledku dělá furt, zatím co Java je ideální pro abstraktní přístup a línější programování ;-)
Jsem ochotný připtustit že průměrný programátor v Javě, napíše stejně efektivní kód jako průměrný programátor v C, kazdý z těch programů bude fungobat úplně jinak i přesto, že budou dělat totéž a stejně efektivně. Ale trvám na tom, že dobrý programátor v C napíše řádově efektivnější kód než ten nejlepší programágor v Javě, a pokud vše správně pokryje testama a nebude mu nějaký manager optimalizovat dojivost tak bude ten výsledek v C i daleko spolehlivjejší, třeba už jen proto že bude závislý na méně subdodavatelých :-) i když zrovna v případě Androidu je tento argument směšný :-)
IMHO ta komerční "porovnání" mi připadají určena pro NEprogramující managment :-)
A přenos mezi procesory, se stejnou šíří zběrnice s ideální efekivitou, ti na úrovni zdrojů, zajistí správné nastavení překladače.
Dalo by se říct že Java je výborná k tomu, aby produkty neschopných programátorů byli použitelné ;-) Nejvíc mě baví sledovat jak všude cpou ORM a pak se diví jak je databáze pomalá :-D
To jsou komedialni kecy.
Psat DB aplikaci v C, to uz chce opravdoveho cloveka, co neni schopen se podivat po cemkoliv jinem...
V jave, ve Spring Boot ti napisu DB aplikaci s REST rozhranim za dopoledne, co si ani nestihnes rozplanovat praci v C... A samozrejme s vyuzitim ORM, konkretne ja pouzivam Hibernate s nativnimi SQL dotazy, na DB independence si nehraju. ORM znamena Object Relational Mapping - JSQL opravdu neni povinne. A odpadne ten nebetycny opruz pri praci s jednotlivymi columny resultsetu.
V hibernatu napisu nativni sql dotaz select id, name, surname from XXX where .... a vysledek je set naplnenych java beanu. A primo ten set se oanotuje @RestService a je to vystavene na rest api. Cela aplikace bez logiky zpracovani dat na baj voko 100 radek kodu - pokud staci default konfigurace spring boot a ta obvykle staci.
Primo v spring bootu zadratovany caching engine, pomoci ktereho se nacachuji casto pouzivane DB dotazy a selecty se znova neprovadeji - opet plne automaticke, staci zapnout podporu anotaci @Cacheable a casto pouzivane dotazy se vubec nebudou posilat do DB ale vysledek to vyplivne z cache.
A samozrejme DB konektivita pres connection pool, ktery reusuje connections a zabranuje pomalemu a drahemu navazovani spojeni - opet funguje out of box.
Na ten REST se posadi angular, pripadne se beany pouzijou jako backing beans pro primefaces a luxusni GUI je na svete.
V mavenu target na spring boot JAR, ktery je mozno spoustet z ruky (embedded Tomcat na RESTy included), pripadne jak lezi a bezi pouzit jako LSB compliant init.d service (podporuje star/stop/restart) nebo systemd servicu.
Nebo si nastavim target do WARu.
JUnit testy v zakladnim baliku, stejne tak Mockito testy.
Babrat se v databazich za pomoci C muze dneska jenom clovek, co nema tuseni o novych vecech.
Ve spring boot to same napises za zlomek casu a bude to robustnejsi, rychlejsi a spravovatelnejsi.
Kdyz potrebujes performance, tak je ti toto k nicemu. Vim o cem mluvim, v Jave programuju leta(i v C++).
Napises to radove rychleji, bude to robustnejsi, pro vetsinu prumernych programatoru i spravovatelnejsi, ale rychlejsi ne.
Samozrejme kdyz pise nekdo jak lempl, tak i to c++ je pomale. Ale dobry programator, ktery vi co dela bude mit vysledek uplne nekde jinde(i kdyz mu to bude trvat opravdu o dost dele, v tom je Java opravdu vyhodna).
-
Kdyz potrebujes performance, tak je ti toto k nicemu.
Rozhodně. A proto se nemá cenu tady hádat, když nikdo nezná celé zadání ani jedné ze stran. V první případě byla dost důležitější podmínka na rychlost výsledku (nebo to třeba bylo v embedded zařízení s omezenými zdroji), ve druhém případě rychlost vývoje (provoz na std. serveru s kupou paměti a jader). Není jedna pravda.
-
Použij Javu proboha, NDK se používá jen když de o každou kapku výkonu (některé hry obvykle), jinak nemá smysl.
-
s javou by som neopovrhoval, pokial si tak schopny C expert , prepisat / prelozit C kod do Javy mi pride ako vec na par hodin.
eventualne to narvat vsetko do jednej triedy a namiesto goto metody bez argumentov a vsetky premenne public static.
vybavene
To je přesně názor těch kteří neumí ani jedno pořádně, NELZE přepsat z C do Javy ani obráceně, pokud se má daný jazyk použít správně, tak se musí s každým pracovat jinak.
Java, manipuluješ s objekty, z C-pohledu s komplexními datovými struktůramy o kterých nesmíš mít ponětí o jejich vnitřní struktůře. To že k datům je přibaleny i kód, (metody tříd), to s tím právě souvisí.
C, manipuluješ se z Java-pohledu velice primitivními datovými strukturami, o jejichž vnitřní reprezentaci máš neustále povědomí.
Tento rozdíl implikuje návyky jak myslet při programování v daném jazyce. Tak že ten kdo je rozepsaný v C nikdy nemůže efektivně psát v javě a obráceně a ten kdo umí oboje, tak určitě neefektivně !
-
Java, manipuluješ s objekty, z C-pohledu s komplexními datovými struktůramy o kterých nesmíš mít ponětí o jejich vnitřní struktůře. To že k datům je přibaleny i kód, (metody tříd), to s tím právě souvisí.
C, manipuluješ se z Java-pohledu velice primitivními datovými strukturami, o jejichž vnitřní reprezentaci máš neustále povědomí.
Nejsem žádný specialista na Cčko, ale např. v kernelu se hojně používají structy s pointery na funkce. Blíží se to objektům. Konkrétně např. "interface" https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/pci/ice1712/ice1712.h#n362 či celý https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/pci/ice1712/ice1712.h#n297 , kde se defaultní implementace definuje v "předkovi" https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/pci/ice1712/ice1724.c#n2678 a konkrétně některé "metody" "přetěžují" v "potomkovi" https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/pci/ice1712/juli.c#n645 . IMO to má s objektovým programováním leccos společného.
-
Použij Javu proboha, NDK se používá jen když de o každou kapku výkonu (některé hry obvykle), jinak nemá smysl.
NDK se používá také pro aplikace, které mají být multiplatformní. Javu na iOSu či Windows Phone nespustíte. Existuje sice GCJ, ale je s ním výrazně víc práce, než s použitím NDK v Androidu.
To je přesně názor těch kteří neumí ani jedno pořádně, NELZE přepsat z C do Javy ani obráceně, pokud se má daný jazyk použít správně, tak se musí s každým pracovat jinak.
To záleží, jak v tom C píšeš. Z Javy do C to jde celkem snadno, třeba GTK funguje v podstatě stejně (ono tam není moc co vymýšlet). Z C do Javy záleží na způsobu psaní v C, třeba linuxové ovladače (ne celý kernel, ten používá hodně divoký kód, ale API pro ovladače) nebo ty aplikace pro GTK (pokud nedělají nějakou složitou ukazatelovou aritmetiku) by se daly přepsat docela snadno.
Java, manipuluješ s objekty, z C-pohledu s komplexními datovými struktůramy o kterých nesmíš mít ponětí o jejich vnitřní struktůře. To že k datům je přibaleny i kód, (metody tříd), to s tím právě souvisí.
Java má velmi jasnou specifikaci toho, jak uvnitř funguje, (https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html) a pokud pracuješ s JNI, tak pracuješ právě s tímhle formátem.
C, manipuluješ se z Java-pohledu velice primitivními datovými strukturami, o jejichž vnitřní reprezentaci máš neustále povědomí.
Obzvlášť když se často používají pointery na forward-declarované struktury jako třeba FILE či pthread_mutex_t :)
Tento rozdíl implikuje návyky jak myslet při programování v daném jazyce. Tak že ten kdo je rozepsaný v C nikdy nemůže efektivně psát v javě a obráceně a ten kdo umí oboje, tak určitě neefektivně !
To, že nedokážeš efektivně psát ve více jazycích ty, ještě neznamená, že by to nezvládl někdo jiný :D Programuju low- i high-level kód pro Android, takže denně dělám v Javě i C++, a nemám nějaké problémy psát v každém jinak. Občas mě štve, že některé skvělé vlastnosti z jednoho dost chybí ve druhém (hlavně anotační preprocersory a šablony), ale to je tak všechno. Mimochodem pokud člověk dělá hodně do hloubky s C++, tak se stejně musí naučit dobře programovat imperativně i funkcionálně (šablony jsou čistě funkcionální), což je mnohem větší rozdíl než mezi C a Javou.