Hirdetés

Keresés

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

  • vz12

    tag

    Nemrég kezdtem androidos programozással foglalkozni, remek szórakozás. :) PC-n az Android 2.1 - 2.3 -as emulátorokkal tesztelve tökéletes minden, ahogy a 2.3-as kütyün is. Ma gondoltam egyet és indítottam egy 4.0.3-as emulátort is, de azon elhasalt a programom valami ilyesmi szöveggel: "Unfortunately <app> has stopped.". Pontosabban elindulni látszott, de kb. 1 mp után kidobta ezt a szöveget és kilépett. Az <app> persze az én progim neve volt.
    Kérdés: Van-e itt valaki aki találkozott már ezzel a problémával, és meg is oldotta? Összefüggésben lehet-e a probléma azzal hogy a projektet anno 2.1-ben hoztam létre, és esetleg a 4-es nem teljesen kompatibilis visszamenőleg?

    Egyébként Eclipse 3.7.1, a gépben 2 GB RAM van.

    [ Szerkesztve ]

  • vz12

    tag

    válasz SektorFlop #47 üzenetére

    Köszi az ötletet, reményteljesnek látszik. Leghamarabb csak ma este tudok a dologgal foglalkozni, majd megírom a fejleményeket.

  • vz12

    tag

    válasz vz12 #48 üzenetére

    No, kipróbáltam az ötletedet, nem változott semmi. :N
    (pedig utána még a minSdkVersion-t is is feltettem "15"-re)

    Ezután egy "régi" gyakorló programomat is ráküldtem a 4.0.3-ra, ami alig volt bonyolultabb a "Hello, World"-nél, az csont nélkül ment, targetSdkVersion nélkül is. :U
    Ekkor kezdtem gyanakodni a Splash Screen-re, amivel indult a program, és tényleg ott volt a bibi !!! Amikor kiszedtem a Splash-t, akkor már nem akadt ki. Igaz ugyan hogy néhány mp-ig csak fekete képernyőt láttam, miközben inicializálódtak az adatok (sok adat, ezért csináltam a Splash-t), de aztán elindult rendesen, ezzel a hiba behatárolódott.
    Kicsit kísérleteztem a targetSdkVersion-nel, kis stílusbeli (megjelenési) különbség volt bizonyos elemeknél a megszokotthoz képest (pl. a képernyő teteje, a scrollbar, a hardveres Beállítások gomb után megjelenő menü kinézete, rádió-gombok és textboxok kinézete, ilyenek), ha viszont kiszedem akkor pontosan úgy nézett ki mint addig, tehát kiszedtem. :)
    Ezután a neten már gyorsan megtaláltam pl. ezt, ahol leírják hogy 4.0-tól kezdve a thread-ek kezelésében a stop() kerülendő. Tudni kell, hogy a Splash-ek külön thread-ben szoktak lenni, nálam is így van. Visszatettem a Splash Screen-t, a stop()-ot lecseréltem finish()-re, és megy, nem dob ki. Pici probléma még van vele, nevezetesen hogy a splash képernyő éppen csak felvillan, majd az adataim inicializálása alatt csak a fekete képernyőt látom a "rendes" képernyő megjelenéséig, de ezt majd valahogy megoldom. Minden bizonnyal összefüggésben van a 4.0 megváltozott thread-kezelésével, mert 2.x alatt az inicializálás során végig kint van a splash.

    Tehát a minSdkVersion maradt "7", a targetSdkVersion nincs beállítva (vagyis az is "7"), és tulajdonképpen megy rendesen.

    Azért írtam le ilyen részletesen, hogy akinek ilyen problémája van, az esetleg tudjon ötletet meríteni belőle. ;)

  • vz12

    tag

    válasz vz12 #51 üzenetére

    Úgy tűnik, hogy a Splash Screen problémám sokat javult. :)
    A sima egyszerű Thread helyett átírtam a splasht AsyncTask-osra egy netes példa alapján, ahol van onPreExecute, doInBackground, onPostExecute. Az onPostExecute-ba tettem a stop() helyett a finish()-t (meg persze a main activity elindítását), és tul.képpen oké minden. 2.x alatt rendesen megy emulátoron és a kütyün is, ahogy eddig, tehát nem sikerült elrontani. 4.0.3-ban csak emulátoron tudtam nézni (mert ilyen kütyüm nincs), ott egy jó darabig stabilan kint van a konstans tartalmú splash képernyő, a végén egy kis szabálytalan villogást ugyan megenged magának, de remélem hogy ez csak az emulátoron van így ..., mindenesetre sokkal jobb a helyzet mint eddig, a problémát megoldottnak tekintem, a kompatibilitásom megvan 2.1 és 4.0.3 között.

    [ Szerkesztve ]

  • vz12

    tag

    Sziasztok!

    Ismét lenne egy kérdésem.
    Van egy teljes szélességű /fill-parent-es/ TableLayout-om 1 sorral, benne 5 oszlop, minden elem TextView, ezeket 2dp "left_margin" választja el egymástól. Az oszlopokban időnként változnak az adatok, de persze elférnek. A stretchColumns és shrinkColumns be van állítva és remekül működik a (nem nagy mértékben) változó adatszélesség követése. Viszont a táblázatnak van háttérszíne és így nagyon feltűnő a fekete háttéren, hogy van amikor teljesen kiér a táblázat a képernyő jobb szélére, van amikor viszont 1 vagy 2 pixel-lel (dp-vel) beljebb van, azaz nem éri el a képernyő jobb szélét. Ez így van álló és fekvő képernyőn is, valamint az emulátoron és a telefonomon is,ezen belül emulátoron 2.1 - 4.0.3-ig mindenhol.
    Az rendben van hogy az oszlopok belső határai mozognak, de miért mozog a táblázat jobb széle? A fill_parent miatt nem kellene mozognia, szerintem. Esetleg valaki tudna erre megoldást? Tehát ne izegjen-mozogjon a táblázat jobb széle. Egyébként kísérletezgettem már sok mindennel, de elfogytak az ötleteim.

    [ Szerkesztve ]

  • vz12

    tag

    válasz SektorFlop #92 üzenetére

    Nem tudom hogy mi az a "setIndicator", de pl. "setText"-ben, vagy "Toast"-ban nekem így működni szokott:

    "Havi\negyenleg"

  • vz12

    tag

    válasz fatal` #94 üzenetére

    Köszi a megerősítést, én is úgy gondoltam hogy ennek kb. minden string esetén működnie kellene, ezt próbáltam jelezni.
    Persze ha nincs hely probléma, illetve ha pl. a "lines", "maxLines" nem korlátozza.

  • vz12

    tag

    válasz SektorFlop #136 üzenetére

    Én már csináltam ilyet. A position paraméter alapján behozod az aktuális adatot, amivel a getView éppen foglalkozik, majd ezután ezt az adatot építed be a feltételbe, nem magát a position-t.
    Ha pl. egy kétdimenziós tömb 1. oszlopát jeleníted meg, akkor valahogy így kell ennek kinézni:

    mydata=tomb.get(position).get(0);
    if (mydata==1) ...

    A relációs adatbázis mutat némi hasonlóságot a 2 dimenziós tömbbel, ezért hoztam ezt a példát, de a dolgot konkretizálni majd Neked kell. Ha szűrés van az adatbázison, akkor a helyzet persze bonyolultabb.

  • vz12

    tag

    válasz SektorFlop #139 üzenetére

    Nos, én a fő-fő osztályomban definiált, és gyakorlatilag az egész (nem túl nagy) programomban globálisan (belülről) elérhető tömbökben tároltam az adatokat, így a getView-ban is elérhető volt, nem paraméterből jött be neki. Én egy gridView alá "toltam be" ezt a tömböt, amelyet bizonyos metódusok írtak, bizonyos metódusok olvastak, a grid frissítése meg volt oldva, illetve hát ugye a getView pontosan ezt végezte a módosítások után. Tehát a getView futásakor az adatok már aktuálisak voltak, és mivel "globálisak", ezért lekérdezhetők, felhasználhatók feltételek megfogalmazásához. Szerintem egy kurzort is lehet így használni, de ezt csak gondolom, nem tudom. Lehet hogy kifogásolható a módszerem, de nekem bevált és tetszik, nem látom a hátrányát.

    Az említett másik módszer is biztosan járható, én magamnak ezt találtam ki erre a problémára.

  • vz12

    tag

    Sziasztok!
    Már több napja próbálok megoldást találni egy problémámra, de nem sikerül. Sok ötletet kipróbáltam és nem vagyok előrébb, ezért bátorkodom itt feltenni a kérdést, hátha van itt egy widget guru.

    Tehát van egy widget-em, amelynek csupán naponta kell adatfrissítést végeznie, amúgy egy napig állandó a tartalma. Normális helyzetben működik is, éjfél után szépen frissít automatikusan (egy AlarmManagert állítottam éjfélre). Azonban ha megváltozik a rendszerdátum (pl. a felhasználó átállítja), akkor is frissíteni kellene. Ez meg is történik (ráadásul elég gyorsan), ha ELŐRE állítom a dátumot, viszont nem történik meg, ha HÁTRAFELÉ állítom a dátumot. Ez számomra érthetetlen. TIME_SET, DATE_CHANGED eseményekre természetesen fel van készítve, ezért is működik előrefelé, de kísérleteztem másféle eseményekkel is. Ezen események neve is oda-vissza működést sejtet, semmi nem utal az egyirányúságra. Ez egy Android feature bug lenne? :F Én hajlok arra hogy ez nem így van, hanem csak én nem tudok valamit, de mit? Egyformán így működik az emulátorban, fizikai telefonon, tableten, Android 2.3-on és 4.1-en is. Persze aksit zabáló sűrű Timer pufogtatást nem szeretnék alkalmazni, az nem pálya ...

    Amúgy a Google-val keresgélve úgy látom hogy nem vagyok egyedül a problémámmal, de a válaszoknak látszó reagálásokban semmi új nincs, a dátumot hátrafelé állítva nálam nem működnek, és a kérdező sem írta ezt vissza.
    Ha valaki sikeresen túljutott egy ilyen probléma megoldásán, megköszönném a segítségét.

    Előre is köszi. vz12

    [ Szerkesztve ]

  • vz12

    tag

    válasz Karma #2324 üzenetére

    Köszi a választ. :R
    Nincs ügyfél, ingyenes marketes program, de ezt a dolgot csak nemrég vettem észre, és azt gondoltam hogy kijavítom ... Nem túl szép dolog hogy egy ismert régi hiba még mindig benne van, ráadásul nem hinném hogy nehéz lenne kijavítani, de ez van.
    Akkor "leszállok" a problémáról, végülis normális használat során úgysem jön elő, én legalábbis nem szoktam állítgatni a dátumot, mutassa csak a valóságot.

  • vz12

    tag

    Sziasztok!
    Magyar ékezetes szavak ékezetekre "nem érzékeny" keresésére szeretnék írni egy gyors, hatékony, ezért nem túl bonyolult algoritmust magamnak. A "rendes" ékezetekkel (pl."á", "Á", "é", "É", stb.) nincs is bajom, ezektől már függetleníteni tudtam magam, azonban az "egzotikus", tehát pl. a fordított, karikás, hullámos, vagy hosszú kettős ékezetek gondot okoznak még.
    Például ha a telefonos névjegyzékben keresem a "Jenő"-t, nos azt jó eséllyel NEM találom meg, mert az "ő" betű a kereső sztringben ugye egyféle módon van leírva, a felhasználók pedig a kettős ékezeteket telefontól és szokástól függően hol így írják, hol úgy. Egyébként akkor is gond van, ha "ő"-vel van írva a "Jenő" a névjegyzékben, mert valószínűleg ott más a kódja mint a kereső sztringben (ezt csak a hosszú kettős ékezetes betűknél, tehát az "ő" és "ű" betűknél tapasztaltam). El tudom képzelni, hogy az "egy vesszős" ékezetek esetén is "kreatívkodik" valaki, pl. fordított irányú ékezettel, vagy karikás ékezettel írja az "á" betűt, mert nincs "rendes "á" betűje. Ha a tel.könyvben valaki nem ír ékezeteket (pl. "Jeno"), és én mégis "Jenő"-t, vagy "jeno"-t, vagy "JENO"-t keresek, akkor már megtalálom. :)

    Előre is köszi, ha valakinek van ötlete ennek az érdekes problémának a megoldására.

    Valószínűleg "tökéletes" megoldás nincs, de egy "minél jobb" módszert azért megpróbálnék megalkotni, ami jobb mint az "így jártál" ...

    [ Szerkesztve ]

  • vz12

    tag

    válasz Karma #2358 üzenetére

    Köszi, megnézem.
    Nos, igazából Android "2.2 és felette" van megcélozva, tehát "Level 8", de a 9-es nincs messze ettől, azaz lehet hogy szigorítok.
    Vagy esetleg egy verzió vizsgálattal a "Level 9+"-ra adom a jobb megoldást.

  • vz12

    tag

    válasz Karma #2358 üzenetére

    A "Map"-os módszerből kiindulva csináltam egy hasonló megoldást, az ékezetes karakterek listáját teljesebbé tettem egy unicode-os karakter táblázat alapján, és a függvénybe is belenyúltam egy kicsit.
    Remekül működik, a sebességre sincs panaszom, és Android verzió független. :)

    De igazából el szerettem volna kerülni az egyenkénti karakter megadásokat, meg persze nem is biztos hogy csupán az ékezetes karakterekkel trükközik valaki, ezért a "Normalizer"-es megoldás nagyon tetszett volna, de nálam azt nem ismeri fel az Eclipse. Én még 3.7-es Eclipse-t és Java6-ot használok, lehet hogy ez a probléma, de végülis beérem a fenti "Map"-os módszerrel is, az Android 2.2 miatt úgyis benne kellett volna hagyni azt is, így most csak az van benne. Aki meg a nem ékezetes betűkkel is szórakozik, az vessen magára.

    Köszi az útmutatást, a kulcsszó a megoldáshoz a "unicode" volt.
    A régi megoldásom hasonló volt a "Map"-oshoz, csak nem unicode alapon.

    [ Szerkesztve ]

  • vz12

    tag

    válasz Karma #2364 üzenetére

    Értem, köszi a válaszokat.
    Valóban 8-as a minSdkVersion és a targetSdkVersion is, így 2.2-es AVD-vel szoktam tesztelni. Akkor majd (ma este) nagyobbra állítom a "target"-et, és meglátjuk hogy mi lesz.
    Azt találtam ki, hogy nem is az "API level"-től fogom függővé tenni a 2 változat közötti választást, hanem try-ban megpróbálom a Normalizer-es változatot, a catch-be pedig beleteszem a Map-osat, így talán rugalmasabb, kevésbé kötött a szelekció.
    Ha a Normalizer-es változat (ami többet tud mint ami nekem kell) sebessége megfelelő lesz, akkor benne is hagyom, ha lassú akkor marad csak a Map-os.

    Update: OK, majd ránézek a "project.properties"-re is.

    [ Szerkesztve ]

  • vz12

    tag

    válasz Karma #2368 üzenetére

    Eddig nemigen csináltam hálózati kommunikációt, de azért köszi.
    Két kütyün mindig letesztelem "élesben" is amit csinálok, az egyik Android 2.3-as telefon, a másik 4.1-es tablet, gondolom hogy kiderülne ha baj van.

  • vz12

    tag

    válasz vz12 #2367 üzenetére

    Siker! :)
    Először a manifest fájlt babráltam (minSdkVersion="9", targetSdkVersion="9", külön és együtt is), ekkor az Eclipse a .java fájlomat (az összes import-ot) kidekorálta piros X-ekkel, azaz még a Normalizer nélkül is hiba.
    Visszatettem "8"-ra mindent, majd a Project/Properties-ben a "Build Target"-et az addigi Android 2.2-ről átállítottam 2.3-ra, ekkor nem volt hiba, beírtam a Normalizer-es kódot, és az Eclipse fel is ajánlotta a Normalizer importját, azaz minden rendben. Ráadásul még működött is, a korábbi 2.2-es AVD-vel is ment a Normalizer-es kód (!!!) Persze - gondolom - át lett verve szegény szimulátor a "Build Target" átállításával, hiába 2.2-es a szimulátor, ha 2.3-as "motor" lett alátöltve.

    Viszont így nem tudom hogy "igazi" 2.2-es fizikai eszközön mi történik, erre kíváncsi lennék.

    Beletettem try-ba a Normalizer-es kódot, catch-be a Map-es kódot, a debugolás szerint az így beállított környezetben a 2.2-es szimulátorban hibátlanul lefutott a Normalizer-es kód, és nem is ment át a catch-be. (Egyébként amikor beletettem a try-ba egy nullával osztást, akkor átment, és szépen lefutott a catch-es rész, az eredmény ugyanaz lett!)
    A két módszer sebességre és végeredményre is megegyezik a szimulátorban is, meg a 2.3-as telefonomon is. Sajnos nekem nincs Android 2.2-vel fizikai eszközöm, így nem vagyok benne biztos, hogy ott a catch-ben landolna a folyamat, elképzelhetőnek tartom, hogy ott kiakad a program.
    Mivel sebességben egyforma a két módszer, a nem ékezetes betűk meg nem igazán érdekelnek, így talán biztonságosabb ha csak a Map-es módszert hagyom benne, a Normalizer-est meg megjegyzem magamnak a későbbiekre nézve, de itt kiszedem. Persze hagyhatnám is a 2.2-t a csudába, de egyelőre még inkább megtartanám.
    Erről mi a véleményetek?

    [ Szerkesztve ]

  • vz12

    tag

    válasz thon73 #2373 üzenetére

    Az előbb megszámoltam, 48 nagybetű + 47 kisbetű = 95 db ékezetes betű van a Map-omban, és nekem az indexem a unicode-os karakter, '\uxxxx' formában, mert amúgy az Eclipse beszólt, hogy a .java fájlomban "illegális" karakter található.

    Nekem kb. 2 éves installációm van, és bevált dolgokon nem változtatok ... ;)
    Persze ha valami gond lenne, akkor nyilván rákényszerülnék, de egyrészt tesztelem a szimulátor(ok)on túl 2-3 kütyün, 2-es és 4-es androidon is, másrészt szerintem nagyon extra dolgokat nem használok, harmadrészt van már pár száz letöltésem a Play-en szerte a nagyvilágból mindenféle eszközre, de senki és semmi nem jelzett semmiféle problémát még.

    [ Szerkesztve ]

  • vz12

    tag

    válasz WonderCSabo #2376 üzenetére

    Újra megcsináltam "nulláról".
    1- Bezártam az Eclipse-t, meg a szimulátort is.
    2. Eclipse elindítva, AVD 2.2 kézzel (csak hogy tuti legyen) elindítva.
    3. Manifest fáljba belenéztem, mindkét sdkVersion "8" -ra volt állítva, nem bántottam.
    4. Project/Properties/Android/"Project Build Target" ellenőrizve, Android 2.3.3-ra volt állítva, nem bántottam.
    5. A .java fájlba belenéztem, az "import java.text.Normalizer;" benne van, a "tuti" miatt a Map-os részt kiszedtem, a Normalizer-es kód futását fixre beállítottam.
    6. Program elindít, 2.2-es AVD-re áttöltés, hibátlanul lefutás, ékezetes név megtalálva, semmiféle exception nem történt.

    Nekem is furcsa (volt, és kicsit most is az), de a saját szememmel látom.
    Ezért is kérdeztem, hogy vajon ha nem szimulátorban menne, akkor mi lenne a helyzet?
    Nem tudom hogy örüljek-e, most hajlok arra, hogy maradok fixen a Map-es módszernél, úgy nem várható semmilyen negatív meglepetés.

  • vz12

    tag

    válasz WonderCSabo #2378 üzenetére

    Emulátor, igazad van, köszi. :K
    Most már sokáig nem halogatom a döntést, szerintem maradok a verziófüggetlen (és számomra elegendő) Map-es megoldásnál, egyrészt dolgoztam vele eleget hogy ne hagyjam ki, másrészt egyelőre a 2.2-es Androidos táborról sem akarok még lemondani, és felesleges bizonytalanságot vagy kockázatot sem szeretnék generálni. Azt a 2 sor Normalizer-es kódot emlékül benne hagyom, de persze csak kommentben.

    [ Szerkesztve ]

  • vz12

    tag

    válasz WonderCSabo #2380 üzenetére

    Mármint érdemes.
    Sejtettem, a Play-en a statisztikánál akár verzióra lebontva is láthatom a letöltési darabszámokat, ebből tudom hogy ha nem is sok, de néhány 2.2-es letöltésem azért van (az arány hasonló mint a Te grafikonodon), én pedig nem akarom elvenni az örömet tőlük, hogy használják a remek kis programocskám továbbfejlesztett változatát. :) Mint már említettem, a gyakorlatban nem életszerű hogy valaki pl. farkincás C, vagy hasonló elvetemült karaktereket írna be a névjegyzékbe (az ilyen meg is érdemli hogy ne találja meg), a "rendes" és "rendetlen" magyar ékezetes betűk tekintetében pedig a 2 megoldás teljesen egyforma, így semmi hátrányát nem érzem a Map-es módszernek, sőt még talán túlzásba is vittem a "megoldott" karakterek számát. Persze nem erről a módszerről álmodtam, de ez van.
    Egyébként csak azért nem megyek "lejjebb" a verzióban, mert úgy tudom hogy widget-ek csak a 2.2+ verziókban vannak, tehát a 2.2 az alsó határ.

    [ Szerkesztve ]

  • vz12

    tag

    válasz vz12 #2381 üzenetére

    Ja, azt talán még nem említettem, hogy ezt a keresést magyar nyelvű (1 nyelvű) alkalmazásban szeretném használni, így tehát az idegen karakterek kezelése ezért nem feladat.

  • vz12

    tag

    válasz sztanozs #2385 üzenetére

    Értem, de jelen esetben nem csak a nyelv, hanem a "téma" is magyar, a külföldi ismerősök érdektelenek, sőt talán még hiba is ha a program esetleg megtalálja őket ... ;) Amúgy az én progimba a felhasználónak nem kell beírni semmit, a telefonkönyvbe lehet, viszont az nem az én programom.
    De köszi a felvetést, ha esetleg majd egy másik alkalmazásomban ez a dolog felmerül, akkor majd ezt a kérdést ismét megvizsgálom, és ha úgy adódik, akkor az minimum Android 2.3-as lesz, és a Normalizer-t fogom használni.

    [ Szerkesztve ]

  • vz12

    tag

    válasz Superhun #2444 üzenetére

    Egy kis gyakorlati tapasztalat:
    A .keystore fájlod készítésekor meg kell adni egy jelszót, és hiába másolja majd le valaki ezt a .keystore fájlt, a jelszó hiányában nem tudja majd használni. Arra majd vigyázz, hogy ha a jelszót esetleg elfelejted, akkor bizony Te sem tudod majd (újra)használni. Ha mondjuk egy év múlva továbbfejleszted az APK-t, akkor pontosan ugyanazzal a .keystore fájllal aláírva kell majd feltölteni a Play-be ahhoz hogy ugyanannak az alkalmazásnak (az új verziójának) látszódjon, ehhez viszont tudni kell a jelszót, amit először adtál neki, egyébként ez legalább 6 karakter hosszú (és kis/nagybetű érzékeny), legalábbis az amit az Eclipse gyárt.
    Ha elfelejted a jelszót, és másik .keystore fájlt raksz APK Release verziójához, akkor azt bizony másik alkalmazásnak fogja tekinteni a Play, és a korábbi letöltők nem fognak értesülni róla, hogy a programodnak új verziója van, "kézzel" kell majd megkeresni és lecserélni a régit.

    Nekem ezt nem mondta senki, akkor szembesültem vele, amikor másfél hónap után update-eltem. Nos, kb. 1 napig gondolkodtam és próbáltam kitalálni hogy mi volt a jelszavam ..., végül sikerült. :)

    [ Szerkesztve ]

  • vz12

    tag

    válasz Zé777 #2742 üzenetére

    Hello!

    Bevezetésnek esetleg olvasd el ezt a korábbi hozzászólásomat.
    Kicsit részletezve elmondom, hogy én is több (3-4) programmal próbálkoztam, a választásom végül az "AndroidKeystoreBrute_v1.05.jar" programra esett, nekem ez a program meg a közben kicsit javuló memóriám hozta meg a sikert. Ha semmit nem tudsz a jelszavadról, azaz a "normál" brute force az nagyon durva időigényű, szerintem felejtős. Nagy segítség, ha mondjuk a jelszavad hosszára emlékszel, vagy ha tudod hogy pl. csupa kisbetűvel, vagy nagybetűvel írtad. Segítségnek tűnik, ha emlékszel a jelszavad elejére, de brute force esetén szerintem ez nem nagy segítség ha utána biztosan van még 3-4 karakter, mert a keresési idő exponenciálisan nő a jelszó hosszával, és ugye a vége ismeretlen, tehát a legtöbb időt jelentő keresést nem lehet megspórolni.
    Sajnos én nem emlékeztem a jelszavam hosszára, és biztos voltam benne hogy kis- és nagybetű is van benne, így nem tudtam időt spórolni, és feleslegesen vesztegettem az időt a rövidebb jelszavak keresésével. Nem árt tudni, hogy az Eclipse által generált jelszó legrövidebb hossza 6 karakter, én 4-gyel kezdtem el, tehát raboltam a saját időmet.
    Sokat keresgéltem a neten, hátha van egy hatékonyabb módszer, de csak olyan véleményeket találtam, hogy nincs (legalábbis 5 hónapja nem volt, azóta nem néztem).

    Azonban egy jó alvás után valami emlékem visszajött a jelszóról, és nagyjából (de nem pontosan) visszaemlékezve rá, a fenti program által biztosított szótáras (wordlist) módszerrel találgattam (a program meg kombinálgatott az elemekből), és így az addig eltöltött időhöz képest rövid idő alatt sikerrel jártam. Mondhatom hogy megizzadtam, de kb. bruttó és nettó 24 óránál nem vett el többet az életemből. Azért nettó is ennyi, mert hétvége volt, itthon voltam, és a gép éjszaka is dolgozott amíg én aludtam, persze akkor még brute force volt, de mindegy. Jó lecke volt ez nekem is, és azzal együtt hogy jó néhány hónap távlatából még ma is emlékszem a jelszóra, le is írtam egy csak általam ismert helyre ...

    Nem tudom, hogy ez a példa segíteni fog-e, de talán reményt ad.

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