Messages by Tuukka

In what kind of situation are you needing this? Going back to a previously opened frame or some completely different circumstance?

For lots of code to begin with, check the online demo (http://www.kalmeo.org/projects/kuix/demo) and download it's sources. That's propably the best place to start after going through the turorials.

I'd store the dataproviders in some array or collection in the memory and find the right one with some primary key, in your case propably city. Then in the onAction call "select(@{city})" and use that key to find the correct dataprovider.

I use similar approach on several screens with a lot more content and have not run into any problems... Are you sure this is where your problem is? Also note that Kuix seems to occasionally "freeze" when actually only the screen drawing is left undone for some reason. To get around this, you have to press some key for Kuix to render again properly.

This

  <listitem id="listItem1" onfocus="selectionChanged(this)">List Item 1
  </listitem>

is exactly equivalent to this:

  <listitem id="listItem1">List Item 1
    <_onfocus>selectionChanged(this)</_onfocus>
  </listitem>

You can use which ever you want. I don't think there are any differences in how they work but I cannot guarantee that. Haven't looked that deep.

Yes, you can use a single Java class and a single XML file for each of these similar pages. It is not any more efficient in runtime but the size of the jar package is smaller this way. Also you have less code and it's easier to maintain.

How do you do it? Just as if there were different classes and XML files. Only thing that changes between the similar screens are the calls to the constructors (pass in the parameters required) and the dataproviders of the screens. Or if you plan wisely, you propably can manage with only changing the dataprovider.

If you need more help, please post your code and a more accurate description of what you are trying to do.

Using screen.getFocusManager().getVirtualFocusedWidget might do the trick? Haven't tried this, but here is an excerpt from the JavaDoc:

"Returns the focused widget.
Caution : if focused widget is a TabFolder the current TabItem's focused widget is returned.
For focusManager internal use, prefer to use the protected focusedWidget member."

Another apporach is to provide a parameter to the event handler like this:

<_onfocus>selectionChanged(@{_id})</_onfocus>

And then in the onMessage, use it like this:

  if ("selectionChanged".equals(identifier)) {
    int id = Integer.parseInt((String) arguments[0]);
    doSomething(id);
  }

Instead of @{_id} you can also pass "this" as the parameter like this:

<_onfocus>selectionChanged(this)</_onfocus>

Then you'd get the listitem widget from arguments[0].

As far as I kwow, Kuix doesn't provide any support for direct drawing. You could try to use the staticlayout, but I doubt that'll get you too far. I'm afraid you'll have to find another library (to use with Kuix or alone) for that or use J2ME:s own primitive drawing mechanics for that.

I suspect you are loading the screen from the XML in the frames onAdded method, correct? Lets see what the problem is when you do this.

1. The first frame is constructed and loaded like this:

Kuix.getFrameHandler().pushFrame(new FirstFrame());

pushFrame automatically calls the FirstFrame's onAdded method, where you propably load the screen from the XML

2. You proceed to the next frame similarly:

Kuix.getFrameHandler().pushFrame(new NextFrame());

 3. You come back from the NextFrame with code something like this:

Kuix.getFrameHandler().removeFrame(frame);
Kuix.getFrameHandler().getTopFrame().onAdded();

See the problem already? When the NextFrame is removed from the frame stack, the FirstFrame becomes the topmost frame. Then the getTopFrame returns the FirstFrame instance created in phase 1 and calls its onAdded. And what happens in the onAdded? You load the screen again from the XML.

The solution to this is to load the screen in the frames consructor instead of the onAdded method. The onAdded then only calls screen.setCurrent(). This way it works exactly like you want and is even otherwise much more efficient. No neet to load the screen when it is already loaded an in memory...

Oh, sorry, i'll edit that to avoid future problems on people stumbling on this thread.

ProgressBox is another widget in my application where the progressBar and taStatus widgets are in. You should be able to replace progressBox with screen, so that it becomes screen.getWidget(...), screen being the screen loaded from XML such as this:

screen = Kuix.loadScreen("SomeFrame.xml", null);

1:

Just give id:s to the widgets in the xml and then this should work:

  Gauge progressBar = (Gauge) screen.getWidget("progressBar");
  TextArea taStatus = (TextArea) screen.getWidget("taStatus");
   
  progressBar.setValue(50);
  taStatus.setText("Some info");

2:

Container is essentially a representation of the base Widget, so something like this should work:

  Widget w = new Widget();
  //Set w:s properties as you like
  screen.add(w);

### Edit: progressBox -> screen

Like this:

  PopupBox popup = Kuix.alert(Kuix.getMessage(completeMessage), KuixConstants.ALERT_OK | KuixConstants.ALERT_ERROR, "errorok", null);
  
  popup.remove();
  popup.cleanUp();

Why don't you try commenting out the RMS and bluetooth parts and see how much that improves the speed. Then come here to share the results, so we can dig deeper. 

RMS is quite slow with quite a few mobile phones. Also bluetooth is quite slow, and even if it is run in another thread, as it should (and as the RMS also should be done), the Java virtual machine on mobile phones doesn't actually run the threads in parallel, it only simulates such actions. Hence even operations in other threads affect the performance of the main thread.

I have not found a solution to this either. As far as I can tell, there's no way to intercept the amount of data transferred until the transfer has finished. If you do find a solution, please share it here.

Sounds like you are doing something wrong. First idea coming to my mind is that you could be always creating a new screen with new data objects, even when going back to a screen previously shown.

The easiest way to find out what's happening is by using the emulator Memory Monitor. You can activate it from the Sun Wireless toolkit preferences in the Monitor section. Then when you fire up the emulator, a graph showing the memory usage of your application is shown in real time. From there it's easy to see what actions take most memory and whether or not the memory is freed in any point of execution.

For more exact help I'd have to see some of your code...