Another Newbie's Insights to cross the Usual Stumbling Blocks Re: Newbie needs help with tableview and bindings
Another Newbie's Insights to cross the Usual Stumbling Blocks Re: Newbie needs help with tableview and bindings
- Subject: Another Newbie's Insights to cross the Usual Stumbling Blocks Re: Newbie needs help with tableview and bindings
- From: Franklin Vermeulen <email@hidden>
- Date: Fri, 25 Nov 2005 11:46:52 +0100
Hi, a while ago, I went through the same learning process (being a
beginning cocoa programmer).
Let me just point out which were the major insights for me.
I apologize to the diehards if the following sounds primitive, or
inaccurate. However, for a beginner there are certain points that are
not well-documented. It isn't that the information isn't there, but
one needs to read (and re-read) every word, even between the lines,
before things start falling into place. True enough, there is a good
example of many concepts in the currency converter tutorial, but when
you are new to document-based apps, it is not immediately clear how
the single-window example extends to document based apps. Even though
I have learned to use (and enjoy) other APIs in the past, it took a
disproportionate amount of time to gain these simple insights.
I used a document-based app, programming in Java. (see the digression
below about java dev. beyond 10.4)
1. I didn't use bindings, just NSDocument's Data Source interface
(sufficient for the job, as pointed out by mmalcolm crawford)
This interface requires you to implement 3 methods: a data getter, a
data setter
AND THE numberOfRowsInTableView METHOD.
It is the TableView that finds out from the Data Model how many rows
there are. Nothing needs to be done to define the number of rows in
the TableView.
Therefore, you need to set up the data model quite early on, so that,
as soon as the NIB is loaded, you can start accessing the GUI's
outlets to setup the GUI, e.g., to load the items in pupUpButtons.
Note that the
For the data model I used a plist (NSMutableArray of NSMutableDicts)
because of the ease to read/write xml property list files (basically
a one-liner), but, obviously, any other appropriate data
representation would be fine as well.
Given the above methods, there is bidirectional communication between
the Data Source and the TableView. If there is an update to the data
model that is not caused by a GUI event, then the upload to the GUI
can be forced by calling reloadData() on your tableView.
2. But the first thing that I found not to be clearly documented
(although everything is mentioned, somewhere, if you can find it), is
how the user-written subclass to NSDocument communicates with the GUI.
- One needs to create Outlets in Interface Builder (using the
Attribute Info Pane for the NSDocument subclass)
- The outlets need to be defined as public instance variables
(labeled as IBOutlets) in NSDocument. This is done automatically if
you (re)generate the NSDocument subclass, but unless you want to go
through the hassle of merging new additions with previously written
code, you want to do this only once. Therefore most outlets are
defined manually in the NSDocument subclass.
- Similarly, action methods are initially automatically generated in
the initial MyDocument
- Connect the above defined outlets and action methods by control-
dragging between MyDocument and the appropriate GUI element.
[Digression]
BTW, I am far from happy with Apple's decision to give up support
for java (which, understandably is a great
drain of Apple resources -- see below).
I wouldn't mind having to look up things in the Obj-C
documentation. (Occasional notes on java issues would
suffice, after all that's what links in html based documents are
for)
I am sufficiently familiar with SmallTalk to have a nodding
knowledge of Obj-C,
but guess I am hesitating to move to Obj-C because of its lack of
automatic memory management.
But, even without java documentation on Cocoa, I suggest Apple
continue to support multilanguage devlopment,
including any shims between Obj-C and java that would entail.
Surely that would be much less work for Apple than producing two
almost identical versions of the documentation in Obj-C and java.
[/Digression]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden