date:20100120

On Jan 20, 2010, at 5:22 AM, Jens Miltner wrote:

> Am 20.01.2010 um 11:34 schrieb Jeremy Pereira:
> 
>> On 19 Jan 2010, at 23:06, Jens Alfke wrote:
>> 
>>> On Jan 19, 2010, at 10:46 AM, Kirk Kerekes wrote:
>>> 
 NSDictionary will use almost any object as a key:
 
 From the docs:
 "In general, a key can be any object (provided that it conforms to the 
 NSCopying protocol...)"
 
 -- and if it is an immutable object, that -copy is just a -retain.
>>> 
>>> Yes, but he said he wants to use a view as the key. Views are not 
>>> immutable, and do copy themselves in response to -copy. Having a dictionary 
>>> whose key objects are copies of your live views is not very useful. 
>>> (Especially since the copied view will have a different hashcode from the 
>>> original one, so you can't even look it up using the original view 
>>> anymore...)
>> 
>> Well he could write a category to give him an object that satisfies all the 
>> criteria e.g (written in Mail).
>> 
>> 
>> @interface NSView(DictionaryKey)
>> 
>> -(NSNumber*) dictionaryKey;
>> 
>> @end
>> 
>> @implementation NSView(DictionaryKey)
>> 
>> -(NSNumber*) dictionaryKey
>> {
>>  return [NSNumber numberWithUnsignedLongLong: (unsigned long long) self];
>> }
> 
> Slightly safer (because it does not make explicit assumptions about pointer 
> sizes):
> 
> -(id) dictionaryKey
> {
>   return [NSString stringWithFormat:@"%p", self];
> }
> 
> 
> Sorry, couldn't resist ;-)

Um, if you're going to go that route, use +[NSValue 
valueWithNonretainedObject:].  Playing with strings or NSNumbers is doing it 
the hard way.  But, if you can use it, NSMapTable (as mentioned previously) is 
probably more appropriate.

Regards,
Ken

___

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSTextView font problem using arraycontroller

2010-01-20 Thread Grant Christensen

Hi all,

I have an array controller that is feeding a NSTableView on a window.  Also on 
the window are a few text fields showing the contents of the selected row 
(shows more than table).  One of the fields is an NSTextView.

I am having a problem with fonts in the text view (google searches show this is 
no stranger to font idiosyncrasies).  

When I click on a row in the table the text view shows the data under that row 
for that field, which is a multi line string.  The font used seems to be the 
default font, not what I have set for the view.  I can then set the font for 
the view using setFont and/or setTypingAttributes:
[atisView setFont: font];
NSMutableDictionary *attributes = [[NSMutableDictionary alloc] 
init];   
[attributes setObject: font forKey: NSFontAttributeName];
[atisView setTypingAttributes:attributes];

However each time a new row is selected it reverts to the default font again.  
I have a slider that allows the user to change the font size used for the 
window, and triggering that resizes the font to the correct size again, but 
that is not a suitable solution.

Any thoughts on how to make the font I set stay as the font between row changes?


---
Grant Christensen




___

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Unable to recieve mouse moved events on NSBorderless window

2010-01-20 Thread Poonam Virupaxi Shigihalli


Hi,

I am using NSBorderless window style mask for window to set in full screen 
mode. I am unable to recieve the mouse moved event on borderless window.
If I set the window style mask to titled I am able to recieve  mouse moved 
events.

I have set in awake from nib  
[window  setAcceptsMouseMovedEvents:YES];

And using mousemoved: function to detect the event.


Thanks

___

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Problem using bindings with deep key paths

2010-01-20 Thread Gwynne Raskind

This is most likely a very basic question, but I seem to be stumped just the 
same.

I have an application nib (MainMenu) set up such that it instantiates the 
NSApplication delegate and the application's main window.

The application delegate class has a property "player". The player is an 
instance of a class Player, which has as a property "track", which is 
(naturally enough) a Track object. Finally, the Track object has a property 
"info", which is again obviously an Info object.

The Player object is effectively constant; from a KVO perspective, it never 
changes over the course of the application. The Track object it contains 
changes often, and therefore the Info changes as well.

I created an NSObjectController at the top level of the nib, and connected its 
"content" outlet to the application delegate. I then created a second 
NSObjectController, and bound its "contentObject" binding to "selection.player" 
on the first controller. Repeat inwards until there are four controllers, one 
for each level of the above-described model objects. (This is not the natural 
configuration, but rather one of the variants I tried in the process of trying 
to make this work. The original configuration was a single object controller 
bound to the app delegate.)

Finally, I bound several views' "value" bindings to the controller for the Info 
object, with the appropriate model keys for the Info class, one of which is the 
aptly-named "title" (not to be confused with Sir Not Appearing In This Film). 
The full key path for the NSTextField in question is 
"selection.player.track.info.title", where selection is the app delegate.

It didn't work. The UI did not update with the values in the Info object for 
the given Track in the Player. I tried a couple dozen things, and finally found 
that the UI updated correctly when I generated a fake KVO notification for the 
"player" key in the application delegate.

It seems to me that this means that the object controller(s) are not observing 
the changes made to the various sub-objects of the application delegate. In 
other words, given the key path "player.track.info.title", any change to any 
key along that path is ignored unless "player" is considered to have changed as 
well. I've verified that all the accessors are fully KVC and KVO compliant 
(most are synthesized properties), and I've tried a long list of combinations 
of flags on the controllers and individual bindings.

Is this a design failure on my part, or am I trying to do something that 
bindings can't handle? To summarize, I want my UI to update any time I change 
the current Track object, which is contained by the "constant" Player object. 
This all worked very nicely and very neatly when I was using outlets and doing 
the KVO bits myself; the only issue I had with it then was that there were a 
whole lot of outlets on the application delegate...

(Note: The documentation on bindings is quite ancient (some of the screenshots 
are from 10.3's IB, for mercy's sake) and was completely unhelpful.)

-- Gwynne

___

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

iPhone - Device Notifications Status

2010-01-20 Thread Mick Walker

Hello,

Could anyone tell me how I can tell if push notifications are turned on or off 
on a device?

I only need to retrieve the current state of Notifications on the device, I 
don't need to alter the state (I very much doubt that you could even if you 
wanted to.)

Regards
Mick___

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSTextView font problem using arraycontroller

2010-01-20 Thread Jens Alfke

On Jan 20, 2010, at 5:27 AM, Grant Christensen wrote:

> I have an array controller that is feeding a NSTableView on a window.  Also 
> on the window are a few text fields showing the contents of the selected row 
> (shows more than table).  One of the fields is an NSTextView.

What property of the text view are you binding to the controller?

> When I click on a row in the table the text view shows the data under that 
> row for that field, which is a multi line string.  The font used seems to be 
> the default font, not what I have set for the view.

I believe what happens is that if you set a string value for the text view's 
contents, it gets promoted to an attributed string with no styles; but if no 
styles are set the default ones will be used, i.e. 12pt Helvetica.

What I would do is either write a custom NSValueTransformer that will convert 
an NSString into an NSAttributedString containing your desired attributes; or 
bind the controller's value to a property on a custom object of your own, whose 
setter will set the proper value on the text view.

Or just use an NSTextField instead...

—Jens

___

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: iPhone - Device Notifications Status

2010-01-20 Thread Alex Kac

[[UIApplication sharedApplication] enabledRemoteNotificationTypes] != 
UIRemoteNotificationTypeNone

On Jan 20, 2010, at 8:36 AM, Mick Walker wrote:

> Hello,
> 
> Could anyone tell me how I can tell if push notifications are turned on or 
> off on a device?
> 
> I only need to retrieve the current state of Notifications on the device, I 
> don't need to alter the state (I very much doubt that you could even if you 
> wanted to.)
> 
> Regards
> Mick___
> 
> 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/alex%40webis.net
> 
> This email sent to a...@webis.net

Alex Kac - President and Founder
Web Information Solutions, Inc.

"Patience is the companion of wisdom."
--Anonymous




___

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: iPhone - Device Notifications Status

2010-01-20 Thread Mick Walker

Thanks for your reply Alex.

Is there any way I can show the standard "XX Would like to send you Push 
Notifications" alert dialog?

Regards 
Mick

On 20 Jan 2010, at 16:03, Alex Kac wrote:

> [[UIApplication sharedApplication] enabledRemoteNotificationTypes] != 
> UIRemoteNotificationTypeNone
> 
> On Jan 20, 2010, at 8:36 AM, Mick Walker wrote:
> 
>> Hello,
>> 
>> Could anyone tell me how I can tell if push notifications are turned on or 
>> off on a device?
>> 
>> I only need to retrieve the current state of Notifications on the device, I 
>> don't need to alter the state (I very much doubt that you could even if you 
>> wanted to.)
>> 
>> Regards
>> Mick___
>> 
>> 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/alex%40webis.net
>> 
>> This email sent to a...@webis.net
> 
> Alex Kac - President and Founder
> Web Information Solutions, Inc.
> 
> "Patience is the companion of wisdom."
> --Anonymous
> 
> 
> 
> 

___

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: iPhone - Device Notifications Status

2010-01-20 Thread Alex Kac

When you register for notifications that dialog comes up. Once the user has 
said yes to it, it won't come up again.

On Jan 20, 2010, at 11:14 AM, Mick Walker wrote:

> Thanks for your reply Alex.
> 
> Is there any way I can show the standard "XX Would like to send you Push 
> Notifications" alert dialog?
> 
> Regards 
> Mick
> 
> On 20 Jan 2010, at 16:03, Alex Kac wrote:
> 
>> [[UIApplication sharedApplication] enabledRemoteNotificationTypes] != 
>> UIRemoteNotificationTypeNone
>> 
>> On Jan 20, 2010, at 8:36 AM, Mick Walker wrote:
>> 
>>> Hello,
>>> 
>>> Could anyone tell me how I can tell if push notifications are turned on or 
>>> off on a device?
>>> 
>>> I only need to retrieve the current state of Notifications on the device, I 
>>> don't need to alter the state (I very much doubt that you could even if you 
>>> wanted to.)
>>> 
>>> Regards
>>> Mick___
>>> 
>>> 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/alex%40webis.net
>>> 
>>> This email sent to a...@webis.net
>> 
>> Alex Kac - President and Founder
>> Web Information Solutions, Inc.
>> 
>> "Patience is the companion of wisdom."
>> --Anonymous
>> 
>> 
>> 
>> 
> 

Alex Kac - President and Founder
Web Information Solutions, Inc. 

"If at first you don't succeed, skydiving is not for you."
-- Francis Roberts





___

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Socket Blocking Question

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Bindings: NSMutableArray -> NSArrayController -> NSPopUp

2010-01-20 Thread Charles Jenkins


Okay, let me rephrase my question...

If I get a pointer to the NSArrayController and then call 
[myArrayController setContent:gameList], then should the array 
controller "just work"?


In other words, if the game descriptions do not appear in my NSPopUp, 
then the problem just about has to be in the binding of the NSPopUp to 
the array controller, right?


On 2010-01-17 15:17, Charles Jenkins wrote:

I am struggling with bindings. I have worked through the examples in the 
Hillegass book, but it seems that none of the examples using NSPopUp quite 
matches what I need.

In my app, just before a view appears, it gets handed a list of games in an 
NSMutableArray. It makes the array available with -(NSMutableArray*)gameList. I 
want the NSPopUp to contain a list showing the value of -(NSString*)description 
for each item in the list.

I thought I was supposed to do this by adding an NSArrayController to my .nib 
file, and then making the following bindings:
 Array Controller's Content Array = File's Owner.gameList
 NSPopUp's Content = Array Controller.arrangedObjects

At runtime I get a totally empty popup. I can imagine two possibilities for why 
it doesn't work:
a) I've got the bindings wrong
b) The array controller can't handle the fact that the gameList pointer changes 
right before the view gets shown

Can anyone help me get this working?

---

Just in case it helps pre-answer any questions you may have, here are minimal 
descriptions of my classes:

@interface GameScores {
}
-(NSString*)description;
@end

@interface GameViewController {
   NSMutableArray* gameList;
}
@property (retain) NSMutableArray* gameList;
@end

In the .nib file, NSArrayController tries to manage File's Owner.gameList, and 
the NSPopUp is supposed to display the NSArrayControler's arrangedObjects.


___

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/cjenkins%40tec-usa.com

This email sent to cjenk...@tec-usa.com


   

___

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Bindings Problem


On Jan 18, 2010, at 4:55 PM, Ken Thomases wrote:

> On Jan 18, 2010, at 11:01 AM, Jeffrey Oleander wrote:
> 
>> http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/Collections/Articles/Sets.html
>> 
>> "Set Fundamentals: Note that if mutable objects are stored in a set, either 
>> the hash method of the objects shouldn’t depend on the internal state of the 
>> mutable objects or the mutable objects shouldn’t be modified while they’re 
>> in the set (note that it can be difficult to know whether or not a given 
>> object is in a collection)."
>> 
>> So, you can use your own hash function to determine where in the set each 
>> item is stored.  In this case, each item stored in the set is an 
>> NSMutableDictionary.
> 
> And... you can't change the hash function used by NSMutableDictionary.  So, 
> for a custom class, you can implement a custom -hash method.  But for 
> NSMutableDictionary, you can't.  And, if you do implement a custom -hash 
> method for your custom class which is insensitive to the "contents" (whatever 
> that might be) of its instances, then that's a _very_ different equality 
> semantic than NSDictionary provides.
> 
> 
>> http://developer.apple.com/mac/library/documentation/Cocoa/Reference/Foundation/Classes/NSDictionary_Class/Reference/Reference.html
>> 
>> "Internally, a dictionary uses a hash table to organize its storage and to 
>> provide rapid access to a value given the corresponding key. However, the 
>> methods defined in this cluster insulate you from the complexities of 
>> working with hash tables, hashing functions, or the hashed value of keys. 
>> The methods described below take keys directly, not their hashed form."
>> 
>> So, you may use your own hash function to create your keys... or not, as you 
>> wish.
> 
> Um, the keys are not typically the output of a hash function.  Well, you can 
> use such for keys, but that's irrelevant to the hash of the dictionary 
> object, itself.
> 
>> But then the NSDictionary and NSMutableDictionary will hash the keys you 
>> pass to their methods using their own, internal, hash function, to determine 
>> where objects are stored in the dictionary.
> 
> Right.  So, if you mutate the dictionary while it's in the set, you will 
> break things.  That's why a set of mutable dictionaries (as opposed to 
> immutable dictionaries, or some other data structure entirely) raises a huge 
> red flag.
> 
> As I previously cited, from the documentation of -[NSObject hash]:
> http://developer.apple.com/mac/library/documentation/cocoa/Reference/Foundation/Protocols/NSObject_Protocol/Reference/NSObject.html
> 
> "If a mutable object is added to a collection that uses hash values to 
> determine the object’s position in the collection, the value returned by the 
> hash method of the object must not change while the object is in the 
> collection. Therefore, either the hash method must not rely on any of the 
> object’s internal state information or you must make sure the object’s 
> internal state information does not change while the object is in the 
> collection. Thus, for example, a mutable dictionary can be put in a hash 
> table but you must not change it while it is in there. (Note that it can be 
> difficult to know whether or not a given object is in a collection.)"
> 
> Note that this case of mutable dictionaries in a collection is explicitly 
> warned about.
> 
> 
>> But my primary point was to ask the original poster to think about why he is 
>> using this arrangement of instances of NSMutableDictionary stored in an 
>> NSMutableSet.
> 
> Yes, and that was my point, too.

Thanks for the insight guys - you have convinced me to re-think my data model.  
I never even began to conceive of some of the issues you have put on the table.


> 
> -Ken
> 

___

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Socket Blocking Question

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  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  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

Re: Socket Blocking Question

Oops, correction: the downside is that all arguments and return values need
to conform to NSCoder protocol. So, it's even more strict than I described
earlier. But it's still cool :)

-Steven

On Wed, Jan 20, 2010 at 12:40 PM, Steven Degutis
wrote:

> 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  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 throu

Presets & NSPrintPanel accessory view

2010-01-20 Thread Gerd Knops

Hi All,

I use NSPrintPanel's "addAccessoryController:" method to add an accessory view. 
It is used to manipulate some app-sepcific variables inside NSPrintInfo's 
"printSettings".

Most everything works fine, changing the values changes the preview, they are 
stored in Presets etc.

The one thing I can't figure out is to detect when the user choses a different 
preset. I tried observing printInfo, printInfo.printSettings and 
printInfo.printSettings.myCustomValue, but neither produce KVO messages when a 
preset with different values is picked.

The result is that after picking a preset the preview is updated, but my UI is 
not.

So how can my viewController detect when the user picks a preset, or 
alternatively when specific values inside printSettings change?


Thanks

Gerd
___

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Bindings: NSMutableArray -> NSArrayController -> NSPopUp

For your original question, I think the issue is how "it" gets handed the list 
of games and how "it" makes the array available with -gameList. (As you can 
guess, I'm not sure what "it" refers to in your explanation.)

The bindings are re-established from the NIB during NIB loading.  If you change 
the gameList property of the object which is serving as the NIB's owner in a 
non-KVO-compliant manner after that point, then the binding for the array 
controller's content won't follow the update.

I'm not sure if -setContent: on the array controller works.  In fact, I doubt 
it does. If we use the Content Object binding of an array controller as a 
guide, then the content object has to be another array controller.  It makes 
sense to bind the array controller's Content Array binding to the gameList 
property of File's Owner, as you have done.  It's just that you have to make 
sure you're only mutating that property in a KVO-compliant manner.

Regards,
Ken

On Jan 20, 2010, at 12:01 PM, Charles Jenkins wrote:

> Okay, let me rephrase my question...
> 
> If I get a pointer to the NSArrayController and then call [myArrayController 
> setContent:gameList], then should the array controller "just work"?
> 
> In other words, if the game descriptions do not appear in my NSPopUp, then 
> the problem just about has to be in the binding of the NSPopUp to the array 
> controller, right?
> 
> On 2010-01-17 15:17, Charles Jenkins wrote:
>> I am struggling with bindings. I have worked through the examples in the 
>> Hillegass book, but it seems that none of the examples using NSPopUp quite 
>> matches what I need.
>> 
>> In my app, just before a view appears, it gets handed a list of games in an 
>> NSMutableArray. It makes the array available with 
>> -(NSMutableArray*)gameList. I want the NSPopUp to contain a list showing the 
>> value of -(NSString*)description for each item in the list.
>> 
>> I thought I was supposed to do this by adding an NSArrayController to my 
>> .nib file, and then making the following bindings:
>> Array Controller's Content Array = File's Owner.gameList
>> NSPopUp's Content = Array Controller.arrangedObjects
>> 
>> At runtime I get a totally empty popup. I can imagine two possibilities for 
>> why it doesn't work:
>> a) I've got the bindings wrong
>> b) The array controller can't handle the fact that the gameList pointer 
>> changes right before the view gets shown
>> 
>> Can anyone help me get this working?
>> 
>> ---
>> 
>> Just in case it helps pre-answer any questions you may have, here are 
>> minimal descriptions of my classes:
>> 
>> @interface GameScores {
>> }
>> -(NSString*)description;
>> @end
>> 
>> @interface GameViewController {
>>   NSMutableArray* gameList;
>> }
>> @property (retain) NSMutableArray* gameList;
>> @end
>> 
>> In the .nib file, NSArrayController tries to manage File's Owner.gameList, 
>> and the NSPopUp is supposed to display the NSArrayControler's 
>> arrangedObjects.
>> 
>> 
>> ___
>> 
>> 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/cjenkins%40tec-usa.com
>> 
>> This email sent to cjenk...@tec-usa.com
>> 
>> 
>>   
> ___
> 
> 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/ken%40codeweavers.com
> 
> This email sent to k...@codeweavers.com

___

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Blocking for input during a loop?

2010-01-20 Thread Michael Ash

On Tue, Jan 19, 2010 at 1:16 PM, Jens Alfke  wrote:
>
> On Jan 19, 2010, at 6:10 AM, Per Bull Holmen wrote:
>
>> I have made one class called GameController, which is overridden by
>> subclasses to control one specific type of game (PS: I will soon rename the
>> class "Controller" to "MainController", and instance variable "controller"
>> to "mainController"). The GameController base class also mediates between
>> input from the main thread, and the game thread, with help from the class
>> InputBuffer:
>
> You've basically implemented coroutines, actually a simple form of an actor,
> using multiple threads. Each coroutine is running an event loop, and the
> game one blocks waiting for incoming events from the UI one.
>
> (Ideally it's possible to implement this without using multiple threads; I
> tried to do that about two years ago using the low-level ucontext library,
> but it turns out that the stack manipulation it does is incompatible with
> Objective-C's exception handling system.)

You might be interested in my MAGenerator code:

http://www.mikeash.com/svn/MAGenerator/

While generators aren't exactly coroutines, they're equivalently
capable (you just need to create a dispatcher to switch between
different active generators). Of course it's a hack, but I'd say much
less of one than low-level stack manipulation, and all the hack is at
the level of syntax.

For this particular case, MAGenerator would allow you to write the
game code in straightforward top-to-bottom code, while still yielding
control to the event loop. Your event responders would invoke the
generator with whatever the user action was, and control would resume
in the generator where it left off. The HTTPParser example in
GeneratorTests.m illustrates this approach, albeit for a very
different purpose.

Mike
___

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Socket Blocking Question

On Jan 20, 2010, at 11:39 AM, Carter R. Harrison 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.

If you're using lots of CPU time, then you're not blocking, you're spinning.  
When a thread is blocked, it does nothing and consumes no CPU time.

Now, blocking is bad in the main thread of a GUI app, but if you're writing 
non-GUI code, it can be a perfectly sensible design approach.  However, you 
have to actually implement blocking!

Cheers,
Ken

___

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Uncaught exceptions not terminating my app

2010-01-20 Thread Paul Sanders

Greetings all,

I am experiencing a strange problem with the handling of uncaught exceptions
which I'm hoping someone can shed some light on.

This document:

http://developer.apple.com/mac/library/DOCUMENTATION/Cocoa/Conceptual/Exceptions/Tasks/ControllingAppResponse.html#//apple_ref/doc/uid/2473

states that certain classes of exception will terminate the app if they are not
caught. But this is not the behaviour I observe. To take a specific example,
executing this code:

[NSObject noSuchSelector];
foo ();

Just abruptly returns to the main event loop (and the call to foo (), and
whatever follows, is never executed). This is _not_ the behaviour I want. If
I am stupid enough to send a message to an object that doesn't recognise it,
I'd like my program to crash (and therefore generate a crash log). Then, when
it restarts, it offers to send the log to me (thank you, Uli M Kusterer).
Otherwise, my app will just behave strangely and I will never even know I have
a bug. Exit one [potential] customer.

This is all happening on 10.5.8, but 10.6.2 seems to be the same. Any insight
greatly appreciated. Thanks.

Paul Sanders.
___

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Socket Blocking Question


On Jan 20, 2010, at 1:40 PM, Steven Degutis wrote:

> 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.

Steven - this is a really interesting approach.  I can see how this basically 
achieves the same thing as all the callback methods, but does allow the code to 
be written somewhat inline.  Unfortunately I need to at least support OS X 10.5 
at this point.  I definitely need to read-up on blocks b/c I can see how they 
can be used to work around some tricky design problems.

> 
> 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  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  
> 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 co

Re: Socket Blocking Question

On Jan 20, 2010, at 2:23 PM, Ken Thomases wrote:

> On Jan 20, 2010, at 11:39 AM, Carter R. Harrison 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.
> 
> If you're using lots of CPU time, then you're not blocking, you're spinning.  
> When a thread is blocked, it does nothing and consumes no CPU time.
> 
> Now, blocking is bad in the main thread of a GUI app, but if you're writing 
> non-GUI code, it can be a perfectly sensible design approach.  However, you 
> have to actually implement blocking!

Ken - thanks for the info.  I had thought the same thing when I wrote the code 
so I must be doing something wrong as you said.  Here's my method that sends 
data and then waits for the response back from the server.  I've paired my code 
down so it is a bit simpler than it actually is, but the gist of it is the 
same.  Here the request is sent to the server and the method does not return 
until 1024 bytes of data has been returned.  I'm basically calling 
[NSInputStream hasBytesAvailable] and if it returns NO then I am using the 
sleep() method to sleep the thread for 100ms.  Over a fast connection the CPU 
usage is very very low (< 2%), but on a slower connection where the server 
could take a couple hundred milliseconds to return the CPU usage hovers around 
25 or 30% - way too high for regular use.  In the code, "is" is an 
NSInputStream and "os" is an NSOutputStream.  I would greatly appreciate your 
insight on this.

-(NSData *)sendDataReturningResponse:(NSData *)data error:(NSError **)error
{
//Write the data to the output stream.
int retval = [os write:[data bytes] maxLength:[data length]];

//retval will be -1 if an error has occurred.
if (retval == -1)
{
*error = os.streamError;
NSLog(@"%@", [os.streamError localizedDescription]);
return nil;
}
else
*error = nil;

NSMutableData *response = [[NSMutableData alloc] initWithCapacity:0];

//Wait for response to come back.
while (response.length < 1024)
{
if ([is hasBytesAvailable])
{
uint8_t buf[MAX_RECV_SIZE];
unsigned int maxlen = 0;
maxlen = [is read:buf maxLength:MAX_RECV_SIZE];
[response appendBytes:(const void *)buf length:maxlen];
}
else 
{
sleep(.1);  //No data available on the input 
buffer.  Sleep for 100ms and we'll try again.
}
}
return [response autorelease];
}

> 
> Cheers,
> Ken
> 

___

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Socket Blocking Question

By the way, supporting 10.5 isn't necessarily a problem for using Blocks.
PLBlocks is a viable plugin for Xcode on 10.5 that allows you to use blocks.
I can attest that it is pretty stable and I would use it in production apps
if I had to use 10.5 and needed blocks for something like this.

-Steven

On Wed, Jan 20, 2010 at 1:32 PM, Carter R. Harrison
wrote:

>
> On Jan 20, 2010, at 1:40 PM, Steven Degutis wrote:
>
> 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.
>
>
> Steven - this is a really interesting approach.  I can see how this
> basically achieves the same thing as all the callback methods, but does
> allow the code to be written somewhat inline.  Unfortunately I need to at
> least support OS X 10.5 at this point.  I definitely need to read-up on
> blocks b/c I can see how they can be used to work around some tricky design
> problems.
>
>
> 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  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 in

Re: Uncaught exceptions not terminating my app

On Jan 20, 2010, at 1:27 PM, Paul Sanders wrote:

> I am experiencing a strange problem with the handling of uncaught exceptions 
> which I'm hoping someone can shed some light on.
> 
> This document:
> 
> http://developer.apple.com/mac/library/DOCUMENTATION/Cocoa/Conceptual/Exceptions/Tasks/ControllingAppResponse.html#//apple_ref/doc/uid/2473
> 
> states that certain classes of exception will terminate the app if they are 
> not caught.

But the main application loop is documented as catching all exceptions that 
reach it.  One example of the documentation is the note on this page:

http://developer.apple.com/mac/library/DOCUMENTATION/Cocoa/Conceptual/Exceptions/Concepts/UncaughtExceptions.html#//apple_ref/doc/uid/2056

>  But this is not the behaviour I observe.  To take a specific example, 
> executing this code:
> 
>[NSObject noSuchSelector];
>foo ();
> 
> Just abruptly returns to the main event loop (and the call to foo (), and 
> whatever follows, is never executed).

Right.  As documented.

>  This is _not_ the behaviour I want.  If I am stupid enough to send a message 
> to an object that doesn't recognise it, I'd like my program to crash (and 
> therefore generate a crash log).  Then, when it restarts, it offers to send 
> the log to me (thank you, Uli M Kusterer).  Otherwise, my app will just 
> behave strangely and I will never even know I have a bug.  Exit one 
> [potential] customer.

I don't know if there's a way to prevent NSApplication from catching exceptions 
in the main event loop.  You can override -reportException: to call abort() or 
the like, but a) somebody here recently reported that their -reportException: 
override wasn't being called on Snow Leopard, and b) the abort() will produce a 
crash report that doesn't show the call stack which generated the original 
exception -- it will show the call stack for the abort() call, which is 
uninteresting.

You can compensate for (b) by logging the actual exception, perhaps with the 
help of NSExceptionHandler to add a stack trace.  Maybe you can hack together 
an override of -[NSApplication run] to get rid of the top-level exception 
handling?

Certainly, you can use NSExecptionHandler to log all exceptions which get 
caught by the top-level exception handler, and then you can send yourself that 
log in lieu of a crash report.

-Ken

___

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Socket Blocking Question

On Jan 20, 2010, at 1:42 PM, Carter R. Harrison wrote:

> On Jan 20, 2010, at 2:23 PM, Ken Thomases wrote:
> 
>> If you're using lots of CPU time, then you're not blocking, you're spinning. 
>>  When a thread is blocked, it does nothing and consumes no CPU time.
>> 
>> Now, blocking is bad in the main thread of a GUI app, but if you're writing 
>> non-GUI code, it can be a perfectly sensible design approach.  However, you 
>> have to actually implement blocking!
> 
> Ken - thanks for the info.  I had thought the same thing when I wrote the 
> code so I must be doing something wrong as you said.  Here's my method that 
> sends data and then waits for the response back from the server.  I've paired 
> my code down so it is a bit simpler than it actually is, but the gist of it 
> is the same.  Here the request is sent to the server and the method does not 
> return until 1024 bytes of data has been returned.  I'm basically calling 
> [NSInputStream hasBytesAvailable] and if it returns NO then I am using the 
> sleep() method to sleep the thread for 100ms.  Over a fast connection the CPU 
> usage is very very low (< 2%), but on a slower connection where the server 
> could take a couple hundred milliseconds to return the CPU usage hovers 
> around 25 or 30% - way too high for regular use.  In the code, "is" is an 
> NSInputStream and "os" is an NSOutputStream.  I would greatly appreciate your 
> insight on this.

First, you're not sleeping for 100ms.  sleep() takes an integer number of 
seconds.  You're passing .1 which is getting truncated to 0.  So, you're 
calling sleep(0).  That may not be a total no-op -- the kernel will probably 
yield your time slice to another process or thread -- but it doesn't block your 
thread.

Second, you need not invoke -hasBytesAvailable.  Just invoke -read:maxLength:.  
That will block if no data is available.

Cheers,
Ken

___

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Socket Blocking Question

Also, I still recommend using AsyncSocket instead of NSStream APIs as
AsyncSocket will make your life much simpler at pretty much no cost.

-Steven

On Wed, Jan 20, 2010 at 11:39 AM, Carter R. Harrison  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.c

iPhone UITableView / UITableViewCell - Delete Button

2010-01-20 Thread Mick Walker

I am using the 'swipe to delete' functionality of the UITableView.
The problem is I am using a customised UITableViewCell which is created on a 
per item basis in

- (UITableViewCell *)tableView:(UITableView *)aTableView 
cellForRowAtIndexPath:(NSIndexPath *)indexPath

I need to alter the position of the delete button (simply to move it around 
10px to the left), how would I go about doing this?
Here is my existing code for creating the cell:

- (UITableViewCell *)tableView:(UITableView *)aTableView 
cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
   NSLog(@"cellForRowAtIndexPath");
#if USE_CUSTOM_DRAWING
   const NSInteger TOP_LABEL_TAG = 1001;
   const NSInteger BOTTOM_LABEL_TAG = 1002;
   UILabel *topLabel;
   UILabel *bottomLabel;
#endif

   static NSString *CellIdentifier = @"Cell";
   UITableViewCell *cell = [aTableView 
dequeueReusableCellWithIdentifier:CellIdentifier];
   if (cell == nil)
   {
   //
   // Create the cell.
   //
   cell =
   [[[UITableViewCell alloc]
 initWithFrame:CGRectZero
 reuseIdentifier:CellIdentifier]
autorelease];

#if USE_CUSTOM_DRAWING


   const CGFloat LABEL_HEIGHT = 20;
   UIImage *image = [UIImage imageNamed:@"trans_clock.png"];

   //
   // Create the label for the top row of text
   //
   topLabel =
   [[[UILabel alloc]
 initWithFrame:
 CGRectMake(
image.size.width + 2.0 * cell.indentationWidth,
0.5 * (aTableView.rowHeight - 2 * LABEL_HEIGHT),
aTableView.bounds.size.width -
image.size.width - 4.0 * cell.indentationWidth
,
LABEL_HEIGHT)]
autorelease];
   [cell.contentView addSubview:topLabel];

   //
   // Configure the properties for the text that are the same on every row
   //
   topLabel.tag = TOP_LABEL_TAG;
   topLabel.backgroundColor = [UIColor clearColor];
   topLabel.textColor = fontColor;
   topLabel.highlightedTextColor = [UIColor colorWithRed:1.0 green:1.0 
blue:0.9 alpha:1.0];
   topLabel.font = [UIFont systemFontOfSize:[UIFont labelFontSize]];

   //
   // Create the label for the top row of text
   //
   bottomLabel =
   [[[UILabel alloc]
 initWithFrame:
 CGRectMake(
image.size.width + 2.0 * cell.indentationWidth,
0.5 * (aTableView.rowHeight - 2 * LABEL_HEIGHT) + 
LABEL_HEIGHT,
aTableView.bounds.size.width -
image.size.width - 4.0 * cell.indentationWidth
,
LABEL_HEIGHT)]
autorelease];
   [cell.contentView addSubview:bottomLabel];

   //
   // Configure the properties for the text that are the same on every row
   //
   bottomLabel.tag = BOTTOM_LABEL_TAG;
   bottomLabel.backgroundColor = [UIColor clearColor];
   bottomLabel.textColor = fontColor;
   bottomLabel.highlightedTextColor = [UIColor colorWithRed:1.0 green:1.0 
blue:0.9 alpha:1.0];
   bottomLabel.font = [UIFont systemFontOfSize:[UIFont labelFontSize] - 2];

   //
   // Create a background image view.
   //
   cell.backgroundView =
   [[[UIImageView alloc] init] autorelease];
   cell.selectedBackgroundView =
   [[[UIImageView alloc] init] autorelease];
#endif
   }

#if USE_CUSTOM_DRAWING
   else
   {
   topLabel = (UILabel *)[cell viewWithTag:TOP_LABEL_TAG];
   bottomLabel = (UILabel *)[cell viewWithTag:BOTTOM_LABEL_TAG];
   }
   topLabel.text  = @"Example Text";
   topLabel.textColor = fontColor;

   bottomLabel.text = @"More Example Text";
   bottomLabel.textColor = fontColor;

   //
   // Set the background and selected background images for the text.
   // Since we will round the corners at the top and bottom of sections, we
   // need to conditionally choose the images based on the row index and the
   // number of rows in the section.
   //
   UIImage *rowBackground;
   UIImage *selectionBackground;
   NSInteger sectionRows = [aTableView numberOfRowsInSection:[indexPath 
section]];
   NSInteger row = [indexPath row];
   if (row == 0 && row == sectionRows - 1)
   {
   rowBackground = [UIImage imageNamed:@"topAndBottomRow.png"];
   selectionBackground = [UIImage 
imageNamed:@"topAndBottomRowSelected.png"];
   }
   else if (row == 0)
   {
   rowBackground = [UIImage imageNamed:@"topRow.png"];
   selectionBackground = [UIImage imageNamed:@"topRowSelected.png"];
   }
   else if (row == sectionRows - 1)
   {
   rowBackground = [UIImage imageNamed:@"bottomRow.png"];
   selectionBackground = [UIImage imageNamed:@"bottomRowSelected.png"];
   }
   else
   {
   rowBackground = [UIImage imageNamed:@"middleRow.png"];
   selectionBackground = [UIImage imageNamed:@"middleRowSelected.png"];
   }
   ((UIImageView *)cell.backgroundView).image = rowBackground;
   ((UIImageView *)cell.selectedBackgro

Re: Socket Blocking Question

2010-01-20 Thread nicolas berloquin

I may not have fully grasped your problem but you seem to say that  
getting 'pieces' of the reply generates a lot of problems for you.
Couldn't you have a socket that buffers the replies and that sends the  
whole aggregated messages to the rest of the app when done ?
You could have a special 'message' sent by the server to let you know  
that it's done sending or (if it can know beforehand how much will be  
coming)
One thing you could look at are notifications. They're very easy to  
use and are a cool way to send data around an app (locally)  
asychronously or from background threads.



Le 20 janv. 2010 à 21:09, Ken Thomases  a écrit :


On Jan 20, 2010, at 1:42 PM, Carter R. Harrison wrote:


On Jan 20, 2010, at 2:23 PM, Ken Thomases wrote:

If you're using lots of CPU time, then you're not blocking, you're  
spinning.  When a thread is blocked, it does nothing and consumes  
no CPU time.


Now, blocking is bad in the main thread of a GUI app, but if  
you're writing non-GUI code, it can be a perfectly sensible design  
approach.  However, you have to actually implement blocking!


Ken - thanks for the info.  I had thought the same thing when I  
wrote the code so I must be doing something wrong as you said.   
Here's my method that sends data and then waits for the response  
back from the server.  I've paired my code down so it is a bit  
simpler than it actually is, but the gist of it is the same.  Here  
the request is sent to the server and the method does not return  
until 1024 bytes of data has been returned.  I'm basically calling  
[NSInputStream hasBytesAvailable] and if it returns NO then I am  
using the sleep() method to sleep the thread for 100ms.  Over a  
fast connection the CPU usage is very very low (< 2%), but on a  
slower connection where the server could take a couple hundred  
milliseconds to return the CPU usage hovers around 25 or 30% - way  
too high for regular use.  In the code, "is" is an NSInputStream  
and "os" is an NSOutputStream.  I would greatly appreciate your  
insight on this.


First, you're not sleeping for 100ms.  sleep() takes an integer  
number of seconds.  You're passing .1 which is getting truncated to  
0.  So, you're calling sleep(0).  That may not be a total no-op --  
the kernel will probably yield your time slice to another process or  
thread -- but it doesn't block your thread.


Second, you need not invoke -hasBytesAvailable.  Just invoke - 
read:maxLength:.  That will block if no data is available.


Cheers,
Ken

___

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/cepakare%40gmail.com

This email sent to cepak...@gmail.com

___

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Socket Blocking Question

FWIW, that's exactly what AsyncSocket does, using delegate callbacks (pretty
typical Cocoa pattern). This is one reason why I suggested it.

On Wed, Jan 20, 2010 at 3:06 PM, nicolas berloquin wrote:

> I may not have fully grasped your problem but you seem to say that getting
> 'pieces' of the reply generates a lot of problems for you.
> Couldn't you have a socket that buffers the replies and that sends the
> whole aggregated messages to the rest of the app when done ?
> You could have a special 'message' sent by the server to let you know that
> it's done sending or (if it can know beforehand how much will be coming)
> One thing you could look at are notifications. They're very easy to use and
> are a cool way to send data around an app (locally) asychronously or from
> background threads.
>
>
> Le 20 janv. 2010 à 21:09, Ken Thomases  a écrit :
>
>  On Jan 20, 2010, at 1:42 PM, Carter R. Harrison wrote:
>>
>>  On Jan 20, 2010, at 2:23 PM, Ken Thomases wrote:
>>>
>>>  If you're using lots of CPU time, then you're not blocking, you're
 spinning.  When a thread is blocked, it does nothing and consumes no CPU
 time.

 Now, blocking is bad in the main thread of a GUI app, but if you're
 writing non-GUI code, it can be a perfectly sensible design approach.
  However, you have to actually implement blocking!

>>>
>>> Ken - thanks for the info.  I had thought the same thing when I wrote the
>>> code so I must be doing something wrong as you said.  Here's my method that
>>> sends data and then waits for the response back from the server.  I've
>>> paired my code down so it is a bit simpler than it actually is, but the gist
>>> of it is the same.  Here the request is sent to the server and the method
>>> does not return until 1024 bytes of data has been returned.  I'm basically
>>> calling [NSInputStream hasBytesAvailable] and if it returns NO then I am
>>> using the sleep() method to sleep the thread for 100ms.  Over a fast
>>> connection the CPU usage is very very low (< 2%), but on a slower connection
>>> where the server could take a couple hundred milliseconds to return the CPU
>>> usage hovers around 25 or 30% - way too high for regular use.  In the code,
>>> "is" is an NSInputStream and "os" is an NSOutputStream.  I would greatly
>>> appreciate your insight on this.
>>>
>>
>> First, you're not sleeping for 100ms.  sleep() takes an integer number of
>> seconds.  You're passing .1 which is getting truncated to 0.  So, you're
>> calling sleep(0).  That may not be a total no-op -- the kernel will probably
>> yield your time slice to another process or thread -- but it doesn't block
>> your thread.
>>
>> Second, you need not invoke -hasBytesAvailable.  Just invoke
>> -read:maxLength:.  That will block if no data is available.
>>
>> Cheers,
>> Ken
>>
>> ___
>>
>> 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/cepakare%40gmail.com
>>
>> This email sent to cepak...@gmail.com
>>
> ___
>
> 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/
___

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Socket Blocking Question

2010-01-20 Thread nicolas berloquin

This is a genuine question/remark that pops up. No check is done on  
what selector or object is returned or is it ?
If this is done on a public service (web server or other), couldn't  
code injection be too easilly done that way ? (easy hacking, wilfull  
crash etc) ?



Le 20 janv. 2010 à 19:47, Steven Degutis  a  
écrit :


Oops, correction: the downside is that all arguments and return  
values need
to conform to NSCoder protocol. So, it's even more strict than I  
described

earlier. But it's still cool :)

-Steven

On Wed, Jan 20, 2010 at 12:40 PM, Steven Degutis
wrote:

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  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.  Th

Re: Socket Blocking Question

In my implementation of this solution, it is a slight danger of code
injection, but only in the sense that *existing methods can be called with
bunk data*. Methods that are not implemented by the protocol (and thus
destination) are ignored when received over the network. However, this
connection between 2 Cocoa apps can further be secured by using SSL with
AsyncSocket (it just uses CFSocket and friends, so it should be fairly
straightforward, at least as far as SSL goes).

-Steven

On Wed, Jan 20, 2010 at 3:15 PM, nicolas berloquin wrote:

> This is a genuine question/remark that pops up. No check is done on what
> selector or object is returned or is it ?
> If this is done on a public service (web server or other), couldn't code
> injection be too easilly done that way ? (easy hacking, wilfull crash etc) ?
>
>
> Le 20 janv. 2010 à 19:47, Steven Degutis  a
> écrit :
>
>  Oops, correction: the downside is that all arguments and return values
>> need
>> to conform to NSCoder protocol. So, it's even more strict than I described
>> earlier. But it's still cool :)
>>
>> -Steven
>>
>> On Wed, Jan 20, 2010 at 12:40 PM, Steven Degutis
>> wrote:
>>
>>  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  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
 i

Re: Socket Blocking Question