ObjectProxy in Flex 2

ObjectProxy in Flex 2 (continued) I went over the problem of the null responder, and a solution, in the last discussion of Delayed Instantiation. This deserves a deeper look because it is a frequently misunderstood and misapplied area of the Flex framework. Fortunately, Adobe provides the source code for ObjectProxy, and it can be found in the Flex SDK under [Flex SDK Folder]’frameworks’source’mx’utils’ObjectProxy.as. I’ll dig into one particular area, the getter function, as that was what was in doubt in the example.

/** * Returns the specified property value of the proxied object. 
** @param name Typically a string containing the name of the property, 
* or possibly a QName where the property name is found by 
* inspecting the localName property. 
* * @return The value of the property. 
* In some instances this value may be an instance of 
* ObjectProxy. 
override flash_proxy function getProperty(name:*):* { // if we have a data proxy for this then 
   var result:Object = null; 
   if (notifiers[name.toString()]) return notifiers[name]; 
    result = _item[name]; 
    if (result) { 
       if (_proxyLevel == 0 || ObjectUtil.isSimple(result)) 
           { return result; } 
           { result = object_proxy::getComplexProperty(name, result); } 
// if we are proxying } 
  return result; 

In the traditional use of the Virtual Proxy, the caller is requesting the value of some property. The only way to access this property is through the accessor interface, or the getter, which is what is listed above. Now, the getter does not simply return the private value and be done with it. It can do several things. In this case, it does the following: 1) Check to see if we are waiting for a response on this item (from the notifiers). If so, pass back a reference to the notifier. 2) Get the indexed item, and if it is a simple object (a Number, say) or if the _proxyLevel is 0, just return the object 3) Otherwise, send back a proxy to the complex object The caller is never sure what he is going to get, and has to work with the interfaces presented to him. In the first use case, where the Notifier is returned, is this what we see when we are givge, en the null error, as in the last article? Or is this a different case altogether? Now, you think, it would be really handy if I could introspect the proxy to see if it is the real object, or if it is a notifier or proxy. But it would also be the exact opposite of what the design pattern was supposed to encourage, thus reducing the solution’s overall effectiveness, and lowering the measure of loose coupling between those layers. As soon as you start digging inside of the object to find out stuff (not during debug, I am talking about realtime deep uinstrospecting to gain knowledge about the state of an object when it was intended to be encapsulated. This is a good time to go ahead and trace through a test case with the debugger, to see what is going on. Why is there a delay in that object’s instantiation, and why do we get a null error? What are the mechanics of what is going on? What is the proper way to handle these objects with care, to avoid producing that error. And finally, if there is an inherent problem with the architecture, how could it be fixed, so that a deeper look would not be necessary? (continued) Here’s another solution I have seen applied, which eliminates the errors, but we still haven’t fully clarified the root cause yet.:

public function result( event : Object ) : void
   var resultEvent:ResultEvent = ResultEvent(event); 

   var result:ArrayCollection = resultEvent.result as ArrayCollection;
    for (var i:String in result) 
    { result[i] = new ObjectProxy(result[i]);}
    ModelLocator.getInstance().myArray = result;

This looks suspiciously like the code in the previous post, in the framework itself. So, this move compensates for something the framework is not handling for some reason. That is, the result is not being wrapped in a Proxy because of the type of variable the result is being assigned to. So, the return code is doing what the framework would have done, wrapping it in a Proxy, so the Proxy will handle peeking at the contents to see if it’s ready. More can be gleaned from the documentation on RemoteObject, and the ways to handle the results and bindings. The best results seem to come from letting the bindings do the hard work, and to not beat the framework into submission with multiple type casts, and extraneous events. But, sometimes, this seems to be all you can do to make it go… (to be continued)


One Response to ObjectProxy in Flex 2

  1. […] Object Proxy in Flex 2 (cont) (I left off at https://howardscholz.wordpress.com/2007/05/18/there/) […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: