Android studio, kuinka alkuun?

Niin, kyllähän javan pitää olla hanskassa ennen kuin tuohon ryhtyy. Classes, subclassing, threads, inheritance, interfaces, callback methods ovat käsitteitä, jotka tulevat tossa hommassa koko ajan eteen.

Mobiiliohjelmoinnissa on yleinen väärinkäsitys (firmoissa pomoportaasta lähtien), että koska kun laite ja ruutu on pieni, on ohjelmointikin helpompaa. Äkkiäkös siihen nyt kikkareen vääntää, hopi hopi, miksei ole jo valmista.

Sehän on oikeasti juurikin päinvastoin.

niin-on kirjoitti:

Niin, kyllähän javan pitää olla hanskassa ennen kuin tuohon ryhtyy. Classes, subclassing, threads, inheritance, interfaces, callback methods ovat käsitteitä, jotka tulevat tossa hommassa koko ajan eteen.

Mobiiliohjelmoinnissa on yleinen väärinkäsitys (firmoissa pomoportaasta lähtien), että koska kun laite ja ruutu on pieni, on ohjelmointikin helpompaa. Äkkiäkös siihen nyt kikkareen vääntää, hopi hopi, miksei ole jo valmista.

Sehän on oikeasti juurikin päinvastoin.

Lue lisää

Ei laitteen koko vaikuta ohjelmoinnin helppouteen. Ohjelman kompleksisuus mitä on tekemässä voi vaikuttaa.

Eli tuossa ei ole mitään mikä tekisi siitä vaikeampaa. Aika yksinkertaisesti sille Androidille saa niitä sovelluksia tehtyä.

M-Kar kirjoitti:

Ei laitteen koko vaikuta ohjelmoinnin helppouteen. Ohjelman kompleksisuus mitä on tekemässä voi vaikuttaa.

Eli tuossa ei ole mitään mikä tekisi siitä vaikeampaa. Aika yksinkertaisesti sille Androidille saa niitä sovelluksia tehtyä.

Lue lisää

Ei taida M-Kar olla koskaan ohjelmoinut Androidille. Framework on varsin monimutkainen ja siinä on monta sisäistettävää asiaa, mm. activity lifecycle, fragments, ja käyttöjärjestelmän asettamat rajoitukset sekä miten niitä voi kiertä androidin omilla metodeilla jne jne. guin rakentaminen vaatii kokonaisen frameworkin omaksumista, eikä se käy hetkessä. Swing-ohjelmoinnista ei ole tässä mitään hyötyä.

Itse koen Android-ohjelmoinnin kohtalaisen hankalana ja lisäksi se on varsin turhauttavaa, koska api vaihtelee versioista riippuen, eivätkä appcompatibility-kirjastot todellakaan ratkaise kaikkia ongelmia.

noo.noo kirjoitti:

Ei taida M-Kar olla koskaan ohjelmoinut Androidille. Framework on varsin monimutkainen ja siinä on monta sisäistettävää asiaa, mm. activity lifecycle, fragments, ja käyttöjärjestelmän asettamat rajoitukset sekä miten niitä voi kiertä androidin omilla metodeilla jne jne. guin rakentaminen vaatii kokonaisen frameworkin omaksumista, eikä se käy hetkessä. Swing-ohjelmoinnista ei ole tässä mitään hyötyä.

Itse koen Android-ohjelmoinnin kohtalaisen hankalana ja lisäksi se on varsin turhauttavaa, koska api vaihtelee versioista riippuen, eivätkä appcompatibility-kirjastot todellakaan ratkaise kaikkia ongelmia.

Lue lisää

"Ei taida M-Kar olla koskaan ohjelmoinut Androidille."

Olen tehnyt alustariippumatonta sovellusta mikä toimii myös Androidissa. En ole niin paljoa kiinnostunut Androidin natiivista kun standardi HTML5 toimii kerralla joka paikassa.

Androidille tehnyt natiivisti lähinnä pieniä kokeiluita.

"Framework on varsin monimutkainen"

Ei oikeastaan. Aika simppeli.

" ja käyttöjärjestelmän asettamat rajoitukset sekä miten niitä voi kiertä androidin omilla metodeilla"

Ei Android rajoita mitenkään käyttöliittymien tekemistä.

"guin rakentaminen vaatii kokonaisen frameworkin omaksumista, eikä se käy hetkessä."

Guin tekeminen vaatii käytännössä aina jonkin tekniikan omaksumista. Olkoot se sitten React, Vue, Android API, WinRT tai mitä nyt haluaakaan.

"Swing-ohjelmoinnista ei ole tässä mitään hyötyä."

Ei tietenkään. Legacyähän se.

M-Kar kirjoitti:

"Ei taida M-Kar olla koskaan ohjelmoinut Androidille."

Olen tehnyt alustariippumatonta sovellusta mikä toimii myös Androidissa. En ole niin paljoa kiinnostunut Androidin natiivista kun standardi HTML5 toimii kerralla joka paikassa.

Androidille tehnyt natiivisti lähinnä pieniä kokeiluita.

"Framework on varsin monimutkainen"

Ei oikeastaan. Aika simppeli.

" ja käyttöjärjestelmän asettamat rajoitukset sekä miten niitä voi kiertä androidin omilla metodeilla"

Ei Android rajoita mitenkään käyttöliittymien tekemistä.

"guin rakentaminen vaatii kokonaisen frameworkin omaksumista, eikä se käy hetkessä."

Guin tekeminen vaatii käytännössä aina jonkin tekniikan omaksumista. Olkoot se sitten React, Vue, Android API, WinRT tai mitä nyt haluaakaan.

"Swing-ohjelmoinnista ei ole tässä mitään hyötyä."

Ei tietenkään. Legacyähän se.

Lue lisää

Ok, eli et todellakaan tiedä Android-ohjelmoinnista mitään. HTML5:llä pystyt tekemään simppeleitä videon pyörittelyitä ja vastaavia, mutta et yhtään monimutkaisempaa tai vaativampaa ohjelmaa. Se nyt vaan ei onnistu HTML5:llä eikä millään muullakaan halvalla poppakonstilla.

Jos olet tehnyt vain pieniä kokeiluita, miten voit todeta että on aika simppeli? Aivan, et voikaan. Sinä vain luulet sen olevan simppeli, kun olet plärännyt apia selaimella. Sen verran hankala framework on, että kunnollista koodia tekeviä android-kehittäjiä on hyvin vaikea löytää, paljon vaikeampi kuin kunnollista koodiea tekeviä java-ohjelmoijia. Harrastelijoita tietysti on kymmenen tusinassa.

Ei kukaan puhunut käyttöliittymien rajoituksesta mitään. Käyttöjärjestelmä asettaa rajoituksia sille, mitä andoidilla voi tehdä ja mitä ei. Et voi laittaa croniin mitään, vaan sinun pitää käyttää ScheduledTaskia jne. Ja se taas toimii miten toimii, riippuen versiosta ja laitevalmistajasta.

Swing ei ole legacya Androidille. Android ei koskaan ole tukenut Swingiä. Sillä onko Swing legacy vai ei, ei ole tämän asian kanssa mitään tekemistä. Otin sen esimerkiksi siksi, että se on natiivi javan gui-framework.

En viitsi jatkaa kanssasi inttämistä, kun et selvästi ole samalla tasolla, mutta pätemisen tarve on kova. Kesän jatkoja.

noo.noo kirjoitti:

Ok, eli et todellakaan tiedä Android-ohjelmoinnista mitään. HTML5:llä pystyt tekemään simppeleitä videon pyörittelyitä ja vastaavia, mutta et yhtään monimutkaisempaa tai vaativampaa ohjelmaa. Se nyt vaan ei onnistu HTML5:llä eikä millään muullakaan halvalla poppakonstilla.

Jos olet tehnyt vain pieniä kokeiluita, miten voit todeta että on aika simppeli? Aivan, et voikaan. Sinä vain luulet sen olevan simppeli, kun olet plärännyt apia selaimella. Sen verran hankala framework on, että kunnollista koodia tekeviä android-kehittäjiä on hyvin vaikea löytää, paljon vaikeampi kuin kunnollista koodiea tekeviä java-ohjelmoijia. Harrastelijoita tietysti on kymmenen tusinassa.

Ei kukaan puhunut käyttöliittymien rajoituksesta mitään. Käyttöjärjestelmä asettaa rajoituksia sille, mitä andoidilla voi tehdä ja mitä ei. Et voi laittaa croniin mitään, vaan sinun pitää käyttää ScheduledTaskia jne. Ja se taas toimii miten toimii, riippuen versiosta ja laitevalmistajasta.

Swing ei ole legacya Androidille. Android ei koskaan ole tukenut Swingiä. Sillä onko Swing legacy vai ei, ei ole tämän asian kanssa mitään tekemistä. Otin sen esimerkiksi siksi, että se on natiivi javan gui-framework.

En viitsi jatkaa kanssasi inttämistä, kun et selvästi ole samalla tasolla, mutta pätemisen tarve on kova. Kesän jatkoja.

Lue lisää

"Ok, eli et todellakaan tiedä Android-ohjelmoinnista mitään."

Tiedän oikein hyvin.

"HTML5:llä pystyt tekemään simppeleitä videon pyörittelyitä ja vastaavia, mutta et yhtään monimutkaisempaa tai vaativampaa ohjelmaa."

HTML5:lla voi tehdä melkein mitä tahansa mutta natiivisovelluksissa on pääsy kaikkiin toimintoihin mitä laitteessa on, esimerkiksi vaikka Bluetoothin mikä puuttuu HTML5:sta. Natiivilla saa myös enemmän resursseja käyttöön. HTML5:ssa karkeasti seuraavanlaiset rajoitteet:

-Päätelaitteen paikallinen tallennus (non-volatile): 4Mt
-Tietorakenteet päätelaitteen muistissa (volatile): 16Mt
-Koko sovelluksen cacheen esiladattavat assetit: 100Mt

Lisäksi voidaan striimata niitä videoita ja musiikkia.

Tietysti sovellus voi vapaasti siirtää kaikkea prosessointia ja tietorakenteita palvelimen puolelle. Tuota paikallista muistia ja tallennusta tarvitaan siihen, että ohjelma sietäisi paremmin käyttöä ilman verkkoyhteyttä.

"Jos olet tehnyt vain pieniä kokeiluita, miten voit todeta että on aika simppeli?"

No lukeehan se siellä API:n kuvauksessa miten sitä käytetään ja ei siellä ole mitään monimutkaisia asioita.

Sanoit myös tämän:

"Itse koen Android-ohjelmoinnin kohtalaisen hankalana ja lisäksi se on varsin turhauttavaa, koska api vaihtelee versioista riippuen, eivätkä appcompatibility-kirjastot todellakaan ratkaise kaikkia ongelmia."

Käytännössä sitä vaan ottaisi Android API 18 mitä vasten alkaa kehittämään ja compatibility library sitten jos tarvisee tähän jotain toimintoa mikä on uudemmassa Android API:ssa. Voi joutua nysväämään jotain.

Lähinnä tuossa se että pitäisi kikkailla testausautomaatiota mutta onhan noihin ratkaisuja.

"Sen verran hankala framework on, että kunnollista koodia tekeviä android-kehittäjiä on hyvin vaikea löytää, paljon vaikeampi kuin kunnollista koodiea tekeviä java-ohjelmoijia. Harrastelijoita tietysti on kymmenen tusinassa."

Sanoisin että Angular ja Symfony sisältävät selvästi jyrkemmän kynnyksen.

"Ei kukaan puhunut käyttöliittymien rajoituksesta mitään."

Android on päätelaitteen käyttöjärjestelmä. Sillä ajetaan käyttöliittymiä ja edustaprosesseja.

"Käyttöjärjestelmä asettaa rajoituksia sille, mitä andoidilla voi tehdä ja mitä ei."

Toki. Android on päätelaitteen käyttöjärjestelmä. Sillä ajetaan käyttöliittymiä.

"Et voi laittaa croniin mitään, vaan sinun pitää käyttää ScheduledTaskia jne. Ja se taas toimii miten toimii, riippuen versiosta ja laitevalmistajasta."

No kuten sanoin, Android on päätelaitteen käyttöjärjestelmä. Taustaprosessointi oletusarvoisesti kuuluu palvelimen puolelle. Ja ne rajoitteet on siksi, että rajoitettu, suppea rajapinta mikä mahdollistaa tietyt temput että pysyy se sovellusekosysteemi jokseenkin ruodussa ja yhteensopivana ja saa hiekkalaatikoitua. Ei ole tarkoituskaan että voi tehdä kaikkea mahdollista viritystä. Silloin kun tekee viriviriä niin kyse on jostain valmistajakohtaisesta tai laitemallikohtaisesta asiasta.

"Swing ei ole legacya Androidille. Android ei koskaan ole tukenut Swingiä."

Ei Androidissa ole ikinä ollut Swingiä, tiedän toki. Ei sitä tarvitse mihinkään.

"Sillä onko Swing legacy vai ei, ei ole tämän asian kanssa mitään tekemistä. Otin sen esimerkiksi siksi, että se on natiivi javan gui-framework."

Android API on oma rajapintansa, Java SE sitten omansa mutta GUI puoli on käytännössä kuollutta. Swing on siinä legacyä kun Oracle tuonut JavaFX:n korvaamaan sen mutta sitäkään ei kukaan käytä missään eikä sillä tee mitään kun parempiakin on. Swing oli oikein kiva vielä joskus yli 8v sitten.

"En viitsi jatkaa kanssasi inttämistä, kun et selvästi ole samalla tasolla"

Olen selvästikin edistyneemmällä tasolla koska et ymmärrä, että Android API on käytännössä fronttikoodaukseen ja siihen, että mahdollistetaan pääsy Android laitteiden toimintoihin. Siellä on rajoitteet tarkoituksella.

noo.noo kirjoitti:

Ok, eli et todellakaan tiedä Android-ohjelmoinnista mitään. HTML5:llä pystyt tekemään simppeleitä videon pyörittelyitä ja vastaavia, mutta et yhtään monimutkaisempaa tai vaativampaa ohjelmaa. Se nyt vaan ei onnistu HTML5:llä eikä millään muullakaan halvalla poppakonstilla.

Jos olet tehnyt vain pieniä kokeiluita, miten voit todeta että on aika simppeli? Aivan, et voikaan. Sinä vain luulet sen olevan simppeli, kun olet plärännyt apia selaimella. Sen verran hankala framework on, että kunnollista koodia tekeviä android-kehittäjiä on hyvin vaikea löytää, paljon vaikeampi kuin kunnollista koodiea tekeviä java-ohjelmoijia. Harrastelijoita tietysti on kymmenen tusinassa.

Ei kukaan puhunut käyttöliittymien rajoituksesta mitään. Käyttöjärjestelmä asettaa rajoituksia sille, mitä andoidilla voi tehdä ja mitä ei. Et voi laittaa croniin mitään, vaan sinun pitää käyttää ScheduledTaskia jne. Ja se taas toimii miten toimii, riippuen versiosta ja laitevalmistajasta.

Swing ei ole legacya Androidille. Android ei koskaan ole tukenut Swingiä. Sillä onko Swing legacy vai ei, ei ole tämän asian kanssa mitään tekemistä. Otin sen esimerkiksi siksi, että se on natiivi javan gui-framework.

En viitsi jatkaa kanssasi inttämistä, kun et selvästi ole samalla tasolla, mutta pätemisen tarve on kova. Kesän jatkoja.

Lue lisää

Taidatkos tuota tämän selkeämmin sanoa.

t. Ammatikseen Androidia koodaava

ammatttimies kirjoitti:

Taidatkos tuota tämän selkeämmin sanoa.

t. Ammatikseen Androidia koodaava

Minun työn kuvaan kuuluu myös käyttöliittymien ohjelmointi ja teen sen alustariippumattomasti. Sama käyttöliittymäkoodi toimii siis Androidilla, Mac OS:lla, iOS:lla, Ubuntulla, Windowsilla, Debianilla, Red Hat Enterprisella ja jne.

Sattuu olemaan se HTML5 aika kiva standardi kun voi tehdä sovelluksia välittämättä siitä mikä käyttöjärjestelmä sattuu olemaan siinä päätelaitepuolella.

Android API:n rajoitteet muistuttavat HTML5:n, WinRT:n ja iOS:n API:n rajoitteita. Rajoitteet ovat sitä kun tarkoitus on tehdä nimenomaisesti käyttöliittymäkoodia.

Onhan ne natiivit vähän viritetympiä ja mahdollistavat enemmän, en kiellä.

Ketjun aloittajalle ja muillekin voisi miettiä tämmöistä vaihtoehtoa: http://www.material-ui.com/#/

Siinä on kiva käyttöliittymäkirjasto joka tekee juurikin Googlen tyylillä niitä sovelluksia ja toimivat saumattomasti Androidissa. Toimivat vaan suoraan myös muualla.

Ainiin mutta tämänhän ei pitänyt olla mahdollista tuon erään kirjoittajan mielestä.

M-Kar kirjoitti:

"Ok, eli et todellakaan tiedä Android-ohjelmoinnista mitään."

Tiedän oikein hyvin.

"HTML5:llä pystyt tekemään simppeleitä videon pyörittelyitä ja vastaavia, mutta et yhtään monimutkaisempaa tai vaativampaa ohjelmaa."

HTML5:lla voi tehdä melkein mitä tahansa mutta natiivisovelluksissa on pääsy kaikkiin toimintoihin mitä laitteessa on, esimerkiksi vaikka Bluetoothin mikä puuttuu HTML5:sta. Natiivilla saa myös enemmän resursseja käyttöön. HTML5:ssa karkeasti seuraavanlaiset rajoitteet:

-Päätelaitteen paikallinen tallennus (non-volatile): 4Mt
-Tietorakenteet päätelaitteen muistissa (volatile): 16Mt
-Koko sovelluksen cacheen esiladattavat assetit: 100Mt

Lisäksi voidaan striimata niitä videoita ja musiikkia.

Tietysti sovellus voi vapaasti siirtää kaikkea prosessointia ja tietorakenteita palvelimen puolelle. Tuota paikallista muistia ja tallennusta tarvitaan siihen, että ohjelma sietäisi paremmin käyttöä ilman verkkoyhteyttä.

"Jos olet tehnyt vain pieniä kokeiluita, miten voit todeta että on aika simppeli?"

No lukeehan se siellä API:n kuvauksessa miten sitä käytetään ja ei siellä ole mitään monimutkaisia asioita.

Sanoit myös tämän:

"Itse koen Android-ohjelmoinnin kohtalaisen hankalana ja lisäksi se on varsin turhauttavaa, koska api vaihtelee versioista riippuen, eivätkä appcompatibility-kirjastot todellakaan ratkaise kaikkia ongelmia."

Käytännössä sitä vaan ottaisi Android API 18 mitä vasten alkaa kehittämään ja compatibility library sitten jos tarvisee tähän jotain toimintoa mikä on uudemmassa Android API:ssa. Voi joutua nysväämään jotain.

Lähinnä tuossa se että pitäisi kikkailla testausautomaatiota mutta onhan noihin ratkaisuja.

"Sen verran hankala framework on, että kunnollista koodia tekeviä android-kehittäjiä on hyvin vaikea löytää, paljon vaikeampi kuin kunnollista koodiea tekeviä java-ohjelmoijia. Harrastelijoita tietysti on kymmenen tusinassa."

Sanoisin että Angular ja Symfony sisältävät selvästi jyrkemmän kynnyksen.

"Ei kukaan puhunut käyttöliittymien rajoituksesta mitään."

Android on päätelaitteen käyttöjärjestelmä. Sillä ajetaan käyttöliittymiä ja edustaprosesseja.

"Käyttöjärjestelmä asettaa rajoituksia sille, mitä andoidilla voi tehdä ja mitä ei."

Toki. Android on päätelaitteen käyttöjärjestelmä. Sillä ajetaan käyttöliittymiä.

"Et voi laittaa croniin mitään, vaan sinun pitää käyttää ScheduledTaskia jne. Ja se taas toimii miten toimii, riippuen versiosta ja laitevalmistajasta."

No kuten sanoin, Android on päätelaitteen käyttöjärjestelmä. Taustaprosessointi oletusarvoisesti kuuluu palvelimen puolelle. Ja ne rajoitteet on siksi, että rajoitettu, suppea rajapinta mikä mahdollistaa tietyt temput että pysyy se sovellusekosysteemi jokseenkin ruodussa ja yhteensopivana ja saa hiekkalaatikoitua. Ei ole tarkoituskaan että voi tehdä kaikkea mahdollista viritystä. Silloin kun tekee viriviriä niin kyse on jostain valmistajakohtaisesta tai laitemallikohtaisesta asiasta.

"Swing ei ole legacya Androidille. Android ei koskaan ole tukenut Swingiä."

Ei Androidissa ole ikinä ollut Swingiä, tiedän toki. Ei sitä tarvitse mihinkään.

"Sillä onko Swing legacy vai ei, ei ole tämän asian kanssa mitään tekemistä. Otin sen esimerkiksi siksi, että se on natiivi javan gui-framework."

Android API on oma rajapintansa, Java SE sitten omansa mutta GUI puoli on käytännössä kuollutta. Swing on siinä legacyä kun Oracle tuonut JavaFX:n korvaamaan sen mutta sitäkään ei kukaan käytä missään eikä sillä tee mitään kun parempiakin on. Swing oli oikein kiva vielä joskus yli 8v sitten.

"En viitsi jatkaa kanssasi inttämistä, kun et selvästi ole samalla tasolla"

Olen selvästikin edistyneemmällä tasolla koska et ymmärrä, että Android API on käytännössä fronttikoodaukseen ja siihen, että mahdollistetaan pääsy Android laitteiden toimintoihin. Siellä on rajoitteet tarkoituksella.

Lue lisää

"Käytännössä sitä vaan ottaisi Android API 18 mitä vasten alkaa kehittämään ja compatibility library sitten jos tarvisee tähän jotain toimintoa mikä on uudemmassa Android API:ssa. Voi joutua nysväämään jotain."

Jäi sanomatta perustelut.

Laitteiden odotettavissa oleva elinikä on 4v myyntihetkestä. Sitä voi valita suoraan vähintään 4v ikäisen API version ja tähdätä siihen, ja saa sitä myöten toimimaan käytännössä joka paikassa. Jää compatibility library nysvät vähäiseksi kun ei yritä edes saada yhteensopivaksi kaikkien muinaisten versioiden kanssa.

HTML5 on periaatteessa helpompi, sillä se kun on standardi niin toimii uusissa ja vanhoissa. Tässäkin temppuna toimii valita se "heikoin lenkki". Ei tarvitse välittää yli 4v ikäisten laitteiden selainkomponentin puutteista.

M-Kar kirjoitti:

Minun työn kuvaan kuuluu myös käyttöliittymien ohjelmointi ja teen sen alustariippumattomasti. Sama käyttöliittymäkoodi toimii siis Androidilla, Mac OS:lla, iOS:lla, Ubuntulla, Windowsilla, Debianilla, Red Hat Enterprisella ja jne.

Sattuu olemaan se HTML5 aika kiva standardi kun voi tehdä sovelluksia välittämättä siitä mikä käyttöjärjestelmä sattuu olemaan siinä päätelaitepuolella.

Android API:n rajoitteet muistuttavat HTML5:n, WinRT:n ja iOS:n API:n rajoitteita. Rajoitteet ovat sitä kun tarkoitus on tehdä nimenomaisesti käyttöliittymäkoodia.

Onhan ne natiivit vähän viritetympiä ja mahdollistavat enemmän, en kiellä.

Ketjun aloittajalle ja muillekin voisi miettiä tämmöistä vaihtoehtoa: http://www.material-ui.com/#/

Siinä on kiva käyttöliittymäkirjasto joka tekee juurikin Googlen tyylillä niitä sovelluksia ja toimivat saumattomasti Androidissa. Toimivat vaan suoraan myös muualla.

Ainiin mutta tämänhän ei pitänyt olla mahdollista tuon erään kirjoittajan mielestä.

Lue lisää

Tarkkaan ottaen tässä puhutaan applikaatioon upotetusta web-komponentista, joka tukee html5:ttä ja jolle siten pystyy rakentamaan applikaatioon html5:een perustuvan "UI":n. Ihan kiva, mutta hidas ja rajoittunut, käyttäjäkokemus huono eikä hyödynnä andoroidin APIa.

On täydellisen harhaanjohtavaa puhua android-koodauksesta tai ios-koodauksesta, jos oikeasti tehdään vain appin sisäistä webbisivua esimerkiksi webview-komponentilla.

Neuvoksi jokaiselle, joka haluaa oppia tekemään sujuvia ja hyvän käyttäjäkokemuksen omaavia sovelluksia: oikotietä onneen ei ole. Unohda HTML5, unohda päälle liimatut frameworkit, unohda lupaukset kaikkien mobiiliappsien yhteensopivuudesta, jos et halua tehdä turhaa työtä ja pettyä pahemman kerran.

Toki jos teet upotettua web-komponenttia, niin asia on aivan toinen. Mutta silloinkin sopii kysyä, mikset vain tekisi mobiilioptimoitua web-sivua. Tällöin ei tarvita kuin backend-ohjelmointia. Jos pitää välttämättä olla "appi", tee yksinkertainen web-view joka hakee kyseisen sivun.

ammatttimies kirjoitti:

Tarkkaan ottaen tässä puhutaan applikaatioon upotetusta web-komponentista, joka tukee html5:ttä ja jolle siten pystyy rakentamaan applikaatioon html5:een perustuvan "UI":n. Ihan kiva, mutta hidas ja rajoittunut, käyttäjäkokemus huono eikä hyödynnä andoroidin APIa.

On täydellisen harhaanjohtavaa puhua android-koodauksesta tai ios-koodauksesta, jos oikeasti tehdään vain appin sisäistä webbisivua esimerkiksi webview-komponentilla.

Neuvoksi jokaiselle, joka haluaa oppia tekemään sujuvia ja hyvän käyttäjäkokemuksen omaavia sovelluksia: oikotietä onneen ei ole. Unohda HTML5, unohda päälle liimatut frameworkit, unohda lupaukset kaikkien mobiiliappsien yhteensopivuudesta, jos et halua tehdä turhaa työtä ja pettyä pahemman kerran.

Toki jos teet upotettua web-komponenttia, niin asia on aivan toinen. Mutta silloinkin sopii kysyä, mikset vain tekisi mobiilioptimoitua web-sivua. Tällöin ei tarvita kuin backend-ohjelmointia. Jos pitää välttämättä olla "appi", tee yksinkertainen web-view joka hakee kyseisen sivun.

Lue lisää

"Tarkkaan ottaen tässä puhutaan applikaatioon upotetusta web-komponentista, joka tukee html5:ttä ja jolle siten pystyy rakentamaan applikaatioon html5:een perustuvan "UI":n."

Juurikin näin. Saa kivasti paketoitua sovelluksen sovelluskauppaan tuolla tavoin, tai sitten tekee vaan linkin kautta toimivan sovelluksen.

"Ihan kiva, mutta hidas ja rajoittunut, käyttäjäkokemus huono eikä hyödynnä andoroidin APIa."

Android API:a voi itseasiassa hyödyntää kun on tuollainen web komponentti käytössä. Sitä voi eristää Android API:a vaativat jutut pieneen osaan koodia ja sitten pitää lähes kaikki HTML5:na ja näin ollen suoraan siirrettävänä mihin tahansa. Jää porttausvaiva pienemmäksi.

Tuo nyt ei ihan pidä paikkaansa että olisi "hidas, rajoittunut ja käyttäjäkokemus huono".

Kyllä sitä koodia voi tehdä hyvin myös HTML5:lla, että käyttöliittymä reagoi nopeasti. HTML5:ssa ON joitakin rajoitteita että esim. joku Bluetooth ei onnistu tai muuta vastaavaa mutta tosiasiassa lähes kaikki käyttöliittymät onnistuvat HTML5:lla ihan hyvin.

"On täydellisen harhaanjohtavaa puhua android-koodauksesta tai ios-koodauksesta, jos oikeasti tehdään vain appin sisäistä webbisivua esimerkiksi webview-komponentilla."

Eihän siinä nyt muuta eroa kuin että tehdään standarditekniikalla ja standardi toimii joka puolella tai sitten voi tehdä viritetympää ja muutamalla lisähöysteellä varustettua natiivia joka tehdä erikseen Androidille, iOS:lle, Windowsille ja jne.

"Unohda HTML5, unohda päälle liimatut frameworkit, unohda lupaukset kaikkien mobiiliappsien yhteensopivuudesta, jos et halua tehdä turhaa työtä ja pettyä pahemman kerran."

Nyt puhut roskaa. HTML5 on standarditekniikka käyttöliittymille. Suurin osa käyttöliittymistä tehdään HTML5:lle, ja yhteensopivuus on erinomainen. Yhteensopivuus Android vehkeissä Android API:lle ohjelmoitaessa kun tapahtuu valitsemalla sen "heikoimman lenkin" API version niin HTML5:lla valitaan ne ominaisuudet jotka löytyvät "heikoimman lenkin" laitteesta. Käytännössä toimii kaikkialla muualla sitten suoraan.

Kysehän on vaatimusmäärittelystä mikä on sopivin tapa.

"Mutta silloinkin sopii kysyä, mikset vain tekisi mobiilioptimoitua web-sivua."

"Web sivu" voi olla mobiilisovellus. Ei sovelluksia ole pakko jakaa sovelluskaupan kautta vaan voi mennä suoraan linkistä. Se että on "mobiili" ei tarvitse välttämättä yhtään mitään erikoisempaa optimointia. Kyllähän ne CSS palikat, kuten vaikka Bootstrap, on tehty sillä ajatusmallilla että on siinä grid systeemissä mitat mietitty juurikin eri kokoisille laiteluokille ja kehittäjä voi sitten miettiä ulkoasun täggäämällä niitä gridin soluja mikä näkyy ja minkäkokoisena ja missä.

"Tällöin ei tarvita kuin backend-ohjelmointia. Jos pitää välttämättä olla "appi", tee yksinkertainen web-view joka hakee kyseisen sivun."

Web-viewissä nyt pitäisi onnistua paketoimaan sovelluksen tiedostot samaan asennuspakettiin. Ja voisi myös optimaalistella vaikka käyttämällä webassemblyksi kääntämistä. Backend ohjelmointi ei ole välttämätöntä. Joitakin sovelluksia voi tehdä puhtaasti toimimaan frontissa, esim. vaikka taskulaskin.

Tarkennus: html5-sovelluksella ei siis voi tehdä juuri mitään. Sillä voi tehdä html5:ttä, ei mitään vaativampaa android-ohjelmaa. Siihen tarvitset APIa ja loppuu tuskailu "eikö tätäkään voi tehdä".

ammatttimies kirjoitti:

Tarkennus: html5-sovelluksella ei siis voi tehdä juuri mitään. Sillä voi tehdä html5:ttä, ei mitään vaativampaa android-ohjelmaa. Siihen tarvitset APIa ja loppuu tuskailu "eikö tätäkään voi tehdä".

Lue lisää

Roskaa.

Edelleenkin: LÄHES KAIKKIEN SOVELLUSTEN KÄYTTÖLIITTYMÄN VOI TEHDÄ HTML5 TEKNIIKALLA.

Todiste: https://www.getapp.com/

Eli kerrohan nyt mitä olennaista "vaativampaa" ei pysty? Kyllä niitä joitakin on, tiedän sen oikein hyvin koska natiivi mahdollistaa pääsyn kaikkiin laitteen antureihin ja HTML5 ei salli.

Tosiasia vaan on, että kaikkiin toimintoihin ei läheskään aina tarvitse päästä. Katso vaikka noita sovelluksia mitä tuolla on listattuna ja mieti kuinka monta tarvitsee vaikka sitä Bluetoothia.

Muista että suurin osa sovelluksista tehdään HTML5:lla, erityisesti desktop sovellukset kun desktop vehkeissä on vähemmän niitä antureita kuin mobiilivehkeissä. Mobiiliin tehdään natiivia yleensä poikkeussyistä kun nyt tarvitseekin jotain semmoista juttua mikä ei vielä standardilla tavalla onnistu.

On ihan normaalia että täysin sama HTML5 sovellus toimii kaikissa laiteluokissa.

ammatttimies kirjoitti:

Taidatkos tuota tämän selkeämmin sanoa.

t. Ammatikseen Androidia koodaava

Tekiskö joku osaava koodari minulle Samsung j5 teen ajoitetun käynnistys sammutus ohjelman Huaveissä oli valmiina mut samsungiin ei sisälly

"Aloittaja halusi oppia tekemään ohjelmia Android Studiolla, ei vääntämään html-sivuja."

Aloittajan viestistä voi päätellä sellaista, että ei ole tehnyt sovelluksia pahemmin Androidille.

Sovelluksia voi tehdä standardilla tavalla myös, että ei tarvitse välttämättä ollenkaan koko Android studiota saadakseen aikaiseksi sen mitä haluaa.

Sitä ei tiedetä mitä aloittaja haluaa saada aikaiseksi. Auttaisi asiaa jos tietäisi mikä on tavoite, että onko se Hello World vai jotain muuta.

M-Kar kirjoitti:

"Aloittaja halusi oppia tekemään ohjelmia Android Studiolla, ei vääntämään html-sivuja."

Aloittajan viestistä voi päätellä sellaista, että ei ole tehnyt sovelluksia pahemmin Androidille.

Sovelluksia voi tehdä standardilla tavalla myös, että ei tarvitse välttämättä ollenkaan koko Android studiota saadakseen aikaiseksi sen mitä haluaa.

Sitä ei tiedetä mitä aloittaja haluaa saada aikaiseksi. Auttaisi asiaa jos tietäisi mikä on tavoite, että onko se Hello World vai jotain muuta.

Lue lisää

Aloitus:
18.1.2017 0:57
Ensimmäinen vastaus:
6.7.2017 16:46

Ehkä aloittaja on kyllästynyt odottamaan teidän "herkutteluanne" kaikenlaisella. ;DD

"Tiedoksi aloittajalle: käyttöliittymän teko ei ole sama kuin Android-ohjelmointi."

Kyllä se vaan on, sillä Android on päätelaitteen käyttöjärjestelmä. Päätelaitteissa ajetaan sovelluksen käyttöliittymäosaa.

"Käyttölittynässä on nappulat, tekstin syötekentät, kuvat ja ja vastaavat. Itse ohjelman logiikka koodataan muualla, siihen ei html riitä."

Käyttöliittymissä on logiikkaa. Esim. tekstin syötekenttien sisältö validoidaan käyttöliittymäpuolella. Napin painaminen voi avata dialogin, käyttäjä voi avata paneeleja, voi olla reaaliaikainen reitin haku kartalla, navigoida käyttöliittymän eri osissa, ruudulla voidaan vaikka visualisoida jotain dataa. Laskenta joka voidaan tehdä reaaliajassa käyttöliittymässä, tehdään siellä.

Palvelinpuolella tehdään taustaprosessointi, tiedon keskitetty tallennus ja haku.

Android ohjelmointi on juurikin käyttöliittymäohjelmointia. Ei sillä mitään web servicejä ja tietokantoja tehdä. Se sitten sinun rajoitteista käsityskykyä jos et ymmärrä, että käyttöliittymissä on myös logiikkaa.

Käyttöliittymissä voi olla hyvinkin monimutkaista logiikkaa, kuten vaikka jonkinlainen virtuaalitodellisuus jossa voidaan liikkua.

HTML5 on API. Tutki vaikka mitä sieltä löytyy: http://html5index.org/

Eli HTML5:lla tehdään vaikka säikeet, on paikallista, persistenttiä tallennusta, vektorin piirtoa, socketit jne.

Standarditekniikalla ohjelmointi helpottaa valtavasti ohjelmien siirrettävyyttä ja yhteensopivuutta.

En sitten tiedä millä planeetalla porukka on jos kuvittelee HTML:n tarkoittavan jotain staattisia kotisivuja.

M-Kar kirjoitti:

"Tiedoksi aloittajalle: käyttöliittymän teko ei ole sama kuin Android-ohjelmointi."

Kyllä se vaan on, sillä Android on päätelaitteen käyttöjärjestelmä. Päätelaitteissa ajetaan sovelluksen käyttöliittymäosaa.

"Käyttölittynässä on nappulat, tekstin syötekentät, kuvat ja ja vastaavat. Itse ohjelman logiikka koodataan muualla, siihen ei html riitä."

Käyttöliittymissä on logiikkaa. Esim. tekstin syötekenttien sisältö validoidaan käyttöliittymäpuolella. Napin painaminen voi avata dialogin, käyttäjä voi avata paneeleja, voi olla reaaliaikainen reitin haku kartalla, navigoida käyttöliittymän eri osissa, ruudulla voidaan vaikka visualisoida jotain dataa. Laskenta joka voidaan tehdä reaaliajassa käyttöliittymässä, tehdään siellä.

Palvelinpuolella tehdään taustaprosessointi, tiedon keskitetty tallennus ja haku.

Android ohjelmointi on juurikin käyttöliittymäohjelmointia. Ei sillä mitään web servicejä ja tietokantoja tehdä. Se sitten sinun rajoitteista käsityskykyä jos et ymmärrä, että käyttöliittymissä on myös logiikkaa.

Käyttöliittymissä voi olla hyvinkin monimutkaista logiikkaa, kuten vaikka jonkinlainen virtuaalitodellisuus jossa voidaan liikkua.

HTML5 on API. Tutki vaikka mitä sieltä löytyy: http://html5index.org/

Eli HTML5:lla tehdään vaikka säikeet, on paikallista, persistenttiä tallennusta, vektorin piirtoa, socketit jne.

Standarditekniikalla ohjelmointi helpottaa valtavasti ohjelmien siirrettävyyttä ja yhteensopivuutta.

En sitten tiedä millä planeetalla porukka on jos kuvittelee HTML:n tarkoittavan jotain staattisia kotisivuja.

Lue lisää

Ei pidä paikkaansa.

Android-laite on päätelaite samassa mielessä missä pc:kin. Voit tehdä sillä vaikka niitä mainitsemiasi tietokantoja jos haluat. Sqlite tulee mukana.

Päätelaitteen roolissa se on silloin kun surffataan tai käytetään niitä sun html-"sovelluksia". Tyhmä pääte, ei juuri muuta.

Mutta teepäs vaikka nyt finnairin appi html:llä. Tekemättä jää. Pitää tehdä ihan oikea softa Androidin dalvikvm frameworkillä.

Html sopii pikku juttuihin ja on ihan ok tehdä kikkareet sillä. Sovelluksia niin ei kuitenkaan tehdä vaan siihen tarvitaan dalvikia

mökiltä.kirjoitettua kirjoitti:

Ei pidä paikkaansa.

Android-laite on päätelaite samassa mielessä missä pc:kin. Voit tehdä sillä vaikka niitä mainitsemiasi tietokantoja jos haluat. Sqlite tulee mukana.

Päätelaitteen roolissa se on silloin kun surffataan tai käytetään niitä sun html-"sovelluksia". Tyhmä pääte, ei juuri muuta.

Mutta teepäs vaikka nyt finnairin appi html:llä. Tekemättä jää. Pitää tehdä ihan oikea softa Androidin dalvikvm frameworkillä.

Html sopii pikku juttuihin ja on ihan ok tehdä kikkareet sillä. Sovelluksia niin ei kuitenkaan tehdä vaan siihen tarvitaan dalvikia

Lue lisää

"Android-laite on päätelaite samassa mielessä missä pc:kin."

Android laitteet ovat PC:itä.

"Voit tehdä sillä vaikka niitä mainitsemiasi tietokantoja jos haluat. Sqlite tulee mukana."

Tuo ei ole mikään palvelimen tietokanta vaan kanta jota käytetään käyttöliittymäpuolella. Siinä pidetään vaikka postisovelluksen paikallisesti tallennettuja kopioita posteista. HTML5 sisältää toki myös tällaisen lokaalin tietokannan mutta ei se tee Androidia kelvolliseksi postipalvelimeksi.

"Päätelaitteen roolissa se on silloin kun surffataan tai käytetään niitä sun html-"sovelluksia". Tyhmä pääte, ei juuri muuta."

Ei Android ole tyhmä pääte. Käyttöliittymissä voi olla logiikkaa ja se voi ajaa edustaprosesseja.

"Mutta teepäs vaikka nyt finnairin appi html:llä. Tekemättä jää."

Miksi muka? Mitä tuossa on sellaista mihin ei standarditekniikka käy?

Kuvien perusteella voisi päätellä, että tuo sovellus ottaa valokuvia QR-koodatuista lapuista. Tuo on ongelma jos halutaan tehdä täysin yhteensopivaa sillä vanhat Lumia puhelimet ja iOS eivät standardilla tavalla voi ottaa kuvia vaan tarvitsee natiivia. Windows Phone 8.1:llä se on WinRT:tä ja iOS:lle sitten sitä jotain Cocoan ympärille tehtyä frameworkkia. Jos tekee puhtaasti Android sovellusta tai uusille Windows puhelimille, voi kuvat ottaa myös standardilla tavalla HTML5 API:n kautta.

"Pitää tehdä ihan oikea softa Androidin dalvikvm frameworkillä."

Miksi? Perustele.

M-Kar kirjoitti:

"Android-laite on päätelaite samassa mielessä missä pc:kin."

Android laitteet ovat PC:itä.

"Voit tehdä sillä vaikka niitä mainitsemiasi tietokantoja jos haluat. Sqlite tulee mukana."

Tuo ei ole mikään palvelimen tietokanta vaan kanta jota käytetään käyttöliittymäpuolella. Siinä pidetään vaikka postisovelluksen paikallisesti tallennettuja kopioita posteista. HTML5 sisältää toki myös tällaisen lokaalin tietokannan mutta ei se tee Androidia kelvolliseksi postipalvelimeksi.

"Päätelaitteen roolissa se on silloin kun surffataan tai käytetään niitä sun html-"sovelluksia". Tyhmä pääte, ei juuri muuta."

Ei Android ole tyhmä pääte. Käyttöliittymissä voi olla logiikkaa ja se voi ajaa edustaprosesseja.

"Mutta teepäs vaikka nyt finnairin appi html:llä. Tekemättä jää."

Miksi muka? Mitä tuossa on sellaista mihin ei standarditekniikka käy?

Kuvien perusteella voisi päätellä, että tuo sovellus ottaa valokuvia QR-koodatuista lapuista. Tuo on ongelma jos halutaan tehdä täysin yhteensopivaa sillä vanhat Lumia puhelimet ja iOS eivät standardilla tavalla voi ottaa kuvia vaan tarvitsee natiivia. Windows Phone 8.1:llä se on WinRT:tä ja iOS:lle sitten sitä jotain Cocoan ympärille tehtyä frameworkkia. Jos tekee puhtaasti Android sovellusta tai uusille Windows puhelimille, voi kuvat ottaa myös standardilla tavalla HTML5 API:n kautta.

"Pitää tehdä ihan oikea softa Androidin dalvikvm frameworkillä."

Miksi? Perustele.

Lue lisää

Tarvitset paikannusta ja offline-toiminnallisuutta, noin niinkuin aluksi.

mokiltä.kirjoitettua kirjoitti:

Tarvitset paikannusta ja offline-toiminnallisuutta, noin niinkuin aluksi.

HTML5:lla saa offline toiminnallisuuden.

Kuten sanoin niin rajoitteet on noin suunnilleen 4Mt non-volatile muisti, 16Mt volatile muisti ja 100Mt assettien preload cacheen.

Paikannus API löytyy niinikään myös.

Nuo toiminnot ovat ihan yleisesti joka puolella olleet iäisyyden.

mokiltä.kirjoitettua kirjoitti:

Tarvitset paikannusta ja offline-toiminnallisuutta, noin niinkuin aluksi.

Niin ja joo, nuo rajoitteet noin kun linkistä käynnistää. Jos tekee web componentilla ja paketoi sovelluskauppaan tai .apk paketiksi niin siinähän varmaan saa lisää vapauksia. Huomioin noissa rajoitteissa kaikenkirjavat ja tehoiset laitteet.

M-Kar kirjoitti:

Niin ja joo, nuo rajoitteet noin kun linkistä käynnistää. Jos tekee web componentilla ja paketoi sovelluskauppaan tai .apk paketiksi niin siinähän varmaan saa lisää vapauksia. Huomioin noissa rajoitteissa kaikenkirjavat ja tehoiset laitteet.

Lue lisää

Ei löydy laitteen koordnaatteha muun kuin natiivin apin kautta. Ja mihin tallennat offlinea? Pilveenkö? Sovelluksen tulee toimia myös ilman verkkoyhteyttä.

mokiltä.kirjoitettua kirjoitti:

Ei löydy laitteen koordnaatteha muun kuin natiivin apin kautta. Ja mihin tallennat offlinea? Pilveenkö? Sovelluksen tulee toimia myös ilman verkkoyhteyttä.

"Ei löydy laitteen koordnaatteha muun kuin natiivin apin kautta."

Löytyyhän ne HTML:n Geolocationilla.

"Ja mihin tallennat offlinea?"

Sovelluksen muistitilaan. LocalStorage, IndexedDB jne. Sitä kun HTML5 sovelluksille voi odottaa löytävän 4-5Mt paikallista tallennustilaa ja voidaan tallentaa tietoa sinne puskuriin. Ne voi sitten siirtää automaattisesti palvelimelle talteen sitten kun verkkoyhteys tulee saataville. Ja jos sovellus on käynnissä muistissa, on jotain 16- 20Mt muistissa tilaa pitää tietoa.

M-Kar kirjoitti:

"Ei löydy laitteen koordnaatteha muun kuin natiivin apin kautta."

Löytyyhän ne HTML:n Geolocationilla.

"Ja mihin tallennat offlinea?"

Sovelluksen muistitilaan. LocalStorage, IndexedDB jne. Sitä kun HTML5 sovelluksille voi odottaa löytävän 4-5Mt paikallista tallennustilaa ja voidaan tallentaa tietoa sinne puskuriin. Ne voi sitten siirtää automaattisesti palvelimelle talteen sitten kun verkkoyhteys tulee saataville. Ja jos sovellus on käynnissä muistissa, on jotain 16- 20Mt muistissa tilaa pitää tietoa.

Lue lisää

Löytyy isp:n tarjoamat koordinaatit ip:n perusteella, mutta se on karkea 'sinne päin'-tieto. Laitteen koorsinaatteja et saa.

Tallennustilan löytyminen html:llä ei toimi. Paikka vaihtelee laitteesta riippuen, eikä api osaa automaattisesti tarjota oikeaa polkua sdcardille, remote storagesta nyt puhumattakaan . Tietäisit kyllä tämän mikäli olisit joskus tehnyt vakavasti koodia androidille etkä ainoastaan lueskellut minkä pitäisi olla mahdollista. Totuus on se että upotetut web-komponentit noudattavat standardia huonosti, mimkä lisäksi monet laitevalmistajat ovat jättäneet tyystin toiminnallisuutta tekemättä. Tämä tulee vastaan ennen kuin käki kolmasti kukkuu.

Siksi html5-pohjainen mobiiloohjelmointi on jäänyt pienen piirin hypetykseksi. Paljon puheita, vähän villoja.

"Löytyy isp:n tarjoamat koordinaatit ip:n perusteella, mutta se on karkea 'sinne päin'-tieto. Laitteen koorsinaatteja et saa."

Ei vaan koordinaatit tulee sen tiedon mukaan mitä saadaan. Esim. GPS, mobiiliyhteyden solu, IP, Wlan sijainti ja jne. Vastaava rajapinta on myös Android API:ssa.

"Tallennustilan löytyminen html:llä ei toimi."

Kyllä löytyy. Esimerkiksi: https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage

"Paikka vaihtelee laitteesta riippuen, eikä api osaa automaattisesti tarjota oikeaa polkua sdcardille,"

Ei siinä mitään polkuja tietenkään ole kun kyse ei ole mistään tiedoston tallentamisesta SD-kortille vaan tallentamisesta sovellukselle varattuun muistialueeseen. Sitä muistia on kahdenlaista:

1. Muisti joka säilyy vaikka sovellus suljetaan ja sähköt katkaistaan
2. Muisti joka säilyy niin pitkään kuin sovellus on käynnissä

Ei ole tarkoituskaan tallentaa mitään paikallisia tiedostoja vaan pitää tieto tallessa offline tilassa. Sitten kun on verkkoyhteys taas saatavilla niin se voidaan siirtää palvelimelle itsekseen.

Tallentaminen tiedostoonkin onnistuisi avaamalla uusi ikkuna jonka DOM:n täyttää tallennettavalla tiedolla jolloin käyttäjä voi tallentaa tiedon tiedostoksi, mutta se nyt edellyttäisi käyttäjältä "tiedosto->tallenna" operointia.

Mitään järkeä tuollaisessa ei tietenkään ole kun "puhtaat" sovellukset eivät sotke päätelaitetta tunkemalla sinne tiedostoja. Tiedon tallennus tapahtuu palvelimessa mutta sovellus voi tallentaa tietoa offline toiminnallisuutta varten.

"Tietäisit kyllä tämän mikäli olisit joskus tehnyt vakavasti koodia androidille etkä ainoastaan lueskellut minkä pitäisi olla mahdollista."

Teen Androidillakin ajettavaa koodia melkein päivittäin.

"Totuus on se että upotetut web-komponentit noudattavat standardia huonosti, mimkä lisäksi monet laitevalmistajat ovat jättäneet tyystin toiminnallisuutta tekemättä."

Ei tarvitse upottaa mitään web componenttia. Upotettua web componenttia käytetään kun kääritään sovellus sovelluskauppaan ja/tai tehdään ns. hybridi sovellus, eli tehdään mahdollisimman suuri osa sovelluksesta standardilla tavalla mutta jos jotain olennaista puuttuu syystä tai toisesta niin sinne tehdään "koukku" jolla tehdään pieni pätkä natiivia.

Ideana tietenkin on tehdä mahdollisimman helposti siirrettävä sovellus, sillä sovelluksen kun siirtää Androidilta vaikka iOS:lle niin tarvitsee uudelleen kirjoittaa vain se natiivikoodi pätkä.

"Totuus on se että upotetut web-komponentit noudattavat standardia huonosti, mimkä lisäksi monet laitevalmistajat ovat jättäneet tyystin toiminnallisuutta tekemättä. Tämä tulee vastaan ennen kuin käki kolmasti kukkuu."

Minulla on muuten yli 4v ikäinen Android tabletti ja puhelin, eri valmistajilta ja niissä on molemmissa uusi Chrome, että ei ole mitään ongelmia. Katsos kun HTML5 sovellus ei tarvitse muuta kuin sen selaimen. Sitä voi sitten tehdä home screenille pikakuvakkeen.

"Siksi html5-pohjainen mobiiloohjelmointi on jäänyt pienen piirin hypetykseksi. Paljon puheita, vähän villoja."

Miksi sitten mobiilisovellukset on yleensä tehty HTML5:lla? Joko ne toimivat suoraan linkistä tai sitten on kääritty sovelluskauppaan. Itseasiassa monet hyvin yleiset ja tunnetut mobiilisovellukset ovat HTML5:sta vaikka olisi resursseja tehdä natiiviakin. Esimerkiksi Evernote ja Twitter.

Tosiasia on, että eihän niitä edes erota onko natiivia vai HTML5:sta jos on kääritty web componentilla mutta jos selaimella suoraan käynnistää sovelluksen niin on sitten HTML5:sta.

"Tässä on suht asiallinen artikkeli html5-koodauksesta mobilille."

Artikkeli on vanhentunut. Se on vuodelta 2015 jolloin oli vielä vuoden 2011 laitteita käytössä.

Itselläni on Android 4.1 puhelin ja tabletti ja niihin ei päde tuollaiset Android 2.x aikaiset jutut.

"- hidas, huono käyttäjäkokemus"
"- hitauden vuoksi ei usein kelpaa app storeen"

Onko Twitter muka hidas ja huono? Miten se voi olla niin suosittu jos on muka huono?

"-huono tai olematon rautatuki
-peliohjelmoinnissa esim open gl ei toimi. Tarkoittaa ettei matopeliä kummempaa grafiikkaa voi tehdä"

Ei pidä paikkaansa. Olen itse kirjoittanut WebGL koodia ja se toimii ihan hyvin Android 4.1:llä

"-html5:n implementaatuo ob kuitenkin vähän erilainen eri laitteissa. Vähän niinkuin eri selaimet tulkitsevat sivuja eri lailla ja javaskripti on tehtävä osittain erikseen eri selaimille. Sama koskee mobiilia."

Toteutuksissa oli eroa joskus ennen vuotta 2011 mutta ne tasaantuivat ja sitä myös tasattiin, sillä frameworkit olennaisesti sisältävät tarvittavan nysvän millä on kierretty bugit yms. kummallisuudet toteutuksissa.

Tämähän oli se jQueryn mahtijuttu aikoinaan kun sitä ohjelmointia pystyi tekemään samalla tavalla joka puolelle. Se mekanismi käytännössä se, että otetaan heikoin lenkki ja kehitetään sillä standardilla tavalla. Uudemmat ovat käytännössä yhteensopivia vanhemman kanssa.

"Meillä on esim ohjelma joka ottaa ssh:n toiseen komponenttiin. Siisti ratkaisu siinä ympäristössä eikä tarvita backendia. Tämäkään ei onnistuisi html:llä."

Surkealta tuo vaikuttaa kun salatun yhteyden saa näppärästi HTTPS:llä.

"Html5:ssä Kustannuksia "säästetään" mutta se aika kuluu palavereissa miten kierretään mikäkin ongelma. Ei hyvä bisneksen kannalta."

Niitä "ongelmia" tulee vaan aloittelijoille jotka alkavat tehdä päin persettä heti lähtöruudusta. Esim. ei ole miettitynä arkkitehtuuria kuten mikä osa koodista kuuluu olla frontissa, mikä backendissä, sovelluksen toimintojen purkamista palveluarkkitehtuuriksi ja käyttöliittymää komponenteiksi.

M-Kar kirjoitti:

"Tässä on suht asiallinen artikkeli html5-koodauksesta mobilille."

Artikkeli on vanhentunut. Se on vuodelta 2015 jolloin oli vielä vuoden 2011 laitteita käytössä.

Itselläni on Android 4.1 puhelin ja tabletti ja niihin ei päde tuollaiset Android 2.x aikaiset jutut.

"- hidas, huono käyttäjäkokemus"
"- hitauden vuoksi ei usein kelpaa app storeen"

Onko Twitter muka hidas ja huono? Miten se voi olla niin suosittu jos on muka huono?

"-huono tai olematon rautatuki
-peliohjelmoinnissa esim open gl ei toimi. Tarkoittaa ettei matopeliä kummempaa grafiikkaa voi tehdä"

Ei pidä paikkaansa. Olen itse kirjoittanut WebGL koodia ja se toimii ihan hyvin Android 4.1:llä

"-html5:n implementaatuo ob kuitenkin vähän erilainen eri laitteissa. Vähän niinkuin eri selaimet tulkitsevat sivuja eri lailla ja javaskripti on tehtävä osittain erikseen eri selaimille. Sama koskee mobiilia."

Toteutuksissa oli eroa joskus ennen vuotta 2011 mutta ne tasaantuivat ja sitä myös tasattiin, sillä frameworkit olennaisesti sisältävät tarvittavan nysvän millä on kierretty bugit yms. kummallisuudet toteutuksissa.

Tämähän oli se jQueryn mahtijuttu aikoinaan kun sitä ohjelmointia pystyi tekemään samalla tavalla joka puolelle. Se mekanismi käytännössä se, että otetaan heikoin lenkki ja kehitetään sillä standardilla tavalla. Uudemmat ovat käytännössä yhteensopivia vanhemman kanssa.

"Meillä on esim ohjelma joka ottaa ssh:n toiseen komponenttiin. Siisti ratkaisu siinä ympäristössä eikä tarvita backendia. Tämäkään ei onnistuisi html:llä."

Surkealta tuo vaikuttaa kun salatun yhteyden saa näppärästi HTTPS:llä.

"Html5:ssä Kustannuksia "säästetään" mutta se aika kuluu palavereissa miten kierretään mikäkin ongelma. Ei hyvä bisneksen kannalta."

Niitä "ongelmia" tulee vaan aloittelijoille jotka alkavat tehdä päin persettä heti lähtöruudusta. Esim. ei ole miettitynä arkkitehtuuria kuten mikä osa koodista kuuluu olla frontissa, mikä backendissä, sovelluksen toimintojen purkamista palveluarkkitehtuuriksi ja käyttöliittymää komponenteiksi.

Lue lisää

Surkealta tuo vaikuttaa kun salatun yhteyden saa näppärästi HTTPS:llä."

Saa saa, mutta entä ssh:n oma autentikointi, port forwardimg, dynaaminen pf socks proxya varten jne. Kaikki nämä ja paljon muuta on käytössä kun ei rupea oikomaan html:n avulla.

Harmi jos joku aloittelija luulee että html on ratkaisu kaikkeen. Ei se ole. Monen mielestä se on kelvoton laastari yhteensopivuusongelmiin joita kyllä riittää android-maailmassa.

mokiltä.kirjoitettua kirjoitti:

Surkealta tuo vaikuttaa kun salatun yhteyden saa näppärästi HTTPS:llä."

Saa saa, mutta entä ssh:n oma autentikointi, port forwardimg, dynaaminen pf socks proxya varten jne. Kaikki nämä ja paljon muuta on käytössä kun ei rupea oikomaan html:n avulla.

Harmi jos joku aloittelija luulee että html on ratkaisu kaikkeen. Ei se ole. Monen mielestä se on kelvoton laastari yhteensopivuusongelmiin joita kyllä riittää android-maailmassa.

Lue lisää

"mutta entä ssh:n oma autentikointi"

Ei tarvitse. Autentikointi voidaan tehdä samalla tavalla kuin palvelun käytön todennus.

"port forwardimg"

Ei tarvitse. Kaikki yhteydet muodostetaan päätelaitteista palvelimen suuntaan. Jos on tekemässä päin vastoin, on arkkitehtuuri pielessä.


"dynaaminen pf socks proxya varten jne"

Ei tarvitse.

"Kaikki nämä ja paljon muuta on käytössä kun ei rupea oikomaan html:n avulla."

Ei vaan kyse on siitä, että tuollaisessa ssh kikkailussa oikaistaan järjestelmän arkkitehtuurissa. Parempi pitää vaan web serviceinä tai sitten suoraan sockettien kautta, ja yleensäkin käyttää standardeja verkkoprotokollia.

"Harmi jos joku aloittelija luulee että html on ratkaisu kaikkeen."

Olet siis aloittelija jos tuollaista kuvittelet.

"Ei se ole."

Sinähän se sellaisista kuvitelmista puhut. Minä olen kaiken aikaa sanonut HTML5:n olevan STANDARDI, sillä onnistuu LÄHES kaikki käyttöliittymät ja on suositeltava yhteensopivuuden ja siirrettävyden takia.

Kaikki ei onnistu eikä tarvitsekkaan. Poikkeustarpeisiin on natiivisovellukset olleet kaiken aikaa kuten olleet aina ennenkin.

Tarve natiiville on kaiken aikaa pienempi johtuen siitä, että standardointi ja teknologia kehittyy kaiken aikaa. Eihän sitä ennen vuotta 2005 oikein ajettu mitään logiikkaa fronttipuolella standardilla tavalla ja oli kelvottoman hidasta standardilla tavalla ennen vuotta 2009. Ja tämäkin päti desktopiin. Mobiili tullut jotain 1,5v jäljessä. Lisäksi mobiilivehkeet eivät aina ole päivitettävissä täysin uuteen ja niitä on kuitenkin käytössä, että jos haluaa sovelluksen toimivan muuallakin kuin uusimmalla niin pitää tähdätä 4v ikäiselle tekniikalle. Tämä tarkoittaa noin 5,5-6v viivettä standardiin siirtymisessä.

Siksi niitä natiivisovelluksia tai muita kikkareita ollut pidempään mobiilissa kuin desktopilla. Desktopilla menty HTML5:n 2009..2011 välillä voimalla. Mobiilissa viimeiset 2v.

"Monen mielestä se on kelvoton laastari yhteensopivuusongelmiin joita kyllä riittää android-maailmassa."

Kyllä se yhteensopivuusongelma johtuu siitä että kikkailet aloittelijoiden tapaan. Ihan itse kerroit jostain cron virityksistä kun yrität käyttää PÄÄTELAITETTA ajamaan taustajärjestelmän toimintoja. Älä unohda sitä, että Android on PÄÄTELAITE, siihen tehdään se käyttöliittymäosa. Jos yrität kikkailla sitä toimimaan kuin palvelin niin teet väärin ja ongelmat on seurausta siitä. Android API:a ja HTML5:sta ohjelmoidaan periaatetasolla täysin samalla tavalla, eli sillä tehdään käyttöliittymäosa.

Se on semmoinen aloittelijan moka, että aletaan kikkailemaan. Kaikki mikä on mahdollista, ei ole missään nimessä siistiä arkkitehtuuria.

Kuten HTML5:lla, Android API:sta valitaan myös se vähintään 4v ikäinen API versio ja tähdätään siihen niin toimii sitten melko vaivatta joka Android laitteessa kun jättää kaikki typerät kikkailut pois. Tietysti voi vapaasti tähdätä vain uudemmille laitteille ja uusille rajapinnoille.

M-Kar kirjoitti:

"mutta entä ssh:n oma autentikointi"

Ei tarvitse. Autentikointi voidaan tehdä samalla tavalla kuin palvelun käytön todennus.

"port forwardimg"

Ei tarvitse. Kaikki yhteydet muodostetaan päätelaitteista palvelimen suuntaan. Jos on tekemässä päin vastoin, on arkkitehtuuri pielessä.


"dynaaminen pf socks proxya varten jne"

Ei tarvitse.

"Kaikki nämä ja paljon muuta on käytössä kun ei rupea oikomaan html:n avulla."

Ei vaan kyse on siitä, että tuollaisessa ssh kikkailussa oikaistaan järjestelmän arkkitehtuurissa. Parempi pitää vaan web serviceinä tai sitten suoraan sockettien kautta, ja yleensäkin käyttää standardeja verkkoprotokollia.

"Harmi jos joku aloittelija luulee että html on ratkaisu kaikkeen."

Olet siis aloittelija jos tuollaista kuvittelet.

"Ei se ole."

Sinähän se sellaisista kuvitelmista puhut. Minä olen kaiken aikaa sanonut HTML5:n olevan STANDARDI, sillä onnistuu LÄHES kaikki käyttöliittymät ja on suositeltava yhteensopivuuden ja siirrettävyden takia.

Kaikki ei onnistu eikä tarvitsekkaan. Poikkeustarpeisiin on natiivisovellukset olleet kaiken aikaa kuten olleet aina ennenkin.

Tarve natiiville on kaiken aikaa pienempi johtuen siitä, että standardointi ja teknologia kehittyy kaiken aikaa. Eihän sitä ennen vuotta 2005 oikein ajettu mitään logiikkaa fronttipuolella standardilla tavalla ja oli kelvottoman hidasta standardilla tavalla ennen vuotta 2009. Ja tämäkin päti desktopiin. Mobiili tullut jotain 1,5v jäljessä. Lisäksi mobiilivehkeet eivät aina ole päivitettävissä täysin uuteen ja niitä on kuitenkin käytössä, että jos haluaa sovelluksen toimivan muuallakin kuin uusimmalla niin pitää tähdätä 4v ikäiselle tekniikalle. Tämä tarkoittaa noin 5,5-6v viivettä standardiin siirtymisessä.

Siksi niitä natiivisovelluksia tai muita kikkareita ollut pidempään mobiilissa kuin desktopilla. Desktopilla menty HTML5:n 2009..2011 välillä voimalla. Mobiilissa viimeiset 2v.

"Monen mielestä se on kelvoton laastari yhteensopivuusongelmiin joita kyllä riittää android-maailmassa."

Kyllä se yhteensopivuusongelma johtuu siitä että kikkailet aloittelijoiden tapaan. Ihan itse kerroit jostain cron virityksistä kun yrität käyttää PÄÄTELAITETTA ajamaan taustajärjestelmän toimintoja. Älä unohda sitä, että Android on PÄÄTELAITE, siihen tehdään se käyttöliittymäosa. Jos yrität kikkailla sitä toimimaan kuin palvelin niin teet väärin ja ongelmat on seurausta siitä. Android API:a ja HTML5:sta ohjelmoidaan periaatetasolla täysin samalla tavalla, eli sillä tehdään käyttöliittymäosa.

Se on semmoinen aloittelijan moka, että aletaan kikkailemaan. Kaikki mikä on mahdollista, ei ole missään nimessä siistiä arkkitehtuuria.

Kuten HTML5:lla, Android API:sta valitaan myös se vähintään 4v ikäinen API versio ja tähdätään siihen niin toimii sitten melko vaivatta joka Android laitteessa kun jättää kaikki typerät kikkailut pois. Tietysti voi vapaasti tähdätä vain uudemmille laitteille ja uusille rajapinnoille.

Lue lisää

Ahaa eli tiedät mitä meidän sovelluksemme ei tarvitse. Kuinka väärässä oletkaan.

ei.jaksa.enää kirjoitti:

Ahaa eli tiedät mitä meidän sovelluksemme ei tarvitse. Kuinka väärässä oletkaan.

Voi kuule kun ei liity mitenkään teidän sovelluksen kokonaistarpeisiin.

Kyse on teidän sovelluksen KÄYTTÖLIITTYMÄN tarpeista.

Unohdat jälleen sen arkkitehtuuripuolen kokonaan ja säädät jotain virityksiä kuten taustaprosessointia, port forwardingia yms. käyttöliittymään.

Toisin sanoen et vaan osaa, teet väärin ja ongelmasi aiheutuvat siitä. HTML5 olisi oikeastaan vaan hyvä asia sinulle koska rajatumpi hiekkalaatikointi pakottaa tekemään asioita oikein.

Rajapintakuvaukset on, niitä vaan ei ole läheskään kaikkea implementoitu kyllä pitää selvittää ihan googlelta mitä on toteutettu ja mitä ei. Huhhuh, mietis nyt mitä kirjoitat.

Kirjoituksestasi voi lukea rivien välistä, ettet koodaa työksesi vaan huviksesi. Ihan hyvä, mutta isommissa taloissa softat tehdään tietenkin siihen tarjotulla apilla eikä päälle liimatulla ylimääräisellä kerroksella. Html5:ttä voi verrata virtuaalikoneeseen. Toimii monasti ok, mutta on vanhalla raudalla hidas ja käyttökokemus on ikävä. Ja puhelinten rauta nyr on mitä on, suurin osa olevasta laitekannasta on hidasta ja vanhaa. Softan pitää toimia kaikissa laitteissa eikä vain kehittäjän supernopeassa testipuhelimessa.

mokiltä.kirjoitettua kirjoitti:

Rajapintakuvaukset on, niitä vaan ei ole läheskään kaikkea implementoitu kyllä pitää selvittää ihan googlelta mitä on toteutettu ja mitä ei. Huhhuh, mietis nyt mitä kirjoitat.

Kirjoituksestasi voi lukea rivien välistä, ettet koodaa työksesi vaan huviksesi. Ihan hyvä, mutta isommissa taloissa softat tehdään tietenkin siihen tarjotulla apilla eikä päälle liimatulla ylimääräisellä kerroksella. Html5:ttä voi verrata virtuaalikoneeseen. Toimii monasti ok, mutta on vanhalla raudalla hidas ja käyttökokemus on ikävä. Ja puhelinten rauta nyr on mitä on, suurin osa olevasta laitekannasta on hidasta ja vanhaa. Softan pitää toimia kaikissa laitteissa eikä vain kehittäjän supernopeassa testipuhelimessa.

Lue lisää

"Rajapintakuvaukset on, niitä vaan ei ole läheskään kaikkea implementoitu kyllä pitää selvittää ihan googlelta mitä on toteutettu ja mitä ei."

Kuten Android API:lla, ei eroa. Pitää valita API versio mihin tähtää ja katsoa mitä toimintoja siinä. HTML5:lla sama että tarkistaa vaikka tällä: https://html5test.com/

"Kirjoituksestasi voi lukea rivien välistä, ettet koodaa työksesi vaan huviksesi."

Työkseni koodaan.

"Ihan hyvä, mutta isommissa taloissa softat tehdään tietenkin siihen tarjotulla apilla eikä päälle liimatulla ylimääräisellä kerroksella."

Softat tehdään tarjotulla API:lla. On ihan normaalia että on käytössä jotain kirjastoja ja frameworkkeja. Onhan sinullakin se Android API etkä siis tee pelkällä Javakielellä ilman rajapintaa kaikkea itse.

HTML5 on suhteellisen matalan tason API, vähän niinkuin POSIX. Siksi se Android API on siinä POSIX:n päällä ja HTML5:n päällä on sitten tavallisesti jotain frameworkkia/kirjastoa. Nyt sitten keksit jotain tekosyitä miksi standardin HTML5:n varassa toimiva tekniikka olisi jotenkin huonompi kuin Android API.

"Html5:ttä voi verrata virtuaalikoneeseen."

Virtuaalikone kuten Dalvik.

"Toimii monasti ok, mutta on vanhalla raudalla hidas ja käyttökokemus on ikävä. Ja puhelinten rauta nyr on mitä on, suurin osa olevasta laitekannasta on hidasta ja vanhaa."

Yli 4v ikäisistä mobiililaitteista ei tarvitse välittää.

"Softan pitää toimia kaikissa laitteissa eikä vain kehittäjän supernopeassa testipuhelimessa."

Et saa tehtyä Android API:lla Windows puhelimissa tai iPhonessa toimivaa sovellusta.

Vähän riippuu tarpeista.

Olennainen syy jonkun kirjaston/frameworkin käyttöön on se, että HTML5:lla standardi tapa tehdä komponentteja, ns. Web Components, ei ole ihan valmis. Siksi tätä paikkailee kirjastoja ja frameworkkeja joilla on omat ekosysteeminsä, omine komponentteineen.

Vähän sama kuin on Android API tai WinRT ja jne. niin HTML5:n päällä on omat kirjastonsa. Ne vaan toimivat käytännössä universaalisti joka laitteella kun nuo natiivit on sidoksissa käyttöjärjestelmään

Homma alkoi silloin vuonna 2006 jQuerystä ja sitä sai oikein kirjoitettua komponentteja tyyliin:

(function ($) { }

Malli oli aikoinaan se, että oli HTML:llä esitettynä DOM joka tuli palvelimelta ja ne palikat joita prosessointiin päätelaitteessa, tehtiin vaikka jokaiselle komponentille oma .js tiedosto ja .css tiedosto BEM nimeämisellä.

Sitten tuli Angular vuonna 2010 joka oli valtavan laaja framework. Tässä ideana vähän se, että sovelluksen koko käyttöliittymä oli hyvin pitkälti päätelaitteessa eikä harrastettu palvelinpuolen koodia. Angularissa HTML pohjaa täydennettiin omilla komponenttitageilla.

Angular määritteli tarkemmin miten komponentteja kirjoitettiin, että pysyi koodi siistinä. jQueryllä oli niin paljon vapauksia että kehittäjän vastuulla oli enemmän.

Angularin jälkeen seuraava merkittävä oli React vuodelta 2013, ja se on nykyisin suosituin ja tällä on laajin ekosysteemi. Tässä vähän semmoinen idea, että HTML:ää on pyritty hävittämään ja softa rakennetaan melko puhtaasti ES6 koodina. Pieniä .jsx pätkiä siellä sitten templateina komponenteissa.

Reactin jälkeen seuraava merkittävä oli Vue, vuodelta 2014. Komponentteja tehdään vastaavasti omilla tageilla HTML pohjaan kuin Angularissa mutta komponenttien teko tehty hyvin yksinkertaiseksi ja on minimalistisempi.

Näitä jos vähän vertailee niin kaikki on hengissä ja voi hyvin, sillä kaikille on tehty paljon koodia ja niitä ylläpidetään vuosikausia. Uutta koodia varten en ottaisi jQueryä enkä Angularia, ne ovat niin vanhanaikaisia.

React ja Vue jos on vertailussa niin Vue on näistä yksinkertaisempi. Itseasiassa Vue on jokseenkin varmuudella helpoin väline tehdä käyttöliittymäkomponentteja. Tästä on vaikea pistää helpommaksi: https://vuejs.org/v2/guide/single-file-components.html

Reactissa taas vahvuutena laajempi ekosysteemi sekä react-native, jossa voi käännellä saman koodin mobiililaitteille natiiviksi. Vue tosin on HTML5:n päällä toimiessaan hieman suorituskykyisempi kuin React.

Tavallisesti tässä otetaan kaveriksi myös redux/vuex käyttöliittymän tilan keskitettyyn hallintaan. Valmista ulkoasua ja valmiita komponenttikirjastoja käytetään myös paljon.

Riippuu vähän minkä näköistä sitten haluaa, että mitä komponenttikirjastoa käyttäisi. Kaikki saa maksutta.

Ehkä semmoista eroa olennaista eroa olisi Reactilla ja Vue:lla, että Vue forcettaa enemmän tietyn mallin mukaiseksi kun React tarjoaisi vapaammat kädet liitellä erilaisia palikoita siihen kiinni mitä muualla.

Että mistä nyt sattuu tykkäämään ja mitä ominaisuuksia painottaa.

M-Kar kirjoitti:

Ehkä semmoista eroa olennaista eroa olisi Reactilla ja Vue:lla, että Vue forcettaa enemmän tietyn mallin mukaiseksi kun React tarjoaisi vapaammat kädet liitellä erilaisia palikoita siihen kiinni mitä muualla.

Että mistä nyt sattuu tykkäämään ja mitä ominaisuuksia painottaa.

Lue lisää

Onpa monimutkaista. Entä jos valitsee väärin? Miten Apache cordova liittyy tähän? Entä phonegap? Miten koodi saadaan asennettua laitteelle, voiko sen julkaista play-kaupassa, entä mikä ide tukee tätä?

Onko samat ongelmat kuin jqueryssä, eli lupaus on että tukee kaikkia selaimia versiosta se ja se ylöspäin, mutta sitten kuitenkaan kaikki ei toimi (ja miten voisikaan).

kokeillaanpa.täälläkin kirjoitti:

Onpa monimutkaista. Entä jos valitsee väärin? Miten Apache cordova liittyy tähän? Entä phonegap? Miten koodi saadaan asennettua laitteelle, voiko sen julkaista play-kaupassa, entä mikä ide tukee tätä?

Onko samat ongelmat kuin jqueryssä, eli lupaus on että tukee kaikkia selaimia versiosta se ja se ylöspäin, mutta sitten kuitenkaan kaikki ei toimi (ja miten voisikaan).

Lue lisää

"Onpa monimutkaista. Entä jos valitsee väärin?"

Siis kyllähän sen sovelluksen voi tehdä eri tekniikoilla. Samalla tavalla Android API:n valinta voi olla "väärin" kun on niin työlästä portata.

"Miten Apache cordova liittyy tähän?"

En ole käyttänyt mutta ymmärtääkseni se olisi työkalu siihen, että saa siirrettyä HTML5 sovelluksen eri mobiililaitteisiin asennettavaksi sovellukseksi ja kun joissakin laitteissa puuttuu HTML5:sta esim. kameran käyttö niin tuo sitten täydentää eri alustojen webview komponenttia.

Toisin sanoen tuolla voi tehdä sovelluksen kerran standardilla tavalla ja siirtää eri laitteisiin.

"Miten Apache cordova liittyy tähän? Entä phonegap?"

Sama asia.

"Miten koodi saadaan asennettua laitteelle, voiko sen julkaista play-kaupassa, entä mikä ide tukee tätä?"

Veikkaan, että tuo Cordova pyöräyttää siitä projektin eri alustoille.

Kuten aiemmin sanoin niin HTML5 sovelluksen voi paketoida sovelluskauppaan yksinkertaisesti tekemällä projektin jossa se webview ja siirtää käännetyn HTML5 sovelluksen tiedostot käynnistymään siihen. Tuo vaihe käy kätevästi sillä Android studiolla ja jokseenkin varmasti skriptattavissa kun ensiksi tehnyt sen varsinaisen sovelluksen.

Itse tykkään tehdä HTML5 sovelluksia Visual Studio Codella. Se on sitten ihan oma vaiheensa paketoida jonkun webviewin kanssa sovelluskauppaan, jos nyt edes halutaan mitään sovelluskauppaa.

"Onko samat ongelmat kuin jqueryssä, eli lupaus on että tukee kaikkia selaimia versiosta se ja se ylöspäin, mutta sitten kuitenkaan kaikki ei toimi (ja miten voisikaan)."

Siis mikä ei muka toimi?

jQuery versiosta 1.0 eteenpäin tarvitsi IE6, Firefox 2 tai Safari 2 selaimen ja pitivät sen toimivana kaikkiin käyttöjärjestelmä/selainvalmistajan tuen piirissä oleviin selainversioihin.

jQuery 2.0:ssa pudottivat IE9:ä vanhemmat IE versiot vaikka Microsoft vielä niitä tuki, mutta pitivät 1.x sarjaa siinä rinnalla näitä varten.

Semmoisia huomioita kyllä, että se jQuery hoiti vain sitä Javascriptiä ja selainten eroavaisuuksien yhtenäistämistä javascriptin ja DOM käsittelyn osalta. Se ei vaikuta HTML5:n rajapinnan toimintoihin eikä CSS asioihin. Niissä mentiin heikoimman lenkin mukaan.

ELI, kerrohan nyt ihan tarkalleen mikä ei toiminut jQueryssä DOM käsittelyssä ja XHR kutsuissa? Edelleenkin lähtökohta on se, että kehitystyö tehdään heikoimmailla selaimella mitä halutaan tukea. Aivan kuten Android API:sta valitaan vanhin API versio minkä laitteita halutaan tukea.

M-Kar kirjoitti:

"Onpa monimutkaista. Entä jos valitsee väärin?"

Siis kyllähän sen sovelluksen voi tehdä eri tekniikoilla. Samalla tavalla Android API:n valinta voi olla "väärin" kun on niin työlästä portata.

"Miten Apache cordova liittyy tähän?"

En ole käyttänyt mutta ymmärtääkseni se olisi työkalu siihen, että saa siirrettyä HTML5 sovelluksen eri mobiililaitteisiin asennettavaksi sovellukseksi ja kun joissakin laitteissa puuttuu HTML5:sta esim. kameran käyttö niin tuo sitten täydentää eri alustojen webview komponenttia.

Toisin sanoen tuolla voi tehdä sovelluksen kerran standardilla tavalla ja siirtää eri laitteisiin.

"Miten Apache cordova liittyy tähän? Entä phonegap?"

Sama asia.

"Miten koodi saadaan asennettua laitteelle, voiko sen julkaista play-kaupassa, entä mikä ide tukee tätä?"

Veikkaan, että tuo Cordova pyöräyttää siitä projektin eri alustoille.

Kuten aiemmin sanoin niin HTML5 sovelluksen voi paketoida sovelluskauppaan yksinkertaisesti tekemällä projektin jossa se webview ja siirtää käännetyn HTML5 sovelluksen tiedostot käynnistymään siihen. Tuo vaihe käy kätevästi sillä Android studiolla ja jokseenkin varmasti skriptattavissa kun ensiksi tehnyt sen varsinaisen sovelluksen.

Itse tykkään tehdä HTML5 sovelluksia Visual Studio Codella. Se on sitten ihan oma vaiheensa paketoida jonkun webviewin kanssa sovelluskauppaan, jos nyt edes halutaan mitään sovelluskauppaa.

"Onko samat ongelmat kuin jqueryssä, eli lupaus on että tukee kaikkia selaimia versiosta se ja se ylöspäin, mutta sitten kuitenkaan kaikki ei toimi (ja miten voisikaan)."

Siis mikä ei muka toimi?

jQuery versiosta 1.0 eteenpäin tarvitsi IE6, Firefox 2 tai Safari 2 selaimen ja pitivät sen toimivana kaikkiin käyttöjärjestelmä/selainvalmistajan tuen piirissä oleviin selainversioihin.

jQuery 2.0:ssa pudottivat IE9:ä vanhemmat IE versiot vaikka Microsoft vielä niitä tuki, mutta pitivät 1.x sarjaa siinä rinnalla näitä varten.

Semmoisia huomioita kyllä, että se jQuery hoiti vain sitä Javascriptiä ja selainten eroavaisuuksien yhtenäistämistä javascriptin ja DOM käsittelyn osalta. Se ei vaikuta HTML5:n rajapinnan toimintoihin eikä CSS asioihin. Niissä mentiin heikoimman lenkin mukaan.

ELI, kerrohan nyt ihan tarkalleen mikä ei toiminut jQueryssä DOM käsittelyssä ja XHR kutsuissa? Edelleenkin lähtökohta on se, että kehitystyö tehdään heikoimmailla selaimella mitä halutaan tukea. Aivan kuten Android API:sta valitaan vanhin API versio minkä laitteita halutaan tukea.

Lue lisää

Ok kiitis. Mulle kyllä epäselvää miten sitä html5-koodia emuloidaan, debugataan, varmistetaan toimivuus eri laitteissa. Onko se mahdollista?

Siyten mulla on omassa puhelimessa muutama applikaatio joista epäilen ettei voisi tehdä html5:llä.

Spotify. Tarvitsee tausta-ajoa. Appi toimii servicenä vaikka näyttö on lukittu tai muita sovelluksia on päällä.

Sähköposti. Käyttää gcm-push-tekniikkaa ja tlimii vaikka sovellus ei olisi käynnissä.

Hp48. Tieteislaskin joka on aivan oikean laskimen näköinen. Epäilen että jos backend on netissä, lagaa ja ei toimi offlinessa.

Taskulamppu. Rautasidonnainen.

Mycelium bittilompakko. Onnistuuko avainten generointi ja pysyvä tallennus.

Whatsapp. Tarvitsee pushia ja pitää toimia servicenä.

Hsl oma matkakortti. Tarvitsee nfc:tä.

Ms office. Veikkaan että html5 ei oysty siihen tai on liian vaikea toteuttaa.

Wifi analyzer. Tarvitsee wifi radiota.

Norton family. Lasten client-versiolla pitää pystyä lukitsemaan muita sovelluksia.

Skype. Samat syyt kuin whatsappissa.

Terminal. Pitää pystyä muuttamaan usb-väylä sarjaporttiliikenteeksi. Pitää toimia offlinena.

Vpn. Kiko laitteen verkkoliikenteen pitää mennä sen kautta, myös jos vaihtaa appia.

Luetelin näitä lähes järjestyksessä omadta puhelimestani. Epäilenkö oikein että ongelmia tulisi?

Jqueryyn voin palata myöhemmin, en muista ulkoa ja olen nyt itsekin lomalla.

kokeillaanpa.täälläkin kirjoitti:

Ok kiitis. Mulle kyllä epäselvää miten sitä html5-koodia emuloidaan, debugataan, varmistetaan toimivuus eri laitteissa. Onko se mahdollista?

Siyten mulla on omassa puhelimessa muutama applikaatio joista epäilen ettei voisi tehdä html5:llä.

Spotify. Tarvitsee tausta-ajoa. Appi toimii servicenä vaikka näyttö on lukittu tai muita sovelluksia on päällä.

Sähköposti. Käyttää gcm-push-tekniikkaa ja tlimii vaikka sovellus ei olisi käynnissä.

Hp48. Tieteislaskin joka on aivan oikean laskimen näköinen. Epäilen että jos backend on netissä, lagaa ja ei toimi offlinessa.

Taskulamppu. Rautasidonnainen.

Mycelium bittilompakko. Onnistuuko avainten generointi ja pysyvä tallennus.

Whatsapp. Tarvitsee pushia ja pitää toimia servicenä.

Hsl oma matkakortti. Tarvitsee nfc:tä.

Ms office. Veikkaan että html5 ei oysty siihen tai on liian vaikea toteuttaa.

Wifi analyzer. Tarvitsee wifi radiota.

Norton family. Lasten client-versiolla pitää pystyä lukitsemaan muita sovelluksia.

Skype. Samat syyt kuin whatsappissa.

Terminal. Pitää pystyä muuttamaan usb-väylä sarjaporttiliikenteeksi. Pitää toimia offlinena.

Vpn. Kiko laitteen verkkoliikenteen pitää mennä sen kautta, myös jos vaihtaa appia.

Luetelin näitä lähes järjestyksessä omadta puhelimestani. Epäilenkö oikein että ongelmia tulisi?

Jqueryyn voin palata myöhemmin, en muista ulkoa ja olen nyt itsekin lomalla.

Lue lisää

"Ok kiitis. Mulle kyllä epäselvää miten sitä html5-koodia emuloidaan, debugataan, varmistetaan toimivuus eri laitteissa. Onko se mahdollista?"

Sitä voi ajaa selaimella, ja voi myös selaimen kehitystyökaluilla skaalata eri kokoiseksi sitä näkymään.

"Spotify. Tarvitsee tausta-ajoa. Appi toimii servicenä vaikka näyttö on lukittu tai muita sovelluksia on päällä."

HTML5:lla voi kyllä tehdä sovelluksen joka jää ikkunaan pyörimään mutta johtuu sitten kännyköistä, että resursseja säästääkseen pysäyttävät taustalla olevia sovelluksia.

Merkittävin ongelma tulee ehkä kopiosuojaustarpeista, tosin tuohonkin taitaa olla jo standardeja mutta en ole varma. Käytännössä saisi tehtyä visuaalisen puolen ja logiikan HTML5:lla mutta sinne pitäisi jäädä pieni kikkare natiivia joka soittaa äänen ja pitää salattuna niitä musiikkia. Itseasiasssa Spotifyssä luultavasti on jo näkyvät osat tehty HTML5:lla.

Cordova luultavasti ratkaisee tuosta paljon.

"Sähköposti. Käyttää gcm-push-tekniikkaa ja tlimii vaikka sovellus ei olisi käynnissä."

Sähköpostisovelluksia on tehty aikoja sitten HTML5:lla. Käytännössä nuo voi tehdä niin, että sovellus kysyy käynnissä ollessaan palvelimelta postilaatikon tilan ja päivittää paikalliseen muistiin postit, ja pollailee tuota käynnissä ollessaan esim. 10s sekunnin välein, ja lähettää mailit kun niitä kirjoittaa tai tallentaa muistiin jos yhteyttä ei ole ja lähettää sitten kun yhteys on olemassa.

Käytän itse Gmailia HTML5 sovelluksena

"Hp48. Tieteislaskin joka on aivan oikean laskimen näköinen. Epäilen että jos backend on netissä, lagaa ja ei toimi offlinessa."

Miksi laskimella tarvitsisi olla backend? Kyllä tuo menisi puhtaasti frontissa.

"Taskulamppu. Rautasidonnainen."

Cordova tarjoaa kutsun tuohon, että jos tekee asennettavan sovelluksen niin saa. Tosin minun puhelimissa on varmaan 5v ollut taskulamppu valmiina ilman erillissovelluksia.

"Mycelium bittilompakko. Onnistuuko avainten generointi ja pysyvä tallennus."

Saahan sitä käyttöliittymiä tehtyä vapaasti. Pitäisin sen arkkitehtuurin edelleen siistinä, että tallennus, haku yms. palvelimen puolella.

"Whatsapp. Tarvitsee pushia ja pitää toimia servicenä."

Ei pushissa ole ongelmaa. Se lähinnä jos pikaviestimen tarvitsee herättää käyttäjä taustalla ollessaan niin Cordovalla saa tehtyä asennettavan HTML5 sovelluksen mikä mahdollistaa sen sitten.

"Hsl oma matkakortti. Tarvitsee nfc:tä."

Ei onnistu puhtaasti HTML5:lla tällä hetkellä.

"Ms office. Veikkaan että html5 ei oysty siihen tai on liian vaikea toteuttaa."

Microsoft on tehnyt tuota jo pitkään ja on aika pitkällä https://office.live.com/

HTML5:lla käyttöliittymien teko on hyvin yksinkertaista, että se ei niinkään ole vaikeata vaan helppoa.

"Wifi analyzer. Tarvitsee wifi radiota."

Ei onnistu puhtaasti HTML5:lla, en käyttäisi HTML5:sta tähän.

"Norton family. Lasten client-versiolla pitää pystyä lukitsemaan muita sovelluksia."

Ei onnistu HTML5:lla, ja tuo nyt vaikuttaa muutenkin turvareiältä jos Norton onnistuu tuon tekemään.

"Skype. Samat syyt kuin whatsappissa."

Skype on tehty HTML5:lla suurelta osin. P2P kikkare löytyy natiivina ja voi olla optimointeja mobiiliversioissa. Desktopilla tuo on aivan selvästi hybridi. Ei tuossa varmaan muuta ole kuin se että käyttäjä pitää voida herättää pikaviestillä joten sovelluksen tekeminen Cordovalla asennettavaksi ratkoo tuon.

"Terminal. Pitää pystyä muuttamaan usb-väylä sarjaporttiliikenteeksi. Pitää toimia offlinena."

Tuo taas kuullostaa rikkinäiseltä arkkitehtuurilta. Ei käyttöliittymän tarvitse tehdä tuollaisia. Aivan helposti voi kommunikoida toisen järjestelmän kanssa webserviceiden välityksellä.

"Vpn. Kiko laitteen verkkoliikenteen pitää mennä sen kautta, myös jos vaihtaa appia. "

Tuo on rikkinäistä arkkitehtuuria myös. Kyllä yhteyden saa salattua HTTPS:llä. Jos siihen jotain VPN:ää käyttää niin jossain on jotain tehty väärin.

M-Kar kirjoitti:

"Ok kiitis. Mulle kyllä epäselvää miten sitä html5-koodia emuloidaan, debugataan, varmistetaan toimivuus eri laitteissa. Onko se mahdollista?"

Sitä voi ajaa selaimella, ja voi myös selaimen kehitystyökaluilla skaalata eri kokoiseksi sitä näkymään.

"Spotify. Tarvitsee tausta-ajoa. Appi toimii servicenä vaikka näyttö on lukittu tai muita sovelluksia on päällä."

HTML5:lla voi kyllä tehdä sovelluksen joka jää ikkunaan pyörimään mutta johtuu sitten kännyköistä, että resursseja säästääkseen pysäyttävät taustalla olevia sovelluksia.

Merkittävin ongelma tulee ehkä kopiosuojaustarpeista, tosin tuohonkin taitaa olla jo standardeja mutta en ole varma. Käytännössä saisi tehtyä visuaalisen puolen ja logiikan HTML5:lla mutta sinne pitäisi jäädä pieni kikkare natiivia joka soittaa äänen ja pitää salattuna niitä musiikkia. Itseasiasssa Spotifyssä luultavasti on jo näkyvät osat tehty HTML5:lla.

Cordova luultavasti ratkaisee tuosta paljon.

"Sähköposti. Käyttää gcm-push-tekniikkaa ja tlimii vaikka sovellus ei olisi käynnissä."

Sähköpostisovelluksia on tehty aikoja sitten HTML5:lla. Käytännössä nuo voi tehdä niin, että sovellus kysyy käynnissä ollessaan palvelimelta postilaatikon tilan ja päivittää paikalliseen muistiin postit, ja pollailee tuota käynnissä ollessaan esim. 10s sekunnin välein, ja lähettää mailit kun niitä kirjoittaa tai tallentaa muistiin jos yhteyttä ei ole ja lähettää sitten kun yhteys on olemassa.

Käytän itse Gmailia HTML5 sovelluksena

"Hp48. Tieteislaskin joka on aivan oikean laskimen näköinen. Epäilen että jos backend on netissä, lagaa ja ei toimi offlinessa."

Miksi laskimella tarvitsisi olla backend? Kyllä tuo menisi puhtaasti frontissa.

"Taskulamppu. Rautasidonnainen."

Cordova tarjoaa kutsun tuohon, että jos tekee asennettavan sovelluksen niin saa. Tosin minun puhelimissa on varmaan 5v ollut taskulamppu valmiina ilman erillissovelluksia.

"Mycelium bittilompakko. Onnistuuko avainten generointi ja pysyvä tallennus."

Saahan sitä käyttöliittymiä tehtyä vapaasti. Pitäisin sen arkkitehtuurin edelleen siistinä, että tallennus, haku yms. palvelimen puolella.

"Whatsapp. Tarvitsee pushia ja pitää toimia servicenä."

Ei pushissa ole ongelmaa. Se lähinnä jos pikaviestimen tarvitsee herättää käyttäjä taustalla ollessaan niin Cordovalla saa tehtyä asennettavan HTML5 sovelluksen mikä mahdollistaa sen sitten.

"Hsl oma matkakortti. Tarvitsee nfc:tä."

Ei onnistu puhtaasti HTML5:lla tällä hetkellä.

"Ms office. Veikkaan että html5 ei oysty siihen tai on liian vaikea toteuttaa."

Microsoft on tehnyt tuota jo pitkään ja on aika pitkällä https://office.live.com/

HTML5:lla käyttöliittymien teko on hyvin yksinkertaista, että se ei niinkään ole vaikeata vaan helppoa.

"Wifi analyzer. Tarvitsee wifi radiota."

Ei onnistu puhtaasti HTML5:lla, en käyttäisi HTML5:sta tähän.

"Norton family. Lasten client-versiolla pitää pystyä lukitsemaan muita sovelluksia."

Ei onnistu HTML5:lla, ja tuo nyt vaikuttaa muutenkin turvareiältä jos Norton onnistuu tuon tekemään.

"Skype. Samat syyt kuin whatsappissa."

Skype on tehty HTML5:lla suurelta osin. P2P kikkare löytyy natiivina ja voi olla optimointeja mobiiliversioissa. Desktopilla tuo on aivan selvästi hybridi. Ei tuossa varmaan muuta ole kuin se että käyttäjä pitää voida herättää pikaviestillä joten sovelluksen tekeminen Cordovalla asennettavaksi ratkoo tuon.

"Terminal. Pitää pystyä muuttamaan usb-väylä sarjaporttiliikenteeksi. Pitää toimia offlinena."

Tuo taas kuullostaa rikkinäiseltä arkkitehtuurilta. Ei käyttöliittymän tarvitse tehdä tuollaisia. Aivan helposti voi kommunikoida toisen järjestelmän kanssa webserviceiden välityksellä.

"Vpn. Kiko laitteen verkkoliikenteen pitää mennä sen kautta, myös jos vaihtaa appia. "

Tuo on rikkinäistä arkkitehtuuria myös. Kyllä yhteyden saa salattua HTTPS:llä. Jos siihen jotain VPN:ää käyttää niin jossain on jotain tehty väärin.

Lue lisää

Harmi kun ei ole kunnon päätettä niin on vaikea keskustella.

Vpn:ää ei käytetä salaukseen vaan toiseen cerkkoon menemiseen, esim työpaikan sisäverkkoon tai silkä voidaan haluta vaihtaa ip ja suojata anonyymisyys.

Terminalilla mennään laitteen sarjaportista sisään kaapelilla ja adapterilla.

Emailissa jatkuva pollaus syö akun.

Bitcoinien avainten kuuluu olla vain itsellä. Jos näin ei ole, rahatkin ovat jollakulla muulla.

Spotifyn katkeamaton tausta-ajo on must. Mikään muu ei ole hyväksyttävää musiikkisovelluksessa.



Norton toimii ok ilman tietoturvareikiä ja on olemassa dokumentoitu api joka vaatii laajennetut oikeudet jotka käyttäjä erikseen hyväksyy.

Laskimessa on siirtetty hp48:n flash sellaisenaan ajoon androidille. Ei tarvitse keksiä pyörää uudelleen.

Kommentteja?

kokeillaanpa.täälläkin kirjoitti:

Harmi kun ei ole kunnon päätettä niin on vaikea keskustella.

Vpn:ää ei käytetä salaukseen vaan toiseen cerkkoon menemiseen, esim työpaikan sisäverkkoon tai silkä voidaan haluta vaihtaa ip ja suojata anonyymisyys.

Terminalilla mennään laitteen sarjaportista sisään kaapelilla ja adapterilla.

Emailissa jatkuva pollaus syö akun.

Bitcoinien avainten kuuluu olla vain itsellä. Jos näin ei ole, rahatkin ovat jollakulla muulla.

Spotifyn katkeamaton tausta-ajo on must. Mikään muu ei ole hyväksyttävää musiikkisovelluksessa.



Norton toimii ok ilman tietoturvareikiä ja on olemassa dokumentoitu api joka vaatii laajennetut oikeudet jotka käyttäjä erikseen hyväksyy.

Laskimessa on siirtetty hp48:n flash sellaisenaan ajoon androidille. Ei tarvitse keksiä pyörää uudelleen.

Kommentteja?

Lue lisää

"Vpn:ää ei käytetä salaukseen vaan toiseen cerkkoon menemiseen, esim työpaikan sisäverkkoon tai silkä voidaan haluta vaihtaa ip ja suojata anonyymisyys."

Siinähän se virhe. Pitäisi olla se palvelin sisäverkon ulkopuolella ja yhteydet otetaan molemmista liittymistä siihen palvelimeen.

Siinä sellainen arkkitehtuuri asia, että yhteydet otetaan aina sisäverkosta ulos päin tai sisäverkon sisällä toimipisteessä, ei sisäverkosta sisäverkkoon eikä ulkoverkosta sisään päin. Sitten pysyy homma siistinä ja selkeänä ja ei ole ylimääräistä viritystä.

"Terminalilla mennään laitteen sarjaportista sisään kaapelilla ja adapterilla."

Sitä voi myös kommunikoida laitteen kanssa webservicellä. Mobiililaitteella se kävisi kätevästi WLAN yhteydellä. Sisäverkossa sitä vaan antaisi laitteen nimen tai IP:n ja jäisi viritykset pois. Arkkitehtuuriasia tuokin.

"Emailissa jatkuva pollaus syö akun."

Ei syö. Sehän tapahtuisi vain silloin kun postisovellus on auki. Itseasiassa riittäisi minuutin välein tapahtuva tarkistus ja se on aika olematonta akun kulutuksen kannalta

"Bitcoinien avainten kuuluu olla vain itsellä. Jos näin ei ole, rahatkin ovat jollakulla muulla."

Kyllä palvelin voi olla itsellä. Mutta, ei tuossa nyt ole ongelmaa generoida ja tallentaa niitä avaimia sovelluksen muistiin mutta joku varmistus niistä pitäisi olla ettei ole omaisuus puhelimen varassa. Sama se millä ne on lähetty ja mihin. Joka tapauksessa ei esteitä toteuttaa.

"Spotifyn katkeamaton tausta-ajo on must. Mikään muu ei ole hyväksyttävää musiikkisovelluksessa."

Cordova ratkaisee tuota.

"Norton toimii ok ilman tietoturvareikiä ja on olemassa dokumentoitu api joka vaatii laajennetut oikeudet jotka käyttäjä erikseen hyväksyy."

Se oikeuksien laajentaminen on se turvapuute. Toki käyttäjä hyväksyy sen mutta silti, Lähtökohtaisesti jokainen sovellus on itsenäinen omassa hiekkalaatikossaan eikä sitä muut sovellukset sotke. Tuollainen sovellusten whitelist/blacklist pitäisi olla käyttöjärjestelmässä/ekosysteemissä itsessään eikä jossain apupyörässä. Tämä menee vähän samaan sarjaan taskulampun kanssa.

"Laskimessa on siirtetty hp48:n flash sellaisenaan ajoon androidille. Ei tarvitse keksiä pyörää uudelleen."

Flash Player? Sehän on käytännössä hävitetty. Pitäisi uudelleenkirjoittaa sovellus ajoissa.

M-Kar kirjoitti:

"Vpn:ää ei käytetä salaukseen vaan toiseen cerkkoon menemiseen, esim työpaikan sisäverkkoon tai silkä voidaan haluta vaihtaa ip ja suojata anonyymisyys."

Siinähän se virhe. Pitäisi olla se palvelin sisäverkon ulkopuolella ja yhteydet otetaan molemmista liittymistä siihen palvelimeen.

Siinä sellainen arkkitehtuuri asia, että yhteydet otetaan aina sisäverkosta ulos päin tai sisäverkon sisällä toimipisteessä, ei sisäverkosta sisäverkkoon eikä ulkoverkosta sisään päin. Sitten pysyy homma siistinä ja selkeänä ja ei ole ylimääräistä viritystä.

"Terminalilla mennään laitteen sarjaportista sisään kaapelilla ja adapterilla."

Sitä voi myös kommunikoida laitteen kanssa webservicellä. Mobiililaitteella se kävisi kätevästi WLAN yhteydellä. Sisäverkossa sitä vaan antaisi laitteen nimen tai IP:n ja jäisi viritykset pois. Arkkitehtuuriasia tuokin.

"Emailissa jatkuva pollaus syö akun."

Ei syö. Sehän tapahtuisi vain silloin kun postisovellus on auki. Itseasiassa riittäisi minuutin välein tapahtuva tarkistus ja se on aika olematonta akun kulutuksen kannalta

"Bitcoinien avainten kuuluu olla vain itsellä. Jos näin ei ole, rahatkin ovat jollakulla muulla."

Kyllä palvelin voi olla itsellä. Mutta, ei tuossa nyt ole ongelmaa generoida ja tallentaa niitä avaimia sovelluksen muistiin mutta joku varmistus niistä pitäisi olla ettei ole omaisuus puhelimen varassa. Sama se millä ne on lähetty ja mihin. Joka tapauksessa ei esteitä toteuttaa.

"Spotifyn katkeamaton tausta-ajo on must. Mikään muu ei ole hyväksyttävää musiikkisovelluksessa."

Cordova ratkaisee tuota.

"Norton toimii ok ilman tietoturvareikiä ja on olemassa dokumentoitu api joka vaatii laajennetut oikeudet jotka käyttäjä erikseen hyväksyy."

Se oikeuksien laajentaminen on se turvapuute. Toki käyttäjä hyväksyy sen mutta silti, Lähtökohtaisesti jokainen sovellus on itsenäinen omassa hiekkalaatikossaan eikä sitä muut sovellukset sotke. Tuollainen sovellusten whitelist/blacklist pitäisi olla käyttöjärjestelmässä/ekosysteemissä itsessään eikä jossain apupyörässä. Tämä menee vähän samaan sarjaan taskulampun kanssa.

"Laskimessa on siirtetty hp48:n flash sellaisenaan ajoon androidille. Ei tarvitse keksiä pyörää uudelleen."

Flash Player? Sehän on käytännössä hävitetty. Pitäisi uudelleenkirjoittaa sovellus ajoissa.

Lue lisää

Openvpn:szä aekkitehtuurivirhe? Rohkenen epäillä. Ei se sentään noin mene. On ihan normaalia vaikka käyttää striimausoalvelua vpn:n kautta. Tai käyttää sisäverkon palveluita von:llä. Niin tekee puoli maailmaa tälläkin hetkellä

Terminasliohjelmaa käytrtään sarjaportilla laitteisiin, jotka on valmistettu siten kun ne on valmistettu. Ei siihen mitään web serviceä rakenneta, jonkun toisen tekemään laittreseen. Ja sisään mennään siis siitä fyysisestä portista, ns konsolista. Softa on sitä varten tehty.

Bitcoin-lompakosra on luonnollisesti kryptatuilla avaimilla tehty backup. Ehkä srandardin mukaiset avaimet voi generoida ilman openssl-kirjastoa, en tiedä.

Androidin arkkitehtuuri on mikä on. Jos löysit mielestäsi tietoturvapuutteen, siitä ehkä kannattaa raportoida googlelle. Tosin luulisi niiden jo miettineen asian.

Ei tietenkään flash player vaan laskimen flash-muistissa/promissa oleva softa ajetaan sellaisenaan androidissa. Kokeile. Se ei vaadi mitään oikeuksia.

kokeillaanpa.täälläkin kirjoitti:

Openvpn:szä aekkitehtuurivirhe? Rohkenen epäillä. Ei se sentään noin mene. On ihan normaalia vaikka käyttää striimausoalvelua vpn:n kautta. Tai käyttää sisäverkon palveluita von:llä. Niin tekee puoli maailmaa tälläkin hetkellä

Terminasliohjelmaa käytrtään sarjaportilla laitteisiin, jotka on valmistettu siten kun ne on valmistettu. Ei siihen mitään web serviceä rakenneta, jonkun toisen tekemään laittreseen. Ja sisään mennään siis siitä fyysisestä portista, ns konsolista. Softa on sitä varten tehty.

Bitcoin-lompakosra on luonnollisesti kryptatuilla avaimilla tehty backup. Ehkä srandardin mukaiset avaimet voi generoida ilman openssl-kirjastoa, en tiedä.

Androidin arkkitehtuuri on mikä on. Jos löysit mielestäsi tietoturvapuutteen, siitä ehkä kannattaa raportoida googlelle. Tosin luulisi niiden jo miettineen asian.

Ei tietenkään flash player vaan laskimen flash-muistissa/promissa oleva softa ajetaan sellaisenaan androidissa. Kokeile. Se ei vaadi mitään oikeuksia.

Lue lisää

Lisäys:striimauspalveluissa vpn:ää käytetään kiertamään maakohtaisia rajoituksia. Noin niinkuin esimerkiksi.

kokeillaanpa.täälläkin kirjoitti:

Openvpn:szä aekkitehtuurivirhe? Rohkenen epäillä. Ei se sentään noin mene. On ihan normaalia vaikka käyttää striimausoalvelua vpn:n kautta. Tai käyttää sisäverkon palveluita von:llä. Niin tekee puoli maailmaa tälläkin hetkellä

Terminasliohjelmaa käytrtään sarjaportilla laitteisiin, jotka on valmistettu siten kun ne on valmistettu. Ei siihen mitään web serviceä rakenneta, jonkun toisen tekemään laittreseen. Ja sisään mennään siis siitä fyysisestä portista, ns konsolista. Softa on sitä varten tehty.

Bitcoin-lompakosra on luonnollisesti kryptatuilla avaimilla tehty backup. Ehkä srandardin mukaiset avaimet voi generoida ilman openssl-kirjastoa, en tiedä.

Androidin arkkitehtuuri on mikä on. Jos löysit mielestäsi tietoturvapuutteen, siitä ehkä kannattaa raportoida googlelle. Tosin luulisi niiden jo miettineen asian.

Ei tietenkään flash player vaan laskimen flash-muistissa/promissa oleva softa ajetaan sellaisenaan androidissa. Kokeile. Se ei vaadi mitään oikeuksia.

Lue lisää

Toinen lisäys. Kyllä pollaus nimenomaan syö akun. Ja jos pollas vain kun sovellus on päällä, ei saa notifikaatiota uudesta meilistä.
https://stackoverflow.com/questions/22663778/why-and-how-is-push-notification-like-gcm-battery-efficient

kokeillaanpa.täälläkin kirjoitti:

Openvpn:szä aekkitehtuurivirhe? Rohkenen epäillä. Ei se sentään noin mene. On ihan normaalia vaikka käyttää striimausoalvelua vpn:n kautta. Tai käyttää sisäverkon palveluita von:llä. Niin tekee puoli maailmaa tälläkin hetkellä

Terminasliohjelmaa käytrtään sarjaportilla laitteisiin, jotka on valmistettu siten kun ne on valmistettu. Ei siihen mitään web serviceä rakenneta, jonkun toisen tekemään laittreseen. Ja sisään mennään siis siitä fyysisestä portista, ns konsolista. Softa on sitä varten tehty.

Bitcoin-lompakosra on luonnollisesti kryptatuilla avaimilla tehty backup. Ehkä srandardin mukaiset avaimet voi generoida ilman openssl-kirjastoa, en tiedä.

Androidin arkkitehtuuri on mikä on. Jos löysit mielestäsi tietoturvapuutteen, siitä ehkä kannattaa raportoida googlelle. Tosin luulisi niiden jo miettineen asian.

Ei tietenkään flash player vaan laskimen flash-muistissa/promissa oleva softa ajetaan sellaisenaan androidissa. Kokeile. Se ei vaadi mitään oikeuksia.

Lue lisää

"Openvpn:szä aekkitehtuurivirhe?"

Ei vaan siinä miten teidän ympäristö on rakennettu. Miksi teidän IT-ympäristö ei ole rakennettu niin, että yhteydet muodostetaan aina sisäverkosta ulos tai sisäverkon sisällä pelkästään?

"On ihan normaalia vaikka käyttää striimausoalvelua vpn:n kautta."

Ihan hyvin näkyy toimivan ilman sitä.

"Tai käyttää sisäverkon palveluita von:llä. Niin tekee puoli maailmaa tälläkin hetkellä."

Sisäverkon palvelut VPN:llä on vain sitä, että ympäristö on mätä. Palvelut joita tarvitsee jakaa useiden paikkojen kanssa, siirretään sisäverkon ulkopuolelle.

"Terminasliohjelmaa käytrtään sarjaportilla laitteisiin, jotka on valmistettu siten kun ne on valmistettu. Ei siihen mitään web serviceä rakenneta, jonkun toisen tekemään laittreseen."

Se on sitten tehty päin persettä. Ei ole mikään vika HTML5:ssa jos mokailut on tehty muualla. Voihan siihen laittaa tietysti adapterin jos siltä tuntuu.

Tämä on sitä hienoutta HTML5:ssa kun se pakottaa tekemään sovelluksia siistillä arkkitehtuurilla.

"Softa on sitä varten tehty."

Softa on suunniteltu väärin.

"Androidin arkkitehtuuri on mikä on. Jos löysit mielestäsi tietoturvapuutteen, siitä ehkä kannattaa raportoida googlelle. Tosin luulisi niiden jo miettineen asian."

Ovat ne voineet tehdä jonkun jonnin joutavan rajapinnan sitä varten, että kolmannen osapuolen turvahärpäkevalmistajat voivat tehdä kikkareita. Sitten jos siinä Nortonissa on vika niin joku voi päästä sotkemaan sovellusten toimintaa laitteessa.

"Ei tietenkään flash player vaan laskimen flash-muistissa/promissa oleva softa ajetaan sellaisenaan androidissa. Kokeile. Se ei vaadi mitään oikeuksia."

No ei tuossa edelleenkään ole mitään mitä HTML5 rajoittaa, tuon kuvauksen perusteella.

Lähinnä se rajoite että 16-20Mt muistiavaruus pitäisi riittää jos toimitaan puhtaasti offiline. Raskaammissa laskennoissa se ei riitä mutta kyllä sillä laskimen käyttöliittymän hoitaa kivasti ja laskentaprosessien halllinnan, ja ne voi sitten toimia vaikka supertietokoneessa.

"Toinen lisäys. Kyllä pollaus nimenomaan syö akun. Ja jos pollas vain kun sovellus on päällä, ei saa notifikaatiota uudesta meilistä."

Teet sellaisen oletuksen, että notifkaatio haluttaisiin uudesta meilistä. Minä en halua. Sähköposti ei ole sellainen reaaliaikainen viestintäväline kuten pikaviestin. Voi vaikka laittaa postijärjestelmän lähettämään viestin pikaviestimeen sieltä joista sen ilmoituksen haluaa.

Taitaa vissiin olla jokaisessa Android laitteessa valmiina sähköpostitoiminto ihan natiivisti jos tuollaisia tarvitsee, että voi käyttää sitä jos on tuollaisia tarpeita.

kokeillaanpa.täälläkin kirjoitti:

Toinen lisäys. Kyllä pollaus nimenomaan syö akun. Ja jos pollas vain kun sovellus on päällä, ei saa notifikaatiota uudesta meilistä.
https://stackoverflow.com/questions/22663778/why-and-how-is-push-notification-like-gcm-battery-efficient

Lue lisää

Niin ja tosiaankin jos sovellus kerran minuutissa tarkistaa onko uutta postia saapunut käynnissä ollessaan ja päivittää tiedot paikalliseen tallennukseen niin kyllä jää akun kulutus minimaaliseksi.

M-Kar kirjoitti:

Niin ja tosiaankin jos sovellus kerran minuutissa tarkistaa onko uutta postia saapunut käynnissä ollessaan ja päivittää tiedot paikalliseen tallennukseen niin kyllä jää akun kulutus minimaaliseksi.

Lue lisää

Google on estänyt lollipop-versiosta lähtien taustalla olevien sovellusten heräämisen esim. tasan minuutin välein juurikin akun kulutuksen vuoksi. Vain service voi pollata taustalla, josta näkyy ilmoitus n-barissa.

Html5:llä serviceä ei voida tehdä. Lisäksi uusimmissa android-versioissa taustasovellukset tapetaan tietyn ajan jälkeen.

Ei ole merkitystä haluatko sinä henjilökohtaisesti ilmoituksen uudesta sähköpostista. Se on normaali käytäntö ja jää siis tekemättä ilman gcm:ää.

https://developer.android.com/training/scheduling/alarms.html#set

M-Kar kirjoitti:

"Openvpn:szä aekkitehtuurivirhe?"

Ei vaan siinä miten teidän ympäristö on rakennettu. Miksi teidän IT-ympäristö ei ole rakennettu niin, että yhteydet muodostetaan aina sisäverkosta ulos tai sisäverkon sisällä pelkästään?

"On ihan normaalia vaikka käyttää striimausoalvelua vpn:n kautta."

Ihan hyvin näkyy toimivan ilman sitä.

"Tai käyttää sisäverkon palveluita von:llä. Niin tekee puoli maailmaa tälläkin hetkellä."

Sisäverkon palvelut VPN:llä on vain sitä, että ympäristö on mätä. Palvelut joita tarvitsee jakaa useiden paikkojen kanssa, siirretään sisäverkon ulkopuolelle.

"Terminasliohjelmaa käytrtään sarjaportilla laitteisiin, jotka on valmistettu siten kun ne on valmistettu. Ei siihen mitään web serviceä rakenneta, jonkun toisen tekemään laittreseen."

Se on sitten tehty päin persettä. Ei ole mikään vika HTML5:ssa jos mokailut on tehty muualla. Voihan siihen laittaa tietysti adapterin jos siltä tuntuu.

Tämä on sitä hienoutta HTML5:ssa kun se pakottaa tekemään sovelluksia siistillä arkkitehtuurilla.

"Softa on sitä varten tehty."

Softa on suunniteltu väärin.

"Androidin arkkitehtuuri on mikä on. Jos löysit mielestäsi tietoturvapuutteen, siitä ehkä kannattaa raportoida googlelle. Tosin luulisi niiden jo miettineen asian."

Ovat ne voineet tehdä jonkun jonnin joutavan rajapinnan sitä varten, että kolmannen osapuolen turvahärpäkevalmistajat voivat tehdä kikkareita. Sitten jos siinä Nortonissa on vika niin joku voi päästä sotkemaan sovellusten toimintaa laitteessa.

"Ei tietenkään flash player vaan laskimen flash-muistissa/promissa oleva softa ajetaan sellaisenaan androidissa. Kokeile. Se ei vaadi mitään oikeuksia."

No ei tuossa edelleenkään ole mitään mitä HTML5 rajoittaa, tuon kuvauksen perusteella.

Lähinnä se rajoite että 16-20Mt muistiavaruus pitäisi riittää jos toimitaan puhtaasti offiline. Raskaammissa laskennoissa se ei riitä mutta kyllä sillä laskimen käyttöliittymän hoitaa kivasti ja laskentaprosessien halllinnan, ja ne voi sitten toimia vaikka supertietokoneessa.

"Toinen lisäys. Kyllä pollaus nimenomaan syö akun. Ja jos pollas vain kun sovellus on päällä, ei saa notifikaatiota uudesta meilistä."

Teet sellaisen oletuksen, että notifkaatio haluttaisiin uudesta meilistä. Minä en halua. Sähköposti ei ole sellainen reaaliaikainen viestintäväline kuten pikaviestin. Voi vaikka laittaa postijärjestelmän lähettämään viestin pikaviestimeen sieltä joista sen ilmoituksen haluaa.

Taitaa vissiin olla jokaisessa Android laitteessa valmiina sähköpostitoiminto ihan natiivisti jos tuollaisia tarvitsee, että voi käyttää sitä jos on tuollaisia tarpeita.

Lue lisää

Ilmeisesti vpn on mätä lähes kaikissa yrityksissä. Ehkä sinun kannattaisi kertoa heille näkemyksestäsi. Toistaiseksi kuitenkin yleensä vaikkapa etätyöntekijä on se joka avaa vpn:n sisäverkkoon. Sitä kutsutaan de facto -standardiksi.

Terminaalisoftan adapterilla muutetaan usb 9-napaiseksi D-liittimeksi. Mutta kai se sitten on päin persettä kuten sanot. Toistaiseksi kuitenkaan kukaan ei ole toteuttanut sitä html5:llä. Ehkä siksi, ettei hyppysähköä ole vielä keksitty.

Android-kehittäjät tuskin pitävät nortonin käyttämää apia jonninjoutavana. samahan se on vaikka windowsissa: admin voi tehdä kaiken ja muut vähemmän. Vai onko sekin jonninjoutavaa?

Hp48 on hyvä esimerkki siitä mitä ei todellakaan voi tehdä html5:llä. Kokeile sitä ennen kuin jatkat väittämistä. Se on sen laskimen softa. Vain hullu lähtisi kehittämään tieteislaskinta scratchista.

Muutenkin: miksi sanot kaikkea vääräksi tai huonoksi, mitä et ymmärrä, osaa tai ole koskaan nähnytkään? Outoa ettei ammattilainen tiedä miten VPN toimii.

kokeillaanpa.täälläkin kirjoitti:

Google on estänyt lollipop-versiosta lähtien taustalla olevien sovellusten heräämisen esim. tasan minuutin välein juurikin akun kulutuksen vuoksi. Vain service voi pollata taustalla, josta näkyy ilmoitus n-barissa.

Html5:llä serviceä ei voida tehdä. Lisäksi uusimmissa android-versioissa taustasovellukset tapetaan tietyn ajan jälkeen.

Ei ole merkitystä haluatko sinä henjilökohtaisesti ilmoituksen uudesta sähköpostista. Se on normaali käytäntö ja jää siis tekemättä ilman gcm:ää.

https://developer.android.com/training/scheduling/alarms.html#set

Lue lisää

"Google on estänyt lollipop-versiosta lähtien taustalla olevien sovellusten heräämisen esim. tasan minuutin välein juurikin akun kulutuksen vuoksi. Vain service voi pollata taustalla, josta näkyy ilmoitus n-barissa."

Ei se sitä oikein voi estää jos käyttäjä lukee posteja ja kirjoittaa, ja se kerran minuutissa tarkistaa sillä välin onko tullut posteja. Käyttäjän pitäisi olla koskematta koko laitteeseen koska eihän siitä tule mitään, että sovellus itsekseen sammuisi kun sitä käyttää.

"Html5:llä serviceä ei voida tehdä. Lisäksi uusimmissa android-versioissa taustasovellukset tapetaan tietyn ajan jälkeen."

Totta, ja hyvä niin. Käyttöliittymän ei pidäkkään ajella taustalla asioita.

"Ilmeisesti vpn on mätä lähes kaikissa yrityksissä."

Suurin osa yrityksistä ei käytä VPN:ää ja ne joissa sitä on, sisältää jotain legacyä ja päin persettä rakennettuja sovelluksia ja infraa.

"Toistaiseksi kuitenkin yleensä vaikkapa etätyöntekijä on se joka avaa vpn:n sisäverkkoon. Sitä kutsutaan de facto -standardiksi."

No ei pidä paikkaansa. Teen itse paljon etätöitä ja en ota ikinä yhteyttä yrityksen sisäverkkoon. Ei palveluja pidetä sisäverkossa.

"Terminaalisoftan adapterilla muutetaan usb 9-napaiseksi D-liittimeksi."

Laita semmoinen adapteri, että yhteys muodostetaan vaikka HTTP:llä tai suoraan socketeilla.

"Mutta kai se sitten on päin persettä kuten sanot."

Varmasti, koska et pysty esittämään syytä miksi ei voisi käyttää normaaliin tapaan. Se sovellus mihin jotain USB yhteyksiä värkkäät toimii omituisesti.

"Ehkä siksi, ettei hyppysähköä ole vielä keksitty."

Keksitty 1800-luvulla. Sitä kutsutaan radioksi.

"samahan se on vaikka windowsissa: admin voi tehdä kaiken ja muut vähemmän. Vai onko sekin jonninjoutavaa?"

Windowsissa ollut käyttäjällä itse vapaus järjestelmää. Siihen tarvittu admin oikeuksia. Tosin hyvin tehdyt Windowssovellukset eivät missään kohtaa tarvitse admin oikeuksia.

Android laitteet oletuksena ovat lukittuja, että ei ole koko admin tiliä ja siellä on jokainen sovellus käytännössä omalla käyttäjätilillä eristettynä muista. Vähän heikennystä tuollaiset lisäoikeudet.

"Hp48 on hyvä esimerkki siitä mitä ei todellakaan voi tehdä html5:llä."

Tämäkö? https://play.google.com/store/apps/details?id=org.ab.x48

Mikä estää? Rakentelin tuossa viime viikolla pikkusovellusta HTML5:lla joka tekee olennaisesti vastaavia asioita ja toimii puhtaasti offline.

"Kokeile sitä ennen kuin jatkat väittämistä. Se on sen laskimen softa. Vain hullu lähtisi kehittämään tieteislaskinta scratchista."

Laskinhan on aika yksinkertainen sovellus ja helppo tehdä, että jos ei mieleistä löydy niin mikä ettei.

"Muutenkin: miksi sanot kaikkea vääräksi tai huonoksi, mitä et ymmärrä, osaa tai ole koskaan nähnytkään?"

Sanon kaikkea sellaista huonoksi jonka arkkitehtuuri on pielessä ja etenkin jos ei ole järjellistä syytä asialle.

Katsos kun ennen muinoin sovelluskehittäjillä jossain DOS aikoina oli kaikki vapaudet rönkkiä ja järjestelmää ja rautaa ja sovellukset olivat aika herkästi paskana. Sitä esim. syytettiin Windowsia sovellusten virheistä kun DOS sovelluksissa oli laiminlyöty muistinhallinta ja oli jotain virityksiä.

Android API, WinRT ja vastaavat rajoittavat tarkoituksella mitä voi tehdä, että saa pidettyä amatöörisovelluskehittäjät kurissa. Tarkoitushan on pitää se päätelaite puhtaasti käyttöliittymänä. HTML5 kiristää hiekkalaatikkoa vielä lisää, että se ohjaa tekemään arkkitehtuurin oikein, eli päätelaitteeseen käyttöliittymä ja edustaprosessointi, sitten se tallennus, haku yms. taustaprosessointi muualle.

Vastaavasti kun kaikki yhteydet muodostaa aina sisäverkosta ulos tai vain sisäverkon sisällä lähiyhteyksinä, jää kaikki jonninjoutava VPN yms. tunnelisäätö ja palomuurikikkailu pois. VPN virityksiä on siksi kun on tehty se ympäristö päin persettä ja on jossain toimistonnurkassa joku palvelin ruksuttamassa tarpeettomasti.

Siinähän ei ole väärää, että on paikallisia palvelimia mutta varsinainen käyttö pitäisi onnistua sisäverkosta ulos yhdistämällä. Sitä voi ne paikalliset palvelimet olla satelliittina, että ei tarvitse WAN yhteyttä kuormittaa.

"Outoa ettei ammattilainen tiedä miten VPN toimii."

Tiedän oikein hyvin. Sitten kun kertoisit miksi etätöiden tekoon tarvitsisi semmoista. Jossain on jotain pielessä jos tarvitsee.

M-Kar kirjoitti:

"Google on estänyt lollipop-versiosta lähtien taustalla olevien sovellusten heräämisen esim. tasan minuutin välein juurikin akun kulutuksen vuoksi. Vain service voi pollata taustalla, josta näkyy ilmoitus n-barissa."

Ei se sitä oikein voi estää jos käyttäjä lukee posteja ja kirjoittaa, ja se kerran minuutissa tarkistaa sillä välin onko tullut posteja. Käyttäjän pitäisi olla koskematta koko laitteeseen koska eihän siitä tule mitään, että sovellus itsekseen sammuisi kun sitä käyttää.

"Html5:llä serviceä ei voida tehdä. Lisäksi uusimmissa android-versioissa taustasovellukset tapetaan tietyn ajan jälkeen."

Totta, ja hyvä niin. Käyttöliittymän ei pidäkkään ajella taustalla asioita.

"Ilmeisesti vpn on mätä lähes kaikissa yrityksissä."

Suurin osa yrityksistä ei käytä VPN:ää ja ne joissa sitä on, sisältää jotain legacyä ja päin persettä rakennettuja sovelluksia ja infraa.

"Toistaiseksi kuitenkin yleensä vaikkapa etätyöntekijä on se joka avaa vpn:n sisäverkkoon. Sitä kutsutaan de facto -standardiksi."

No ei pidä paikkaansa. Teen itse paljon etätöitä ja en ota ikinä yhteyttä yrityksen sisäverkkoon. Ei palveluja pidetä sisäverkossa.

"Terminaalisoftan adapterilla muutetaan usb 9-napaiseksi D-liittimeksi."

Laita semmoinen adapteri, että yhteys muodostetaan vaikka HTTP:llä tai suoraan socketeilla.

"Mutta kai se sitten on päin persettä kuten sanot."

Varmasti, koska et pysty esittämään syytä miksi ei voisi käyttää normaaliin tapaan. Se sovellus mihin jotain USB yhteyksiä värkkäät toimii omituisesti.

"Ehkä siksi, ettei hyppysähköä ole vielä keksitty."

Keksitty 1800-luvulla. Sitä kutsutaan radioksi.

"samahan se on vaikka windowsissa: admin voi tehdä kaiken ja muut vähemmän. Vai onko sekin jonninjoutavaa?"

Windowsissa ollut käyttäjällä itse vapaus järjestelmää. Siihen tarvittu admin oikeuksia. Tosin hyvin tehdyt Windowssovellukset eivät missään kohtaa tarvitse admin oikeuksia.

Android laitteet oletuksena ovat lukittuja, että ei ole koko admin tiliä ja siellä on jokainen sovellus käytännössä omalla käyttäjätilillä eristettynä muista. Vähän heikennystä tuollaiset lisäoikeudet.

"Hp48 on hyvä esimerkki siitä mitä ei todellakaan voi tehdä html5:llä."

Tämäkö? https://play.google.com/store/apps/details?id=org.ab.x48

Mikä estää? Rakentelin tuossa viime viikolla pikkusovellusta HTML5:lla joka tekee olennaisesti vastaavia asioita ja toimii puhtaasti offline.

"Kokeile sitä ennen kuin jatkat väittämistä. Se on sen laskimen softa. Vain hullu lähtisi kehittämään tieteislaskinta scratchista."

Laskinhan on aika yksinkertainen sovellus ja helppo tehdä, että jos ei mieleistä löydy niin mikä ettei.

"Muutenkin: miksi sanot kaikkea vääräksi tai huonoksi, mitä et ymmärrä, osaa tai ole koskaan nähnytkään?"

Sanon kaikkea sellaista huonoksi jonka arkkitehtuuri on pielessä ja etenkin jos ei ole järjellistä syytä asialle.

Katsos kun ennen muinoin sovelluskehittäjillä jossain DOS aikoina oli kaikki vapaudet rönkkiä ja järjestelmää ja rautaa ja sovellukset olivat aika herkästi paskana. Sitä esim. syytettiin Windowsia sovellusten virheistä kun DOS sovelluksissa oli laiminlyöty muistinhallinta ja oli jotain virityksiä.

Android API, WinRT ja vastaavat rajoittavat tarkoituksella mitä voi tehdä, että saa pidettyä amatöörisovelluskehittäjät kurissa. Tarkoitushan on pitää se päätelaite puhtaasti käyttöliittymänä. HTML5 kiristää hiekkalaatikkoa vielä lisää, että se ohjaa tekemään arkkitehtuurin oikein, eli päätelaitteeseen käyttöliittymä ja edustaprosessointi, sitten se tallennus, haku yms. taustaprosessointi muualle.

Vastaavasti kun kaikki yhteydet muodostaa aina sisäverkosta ulos tai vain sisäverkon sisällä lähiyhteyksinä, jää kaikki jonninjoutava VPN yms. tunnelisäätö ja palomuurikikkailu pois. VPN virityksiä on siksi kun on tehty se ympäristö päin persettä ja on jossain toimistonnurkassa joku palvelin ruksuttamassa tarpeettomasti.

Siinähän ei ole väärää, että on paikallisia palvelimia mutta varsinainen käyttö pitäisi onnistua sisäverkosta ulos yhdistämällä. Sitä voi ne paikalliset palvelimet olla satelliittina, että ei tarvitse WAN yhteyttä kuormittaa.

"Outoa ettei ammattilainen tiedä miten VPN toimii."

Tiedän oikein hyvin. Sitten kun kertoisit miksi etätöiden tekoon tarvitsisi semmoista. Jossain on jotain pielessä jos tarvitsee.

Lue lisää

Keskustelu on sivuraiteilla. On sama mihin vpn:ää voi tarvita. Sellainen kuitenkin on ja sitä monet käyttävät. Vaikka sinun mielestäsi turhaan ja väärin, niin kuitenkin käyttävät.

Kysymys kuului, voiko mobiililaitteiseen rakentaa vpn:n html5-tekniikalla ja vastaus on ettei voi.

En tiefä ymmärsitkö tahallaan väärin, kun koetin selittää, että usb-kaapeliin pitää liittää adapteri jos sen haluaa kytkeä fyysiseen D-liittimeen. Ihan kuin voi tarvita ulkomailla sähköpistokkeeseen adapterin jos haluaa käyttää sähkölaitetta. Todennäköisesti ymmärsit tahallaan väärin, mutta en vaan keksi mitä järkeä on ymmärtää tahallaan väärin.

Hoet koko ajan että android on päätelaite ja sillä ei saa tehdä muuta. Play-kauppakin on turha. Ei tämä johda mihinkään. Sinä vain haluat inttää. Tiedät kaiken kaikesta ja kieltäydyt oppimasta uutta. Android on paljon muutakin kuin päätelaite.

Chrome OS-laite on päätelaite.

Laita se html5-laskin jonnekin näkösälle kun olet saanut sen valmiiksi. Muista että HP teki softaa aikanaan monia vuosia. Mutta äkkiähän sinä sen pyöräytät ja väärin ja päin persettä se alkuperäinen muutenkin on tehty, eikö vain.

kokeillaanpa.täälläkin kirjoitti:

Keskustelu on sivuraiteilla. On sama mihin vpn:ää voi tarvita. Sellainen kuitenkin on ja sitä monet käyttävät. Vaikka sinun mielestäsi turhaan ja väärin, niin kuitenkin käyttävät.

Kysymys kuului, voiko mobiililaitteiseen rakentaa vpn:n html5-tekniikalla ja vastaus on ettei voi.

En tiefä ymmärsitkö tahallaan väärin, kun koetin selittää, että usb-kaapeliin pitää liittää adapteri jos sen haluaa kytkeä fyysiseen D-liittimeen. Ihan kuin voi tarvita ulkomailla sähköpistokkeeseen adapterin jos haluaa käyttää sähkölaitetta. Todennäköisesti ymmärsit tahallaan väärin, mutta en vaan keksi mitä järkeä on ymmärtää tahallaan väärin.

Hoet koko ajan että android on päätelaite ja sillä ei saa tehdä muuta. Play-kauppakin on turha. Ei tämä johda mihinkään. Sinä vain haluat inttää. Tiedät kaiken kaikesta ja kieltäydyt oppimasta uutta. Android on paljon muutakin kuin päätelaite.

Chrome OS-laite on päätelaite.

Laita se html5-laskin jonnekin näkösälle kun olet saanut sen valmiiksi. Muista että HP teki softaa aikanaan monia vuosia. Mutta äkkiähän sinä sen pyöräytät ja väärin ja päin persettä se alkuperäinen muutenkin on tehty, eikö vain.

Lue lisää

"Kysymys kuului, voiko mobiililaitteiseen rakentaa vpn:n html5-tekniikalla ja vastaus on ettei voi."

Ei voi, eikä tarvitse voida.

HTML5 on sovellusten käyttöliittymiin, ja sillä voi tehdä lähes minkä tahansa sovelluksen käyttöliittymän. Voi täysin perustellusti sanoa HTML5 soveltuvan lähes kaikkeen sovelluskehitykseen.

Se ei tee HTML5:sta mitenkään huonoa jos pitäisi tehdä jotain viritelmää siksi on asioita sössitty. Eli jos ensiksi tehdään asiat päin persettä ja sitten rakennetaan jotain viritelmää sen takia, ei ole HTML5:n rajoite. Korjataan ne virheet siellä missä ne on. HTML5 sitten ratkoo sitä varsinaista ongelmaa siinä sovelluksessa. Eli MIKÄ on se etätyö mitä tehdään niin HTML5:lla tekee lähes aina sen käyttöliittymän siihen. Se VPN ei ole varsinaisesti sovellus mikä ratkoisi mitään työprosessia. Sillä vain on kikkailtu sitä kun on rakennettu ympäristö päin persettä.

"En tiefä ymmärsitkö tahallaan väärin, kun koetin selittää, että usb-kaapeliin pitää liittää adapteri jos sen haluaa kytkeä fyysiseen D-liittimeen."

Niin minä nyt tarkoitinkin sellaista adapteria mihin otetaan yhteys WLAN:lla esim. HTTP:llä tai suoraan socketeilla ja siitä adapterista sitten lähtee signaali fyysisesti mihin tarvitsee vaikka siihen D-liittimeen. Saa pidettyä kivasti vakaana sitten ja ei ole väliä millä laitteella sitä käyttää eikä tarvitse asennella mitään sovelluksia.

"Hoet koko ajan että android on päätelaite ja sillä ei saa tehdä muuta."

Siistissä arkkitehtuurissa kaikki tabletit, kännykät, läppärit, pöytäkoneet jne. millä käytetään käyttöliittymää, ovat päätelaitteita. Tuo selkeä jako että pidetään käyttöliittymä ja datan tallennus omissa IP-osoitteissa ja yhteydet aina sisäverkosta ulospäin ja lähiyhteydet sisäverkon sisällä.

Tuolla tavalla jää se kaikki nysvä ja sonta kokonaan pois, ja tuohon suuntaan isot teknologiafirmat vievät sitä tekniikkaa kaiken aikaa. Palvelinominaisuudet poistuvat päätelaitteista ja palvelimista poistuu käyttöliittymäosat ja sinne jää joku musta ruutu ja tekstiä.

Samalla tavallahan se softaprojektit jaetaan, että on käyttöliittymäosa ja palvelinosa vaikka erillisiin repoihin jopa, ja konffit vielä erikseen. Vähentää kummasti kaikkia virheitä ja nysvää kun ei ole kaikki yhtenä sekasotkuna.

Yks kaks poistuu tarpeet suurelle osalla typeryyksiä kun pidetään arkkitehtuuri kunnossa. Että korjaa virheet siinä ensiksi ja sitten tarkastele sitä onko siinä HTML5:ssa mitään todellista ongelmaa.

"Play-kauppakin on turha."

En ole sanonut tuollaista.
Ei tämä johda mihinkään. Sinä vain haluat inttää. Tiedät kaiken kaikesta ja kieltäydyt oppimasta uutta.

"Android on paljon muutakin kuin päätelaite."

Edelleenkin jos jokin asia onnistuu, ei tarkoita että niin pitäisi tehdä. Tuon pöljäilyn takia DOS sovellukset olivat usein rikki kun niitä käytti Windowsilla, tai Windows sovellukset rikki kun päivittänyt käyttöjärjestelmää, ongelmia käyttäjäoikeuksien kanssa tai on yhteensopivuusongelmia Android sovelluksilla eri laitteissa, tarpeita kummallisuuksille kuten VPN:lle.

Se HTML5 ohjelmointi tekee vaan hyvää jos ei hahmoita näitä, koska se pakottaa tekemään asioita enemmän oikein.

"Chrome OS-laite on päätelaite."

Kaikki millä ajetaan käyttöliittymiä ovat päätelaitteita.

"Jos laitteessa on konsoli siksi, että siihen pääsee kiinni hos mikään muu ei onnistu, ei siihen mitään wlaneja silloin rakenneta."

Eli siis kyseessä ei ole varsinainen sovellus millä tehdään sitä hallintaa vaan hätäratkaisuvaihtoehto. Ymmärrä mikä on sovellusohjelma: https://fi.wikipedia.org/wiki/Sovellusohjelma

HTML5 on siihen millä hallitaan sitä laitetta kuten normaalisti. En minä käy mitään USB-konsolivirityksiä käyttämään tai asentamaan yhtään mitään kun lisään pari nimeä reitittimen DNS:n vaan klikkaan auki sen hallinnan normaaliin tapaan selaimella.

"On vain hyväksyttävä että näin on, eukä kiukuteltava"

No sitten hyväksyt myös sen, että HTML5:ssa ei sitä rajoitetta ole. Jos minä hallitsen laitetta HTML5 sovelluksella helposti ilman että asentaisin mitään sovellusta tai kikkailisin jotain USB-adaptereita niin sehän todistaa sen, HTML5:lla tekee sen hallinnan ihan hyvin.

Tässä myös tärkeätä asiaa ymmärtää: https://en.wikipedia.org/wiki/Top-down_and_bottom-up_design

Eli tehdään ne järjestelmät kokonaisuudessaan top-down

Siitähän tulee kaaosta kun tehdään sekaisin. Noin hyvänä esimerkkinä miten näkyy puhdas top-down design ohjelmassa on se, että käyttöliittymien näkymässä ei ole yhtään ehtolausetta miten käyttöliittymä rakentuu. Kun design on pielessä niin näkyy kaikennäköisiä if lauseita ja sijoituslauseita sikin sokin.

Sama näkyy tuolla infrapuolella, että tehdään ensiksi päin persettä ja sitten tehdään poikkeusvirityksiä vaikka VPN:llä että saadaan ongelma ratkaistua. VPN on kuin if lause väärässä kohtaa.

"Minusta kommenttisi kuulostavat siltä, että osaat html:ää ja javaskriptiä ja kaikki pn väärin missä käytetään muita tekniikoita."

Kirjoitan melkein millä tahansa kielellä koodia. En ole missään sanonut, että jokin toinen tekniikka olisi väärin. Sovellusten käyttöliittymissä se HTML5 on kuitenkin standardi ja sitten jos tekee jotenkin eritavalla käyttöliittymää niin sille pitäisi löytyä joku peruste, että ei vaikka toistaiseksi onnistu tekemään standardilla tavalla.

Jostain syystä standardien, edes niiden ekosysteemin poropietaristandardien, noudattaminen on joillekin vaikeaa ja lopputuloksena on sitten kuraa. Itsekin mainitsit jostain yhteensopivuusongelmista Androidissa mutta sitähän se on kun on virityksiä. En usko että on mitään ihmeempää ongelmaa kun tähtää Android API 18 versiolle vaikka ja tekee sen koodin puhtaasti ilman virityksiä niin toiminee varsin hyvin nykyisillä Android laitteilla. Sitten kun käännellään laitteen prosessorille käännettyjä juttuja tai tehdään taustaservice virityksiä niin se johtaa olennaisesti laitekohtaiseen koodin ja estää päivittämistä uudemmalle käyttöjärjestelmälle.

Arkkitehtuurilliset ratkaisut ovat sitten asia erikseen. Kyllä se on ymmärretty ikuisuuden miten se arkkitehtuuri tehdään niin että on hallittavissa mutta 70-luvun lopun ja 90-luvun lopun välillä oli semmoinen ajanjakso jossa verkkoyhteydet oli heikkoja ja laitteet kalliita joten sovelluksia tehtiin valtavasti arkkitehtuurilla jossa päätelaitteella on palvelimen ominaisuuksia, eli tehtiin kaikki toiminta lokaalisti.

Sen takia siellä käyttöjärjestelmistä löytyy edelleen valtavasti ylimääräistä tekniikkaa mitä ei pitäisi olla mutta noitahan siivotaan kaiken aikaa. Vähentää valtavasti kaikkia teknisiä ongelmia mutta siinä sivussa jotkut roskaohjelmat lakkaavat toimimasta ja ne tehdään uusiksi.

Niinhän ne ohjelmat muutenkin tehdään uusiksi noin 12v välein kun uudempi tekniikka on niin paljon parempaa ja saadaan kompleksisuutta vähäisemmäksi. Vue osoittaa hyvin, että monissa tekniikoissa on paljon vielä tilaa parantaa yksinkertaisemmaksi, että eiköhän nämä nykyisetkin sovellukset mene uusiksi.

Näköjään ovatkin parantaneet tuota maps apia html5:n osalta joten sillä varmaankin jo pääsee samaan kuin naitiivilla.. joten perun sanani tämän osalta.

Siihen käyttökokemukseen vaikuttaa se komponentit framework. Reactille saa Material-ui:n ja samoin Angularille, joka tekee siitä Androidin näköisen ja tuntuisen.

HTML5 ei muuten tarkoita mitenkään "tökkimistä". Ihan sujuvasti toimivat.

Suorituskyvyssä sitten ON tällä hetkellä eroa. HTML5:lla prosessointi tapahtuu 10x natiivia heikommin kun sen laittaa laskemaan tai rouhimaan dataa päätelaitteessa. Käyttöliittymän leiska nyt piirtyy samalla tavalla mutta sitten kun laitetaan laskemaan jotain niin eroa on. Tuo vähän liittyy siihen kun sanoin, että on 4,5-6v viive desktopilla niin tuo kattaa myös sen.

Tämä nyt on tällä hetkellä, onhan siihen se WebAssembly tulossa että kääntää sitten yhtä tiiviiksi tavukoodiksi kuin natiivit. Softahan tietenkin tehdään tulevaisuutta silmällä pitäen eikä menneisyyttä, että ei tarvitse niin nopeasti olla kirjoittamassa uusiksi.

Siitä tulevaisuuteen tähtäämisestä löytyy muuten paljon hyviä esimerkkejä. Vaikka nyt se kun Java tuli 90-luvulla, niin sehän oli varsin hyvin futureproof ratkaisu sovellusten käyttöliittymille silloin piti prosessoida käyttöliittymässä asioita.

Siinä oli toki haitta: Normaalisti kun riitti 16Mt muistia niin Javasovellusten ajoa varten piti tuplata muisti että oli ainakin 32Mt. Prosessointinopeus oli myös selvästi hitaampi kuin C :lla.

Mutta, kun sillä ei ole väliä. Mooren laki kun oli voimassa, suorituskykyä tuli 100x aina 6v välein rautaan ja Java alustaa itsessään optimointiin nopeaksi, että parin vuoden välein oli aina nopeammaksi virittetty.

Tosiasiassa sillä suorituskyvyllä ei ole ollut juuri mitään merkitystä, koska käyttöliittymissä tehtävät asiat vaativat lähes aina niin vähän prosessoitavaa. Sitten kun lisää jotain reaaliaikaista sinne, kuten vaikka IDE:t värittävät tekstiä tai joku peli tms. niin alkaa tarvita lisää prosessointikykyä. Sekin tulee reaaliaikaisuudesta. Kyllähän sitä saa sinne käyttöliittymään säikeessä ajettua juttuja, että toimii responsiivisesti vaikka laskentaresurssia olisikin vähemmän.