I’m afraid that I haven’t used the new XIFF library (to be honest I didn’t even know there was one ), so its very possible that its changed.

However, I doubt it will have changed too much so you can probably hack the example code to work with the new library without much difficulty.

Good luck!

Dave

BUT, am i to dumb or is there no more XMPPSocketConnection class in the XIFF 3.0 library?! havent got that deep into it right now… is it changed?

Cheers, Ben

You are 100% correct; the best way to do this would be to have an interface on the XMPP model. For the sake of brevity in the tutorial I didn’t do this, but its the best way to go.

I have recently started using RobotLegs which handles mapping of Models (and other things) to interfaces in a brilliant way. I would recommend checking it out if you are interested.

Cheers,

Dave

Great writeup, I was looking for a framework to use with Flash, and this tutorial encouraged me to try PureMVC and I have to say it works very well so far. As its my first time workign with Flash I fell down a few holes (hint: if putting views in a TabNavigator or other hidden layout, set creationPolicy=all or your mediators get passed null instances of the view)

Anyway .. back to a question on the structure … Everyting seems to work for me in the way you have set the project up, excpet for one small niggle .. I can’t seem to get comfortable with the commands calling up an instance of the xmpp object to talk to … to my mind, they should be decoupled from the implementation of the chatclient model .. through either an interface or a wrapper class. I should be able to swap my xmpp model for a newFunkyChatProtocol model without any change to the app or its command structure …

I think .. anyway … but there again I often get confused

One thing I think you might have missed is to add
import org.davekeen.xiffer.model.XMPPProxy
near the start of StartupCommand.as - trying to build the project without it results in “Error: Call to a possibly undefined XMPPProxy” after registering the new proxy.

Other than that, works like a charm!

There aren’t any hard and fast rules to this - its really up to you how you split up the proxies. However, here are some things that I personally think about:

o If a proxy contains methods that operate on a specific logical concept then seperate it out. For example, in an address book application all the methods to do with contact CRUD might be in ContactProxy and all the methods to do with import/export might be in ImportExportProxy.
o I often put things that access different remote services into their own proxies. For example, if our Jabber application also got information about users via a web service these methods might well be in their own proxy.
o Sometimes there is a fairly direct map between the services in your proxy, delegate and backend so I try to keep these synchronised. For example, if I have a large AMFPHP application I’ll have UserProxy only calling methods in UserMethods.php, etc. This means that the way the backend is compartmentalised sometimes dictates the way the proxies are split.
o Its often good to try and get all similar functionality into a single proxy for purposes of re-use. I always try to split them up in such a way that if I decide that I want to use ‘UserProxy’ in a new application it contains everything to do with users.

But, when you get right down to it, split the proxies however you feel most comfortable - they are there for your convenience!

Hope that helps,

Dave