lcdui - List vs ChoiceGroup (midp1.0)

[David N. Welton]

Hi,

I have a question regarding the MIDP1.0 lcdui 'widgets' ChoiceGroup and
List.

Basically - is there any reason to use List for anything other than a
'menu'? ChoiceGroup has an itemstatelistener so that you can write code
that acts immediately when a choice element has been selected, whereas
List doesn't really have this ability for MULTIPLE or EXCLUSIVE type
lists. This has been corrected with MIDP2.0, but I'm interested in
writing code for the widest possible audience, and since 1.0 is still
being sold... 2.0 isn't an option.

I have half an idea to create ListBox and Menu classes, that are
respectively, a Form with only a ChoiceGroup in it, and a List of
IMPLICIT type.

Thoughts?
--
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/

 

[Darryl L. Pierce]

Basically - is there any reason to use List for anything other than a
'menu'?

Yes. For example, it can be used for a screen where the only interaction
for the user is to select one or more items from a series of things. One
application I worked on used List screens to drill down to which
specific printer the user wanted to access through our application.
Doing that on a Form containing ChoiceGroup objects wouldn't have been
feasible since the waterfall updating of lists would've made the
interface messy and unresponsive.

Also, don't use List to create menus. That breaks UI paradigm for the
handset. Use Command objects and let the handset present them like any
other list of commands on the handset. This will make your application
more portable.

 

[David N. Welton]

Perhaps I should define 'menu' better - or what I mean by it:

A list of options on the screen that cause some action to be performed
when one is selected. This is basically what you get with an 'IMPLICIT'
List if you redefine the SELECT_COMMAND to do something interesting.

Yes. For example, it can be used for a screen where the only interaction
for the user is to select one or more items from a series of things. One
application I worked on used List screens to drill down to which
specific printer the user wanted to access through our application.
Doing that on a Form containing ChoiceGroup objects wouldn't have been
feasible since the waterfall updating of lists would've made the
interface messy and unresponsive.

If your application functions by doing something immediately when a List
item is selected, then yes, a ChoiceGroup would have looked wrong too.

I'm not clear if we're writing at cross purposes though... did your
application work like my description of menu, or were your lists
EXCLUSIVE or MULTIPLE and acted on by a Command?

Perhaps I could rephrase my question in a different way:

In the case where I want to display a series of items that are either
EXCLUSIVE or MULTIPLE, are there any disadvantages to a single
ChoiceGroup on a form? The advantage to the ChoiceGroup is that you can
run code immediately on selection of an item. For example: a checklist
(so MULTIPLE), where some action happens when you check off the last
item in the list.

Also, don't use List to create menus. That breaks UI paradigm for the
handset. Use Command objects and let the handset present them like any
other list of commands on the handset. This will make your application
more portable.

Makes sense to me.

Thanks,
--
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/

 

[David N. Welton]

In the case where I want to display a series of items that are either
EXCLUSIVE or MULTIPLE, are there any disadvantages to a single
ChoiceGroup on a form? The advantage to the ChoiceGroup is that you can
run code immediately on selection of an item. For example: a checklist
(so MULTIPLE), where some action happens when you check off the last
item in the list.

What I was thinking of was this, maybe with a bit of tweaking:

import javax.microedition.lcdui.Form;
import javax.microedition.lcdui.ChoiceGroup;

public class ListBox extends Form {
ChoiceGroup cg = null;

public ListBox(String title, int choicetype, String []choices) {
super(title);
cg = new ChoiceGroup("", choicetype, choices, null);
this.append(cg);
}

public int append(String item) {
return cg.append(item, null);
}
}

Ciao,
--
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/

 

[Darryl L. Pierce]

Perhaps I should define 'menu' better - or what I mean by it:

A list of options on the screen that cause some action to be
performed when one is selected. This is basically what you get with
an 'IMPLICIT' List if you redefine the SELECT_COMMAND to do something
interesting.

There are many uses for a List object. It's the LCDUI equivalent of a
group of either radio buttons or checkboxes depending on whether your
application needs exclusive or multiple options set.

If your application functions by doing something immediately when a
List item is selected, then yes, a ChoiceGroup would have looked
wrong too.

Having multiply sets of directly related but mutually exclusive
selections implies an immediate response.

I'm not clear if we're writing at cross purposes though... did your
application work like my description of menu, or were your lists
EXCLUSIVE or MULTIPLE and acted on by a Command?

Exclusive. The selections in the second group depend directly on what's
selected in the first group.

Perhaps I could rephrase my question in a different way:

In the case where I want to display a series of items that are either
EXCLUSIVE or MULTIPLE, are there any disadvantages to a single
ChoiceGroup on a form?

The only advantage to using a ChoiceGroup on a Form is that you can have
other Item objects on the screen as well. This can be good if those
other items and the ChoiceGroup interact with each other in some way,
but it's definitely bad in that it's cluttering up a small display with
items that might end up not being visible.

The advantage to the ChoiceGroup is that you can run code immediately
on selection of an item. For example: a checklist (so MULTIPLE),
where some action happens when you check off the last item in the
list.

No, not quite. Have you actually read the API for ItemStateListener? It
is not guaranteed to fire at any point in time, let alone when options
are toggled in a ChoiceGroup. Be careful in your assumptions.