Re: Tiger development Panther deployment
Re: Tiger development Panther deployment
- Subject: Re: Tiger development Panther deployment
- From: Andy Lee <email@hidden>
- Date: Sun, 29 May 2005 21:37:05 -0400
On May 29, 2005, at 8:24 PM, Frédéric BLANC wrote:
But this was an example for the more global question: what are the
best practices to code in a single source the best of Panther &
Tiger's worlds ;) ? (Reminder: My app is Cocoa-Java-based…) Thx to
keep your attention on the main issue… or I won't give examples
anymore :) ! (Just kidding…)
:) Heh, sorry for digressing...
Bob's answer makes the most sense to me for the general case of
deprecated methods vs. possibly nonexistent newer methods. Check
whether the object responds to the newer message, and if so, send
it. In Objective-C, it's an extra two lines. The corresponding Java
logic using reflection requires a bit more work, something like this
(untested code):
try
{
// Seeking a method with signature setResizingMask(int).
Class parmTypes[] = { Integer.TYPE };
Method meth =
NSTableColumn.class.getMethod("setResizingMask",
parmTypes);
Object methodArgs[] = { new Integer(myResizingMask) };
// The method exists, so invoke it.
meth.invoke(myTableColumn, methodArgs);
}
catch (NoSuchMethodException nsme)
{
// The method doesn't exist, so fall back on the deprecated
// method.
myTableColumn.setResizeable(myResizeableFlag);
}
catch (NullPointerException npe)
{
// ...do something...
}
catch (SecurityException se)
{
// ...do something...
}
This seems rather cumbersome compared to the Objective-C way, but I
don't see how else to do it in Java. An alternative would be to
build different .class files for Tiger and pre-Tiger, and decide at
runtime which class file to load, but that's also cumbersome.
Checking for existence of individual methods is one backwards
compatibility issue. There are also, obviously, entire frameworks
and idioms you'd have to avoid to remain backwards compatible, like
CoreData.
--Andy
_______________________________________________
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