Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: Asynchronious Loading  (Read 10482 times)
turtlebite
Newbie
*
Posts: 7


View Profile Email
« on: January 27, 2014, 12:32:55 »

Hi all

I know there's Async Commands, but I use to do asynchronious loading in a really simple way, and it works perfectly (I'm using it in ActionScript and Java projects). Because it is so easy, I would like to know what you think of it. :-)

PrepareModelCommand is called when PREPARE_MODEL notification is sent. In it, a proxy is registered and the command dies. We have to wait for this proxy to finish it's setup (maybe it loads from a database or whatever). When it is ready, it sends a PROXY_INITIALIZED notification. This is again mapped to PrepareModelCommand, which checks who called it (I use "type" of the notification for this), and then the next proxy is registered and so on. If no async loading is needed, I may register some proxies at the same time, whatever the situation demands. In the end, the PREPARE_VIEW notification is sent, and in the PrepareViewCommand, the same procedure starts again.

In code it looks somehow like this (Java):

AppFacade:
:
...
registerCommand(AppConstants.PREPARE_MODEL, new PrepareModelCommand());
registerCommand(AppConstants.PROXY_INITIALIZED, new PrepareModelCommand());
registerCommand(AppConstants.PREPARE_VIEW, new PrepareViewCommand());
registerCommand(AppConstants.MEDIATOR_INITIALIZED, new PrepareViewCommand());
...

PrepareModelCommand:
:
@Override
    public void execute(final INotification note) throws IOException, ClassNotFoundException {
        if (note.getName() == AppConstants.PREPARE_MODEL) {
            getFacade().registerProxy(new AnswerProxy(new AnswerData()));
            getFacade().registerProxy(new AppProxy(new AppData((Stage) note.getBody())));
        } else {
            if (note.getType() == AppProxy.NAME) {
                // AppProxy is ready. Do something...
                final AppData appData = (AppData) getFacade().retrieveProxy(AppProxy.NAME).getData();
                final double w = (appData.getAppWidth() - 200) / 6;
                configData.setImageSize((int) w);
                // ... and register the next proxy.
                getFacade().registerProxy(new ConfigProxy(configData));
            } else if (note.getType() == ConfigProxy.NAME) {
                // ConfigProxy is ready... load the next Proxy.
                getFacade().registerProxy(new HighScoreProxy(highScoreData));
            } else if (note.getType() == HighScoreProxy.NAME) {
                // HighScoreProxy is ready... register UserProxy (we don't have to wait for this one)
                getFacade().registerProxy(new UserProxy(new UserData()));
                configData = (ConfigData) getFacade().retrieveProxy(ConfigProxy.NAME).getData();
                // ...and register ImagesProxy
                getFacade().registerProxy(new ImagesProxy(configData, new ImagesData(AppConstants.IMAGE_BACKSIDE_PATH)));
            } else if (note.getType() == ImagesProxy.NAME) {
                // ImagesProxy is ready, load the images (get's them from a directory, so we need to wait for it)
                final ImagesProxy imagesProxy = (ImagesProxy) getFacade().retrieveProxy(ImagesProxy.NAME);
                imagesProxy.loadImages();
                // ... but we can already register the StateProxy.
                getFacade().registerProxy(new StateProxy(new StateData()));
            } else if (note.getType() == StateProxy.NAME) {
                // StateProxy is ready, load the next one...
                getFacade().registerProxy(new SoundProxy(new SoundData(configData.getSoundEnabled())));
            } else if (note.getType() == SoundProxy.NAME) {
                // SoundProxy is ready, load the final one, and because we don't have to wait for this,
                // the model is ready and the View can start it's initialisation
                final SoundProxy soundProxy = (SoundProxy) getFacade().retrieveProxy(SoundProxy.NAME);
                soundProxy.getData().playStart();
                // PrepareModelCommand is not needed anymore, so let's get rid of it:
                getFacade().removeCommand(AppConstants.PREPARE_MODEL);
                // Model is ready, move on to the view!
                sendNotification(AppConstants.PREPARE_VIEW);
            }
        }
    }

ConfigProxy:
:
@Override
    public void onRegister() throws IOException, ClassNotFoundException {
        // Do something....
        if (getData().getImagePath().isEmpty()) {
            getData().setImagePath(AppConstants.IMAGE_PATH);
        }
        // ...when you think this proxy is ready, send the notification so the next proxy is registered.
        sendNotification(AppConstants.PROXY_INITIALIZED, null, NAME);
    }

So, the simple idea is that the PrepareModelCommand (and PrepareViewCommad) is called more than once, each time another Proxy requested it. The command does it's job and dies. So we don't misuse a command and let it wait for a response. When a proxy is ready, it just calls the command again, it does the next piece of code and dies again.

What do you think about this procedure?

 

Logged
saad
Sr. Member
****
Posts: 65


View Profile Email
« Reply #1 on: January 27, 2014, 09:31:50 »

how about your Proxies registering other proxies in their onRegister function or within their onComplete (if web services are involved) in a chain...
« Last Edit: January 27, 2014, 10:04:15 by saad » Logged
turtlebite
Newbie
*
Posts: 7


View Profile Email
« Reply #2 on: January 27, 2014, 12:13:08 »

Hi saad

Good point. :-) But when you do it that way you have to go through all the proxies to know what is loaded and in what order. In the PrepareModelCommand it's all neatly togehter in one place, it's easy to change if needed. And, I kind of don't like the idea of a proxy having to know about the loading of another proxy. I think the less it knows about the application the better. I guess it's the commands job to handle such logic.
Logged
saad
Sr. Member
****
Posts: 65


View Profile Email
« Reply #3 on: January 28, 2014, 09:18:38 »

this would be an ideal in case proxies are dependent, i.e. one proxy determining/calculating the input for the next, and the second one for the third one and so on (for example proxies handling parent child database tables passing foreign keys to subproxies - in context of PHP Port)

and yes if there's no sort of dependency then it's better to keep them separate and at the end if there's some kind of logical checks to determine what proxies to register, command is the place to go. :-)
« Last Edit: January 28, 2014, 09:21:09 by saad » Logged
Pages: [1]
Print