sorlok / ornagai-mobile Goto Github PK

What steps will reproduce the problem?
1.Start App.
2.Select Options and select and invalid dictionary file.
3.See user friendly error message.
4.Exit app.
5.Start App.

The application supposed to start but display message saying
"Unhandled exception." And application exit.

NOTE: I think the reference to dictionary file is not restored to original
working one, after the reference is set invalid dict file.

After all the nonsense of signing/unsigning, the JAR file decided to crash
on external dictionaries. 

It gave an elusive "ArrayIndexOutOfBounds" exception, with index "3". This
sounds like one of my "options" arrays is being exhausted. Finding this
error will take some time, as it is a hardware-only bug.

Also, I'd like to add a tab to the "Options" menu that shows how much
memory is in use and how much is free. This will make remote debugging
slightly easier.

Besides this bug, all JARs can be built. We're right before the rc2 release...

Pressing "up" or "down" on the word list moves the cursor, but it "jumps"
instead of sliding nicely. This isn't a big deal, but LWUIT looks so nice
when it's working properly...

Searching for "zz", then clicking on an "A" entry, then a "Z" one, then an
"A" one again will crash the emulator. Although phones have limited memory,
this is more typical of a memory leak. We should fix the leak, so that the
only memory errors are genuine ones.

...Of course, if LWUIT is just consuming slightly more memory as time goes
on, that's another thing...

If you set dictionaryForm's "isScrollable" to true, the list will display
indefinitely, always centered around "a".

If you set it to true when the result form is being shown, the "getSize()"
method of ZawgyiComponent fails with a null pointer exception.

There are ways to get around this (calculate the width of the entire
display based on the splashForm, pass it in) but at the moment I prefer
stability.

For the next release, though, this should probably be solved.

Search for "aback" then click on "take aback". The word is "not found", for
some reason... this also fails from "take". Perhaps something's wrong with
multi-words?

Look up "laugh". Unfortunately, only the "verb" part-of-speech is shown...
and it's shown four times.

I remember NOT seeing this behavior for all words with multiple POS's. So
either this is a recent error, or it only applies to "laugh". Either way,
we should fix the other problem (laissez-faire) first.

Duplicate words are ok (different forms), but having the exact same word
twice is not. Because our binary format enforces a strict ordering, we can
"hide" all resultset words; we should do this.

Test the following things on a phone:
  1) Loading an invalid (bad format) dictionary.
  2) Loading a dictionary that is too big (out of memory)

We need to make sure users aren't crippled if their phone saves some
invalid settings.

The file browser is unusable on real hardware. A few fixes:
  1) Delay the initial connect check until the user clicks the "options"
pane. This is necessary to avoid prompting the user for normal everyday use
of the dictionary.
  2) Find out how to avoid prompting the user each time a single file is
accessed (e.g., when scanning for files). This makes the custom dictionary
reader un-usable.
  3) For some reason, the file browser can't read my SIM card. Figure out
what part of the code is throwing an un-checked IllegalArgumentException,
and figure out what exactly it's trying to access.

Otherwise, no big issues on hardware (yet). Yay!

From Sun's web page:

"Note: CLDC permits implementations to refuse to load an application that
refers to classes that aren't present, so a device that doesn't have the
FileConnection APIs installed might not let your application check for them
at runtime. In this case, you must be prepared to package two different
versions of the application, one that uses the FileConnection APIs and one
that doesn't."

Is this actually a problem? We should test the software on various phones
and see what happens when the FileConnect API isn't present at runtime.

For whatever reason (and this occurs on the emulator, too) jazzlib will
occasionally glitch and fail to load the same ZIP file that it loaded
successfully every other time.

Perhaps we could switch libraries? At any rate, the code is reliable enough
for version 2. It'll have to be fixed in the next version.

Test case: "zadd".

It should just put it somewhere after z. Instead, it crashes.

What steps will reproduce the problem?
1.Start app
2.Type string "about" and click search.
3.show the list of words including "about"
4.Click the center button to see the description.

What is the expected output? What do you see instead?
I expected to see related description but it show error
"ALERT: java/lang/NoSuchMethodError: No such method
getItemAt.(I)Ljava/lang/Object;"
That error is shown on Nokia 6212 classic emulator and Nokia 6500 slide
emulator.

What version of the product are you using? On what operating system?
I am using Onagai version 2.0. 
My computer OS is XP.
java version is 1.6.0_15 and 1.6.0_7.
Tested on Nokia 6212 classic emulator, Nokia 6500 slide emulator N97
emualtor, Nokia Series 40 6th edition emualtor and Nokia Series 60 3rd
edition emulator

Please provide any additional information below.
1. It doesn't show all the text on 320x240 screen size.
2. It is working fine on N97 emulator ,Nokia Series 40 6th edition
emulator, Nokia Series 60 3rd edition emulator.

Car wash = ok. Look up as car or wash (both exist)
Laissez-faire = not ok. Look up laissez or faire and you can't see it
(because neither is in the dictionary). Instead, you see two "Not found"
messages.

There should be ONE not-found message, and then the definition.

What steps will reproduce the problem?
1. Install the application on Sony Ericsson.
2. Start the application.

Message stating "Application Error" is shown and application cannot start up.

NOTE: I will check on the CLDC and MIDP version of the application and
versions supported by SE K770. I doubt that problem or may be something else.
I'll check the source code too.

As much as I dislike adding new features at this late hour, the license
practically dictates an "About" box. Moreover, Ko Thar Thar's name and
Mysteryzillion should be included, and possibly my own.

We can pretty much just copy the ErrorDialog... might as well put it under
the options panel, since we have to edit that anyway.

For low end phones, which does not have much memory, the transition is very
slow and in some cases, crush the application.

Since putting the GUI objects into their respective Form subclasses,
bizarre behavior like the constantly-green List background are gone.
However, styles are now totally messed up. This is a necessary evil, I suppose.

Todo: Re-check ALL styles in the dictionary.

We can't buy a certificate, and "open" ones are not universally accepted.
So, here's the basic plan of attack:

1) Create a boolean flag, "unsigned", which prevents the file dialog from
performing so many checks (including the huge number of checks for whether
or not a folder is empty).

2) Add an additional ant task to the build file which makes the same
version of the JAR, but removes ALL file connect stuff. (Removes from
SOURCE, by the way). This is for phones that don't even allow FC apis to be
loaded.

3) Distribute three JAR files:
  1) Unsigned, without FC apis
  2) Unsigned, with FC apis and "unsigned" flag set
  3) Self-Signed, with FC apis and "unsigned" not set
The third option is the default option.

Although the math is sound, word-wrapping is slightly off. Small letters
(dot below) occasionally surpass the right edge, when there should be a
nice border.

Test case: "mg" --> "mezzo-soprano".

J2ME polish uses CSS and a big device database to target individual
platforms. You can also target Android:
http://www.j2mepolish.org/cms/leftsection/documentation/platforms/android.html

...Unfortunately, I've heard some pretty bad things about J2ME Polish: that
it's hard to use, buggy, and slow/bloated. I have no idea if these rumors
are true or not.

One thing that's certain is that we'll eventually have to start dealing
with all the tiny, slightly-flawed phones that can't run our code. The
device database provided by J2ME Polish might help with this. We might even
consider building a simple "basic english only" version, to get around the
1MB limit, although this would require a lot more work than you might think
--ProGuard, for example, would have to be hooked up to shrink the included
library API.

One promising feature of J2ME Polish is its zip interface:
http://www.j2mepolish.org/javadoc/j2me/index.html

Don't be fooled --although there's a "GZIPInputStream" it actually reads
_Deflate_d data, so it can read ZIP (and PNG, which we need for custom
fonts via Pulp Core). It also _seems_ to be able to read UTF-8-encoded
files, which is a nice bonus.

That said, J2ME Polish is GPL, which is bad for us (MIT isn't compatible,
and GPL strangles creativity, at times). We might try the "J2ME Polish
Developer Program", if it also allows us to release for free (I think it
does). This gives us access to their signing facilities, and allows them to
host the program and all updates. Or, we could just GPL our code, and hope
for the best. Or wait for J2ME Polish to smarten up and go LGPL. 

At this point, I'm rambling, but these are my ideas at this point. Too many
people have phones that don't _quite_ support Ornagai v2, and I think we
can help at least some of them get _something_ to work.

I'm reporting this as a closed bug, because it was really quite significant.

Searching for "pagoda" would give two "not found"s and then the actual
word. This is because of a bug in the converter, which sorted "Pagoda
trustee" before "pagoda". 

In fact, this bug was small. But it required a re-generation of the entire
binary dictionary, so it marks a huge difference between RC1 and RC2.

Two things:
  1) The default style for our Dialog boxes is quite difficult to read.
  2) Error messages are not shown often enough, and don't FORCE you to quit
the program.

We can always hook up command listeners, etc. But sine we've already
over-ridden a dialog class for the FileChooser, why not make a special
ErrorMessage class, complete with a list-style selection interface?

We've inserted definitions into the wrong position. They are always a few
letters short (even for exact matches) which implies that our ordering is
inaccurate.

The final release candidate must be tested on a real Palm-style device. In
other words:
  1) Make sure touch-screen stuff (changing components, etc.) works.
  2) Make sure the layout looks ok on a larger screen.
  3) Make sure the general experience is up to the standards of Palm users.