ActiveDeveloper Sessions ...
10) Workspace files (*.wsp) - What are they ?
*.wsp |
is the new ActiveDeveloper Workspace Objective-C file type. |
They give you an interactive scripting shell for native Objective-C code.
You type in compound statements of Objective-C code, select them, and have
them executed immediately with edit-compile-play cycles like 1-2 seconds.
The Workspace editor gives you two text panes for editing your Workspace files.
In the upper text pane you write eventual #import statements #define statements
and in the lower text pane you can edit Objective-C statements and make
selections for execution.
The namespace (scope) used for executing your Objective-C code selected in a
Workspace file is the global namespace - or a Qualified Class namespace if you
type a class name into the top text field.
Check the following questions on how to make selections and execute them.
Back to Index
10) How to use Workspace files (*.wsp) ?
Workspace files (*.wsp) are your new ActiveDeveloper friend ...
A Workspace is a place for growing Objective-C code interactively
with immediate feedback that it works as intended. This can be used
for many different purposes:
New code |
Many Workspaces are play fields for new code, and will loose
their importance over time, as you have grown the code and
incorporated the essence of it over to your Classes. |
|
Testing |
Some Workspaces are holding Testing code and live on forever
along with your Project code. You don't have to make separate
Testing applications in their own Xcode projects anymore. |
|
SysAdmin |
Other Workspaces are more shell script like, holding those
15 small Project related calls, that you use day in and day out.
But haven't yet found the time to build into a full application.
|
Check the following questions on how to make selections and execute them.
Back to Index
11) How to use Eval, Display and Inspect ?
You will notice Eval, Display and Inspect buttons in several ActiveDeveloper
windows - in Workspaces, the Object Browser and in Class Editors:
They all work similarly - giving you a scripting shell for native Objective-C
code with edit-compile-play cycles like 1-2 seconds.
Evaluate |
Compiles and executes your code in the window scope, where it
is selected. This makes sense whenever you want to just check
syntax, change state or create side-effects on your object structure.
The return value of your code is ignored. |
|
Display |
Compiles and executes your code in the window scope, where it
is selected. The resulting value of your selected code, which is
regarded as anObject or nil, is then Transcribed into an NSString
and showed in the System Transcript. (Using the -description; method) |
|
Inspect |
Also compiles and executes your code in the window scope, where it
is selected. The resulting value of your selected code, which is
regarded as anObject or nil, is then added to a the Object Browser
for Inspector. From here you can then continue to work with
the Resulting Object, view it's Instance Variables and also Browse
around the entire Object Graph behind this object. |
To apply them, you simply Select a compound statement of Objective-C code
and click one of the buttons - et voila - off you go.
You can also copy and paste code from a Workspace file into the Object Browsers
text pane. This works similarly except that your namespace (scope) for self changes
to become that of the currently inspected object in the Object Browser.
Here is an overview of namespace (scope) for self across the windows.
- Workspaces have Global Scope
- Class Editors have Class Scope
- Object Browsers have Object Scope
- plus Workspaces can have Qualified Class Scope - if you set the top text field.
Check the following questions on how to make selections and execute them.
Back to Index
12) How to use appropriate Objective-C Selections ?
With ActiveDeveloper, you can select compound Objective-C statements
in all your windows. A compound Objective-C statement is a selection
of code that would qualify for being isolated into a method of its own.
Here are three simple, but illustrative Examples:
[NSArray arrayWithObjects: @"First", @"Second", nil];
return [NSArray arrayWithObjects: @"foo", @"bar", nil];
id result;
result = [NSArray arrayWithObjects: @"A", @"B", @"C", nil];
If you select a Statement in the middle of a method, ActiveDeveloper
will append a return on the fly. So, the last line of your selection should be
a valid statement by itself or an explicit return anobject; statement;
- and don't include any empty lines at the bottom of your Selection.
Finally, if you want to define Local Variables, you should do this before
the first real Statement - just like you would inside a Method scope.
Check the User Guide Manual Demos and Samples for more details.
Back to Index
13) How to use the Class Editor ?
With the ActiveDeveloper Class Editor you can create New Classes in
source code form, and have them Loaded directly into your running
application under development.
The Class Editor open Classes from *.m files and when you Save,
it will also auto-generate their accompanying Header files *.h.
(This is disabled in the Demo version).
We have provided you with a default Template for Class Definitions. If you
have a better taste for how a Class Definition Template should look like,
you can customize it in the NIB file.
When you create new classes you should also add them to your Xcode
project and rebuild at the next convenient opportunity. Else you will have
load the new class again next time you launch an ActiveDeveloper session.
For further Details: See Header File Creation:
Back to Index
14) How to use the Class Category Editor ?
With the ActiveDeveloper Class Editor you can also create Class Categories
in source code form, and have them Loaded directly into your application
under development.
The Class Editor open Class Categories from *.m files and when you Save,
it will also auto-generate their accompanying Header files *.h.
(This is disabled in the Demo version).
We have provided you with a default Template for Class Categories. If you
have a better taste for how a Class Category Template should look like,
you can Customize in the NIB file.
For further Details: See Header File Creation:
Back to Index
15) How to use automatic Header file Generation ?
With the ActiveDeveloper Class Editor you only have to use the *.m source files
when you edit Class Definitions and Class Categories. When you Save them back,
ActiveDeveloper will auto-generate their accompanying Header files *.h.
Both the Class and the Category Editor give you 4 text panes to work with.
Left |
1) The top interface view goes first into the Header file as a
Prefix and is used for #imports, #defines and module scope variables.
2) The middle interface view is auto-generated class interface
code extracted from the Right side implementation view - and goes
second into the Header file. This view is therefore read only.
3) The bottom interface view goes last into the Header file as a
Suffix and is used in Class files to #imports the Class Category
header files. This encapsulates the Class / Category splitup inside the
Class Definition ... keeping the rest of your code un-aware |
|
Right |
The source text view to the right is for your implementation.
The text here will be Saved into the implementation files *.m |
Please enjoy the middle left interface view also as an Outline view
of your Source code ... Click any of the methods signatures in here to navigate
around your source code in the right view.
Class Definition interface generation:
ActiveDeveloper converts @implementation { } -method; @end sections in your source
code to form identical @interface { } -method; @end sections in your header files.
Class Category interface generation:
ActiveDeveloper converts @implementation (Category) -method; @end sections in your
source code to form identical @interface (Category) -method; @end sections in your
header files.
Method Declaration generation:
ActiveDeveloper extracts method declarations from your method
implementations. This is done by selecting all method implementations
having +/- as first character on the line, and transcribing these up
until and including any eventual semi-colon ;
To keep some methods Private, simply put a space before their +/-.
To implement short methods in 1 line of code, like getters/setters,
simply put a semi colon between the signature and the implementation, like:
- (id)myOnelineGetter; { return object; }
To make Classes conform to Protocols, please put the <protocol> conformance
behind a // comment on the Class @implementation definition line, as below:
@implementation MyClass : NSObject // --- <protocol> ----
.....
@end
Check the User Guide Samples on Activation for more details
Back to Index
|