Container component

[jmhermelin]

Hi all,

I needed for my app to align several component on the same
line.typically Image and Label.
But I have also some more complex needs, like a big picture on the
left and several vertical component on the right.

So I created a special component called container component. it mostly
reuse the Dialog logic (add component, select next component on key
press...)

It supports horizontal or vertical layout.

I guess It could be helpful for others.

If it is the case let me know



Cheers
Jean-Marie

[Dean Browne]

I thought of adding a table component at one time for a similar purpose.  I think everyone would be interested.

My only concern is that many phones have slim screens (i.e. not wide).  And having components side-by-side either means a horizontal scroll bar or squished components.  Horizontal scroll bars are difficult for people on phones where many users are not computer savvy (that's my personal experience from testing, it might just be our golf app surfaces those people).

I'd be interested in hearing people chime in on this topic.  Reply to this thread and let us know what you think!

[Edgar Poce]

cool!, I would appreciate it very much. I'm currently using a
Container that displays one component for line. Your component would
be a great replacement.

[Edgar Poce]

I think I read the initial post too quickly, I thought the proposed
container would put the components in a single line and move to the
next line if they don't fit. An horizontal scrollbar wouldn't be
useful for my usecase.

>
> >
>

[Jean-Marie Hermelin]

> I think I read the initial post too quickly, I thought the proposed
> container would put the components in a single line and move to the
> next line if they don't fit. An horizontal scrollbar wouldn't be
> useful for my usecase.
>
>

No scroll in this version. So it should break a label on several line if
needed.

[Jean-Marie Hermelin]

Actually, this component does not handle scrolling. but I'm sure It
could be added
The basic needed was to a component that helps for a more flexible
layout. (icon / label on same line)

see enclosed image

Dean Browne a écrit :

[Jean-Marie Hermelin]

Here 's the code source (see enclosed file)

However you should apply the proposal patch for issues #18 #20 #21

additionnaly I modify the Dialog.getAt method to behave on absolute
coordinates (this is mandatory if you want the pointer to react as expected)

private int getAt (int x, int y)
{

Enumeration elts = components.elements();
int count = 0;
while(elts.hasMoreElements())
{
Component c = (Component) elts.nextElement();
int top = c.getY();
int bottom = top+c.getHeight();

int left = c.getX();
int right = c.getWidth();

// Does the point fall within this component?
if ( (y >= top) && (y < bottom) &&
(x >= left) && (x < right) )
{
// This is the component that (x, y) falls within.
return count;
}
count++;

}

return -1;
}

[ufuchs]

Hello guys,

I'm not the master of universe, but what we need is:

-Components which orient oneself by the HTML-boxing model.
-A layout manager, which uses a floating design.
-And this manager should decide, if a component will be draw at the
same horizontal position/line or shift to the next vertical position.
-And I believe, this is also a chance to get rid of vertical
limitations of the screen size.

I know, this suggestion will change some implementations completely.

However, we have a great chance. This is a young, lightwight and
sophisticated project.

//(Not such a grown monster like ... j2me-polish?)

Let us say there are no longer screens smaller than 176px. Nowadays.

And I believe, we will have no longer problems to port applications on
different devices.

Maybe the only problems are the different JSRs.

Any comments wellcome, Uli

[ufuchs]

Aso, and we have also the chance to pay attention to

http://code.google.com/android/toolbox/performance.html

Uli

[ris12345]

Personally I value the simplicity of J4ME as it currently is and the
fact that applications made with it seem to deploy reliably on any
MIDP2/CLDC1.1 phone including such as the Nokia 6021 which are small
sized with 128 x 128 displays.

I would hope that proposed changes do not compromise this and end up
with a bloated complex product that suffers from fragmentation
problems.

I guess what I am saying is I will live with a simpler UI if it gives
me reduced deployment issues. I am not a Java expert so it may be
possible to develop J4ME in a way that meets all developers needs but
if not, I am firmly in the simple UI/mass deployment camp

Cheers

Richard

[Edgar Poce]

> Personally I value the simplicity of J4ME as it currently is and the
> fact that applications made with it seem to deploy reliably on any
> MIDP2/CLDC1.1 phone including such as the Nokia 6021 which are small
> sized with 128 x 128 displays.
>

I also value the simplicity of j4me, that's why I started to use it.
However I think that more complex components are valuable for many
users. Maybe we can achieve both goals by packaging new components
separately, just an idea.

br,
edgar