In this manual demo you will learn how to work with the Object Browser and manipulate your own Objective-C business objects - while running live. This will occur both within Workspaces and within the coding pane of the Object Browser. We will also describe how you can improve the textual representation of objects in the Object Browser. |
![]() |
If you use Xcode in concert with ActiveDeveloper, then open CocoaDemos.pbproj in the Demos-Cocoa directory. Select the SampleBrowser 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.
Now drag the SampleBrowser's 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 SampleBrowser becomes the current projectimage in the ActiveDeveloper Project Window. Press Start in ActiveDeveloper and you should see the SampleBrowser application executing.
Drag the workspace.wsp file to the ActiveDeveloper app icon in the Dock.
This will open the ActiveDeveloper Workspace in the SampleBrowser project.
Drag the two Class category files to the ActiveDeveloper app icon in the Dock.
This will open ActiveDeveloper Class Editors on the two files.
Clicking on a method names in the left middle interface pane brings the corresponding method into view in the right source code pane. You can 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.
We will follow the comments in the workspace during this manual demo, to build and improve an object structure of Objective-C Business Objects - while the application is running live. We recommend reading the code first to form an understanding of what it is achieving rather than quickly highlighting and executing the code segments. In this way you can test if you can anticipate what will happen. After you have done this, read on....
We are going to use ActiveDeveloper to manipulate the existing set of data, it comprises of Arrays containing Teachers, Students and Classrooms. Students are represented as NSStrings.
The second segment of code is intended to create a new Teacher and populate it's associated Students. The Students are picked from the existing Array of Students. We also show a technique for improving the information level displayed by objects in the Object Browser. After this we show how to use the Object Browser to change live attributes belonging to the Teacher object.
From the workspace, highlight and inspect (Click Inspect) the first segment to present the runtime Object Browser. (Please read Manual1 first if you are not yet familiar with using ActiveDeveloper Evaluate, Display and Inspect).
Browse around this network of objects to understand the structure being used. In a sense the Arrays form our database. (For not yet registered users: If you have browsed the object structure quite a bit to get familiar with it. You might want to quit ActiveDeveloper here and relaunch this example before continuing)
The second segment of code illustrates how we can incrementally develop a new -addNewTeacher; method. Being able to run them interactively against live instances provides us with a rich experimental working area (the workspace). The following explains how this segment has been constructed.
id studentArray = [[NSApp delegate] studentArray];
id teacherArray = [[NSApp delegate] teacherArray];
The AppKit has a global reference to NSApp, this is our starting point. From NSApp we can retrieve references to its delegate ([NSApp delegate]) from this instance we can retrieve references to the database Arrays. Now studentArray and teacherArray refer to original Arrays. This allows us in the following code to access the objects contained in them and alter them if we need.
id teacher;
int startPos, length;
These create temporary variables, active for the duration of the execution.
teacher = [[Teacher alloc] init];
We can refer to the Teacher class because we imported Teacher.h in the import pane in the workspace. In effect we expanded the workspace's context.
[teacher setTeacherName:[NSString stringWithFormat:@"New Teacher"]];
Here we use standard Objective-C code to initialize the teacherName attribute. I know the attribute name from seeing it in the Object Browser.
startPos = 4;
length = 5; // The next 5 students in studentArray will be assigned.
[teacher setStudents:[studentArray subarrayWithRange: NSMakeRange(startPos,length)]];
Again a standard piece of Objective-C to initialize the teacher's set of Students.
[teacherArray addObject:teacher];
Remember that teacherArray references the original Array created when the application starts. So this piece of code is adding a new teacher to the teacherArray that we saw in the runtime Object Browser.
[teacher release];
Another piece of standard (in this case good practice) Objective-C code to ensure correct
releasing of references to Objects.
return teacher;
This statement is for the benefit of the inspect function. Inspect will open the inspector on the last object returned. So this code ensures that we get a meaningful object back for the benefit of this demo.
So when we execute this code either by Display or Inspect, the result will be that a new teacher will appear in the teacherArray shown in our Objecct Browser.
When you are using the Object Browser for real development, you will find that the default textual representation (or description) of objects is seldom very informative. <Teacher: 0xbec500> is ok for memory purposes but you need to `drill' further into the object to find attribute values that are unique in the problem domain e.g. the teacher's name, in order for you to know which object you are looking at. The next set of comments in the workspace are aimed at showing you how to improve the information that an object can provide about itself.
-(NSString *)description;
is a method defined on NSObject here is the documentation provided by Apple.
Returns an NSString object that describes the contents of the receiver. The debugger's print-object command indirectly invokes this method to produce a textual description of an object.
Now ActiveDeveloper brings a new use for this method. If we write our own description method for each class that we create, we will see this string displayed in our inspectors. Remember that we can change this method whenever we need different information. So depending on what is important to us at the time we can write a description method to suit our needs.
Uncomment the lines within Teacher's methods and Classroom's methods and reload these class categories.
Now click on the teacherArray.
Now we are provided with good business domain level information about each Object. Remember, you are in control as to the amount and kind of information displayed.
Returning to the subject of referencing the objects created by the application. We have seen how we can obtain references in the workspace. Now we will see how we can use the inspector directly to manipulate objects. After all, the inspector is a graphical front end for displaying object references.
As previously mentioned in the coding pane of the Object Browser the context for self is the currently selected object. So when you select a teacher in the Object Browser, self in the coding pane below will now be bound to that teacher object. Select the new teacher just created, copy and paste the code from the workspace to the coding pane and evaluate it.
Click on the Array index to allow the inspector to refresh, you now see from the detailed description that the attribute teacherName has the new value. This occurs because within the context of the coding pane, self is the teacher object that has been selected. The following code segment reinforces this. Keeping the
new teacher selected copy the next piece of code from the workspace to the inspector coding pane, and evaluate it.
Browse over to the classArray, select the last object in the list and then the teacher array. You will now see that the NewName teacher has been included.
Check with the apps Object Browser to confirm that the eight grade has now got NewName as a teacher.
Yes it has - so our "addNewTeacher" code works, and we can copy it out of the Workspace where it has been grown, and make an -addNewTeacher; with the code.
Notice: ActiveDeveloper allows you to script with Cocoa directly in native Objective-C.
So, you can now copy and paste directly from your Workspace to an Objective-C method, no editing
or testing is required ... Cool ... right ..
If you had written your code in a non-Cocoa scripting language, you would now
have needed to convert the scripting code into an Objective-C method - and have performed more testing
to ensure this conversion was correct.
In this manual demo we have concentrated on how to build and manipulate live application objects (i.e. interactively while the application is running) from both ActiveDeveloper Workspaces and from the coding pane within the Object Browser. And you have seen how to improve the textual representation of objects as described in the Object Browser by overriding the -description; method.
Imagine, that all the Business Objects in this Manual demo was your projects standard testing object strucure and came directly from a Database server - and at each launch of your app you had to go through a number of windows to load the correct Business Objects to get to your current test case ...
By using ActiveDeveloper and incremental runtime programming you reduce this time consuming cycle to recompile, relaunch and reload your data (for each change) down to zero. Allowing you to get more work done per debug session and with more clarity.