Manual 2 - Class Editor: Build and re-build Classes (Silly Balls)

In this manual demo you will see how to use the ActiveDeveloper Class Editor. We wil use it to change existing methods and then load those changes into a running application.

We will also use the Class Editor to create new methods and see how ActiveDeveloper autogenerates an interface for this method to the ObjC headerfile - allowing you to keep both .h and .m in sync from a single source.

Finally we will use the runtime Object Browser to allow you to do incremental testing.

Start Xcode.

If you use Xcode in concert with ActiveDeveloper, then open CocoaDemos.pbproj in the Demos-Cocoa directory. Select the SonOfSillyBalls as your current working project to be ready to use Xcode for project control and as a Drag & Drop resource for easy access to (*.m, *.wsp and *.projectimage) files from ActiveDeveloper.

Start ActiveDeveloper

Now drag the SonOfSillyBalls AD-Mac.projectimage from Xcode to the ActiveDeveloper app icon in the Dock, to open it or double click it if ActiveDeveloper isn't already running. Notice that SonOfSillyBalls becomes the current projectimage in the ActiveDeveloper Project Window. Press Start in ActiveDeveloper and you should see the SonOfSillyBalls application executing.

Open a ActiveDeveloper Class Editor

Drag the SillyBallView+Methods.m category source to the ActiveDeveloper app icon in the Dock. This will open an ActiveDeveloper Class Editor on the methods category for the class SillyBallView.

Clicking on a method name in the left middle interface pane brings the corresponding method into view in the right source code pane. You will now make changes to the source code in this pane and follow it by clicking load (top left button), ActiveDeveloper immediately loads and activates a new edition of the source into the currently executing application and you can see the change take effect immediately without having to stop the application, recompile, link and run.

Perform some dynamic code changes

Navigate to -drawRandomBallInside: read the comments and try to edit the code, by commenting out the following line

[[NSColor colorWithDeviceRed:RandFloat() green:RandFloat() blue:RandFloat() alpha:1.0] set];

and un-comment the following statement

// PSsetgray(RandGray());

Click load and watch the SillyBallView change implementation of it's drawing source on the fly,
now drawing in Black and White

You just witnessed the essence of scripting with Objective-C: change a method, load it, run it. This dramatically improves programmers effective programming speed. The reduction in `wait for new build time' means that programmers can continue to think about the work at hand and not have their concentration interrupted with the compile-link cycle.

HowTo: Change the text string drawn in each square.

A word of caution is needed here. Method changes are effective immediately, but if they are not getting called in the running code, you will of cause not notice. Let's demonstrate, by trying to change the textString being displayed in each spot, without stopping the application from running:

First Idea: Locate -initWithFrame:

We see that the textString attribute is initialized in the method called -initWithFrame:. What if we change that to "AD" and reload.

Surprise - nothing happens. How come ?

The method -initWithFrame: is executed only once during startup. When we edit and load this code, it simply has already been called in our debugging session and our incremental change doesn't show - except if we 'Save' and rebuild with Xcode. But then we have to quit our ActiveDeveloper session, and 'Start' again from ActiveDeveloper when Xcode is done building

Second Idea: Locate -drawRandomBallInside:

To help you find this out, ActiveDeveloper allows you to set the textString on the fly. At least the drawing method -drawRandomBallInside: must be called repeatedly. So, try to hardwire this one to set the textString before drawing. Add:

textString = @"AD";

Now that was better, it worked. Though we might not like doing it like that. At least we have now found out that we understand the code well enough to make the change. And the SillyBalls app is still up and running.

Third Idea: Add an -setTextString: accessor method - on the fly.

Lets refactor the code a bit by adding an accessor -setTextString: for the text attribute. And then call this from -drawRandomBallInside: instead of setting it directly.

ActiveDeveloper also allows you to do that on the fly - keeping your debugging session flowing - as we will see in the next section.

Creating methods on the fly with ActiveDeveloper

Create a setter method using the ActiveDeveloper Class Editor.
Type the following code between two methods in the right hand source code pane of SillyBallView+Methods.m. (Possible only after you have purchased a license key)

- (void)setTextString:(NSString *)string;   { [textString release]; textString = [string retain]; }

After you have Registered your copy of ActiveDeveloper you can also 'Save' your changes.
You will then notice how the method signature also get's displayed in the left side interface file pane - by ActiveDevelopers automatic header file creation.

ActiveDeveloper keeps the implementation and interface files synchronized for you. To see this, look at SillyBallView+Methods.h and you will see that an interface definition for setTextString: has been written for you (Possible only after you have purchased a license key).

Testing new methods

At this point we have created a new accessor method and loaded it. Before we write code using the new setter, lets use ActiveDeveloper to test it before we go to the trouble of editing existing methods. (Possible only after you have purchased a license key)

We will use the runtime Object Browser to provide us with the SillyBallView instance. Given this context then we can send it the setter method directly and see if it works.

Open the Object Browser and traverse the following references.

In the coding pane type [self setTextString: @"AD2"]; and evaluate it. The result should be similar to the following

Now we know that the new accessor method works, we can safely proceed to use it by adding the statement in -drawRandomBallInside: .

[self setTextString: @"AD"];

And we are still running in the same ActiveDeveloper session

Now if you had a registered copy of ActiveDeveloper you could simply:

So ActiveDeveloper can be used in concert with Xcode as an interactive source code editor for Objective-C - combining debugging and development.

Closing Comments

We have seen how to use the ActiveDeveloper Class Editor to change existing methods and load those changes into a running application and we have used the Class Editor to create a new method and seen how ActiveDeveloper synchronize code changes with the interface file.

We have also seen how to use the runtime Object Browser to manipulate objects directly during a runtime session.



Home News Jobs Products Download Purchase Consulting Contact Us