Recently I had the same issue you were having, sort of. And I came
up with
a solution I really liked.
When I was playing with Distributed Objects, I fell in love with the
abstract simplicity. However, it blocks and that's bad. It's even
worse when
the server stops responding, because you could potentially have a
60 second
timeout before the single method will return. It's a potential
disaster.
So, I wrote an elegant compromise. Code is still written inline, no
callbacks or delegate messages needed. But, it requires Blocks (and
thus
10.6) to work.
Essentially, I wrote some code on top of AsyncSocket (which is a
brilliant
framework by the way) that allows me to wrap up ObjC messages as
NSData,
send it across the server, and unpack it on the other side. The
other side
then responds to the ObjC message as if it was called right inside
the
application. (All this is thanks to NSInvocation's ability to
introspect an
ObjC message, by the way).
The problem came when I had to return values. As long as the return
value
was void, this worked like a charm. But once I wanted to return an
array of
strings or a number, I had to define a method in the sender's
protocol to
receive such information. This is akin to your "thousands of delegate
messages" you would have to implement, as you stated.
So, using Blocks and NSInvocation and AsyncSocket, I ended up
writing code
that allows me to write code like this:
// protocol.h
@protocol ServerProtocol
- (NSNumber*) calculatePiAndKillTime:(NSNumber*)shouldKillTime;
@end
// client.m
- (void) someMethod {
id <ServerProtocol> server;
NSNumber *sure = [NSNumber numberWithBool:YES];
[[server calculatePiAndKillTime: sure]
returnedValue:^(id value) {
// this will be called later on at some point
NSLog(@"pi = %@", value);
}]
}
// server.m
- (NSNumber*) calculatePiAndKillTime:(NSNumber*)shouldKillTime {
if ([shouldKillTime boolValue])
// synchronously watch some film
[self goWatchTheNewStarTrekFilmFrom2009];
return [NSNumber numberWithFloat: 3.14];
}
All methods sent to a destination's proxy are sent asynchronously.
And, as
you can see, the return value of the method -
calculatePiAndKillTime: is not
actually an NSNumber, but rather a proxy that waits for a response
from the
destination. When the destination responds to the source with a
return
value, the method -returnedValue: is called with the value.
But that's only half of the coolness.
The other half is that methods can simply return the value they
want right
inside the method, no hacks necessary or anything by the
programmer. In this
case, we just use this line of code: return [NSNumber
numberWithFloat:
3.14]; and then the NSNumber object is packaged up and sent back to
the
source through the proxy, all automagically.
The main downfall of this is that every argument and return value
must be
an ObjC type, no scalars or structs or anything else will work with
this
system. (Mike Ash explains pretty well on this blog why trying to
support
those things can lead to some unfixable trickiness, which I just
wanted to
avoid altogether.)
If you can't support 10.6, then, this won't work. But hopefully you
can
soon ;)
Good luck.
-Steven
On Wed, Jan 20, 2010 at 11:39 AM, Carter R. Harrison <
carterharri...@mac.com> wrote:
I need some folks experienced with cocoa and socket programming to
weigh
in for me on some design problems I've been having. I'm designing
an
application that acts as a client in a client-server model. The
client
communicates with the server over the network by issuing a request
and then
receiving a response. Requests can only be issued one at a time,
meaning
that a request cannot be sent until a response from any
outstanding request
is first received. My application works in such a way that the it
could
request a handle to an object on the server and then use that
handle in
subsequent requests to retrieve additional information about the
object. I
see two ways of modeling the application - I've tried both and I'm
not
particularly happy with either.
The first is to send a request, and then have the socket block
until a
response is received. This benefit to this model is that it is so
much
easier to write the higher level application code. The issue with
this
model is that over a slow network connection it can take a
considerable
amount of time for the response to come back from the server and
while that
is happening my CPU usage is through the roof b/c the thread is
blocking.
The second way is to send a request and then let the NSInputStream
call a
delegate method when the response data is available. The response
data is
then pushed up through my protocol stack and finally up to the
higher level
application code. The benefit to this method is that CPU usage is
minimal
due to the fact that I'm no longer blocking, but the downside is
that the
higher level application code is so much more difficult to write
because I
have to write about a thousand methods to act as a callback for
each request
in a series of requests.
I've provided an example of how I see each working below. My first
question is, is there other ways to design an application around
this
client-server model that I'm not thinking about? My 2nd question
is, if
there aren't other ways, how can I adapt either method that I have
outlined
to make it work a little bit better?
As an example let's say the server knows about the following
objects:
1. VendingMachine
- An object that represents a vending machine.
- A vending machine contains Soft Drink objects.
2. SoftDrink
- Has the following properties: drink name, price, number of
calories.
If I use the blocking model, I could write my code like this. The
code is
simple to write but I'm forced to wait for the server to respond
with
information on pretty much every line of code. If the vending
machine had
enough soft drinks it could take a long time to iterate over each
one and
have the server respond with the drink's name of each drink.
-(void)printDrinkNames
{
VendingMachine *machine = [server fetchVendingMachine];
NSArray *softDrinks = [machine getSoftDrinks];
for (int i = 0 ; i < softDrinks.count ; i++)
{
NSString *drinkName = [[softDrinks objectAtIndex:i]
name];
NSLog(@"Found a drink named %@", drinkName);
}
}
Likewise if I do the non-blocking approach I would have to have a
method
that gets called for each step in the process (see below). This
model
drives me crazy b/c the higher level application code is long, has
tons of
methods, and is just difficult to read and maintain. The example
I have
provided is simple enough to get the point across, but in reality
some of
the processes I'm trying to drive are much more complex and
require numerous
callback methods to pull off.
-(void)printDrinkNames
{
[server fetchVendingMachineWithCallBackObject:self
selector:@selector(didFetchVendingMachine:)
}
-(void)didFetchVendingMachine:(VendingMachine *)machine
{
[machine fetchSoftDrinksWithCallBackObject:self
selector:@selector
(didFetchSoftDrinks:)];
}
-(void)didFetchSoftDrinks:(NSArray *)drinks
{
for (int i = 0 ; i < drinks.count ; i++)
{
SoftDrink *drink = [drinks objectAtIndex:i];
[drink fetchNameWithCallBackObject:self
selector:@selector
(didFetchDrinkName:)]
}
}
-(void)didFetchDrinkName:(NSString *)name
{
NSLog(@"Drink name is %@", name);
}
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/steven.degutis%40gmail.com
This email sent to steven.degu...@gmail.com
--
Steven Degutis
http://www.thoughtfultree.com/
http://www.degutis.org/
