Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Java Development

Reply
Contributor
Posts: 17
Registered: ‎08-27-2013
My Device: Blackberry Torch 9860
My Carrier: *

Optimised way to load a MainScreen

Hi All,

 

I am currently having problems with loading mainscreens on my applications. It takes time to load.

 

My question is as follows;

 

1. What is the best way to load mainscreens

 

2. When is the best time to paint the screen with components

 

3. When is the best time to call on threads for network resource.

 

 

Thanks

Developer
Posts: 19,636
Registered: ‎07-14-2008
My Device: Not Specified

Re: Optimized way to load a MainScreen

[ Edited ]

Not sure I understand these questions.  Here is a quick answer to them taking the questions at face value.  You will probably find these answers simplistic, so please ask a more detailed question.

 

1. MainScreens are normally loaded in their constructor with the Fields/Managers that are to be displayed.  Updating a Screen after is has been displayed usually invokes extra overhead as the Screen is re laid out and then repainted.  Note there is only one way to display a Screen - that is using push.  If you don't have to use a modal push, then the general recommendation is not to use them, for overhead and lock out reasons.

 

2.  There is only one time to paint screens and that is when paint() is called.  paint() is called frequently, so minimizing the processing in paint() is a good way to improve the performance of the application.  In addition, this method should only paint the screen (i.e. update the colors of pixels) - if you need to do something with layout that is dynamic then you should use the layout methods (sublayout() for a Manager and layout() for a Field). 

 

3.  There is no best time.  You have to use a Thread for all network requests so start it (or add the request to a Thread pool) as soon as you can.  Since network time is usually a significant delay, you could try to minimize the use of the network, say by caching data or images. 

 

Aside: Apologies, I have just noted that my update to your other Thread did not include my replacement code.  I have just added it.  Please compare the code I supplied with your code for more hints on code/UI optimization:

http://supportforums.blackberry.com/t5/Java-Development/Creating-a-list-of-verticalfieldmanager-in-b...

Highlighted
Contributor
Posts: 17
Registered: ‎08-27-2013
My Device: Blackberry Torch 9860
My Carrier: *

Re: Optimized way to load a MainScreen

I tried the following methods in loading the main screens;

 

1. Created a private method that adds components to the screen and call it in a constructor  e.g.

 

//in my mainscreen class

 

private void paintUi(){

 ...... add components

}

 

public ScreenConstructor(){

  paintUi();

}

 

then i pushed it with this;

 

UiApplication.getUiApplication().invokeLater(new Runnable(){

 

   public void run(){

         UiApplication.getUiApplication.pushScreen(new ScreenConstructor());

  }

 

})

 

 

2. Created a public method of paintUi() and call it after pushing the screen like the method above, without calling it in the constructor though.

 

 

The problem is that it works well on my simulator, but on real device, It is very slow, and sometimes takes a minute, showing the black busy icon to load the screen.

 

 

What am I doing wrong?

Developer
Posts: 19,636
Registered: ‎07-14-2008
My Device: Not Specified

Re: Optimized way to load a MainScreen

[ Edited ]

What you are calling painting is usually referred to as construction.  paint is the actual act of updating the pixels on the screen, performed by the paint() method of most Fields (though you are usually isolated from that). 

 

Going through your points:

 

1) There is no difference between doing this in your constructor via a method call, or just doing it in your constructor, so separating out the processing as you have done provides no advantage and would probably confuse some people.  This process typically takes very little time.

 

2) This is not a recommended approach.  Using this approach you will displaying an empty screen (which has to paint itself), but then you will be updating and repainting the screen each time you add a Field.  If you can add these things before the screen is displayed, then the processing is more efficient - see later. 

 

If you see a clock icon, the problem is most likely related to garbage collection.  Typically this means you are creating and discarding Objects frequently and (eventually) these are filing up memory, meaning the garbage collector has to come in and remove the redundant Objects. While the garbage collector runs, it shows the clock icon and stops other processing. 

 

On the other Thread I referenced above, you were doing creating and removing more Objects that you need - significantly for focus changes you were creating Background and Border Objects that were redundant after the next focus change.  While the Blackberry has a reasonable amount of memory and a reasonable garbage collection, it will still run out if you over use it.  So you should think about Object creation and deletion to optimize this for the program. 

 

In my experience, thinking about this also helps in the programming.  In the code provided for the other Thread, you re created exactly the same Border Object a number of times.  One of my code changes was to only create these Objects once and share them - this actually made it clearer where each definition is being used, 

 

To help you understand the processing, here is a quick summary of the BlackBerry Ui processing steps:

1) Fields added to Managers

2) Managers added to Screens

3) Screens pushed on to the display stack - which triggers

4) Layout of Field/Managers to make sure these are all positioned on the Screen - sublayout() for Screen and Manager, layout() for Field

4) Screen is painted, which iterates through all the Managers and Fields getting them to paint the area that they are using. 

 

Now if you change a Field, or add Field, then steps 4 and 5 are repeated.

 

If you move focus or scroll, then step 5 is repeated.

 

So for overall performance, then the painting is typically the most important part.  But when updating a Field or pushing a screen, then the layout processing can be important too. 

 

However this is not always the most important part.  In your previous Thread, that was not the case - the issue with your previous Thread was caused by other factors most notably your handling of focus changes.