Keresés

Új hozzászólás Aktív témák

  • #79335424

    törölt tag

    válasz vicze #180 üzenetére

    Kicsit rosszul esik, hogy az előzmények alapján nem feltételezed rólam, hogy tisztában vagyok az SDK, vagy az API fogalmával és ezért szükségét érzed annak, hogy elmagyarázd. De lapozzunk!
    Szóval, sírok egy kicsit a Google -nek és/vagy a CM -nek, ők erre belerakják és az működni fog az összes droidon, SOC -tól függetlenül. Ahha. És én élek tündibündi álomvilágban? Biztos én lennék az első dual SIM -es, aki OS szintű támogatásért sírdogál. De, tegyük fel, hogy pont az én kérésemet húzza ki a tündér a kalapból és a Google/CM megoldja nekem! Ettől automatikusan készít hozzá dokumentációt és a nyilvános SDK -ba is beteszi, hogy a Play -ről telepített alkalmazások is értsék, hogy mi az a dual SIM? Mert ha nem, akkor nem lennék vele sokkal előrébb. Most sem az a probléma, hogy a gyári alkalmazások ne tudnák kezelni, hanem az, hogy azokon kívül, szinte semmi.
    Értem én, hogy szabadon módosítható. Sőt, akár írhatnék magamnak egy saját OS -t is. Sőt, mindjárt egy telót is gyárthatnék hozzá. Akkor tényleg minden olyan lenne, amilyennek én szeretném. Csakhogy ez nem erről szól. Hanem arról, hogy ha JB -n, teljes körűen használható volt a mikroSD, akkor egy újabb verzióban se legyen úgy korlátozva, hogy azt a felhasználói (vagy haladó) menüből ne lehessen engedélyezni. Márpedig ez történt és ezt nem a gyártók találták ki. Lássuk be, hogy azért vesz vki bővíthető telót, hogy használja a plusz tárhelyet! Ha nem tudja, vszínűleg akkor sem fog saját OS -t írni, csak nem lesz elégedett. Az pedig hosszú távon vissza fog ütni.
    Egyébként a CIFS csatolásaim is errorba futnak KK -en. JB -n még működtek. Nem tudod véletlenül, hogy ez milyen változtatás miatt nem működik és azt ki követte el?

  • #79335424

    törölt tag

    válasz vicze #171 üzenetére

    Ezen jót mosolyogtam magamban. Gondolhatod, hogy nem a patinás neve miatt vettem Zopo telót. Mit is kaptam? Az MTK SOC lehetővé teszi a slotok és hálózatmódok automatizált kapcsolását. A Google nem kockáztatott. Miután a világ harmadik legnagyobb mobilgyártója (a háromból, egy nem Androidos) kínai és az ott készült telók túlnyomó része dual SIM verzió, végre, 5.1 -től méltóztatott dual SIM támogatást tenni az Androidba. Ez már KK -nél is elkésett lett volna. Automatizált hálózatmód váltás lehetőség pedig sztem most sincs. A telóm 4.4 -gyel jött ki, gyárilag nem rootolt. Ennek ellenére, minden alkalmazás korlátozás nélkül tudja használni a mikroSD -t, aminek a tiltása szintén Google korlátozás. Szóval, a merényleteket a Google követi el. A Zopo, mint gyártó, inkàbb rendbehozni próbálta. A gyártóknak az az érdekük, hogy eladjàk a telóikat. Persze, lehet korlátozgatni, tiltogatni, de hosszú távon ki fog derülni, hogy nem a farok csóvál. Az Apple is belátta, hogy nem ő mondja meg, hogy mekkora az "ideális" telefon. Egy ASUS talán meghátràl, ha a MS és a Google is úgy nyilatkozik, hogy nem örülne egy dualbootos eszköznek. De a kínaiakat ez nem èrdekli. Ha van rá piaci kereslet, akkor megcsinálják. Náluk már próbálkozott tiltással a Google és mi lett belőle? Most sietve próbálja visszacsinálni, mert fáj neki az a néhány millió eladott Iphone. A Meizu pedig jönni fog az Ubuntuval, akár tetszik a Google -nek, akár nem.

  • #79335424

    törölt tag

    válasz vicze #164 üzenetére

    Miért is? Nem kell minden lehetőséget megjeleníteni. Most is vannak olyan funkciók, amik alapértelmezetten nem láthatók. Egy korlátozást pedig meg lehet úgy is írni, hogy deaktiválható legyen. Az átlag user szàmára lehetne akár pont ugyanolyan az OS, mint most. Viszont akinek lenne rá igénye, az jobban ki tudná használni.

  • Benyuss

    tag

    válasz vicze #164 üzenetére

    Nem gondolnám.
    A Linuxot is fejlesztők, szerverek és a zsugori cégek használják. Mégsem hal ki.
    Az átlag user appleje a Windows

  • #79335424

    törölt tag

    válasz vicze #137 üzenetére

    A többiek véleményét értem, mert nem tudják, hogy mi áll ezeknek a funkcióknak a hátterében. A Te véleményed viszont meglep. Pontosan tudod, hogy semmilyen új dolgot nem kell OS részről "fejleszteni". Az intentek, activity -k, broadcast üzenetek eleve adottak, hiszen az Androidos kommunikáció alapelemei. Ráadásul nem is annyira "kocka-misztifikumok". Egy tök egyszerű, kb. 10 sorból álló adatlapról van szó. Egy fájl megnyitásához ebből 2 sort kell kitölteni. Az egyik az "intent ACTION_VIEW", a másik meg az uri, vagyis a fájl elérési útja. Hűha, ez aztán a geek művelet! Nem új funkciót szeretnék, csak beállítási felületet egy létező, alap funkcióhoz. Megzavarná az egységsugarú user -t? Ugyan már! Ez nem érv. Ezer módon meg lehetne oldani. Pl. a haladó menü elemeinek megjelenítését a fejlesztői menüben lehetne aktiválni. Egységsugarú user még a fejlesztői menüvel sem találkozik a telóban.
    Ezt az érdek dolgot sem értem. Amiről én gagyogok, az a rendszer és az alkalmazás közti kommunikáció és a szomorú az, hogy ebben nem a rendszer a rugalmasabb. A Tasker integrációhoz szùkséges kód elérhető és többszáz alkalmazásba integrálták. Ne lenne érdekük? Ezt a feature -t többnyire a fizetős verziók tartalmazzák, úgyhogy nagyon is érdekük a fejlesztőknek.
    Az FTP lehet SFTP is, de nem ez a lényeg. Hanem az, hogy egy platformfüggetlen átviteli mód. A Google alkalmazásokban tárolt jelszavak eleve titkosítottak. A többi adatot meg úgy is küldhetném, hogy kinyomtatom egy lapra, abból repcsit hajtogatnék és átdobnám a Google kerítésén. Sztem az átlag user adatai is kb. ilyen szintű biztonságot igényelnek. FTP klienshez könnyű hozzájutni. Akár egy NAS, vagy egy router is képes rá. A GDrive API viszont nem ilyen egyszerű.

    Azt sem értem, hogy miért tartod furának az almás link kezelését. A főnököm almát használ, èn meg droidot. Egyedi eset lenne? Nem hiszem. Ha a droidos térkép tudja kezelni az almás linket, az nem egy hozzáadott érték, ami a felhasználót segíti? Meg fricskának sem rossz. A user ettől még ugyanúgy a G alkalmazást hasznàlja, tehát a G. -nek is előny. Sztem jogi akadálya sincs. A szerkesztést nevezhetjük átlinkelésnek is. Mit is kellene ehhez fejleszteni? Kb. 2 sort. Nem az a jó kérdés, hogy miért kéne kezelje, hanem az, hogy miért ne.

  • #79335424

    törölt tag

    válasz vicze #122 üzenetére

    Ezzel mit akarsz mondani? Hogy nekem nem való az Android, mert esetleg másképp/hatékonyabban szeretném használni, mint a userek többsége? Nem azt várom, hogy oldja meg úgy, hogy az nekem alapból jó legyen. Csak azt, hogy ne akadályozza, hanem segítse, hogy olyanná tehessem.

    Azt gondoltam, hogy a hsz. -emből kiderül, hogy miért nem közvetlenül a Titanium -mal szinkronizálok. Azért, mert a szinkronizálás körülményei nem paraméterezhetők teljes körűen. Nem is elvárás a Titanium -mal szemben. Arra ott a Tasker, vagy az E-Robot. Csakhogy a Titanium nem Tasker plugin. Továbbá, a Titanium nem ismeri az általános fájlátviteli szabványt (FTP). Mint ahogy a Gdrive sem. Apropó. Miért is nem? A Foldersync pro viszont Tasker plugin és ismeri az FTP -t is.

    Én azt tartom jó megoldásnak, aminél akár egy alkalmazás, akár a rendszer beállításaiban alapból elérhetőek azok a lehetőségek, amik a userek többségének elegendő. De van egy "haladó beállítások" opció is azoknak, akik részletesebben szeretnének paraméterezni. Írok egy példát. Tegyük fel, hogy szeretnék vkit felhívni a névjegyzékből, lehetőleg minél költséghatékonyabban. Pl. úgy, hogy ha megvan hozzá a kellő sávszélességem, akkor VOIP -on, ha nincs, akkor pedig GSM -en történjen a hívás (de akár megfejelhetném azzal, hogy ha a hívandó, mondjuk Whatsapp kontakt, akkor azzal a klienssel indítsa a hívást). Sztem ez nem egy lehetetlen elvárás. Nem azt várom, hogy ezt a Google oldja meg. Arra ott a Tasker, E-Robot, símán lekonfigolom. De b...hatom, ha a hívásindításnál nem tudom alapértelmezetté tenni a Tasker -t, vagy az E-Robotot. Kértem helpet Tamástól (az E-Robot fejlesztője). Addig próbálkoztunk, amíg hívásindításnál megjelent a Robot, mint választható hívóalkalmazás. Kijelöltem alapértelmezettnek és többet nem kellett azzal foglalkoznom, hogy GSM, VOIP, vagy más, csak indítanom a hívást. Ez volt JB -n. Erre KK -en a Google csavart egyet az intenten és a Robot huss, megint nem választható. Kérdem én, mekkora meló lenne a Google -nek, hogy amikor megjelenik a választómenü, akkor a lista végén legyen egy "egyéb alkalmazás" opció. Rábökve megjelenne egy "intent űrlap". Kitölteném azt a pár sort (amit az alkalmazások fejlesztő publikálhatnának a help -jeikben) és ennyi. Ez olyan nagy dolog lenne?

    Ugyanez a Launcher -ben, a parancsikonoknál. Ha meg tudnám adni az uri -t, akkor az alkalmazás egyből azzal nyílna meg. Böngésző az adott weboldallal, zenelejátszó az adott számmal, stb. Tök piti dolog, a rendszer tudja, csak a Launcher nem. Most kell hozzá pl. az xShortcut.

    Változtatnak a szövegkijelölésen? Hurrá! Sztem az egész vágólap kezelés úgy szar, ahogy van. Ennél sem kéne a Google -nek, tőle szokatlant tennie. Tok - vonó fel kéne vásárolnia a Clipper+ -t és egy az egyben beépíteni, mert pontosan úgy kéne működjön alapból a vágólapkezelés.

    Sorolhatnám még hosszasan. Miért nem tudok egy Iphone -ról küldött térképlinket megnyitni G. térképben, amikor Clipper+ -ban csak a http://maps.apple.... -t kell átírni https://maps.google.... -re. Csak hozzá kéne adnia az intent filterhez és akkor nem kéne szerkesztgetni. Ennyire azért lehetne rugalmas a rendszer.
    Stb., stb.

  • hallerlaller

    addikt

    válasz vicze #119 üzenetére

    App Drawer vízszintes görgetésből függőlegesre váltott(3 oszlop, nem változtatható) ABC betűkkel csoportosítva az appokat.

    lol, és tényleg, rohadt jól néz ki a 6" kijelzőn :N bezzeg a 4,7 nexus4-en még 5 oszlop a gyári app drawer, hülyék ezek..

  • #79335424

    törölt tag

    válasz vicze #58 üzenetére

    Átfutottam. Hááát.... Szép elképzelések, de ha mögéjük nézünk, akkor sztem lesznek bőven necces pontok.
    -Jópofa a hangvezérlés API, de hogy is van ez az érintéses megerősítés?
    -Kb. az első Android óta adós a Google egy normális mentés/visszaállítással. Sztem ez sem az lesz. Mennyi tárhelyet ad hozzá? Nincs játék a telómon és így másfél GB körüli a Titanium mentésmappám (nem tömörítek). Hogy is fogja ezt naponta managelni? TiBi -vel 3verziót tároltatok, hogy ha egy fejlesztő elbaltáz egy frissítést, akkor vissza tudjak állni az előző verzióra. Hogy is lesz ez a Google megoldásában? Vajon képes lesz kezelni egy romcserét, amikor megváltozik az Android ID?
    -Tök jó, hogy korlátlan tárhelyen is tárolhatom a képeket, videókat.....lebutítva. Háááát....lehet, hogy inkább keresek másik tárhelyet nekik.
    -Viszont jön az offline G. navi, meg az HBO. De hova és milyen nyelven?
    Szóval szép terv, csak sztem szokás szerint kiderül, hogy a gyakorlatban használhatatlanok az új funkciók.

    noorbertt:
    Pontosan ez a problémám. Mint ahogy automatizáltan beviteli módot sem lehet váltani. DE! Hagy döntsem már el, hogy mekkora biztonsági kockázatot jelent számomra, hogy amikor érzékeli a BT. billentyűzetemet, akkor automatikusan átálljon rá. Az én életmódomban nulla % esélyt látok arra, hogy vki kihasználva ezt a hatalmas biztonsági rést, titokban átvegye a bevitel vezérlését. Tényleg ezért kéne szopnom a bökdöséssel, minden csatlakozásnál? Ha a lakásban, vagy az autóban a helyére (ahol van NFC matrica) teszem a telót, akkor pontosan ugyanekkora biztonsági kockázatot jelent a lezárt képernyős reagálás. Sztem ba...a meg a Google az ilyen biztonsági korlátozásait (a SElinux -szával együtt)! Nem azt mondom, hogy ne legyen ilyen. Sőt, legyen akár alapértelmezett! De kikapcsolható (mondjuk kóddal, vagy ujjlenyomattal)!!!

  • mazsi1911

    aktív tag

    válasz vicze #19 üzenetére

    Korrekt.

    És plusz egy arra, hogy Cloud based lesz az app teszteles. Az Applenek ebben fel kell zarkoznia.

Új hozzászólás Aktív témák

Hirdetés