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

• thon73 tag

  #2373

  #2370 vz12

  2014-06-24 22:15:05

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  thon73

  tag

  #2370 vz12

  #2370 vz12

  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?

  Bocs, csak most csatlakoztam bele a történetbe.
  Én ugyanezzel a problémával szembesültem, azzal kiegészítve, hogy nem csak az ékezetek, hanem néhány írásjel átalakítására is szükségem volt. Végül úgy oldottam meg, hogy készítettem egy kb 300 elemű tömböt. Az indexet az unicode kód adta, az elem értéke pedig visszaadta, hogy milyen ékezettelen karakternek kell ezt tekinteni. A tömb mérete felett csak nagyon elvarázsolt karakterek vannak (vagyis az európai nyelvekben nem használatosak), így ott mindig az "ugord át" jelet adta vissza.
  ((Nagyon zárójelben jegyzem meg, hogy ezt továbbgondolva ezzel az egy táblázattal sikerült a lényeges nyelveken rendezni a kifejezéseket, ill. keresni is ékezetlenített módon.))
  Persze ez is csak egy módszer a sok közül, de gyors, tömör és hasznos volt. Nem a végleges változat, de ITT megtaláltam, amit írtam róla korábban.

  A targettel kapcsolatban annyit fűznék hozzá (bár fentebb elhangzott), hogy ebbe a hibába én is beleestem, mert 2.36 alá írtam a programokat, és a régi sdk-val fordítottam.
  Valóban az a követendő, hogy a leges-legújabb sdk legyen fent, és ez szerepeljen a project.properties-ben is. (És amivel szintén voltak hm. gondjaim: a support library-t is illik ezzel együtt frissíteni a projektben). A minimalis és a target (a manifestben) ettől függetlenül bármire beállítható. (Én is többnyire API8/API10 kombóra fordítok, de (((elvileg))) a legutoljára letöltött sdk-val.)

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