Layout Performance

In case you are not aware of when layout happens, it gets called after every add(), insert(), or delete(). It has to be, so the manager can reposition fields when something changes. The problem with this is that every add() in onLoading() causes another updateLayout(). If you have a lot of fields, or if your fields are managers then there can end up being a large tree of fields.... whoops. A while ago we stumbled upon a way to suspend layout, however a way to make this more global wasn't apparent until now.

There are four classes that implement NativeLoadingManaged and use a LoadingManager.

• AbstractManagedScreen
• AbstractVerticalFieldManager
• AbstractHorizontalFieldManager
• AbstractFlowFieldManager

Calls to onLoading() are now wrapped in a layout suspension. Before onLoading() is called, we suspend layout. When subLayout() gets called, we check to see if it is suspended or not. If it is not, then we call super.sublayout(), if it is then we skip it and continue on. When unsuspending layout after onLoading() is finished, updateLayout() is called. This way there should only be one actual layout per loading call.

Another issue with loading/layout is that we want to build from the bottom up. The fields should be added to the manager before the manager is added to the screen (or some other manager). This is not what happens when we rely on onLoading(). To work around this (sort of), a forceLoad() method was added to NativeLoadingManaged fields. You do not have to call this manually in most cases. If you are adding a managed field to another managed field (Container, Abstract___FieldManager, etc) then you are set already. Managed fields override the add() method and then check to see if the field being added is an instance of NativeLoadingManaged, and if it is, then it will call forceLoad() before calling super.add().

Boom. Here are some numbers to ponder over:

Two separate calls to a manager that was known to be unbearably slow:

Before

onVisiblityChange() start: 1222496839173
onVisiblityChange() end: 1222496841772
A difference of 2599

onVisiblityChange() start: 1222496960586
onVisiblityChange() end: 1222496963154
A difference of 2568

So, about 2.5 seconds, simulator time... that's like 25 seconds device time... or something.

After

onVisiblityChange() start: 1222497074873
onVisiblityChange() end: 1222497074978
A difference of 105

onVisiblityChange() start: 1222497129863
onVisiblityChange() end: 1222497129966
A difference of 103