0

I've got the following problem, my boss wants me to make our app far more responsive without any waiting time between switching views. It used to a "standard" application based on a ViewNavigator but with just one View that was destroyed and re-created with different content based on the user's selection of tabs he created himself. Views were switched with the default SlideViewTransition. I'm down to half a second now with a slightly more lightweight approach as described below, however that half second is still too much.

The app is a tabbed application where the user can create and edit new views himself, so create/edit/delete tabs and their corresponding tabs. My current implementation is based on a ButtonBar and a Group that is used to display the "views". The group's content is created based on the selected tab. The content is based on XML data that stores all the required information to build the "view". Naturally, removing and creating the component's takes a little while (the half second I talked about), so I'm after another solution.

What I thought about is using the ViewNavigator and create all stored views upon application start.

Very much like this:

for each (var _view:XML in _allViewsConfig.children()) {
    var compView:View = new View();
    compView.percentHeight = 100;
    compView.percentWidth = 100;
    compView.name = _view.label;

    for each (var _groupElement:XML in _view.vgroup) {
        var group:VGroup = new VGroup;
        group.percentWidth = 100;
        group.percentHeight = 100;

        for each (var _windowElement:XML in _groupElement.window) {
            var window:WindowContainer = new WindowContainer;
            for each (var _componentElement:XML in _windowElement.component) {                  
                var component:UIComponent = _componentManager.create(_componentElement.@type, _componentElement);
                window.addElement(component);
            }

            group.addElement(window);
        }
        compView.addElement(group); 
    }
    views.addItem(compView);

}

views is an ArrayList that is used to store the created views.

The only problem I've got right now is that I can't use the Views stored in this ArrayList in the corresponding ViewNavigator.

I tried it the usual way, i.e. navigation.pushView(_viewCreator.views.getItemAt(0) as Class); This, however doesn't work, no error or anything, the ViewNavigatorjust doesn't do anything, so I guess that a View class can't be created like this.

So how can I make this work? Also, do you guys think that this is a proper solution to the problem, especially considering the whole dynamic nature of the application (being based on tabs)? Naturally, slide transitions will be completely disabled as they are quite slow with our complex components.

Any help, comments or thoughts would be greatly appreciated!

EDIT: On second thought, simply using Groups instead of ViewNavigator and View should make this a little more lightweight and solve the issue of views not being pushed.

ketan
  • 19,129
  • 42
  • 60
  • 98
AlBirdie
  • 2,071
  • 1
  • 25
  • 45
  • Yes, using `Group`s works very well and quite fast. Haven't tested on the iPad2/3 yet, though. The question remains, viable solution to the problem? – AlBirdie Jul 03 '12 at 15:31
  • Where exactly is your slow down? Generating the view itself or getting the data/images for the view? Generating the view should be pretty fast,fast enough that you won't notice. Are you preloading data/images? – The_asMan Jul 03 '12 at 15:52
  • Generating the view is/was fine, it's just the process of getting the data (from XML that is) and then drawing the subcomponents (which are quite complex) that took about half a second. The preloading I do now works rather well though. – AlBirdie Jul 03 '12 at 15:57
  • 1
    I faced a similar problem with a particular view that was very heavy. We created this view at startup once, and re-used it. It worked much better than having the ViewNavigator recreate it everytime. Only after we did all this, did we discover this property: `View.destructionPolicy`. You can, on a per view basis, tell the navigator to recycle your views. Maybe that will help. – Sunil D. Jul 03 '12 at 17:23
  • If preloading is fine then pre-parse it. – The_asMan Jul 03 '12 at 18:34
  • @SunilD., We're still talking about a one view strategy, right? Otherwise I'd have to create new views and keep them in a Vector or something and then push/pop the views based on the Vector index, which would basically be the same strategy I have now with a simple Group that acts as the ViewNavigator, wouldn't it? Do you think using a ViewNavigator with Views has a definite advantage (I handle all the data myself anyways so no need for the ViewNavigator to take care of it)? – AlBirdie Jul 06 '12 at 11:57
  • @The_asMan, you mean pre-parsing the XML? I thought it would already be parsed once loaded into memory? – AlBirdie Jul 06 '12 at 11:59
  • @Al_Birdy you are right, same approach in the end. The only thing I could think of is that it may optimize some things (view transition effects, etc) for mobile. I was compelled to mention `View.destructionPolicy` b/c there's not much talk about using it on the web :) – Sunil D. Jul 06 '12 at 21:17

1 Answers1

0

In fact ViewNavigator pushView() is a mechanism which create an instance of a given Class (method parameter).

For all navigation history purpose, ViewNavigator uses NavigationStack objects to store relevant values (that you can customize too).

I don't have a straightforward answer for you, but I think you'll have to implement your own custom ViewNavigator mechanism (extending ViewNavigator to leverage existing useful methods and override others).

Mihai Iorga
  • 39,330
  • 16
  • 106
  • 107
Rom's
  • 16