10-31-2012 02:02 PM
That is not what Simon meant I think. He meant you to look at each of the Fields you have added. Can they be updated in place? For example, most EditFields and labels and RichtextField can be updated using setText() and/or setLabel() and by doing this, the Field will automatically refresh the screen.
That said, this can cause a significant overhead. For example if you update 20 TextField sequentially, each one will update itself, then ask the screen to repaint. So in this circumstance I think you might find it is more efficient to create a set of new Fields, add these to a new Manager, then just replace the old Manager with the new Manager.
So I recommend that you create a generic routine that converts the XML and adds the Field into a Manager, say a VerticalFieldManager. When you do this the first time, you will just add this Manager. When you get new XML, just call this method again to get a new manager, then you will replace the old Manager with the new Manager.
Look at the Manager replace() documentation for information on this replace() method.
10-31-2012 02:09 PM
The thing is that MyView is not fixed,its dynamic depending on the xml.Say fr the first time my View can hav a 3 images added horrizontally at top and below there can be low textfield vertically.In the second xml my view can only hav a background image to a vertical manager where we have to add to text at top and bottom.So my view depends on XML and its subjected to change
10-31-2012 02:20 PM
And one more doubt i have,if i call my construction from click event like dis
will it make all my global variables into its default state or will it keep on holding the values it has?
10-31-2012 02:42 PM
"The thing is that MyView is not fixed"
This is not a problem. Using the approach I described, you will add as many or as few items to the Manager. You just have to put everything related to one XML in the Manager. Than swap that with the Manager that was related to the old XML.
I hope that makes sense.
With respect to your second question, I've not really looked at the logic you seem to be using, I figure that is for you to decide. But you actually seem to be using a different strategy to the approach I suggested.
If you call a constructor like this:
then in normal Java you will get a new Screen, that is totally unrelated to your old one. So if you do this, you would pop your old screen and display your new one. That is an alternative to updating the old screen - updating is the process I have described.
I think you try to use static variables to save contents between the new and old screen. This, I think, is very bad practice and I would encourage you to try to remove this. As a general rule, I suggest you use static values to hold fixed (none varying) content, which is the exact opposite to what you seem to be trying to do. .
And if you are updating an Object don't call its constructor - a constructor is used to create a new instance of a class. Provide some update method.
Again, I hope that makes sense.