Android 4.0-ás telefont vennék, jó nagy háttértárral

Android

Olyan alkalmazást szeretnék fejleszteni, amely sok helyet igényel a telefonon. Ami tetszik, az a Galaxy Nexus. Ellentmondó híreket olvasok róla. Egyrészt hogy lesz (van?) 32 Gb-os változata, többi hír meg arról beszél hogy elkaszálták, nem is lesz. Bővítő slotja nincsen, nem tudok beletenni SD kártyát.

Mit ajánlanátok, ha jó lenne a 32 Gb háttértár (ha van bővítő slot, az is okés).
Mikor célszerű ténylegesen vásárolni? Ha kivárom a Barcelona-ban hó végén esedékes konferenciát, az olcsósíthat az ott bemutatott újabb készülékek miatt?

  • 11414 megtekintés

( GCS v | 2012. 02. 17., p – 08:21 )

Ekkora tolongásra nem voltam felkészülve! ;)

( crown v | 2012. 02. 27., h – 13:50 )

Droid RAZR? Amugy nem tudom ertelmezni a "sok helyet igenyel a telefonon" dolgot. Ezek azert scak telefonk, nem PC-k... ha igazan sok hely kell, tervezz inkabb table-el. Szerintem.

( Zokomov | 2012. 02. 27., h – 14:14 )

A Sony Xperia S-t tudom javasolni, én is fogok egyet venni fejlesztéshez. 32 GB-os beágyazott MMC háttértárral rendelkezik.

Mindezt megtoldották egy 1280x720-as felbontású (342 ppi képfelbontású) 4.3"-os érintőkijelzővel (10 pontos multitouch), 1 GB rendszermemóriával, kétmagos 1.5 GHz-es Snapdragon S3 processzorral és Andreno 220 GPU-val.

Rootolható, és megoldható hozzá a Hierarchy Viewer működése is.

Érdemes több készüléket beszerezni, a Samsung Galaxy Y-t tudom javasolni, ami egy budget kategóriás, 320x240-es felbontású (133 ppi képfelbontású) készülék 180 MB háttértárral.

Érdemes többféle sebességű SD kártyát venni teszteléshez és ha az alkalmazás 10-20 MB felett van akkor lehetővé tenni az SD kártyán tárolást, de legalább a resourceok SD kártyán tárolását, ha ezeknek nincs más akadálya (pl. rendszeralkalmazás, live wallpaper stb.)

A nem eltávolítható háttértár is external storage.

USB mass storage módban mountoláskor az Android számára hozzáférhetetlenné válik.

A beágyazott MMC és az SD kártya egy és ugyanaz az alkalmazások számára.

A Galaxy Nexus ugyanakkor nem támogatja az USB mass storage-et, csak az MTP-t, mert nincs external storage tárterület partícionálva rajta.

Kompatibilitási okok miatt a Galaxy Nexus-on is van /sdcard könyvtár FUSE virtuális fájlrendszerként mountolva, a jogosultságokat discardolva (az SD kártyák FAT32 fájlrendszerén sincsenek jogosultságok) az internal storage-en.

( doncarlos v | 2012. 02. 27., h – 14:23 )

Esetleg a most érkező HTC One sorozatból valamelyik? A Samsung Galaxy S II is hamarosan kap ICS-t. De pl. nekem Desire HD-m van, 1 gb belső memóriával, és bővíthető is, ezen most custom 4.0.3 van. De az év folyamán érkezni fog hozzá a hivatalos ICS. Egy ilyen használt telónak kedvezőbb az ára szerintem.

Nagyon jó a sebessége! Bár nekem a 3.5-ös sense is gyors volt. Én pont a design miatt váltottam de amúgy is bejön az ICS. Nagyon szeretem a sense-t de ez a "letisztultság" megfogott. Nem tudom milyen lesz majd a hivatalos ICS a 4-es sense-el, majd csak később derül ki. AOSP-s romból most a CM9-et várom, hiányoznak azok az extrák amiket cyanogenék raknak bele a romokba.

es ebben a custom rom-ban van akkor sense? ki fejlesztette?

en akkor dontottem el hogy csak htc-m lesz androidos telobol (persze ez valtozthat), mikor 1 eve kb sima desire-re felpakoltam cm7-et es nagyon nem tetszett sense nelkul. Ment ra a leedroid helyette ami direkt htc-s custom rom sense-el.

Én a HTC One sorozatról azt olvastam, hogy már nem cserélhető az akksija, hasonlóan az iPhone-okhoz és a Motorola Razr-hőz, valamint a One sorozattal a HTC elindult a felhőszolgáltatás felé és 2 éves ingyenes DropBox account-ot ad hozzá (25 GB hely) és az SD bővítési lehetőséget hanyagolja. De majd ha tényleg kijönnek a telók és forgalmazzák őket kiderül mi igaz az egészből.

( W3ber | 2012. 02. 27., h – 18:23 )

microsdhc kártyát kapni elég olcsón ha tudja készülék támogatja nyert ügyed van.Ha alkalmazást irsz és nagy tárhely igénye van tableten elgondolkodnék pl transformer prime,infinity, asus padfone.De galaxy nexus,nexus prime,.Htc one x,one L,one xL.

( Rinyu | 2012. 02. 29., sze – 06:21 )

Valamelyik HTC Sensation? Gyárilag rootolható mostmár (htcdev.com), upgrade-elhető majd ICS-re, de már vannak hozzá romok 4.0.3-mal és sense 3.6-tal, ahogy olvastam (xda-developers.com) és bővíthető SD-vel. Jah és most fog esni az ára ugye az MWC után.

Akkor meg sem merem említeni, nekem Nexus One és Touch HD telefonjaim vannak. Előbbi 3.7"-os (3.8"-os?) kijelzővel rendelkezik. Mindkettő 800x480 felbontást jelenít meg.
Xperia Arc 4.2"-os, 854x480 kijelzője ezekhez képest nagy. :)

Lényeg, Motorola RAZR amolyan nagy téglának néz ki. Galaxy Nexus ami formára jobban tetszik. Persze az előző felelne meg a programozási céljaimnak. Kettőt egyben keresnék ha lehet, talán a HTC One X ami jó lenne.

Ma tapogattam meg.Nagyon fürge kis dög kamerája ámulatba ejtő.Akkuidővel jól áll szerintem.Teccetős sense se annyira zavaró,bár nem szeretem de kellemes.vodafone store ba megtapogathatod kivan rakva:)Erősen gondolkodom hogy vagy nekem vagy faternak lecseréljem ilyenre mobilját:)

Jogos, pontatlanul fogalmaztam. Olyan programot szeretnék fejleszteni, amely nagy adatmennyiséget is kezelHET. Ezért keresek olyan telefont amely nagy háttértárral rendelkezik. Lássam hogyan skálázódik a programom sok adatnál, hogyan lehet azokat egyáltalán elérni ekkora adatmennyiség esetén. Hogyan particionáljam az adatokat a gyors kereshetőség érdekében, akkor is ha 9-10 Gb adatról van szó.

Ettől még biztos hogy lesznek olyan felhasználók (feltételezem a többség), akik max 50-100 Mb-ot fognak benne tárolni. Erre bármilyen telefon megfelel manapság. Nekem meg a végletre is oda kell figyelnem, amikor valaki igenis, kihasználja a 9+ Gb-os adatmennyiséget.

Ezért szeretném majd valahogy particionálni az adatokat. Telefonkönyvet feltételezve vezetéknevek alapján, az ABC első öt betűje egy adatbázis, második öt betűje már egy másik DB lenne. Tudom hogy sosem lesz egyenletes eloszlás, de hiába több adatbázisban kell majd keresni, egy adott keresztnevet, azok kisebbek mint egy nagy.
Másrészt nekem biztosan nagy adatbázisom lesz, de persze akkor is max 5-6 Gb. Amihez még mindig elég egy általános telefon manapság.

Annyit írt, kell a teszt is. Azt nem, hogy ész nélkül kell csinálni.
Telefonkönyvnél maradva hogy fel lehet vinni UTF8 neveket, azok jól tárolódnak és sorbarendezésük is rendben van. Hosszú vagy egyéb értelemben vett speciális neveket is lekezel a rendszer. Észreveszi hogy két azonos nevet vinnénk fel, stb.

Többszálúság esetén hogy a különféle feldolgozások nem zavarják egymást, párhuzamosan tudnak futni és nem okoznak adatbázis korrupciót.
Sok adatnál meg hogy jól építette-e fel az ember a rendszert, tényleg gyors-e a keresés tíz bejegyzés és ötszáz ezer esetén is.
Jobbak azt is csinálják hogy a felmerült bugokra a javításuk után betesznek egy plusz teszt esetet. Sikerült-e tényleg javítani a hibát és az ne forduljon elő még egyszer.

Te valamit keversz... :)

Azt írtam, hogy a le van tesztelve 1-2-4-8G adatra, akkor abból (és az algoritmus ismeretéből) ki lehet következtetni, hogy mit fog csinálni 16 vagy 32G adattal. Erre jött az a válasz, hogy mindenképpen tesztelni kell 32G adatra ("a tesztelést semmi nem tudja helyettesíteni"). Nem teljesen értem, hogy ezek után Neked honnan és hogyan következik az, hogy milyen tesztelései módszerek vannak és honnan jött le, hogy nem kell tesztelni? :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Szerintem Te keversz valamit. :) Elhangzott hogy fel kell készüljek sok adatra is, akár 9+ Gb-ra is. Erre írtad hogy "[...] lehet extrapolálni 1-2-4-8G adatból, hogy mit fog csinálni 16 vagy 32G esetén". Ezzel egyetértek. Általánosan fogalmaztad meg, akár megfigyelési alapon végzett mérésre is utalhatnál ezzel a mondattal. Szerintem ezért fogalmazta meg zsoltt, hogy "a tesztelést semmi sem tudja helyettesíteni". Ezzel nem azt értette hogy "mindenképpen tesztelni kell 32G adatra" mint ahogy feltételezed.

Hozzászólásomban arra utaltam, a tesztelés általános és nem csak a méretre kell tesztelni. Nagy adatmennyiségnél a kivételes esetek közül több előfordulhat, pl neveket feltételezve a speciális karakterek vagy hosszú nevek is előjöhetnek. Ezekre is érdemes már külön teszteket készíteni.
Azt nem tudom honnan veszed hogy szerintem nem kell tesztelni? Lásd: "honnan jött le, hogy nem kell tesztelni?". Az ész nélküliséget tagadtam, logikusan felépített és kevés, célzatos tesztekre célozva.

"Hozzászólásomban arra utaltam, a tesztelés általános és nem csak a méretre kell tesztelni. Nagy adatmennyiségnél a kivételes esetek közül több előfordulhat, pl neveket feltételezve a speciális karakterek vagy hosszú nevek is előjöhetnek. Ezekre is érdemes már külön teszteket készíteni."

95% feletti code coverage mellett persze szükséges a specifikált use-case lefedése is, de a jelen témakör mintha arról szólna, hogy kell venned egy 16-32G telefont, mert nem tudod másképp kideríteni, hogy az alkalmazás fog futni nagyobb mennyiségű adatokkal is... pedig a szoftverfejlesztés nem feltétlen arról szól, hogy vaktában fellövünk a Holdra néhány rakétát próbaképpen, hogy kiderítsük, el tudjuk-e majd juttatni odáig, ha arra kerül a sor.

Egyébként azt sem értem igazán, hogy milyen adatokból akarsz mobiltelefonon 8G feletti adatbázist építeni, el nem tudom képzelni, hogy ezt milyen strukturált szöveges adattal lehet ezt záros időn belül megközelíteni, ha mégis, akkor egy telefon bőven gyenge lesz ahhoz, hogy ezt az adathalmazt kezelje, ha csak egy részét kezeli, akkor miért kell az egész? Ha pedig videót, képet vagy hangot is tárolsz, akkor pedig messze nem ennyi adatról van szó, mivel a metaadatokat tartalmazó adatbázis meg se fogja közelíteni azt a méretet, amiről beszélsz... mock fájlokkal gond nélkül tesztelhető.

Szóval nem értem igazán az igényt... ha csak arról van szó, hogy egy nagy telefont akarsz venni és ezt alá kell támasztani valamivel, akkor persze, szükséges dolog 32G adatbázison tesztelni... :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Kezdünk elmenni offtopic irányba. Szeretném ha az email-jeim követnének engem és frissen szinkronizálva lennének a telefonomon. Android hívő vagyok, így ez SQLite3 vagy CouchDB adatbázis használatot jelenthet, legalább a metaadatokra.
Napi sok email-t kapok (aminek egy jó része sajnos spam). Több email címem van, csak GMail-en van legalább öt (vezetéknev.keresztnév , keresztnév.vezetéknév , becenév és egyéb dologból képzett , van egy amit a nyerhet-valamit-csak-adja-meg-az-email-jét embereknek adok oda [reklámlevél gyűjtő email cím] és GApps-on kaptam egy címet a nyílt forráskódú levlisták követésére). Lényeg, az egyik GMail-es címemen 5.675 Mb levéltartalom van. Cégek, akiknek én telepítettem a szervereit, a saját becenév [at] cegnev címen érnek el. Régi időkből megmaradt a címem a c64.org -on, és a c64.rulez.org -on is. Előbbire mennek pl a Setiathome és distributed.net statisztikák, hírek. Debian Developer vagyok, elég levél érkezik a debian.hu és debian.org címeimre is. Fogalmam sincsen mennyi email címem vagy levelem van összesen.

Legjobb lenne ha nem csak a metadatokra (küldő, tárgy, érkezési időpont) lehetne keresni, hanem levéltartalomra is. Addig még okés hogy magukat a leveleket egy-egy Maildir/ -ben tartanám (ezek mérete lesz nagy, nem az adatbázisé), de a tartalmuk indexelése még akkor is sok, ha szótövekre bontva teszem adatbázisba a szavakat. Értsd, ablak, ablakos, ablakok szavak ugyanúgy ablak-ként kerülnének be a hivatkozás listába. Keresés, mondjuk "ablakos operációs rendszer" ugyanúgy szótövekre vágást használna. Megnézné hogy mely állományokban van meg az ablak szó, azokat felolvasná és csak azokat adná vissza amelyekben tényleg az ablakos szó szerepel.
Előny, hogy kisebb és kompaktabb lenne az adatbázis a szótövek miatt. Ára az, több IO szükséges keresésnél. Mérlegelve azt, kisebb adatbázisban kevesebb IO-val lehet keresni, ellensúlyozná azt, pár állományt fel kell olvasni.
Lehet vitázni hogy többmagos CPU-k és FLASH tárolók gyorsan elvégeznék a műveleteket. Ettől még az előbbi módon optimalizálnám az adatbázis méretét.

Vedd észre, nem azért vennék 32 Gb tárolóval ellátott telcsit, mert annyira akarom tesztelni. Arra elég lesz az 5.5 Gb nagyságú postafiókom. Ha azon jól vizsgázik a keresés, akkor nagy gond már nem lehet. Hely inkább arra kellene, járulékos adatok (levelek adatait tároló adatbázis) is elférjen, nameg a többi postafiókom és azok adatai is. Kisebbek, de több olyan van, amelyek gigabyte felettiek.
Szintén az optimalizáció kedvéért, minden postafiók önálló adatbázissal rendelkezne.

Illetve vettem egy használt Galaxy S2-őt, így a telefonvásárlás már megoldódott. De ezt már beírtam régebben.

Tudok az FTS3 és FTS4 létezéséről. Régebben valami gond volt ha azzal fordítottad a binárist (Debian-ban az én feladatom az SQLite3 karbantartása).
Illetve ha keresztplatformos megoldást szeretnék (windózer mobile-ra, szifonra is) akkor saját magam kell megoldanom a kérdést. Márcsak azért is, hogy rugalmasabb legyen a rendszer: kezelje a ragozást. alma-almák-almás-almákkal mind ugyanarra a szóra legyen leképezve az adatbázisban. Könnyebb lenne a felhasználónak is, ha csak felmásolhatná a maildir-ben lévő leveleit (pl rsync-el) és kész. Program majd kibányászná belőle az adatokat, nem kellene a maildir-t adatbázisban tartani.
Plusz legjobb lenne desktop klienssel együtt kezelni a leveleket. Bármelyik letölthetné az új leveleket IMAP4-ről, majd valamely felhős adatbázissal (CouchDB vagy MongoDB) megbeszélnék hogy melyikük tud új levélről.

( uid_18079 | 2012. 05. 12., szo – 16:18 )

Készítsdd el az appot, teszteld simulatorban sok adatra, és utána vegyél telefont.