Re: NSBlockOperation with +[sendSynchronousRequest sendSynchronousRequest:...] or async?

[Keith Duncan]

Hi Rick,

Don't use the NSURLConnection synchronous method, it's non-cancellable and 
blocks the calling thread until timeout, or completion.

A better block based NSURLRequest method would be as follows (typed in Mail 
from memory):

> @implementation NSOperationQueue (MyAdditions)
> 
> typedef NSData * (^MyResponseProviderBlock)(NSURLResponse **, NSError **); // 
> Note: this mimics the +sendSynchronousRequest:… signature
> 
> - (NSOperation *)addOperationWithRequest:(NSURLRequest *)request 
> completionBlock:(void (^)(MyResponseProviderBlock))completionBlock {
>   _MyURLConnectionOperation *requestOperation = 
> [[[_MyURLConnectionOperation alloc] initWithRequest:request] autorelease];
>   [self addOperation:requestOperation];
>   if (completionBlock == nil) {
>   return requestOperation;
>   }
>   
>   NSBlockOperation *callbackOperation = [NSBlockOperation 
> blockOperationWithBlock:^ {
>   MyResponseProviderBlock responseProvider = ^ NSData * 
> (NSURLResponse **responseRef, NSError **errorRef) {
>   NSData *bodyData = [requestOperation bodyData];
>   if (bodyData == nil) {
>   if (errorRef != NULL) {
>   *errorRef = [requestOperation error];
>   }
>   return nil;
>   }
>   
>   if (responseRef != NULL) {
>   *responseRef = [requestOperation response];
>   }
>   return bodyData;
>   };
>   completionBlock(responseProvider);
>   }];
>   [callbackOperation addDependency:requestOperation];
>   [self addOperation:callbackOperation];
>   
>   return callbackOperation;
> }
> 
> @end

The implementation of _MyURLConnectionOperation is left as an exercise to the 
reader.

• It is an -isConcurrent NSOperation subclass, check the docs if you're 
uncertain of the implications.
• It creates an NSURLConnection and schedules it on the main run loop, 
collecting the results.

This provides a way to perform an NSURLRequest asynchronously, with 
cancellation, without having to create an NSURLConnection and it's callbacks. 
It essentially 'fakes' the synchronous API whilst still performing the request 
asynchronously.

NB: if you are expecting large response entities, you will want to add a 
variation that streams the received data to disk.

Keith

___

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

NSString localizedStringWithFormat: and thousand separators

[Nala Gnirut]

Hi all,
according to Apple's documentation, localizedStringWithFormat supports
format specifiers as detailed in IEEE printf
specification
.

Unfortunately, a simple test does not seem to work as expected when using '
to request formatting with thousands' grouping character:

NSLog(@"Test: %'6.2f", 90.55);

Does localizedStringWithFormat support this or do I need to rely on
NSFormatter?

Thanks in advance.
___

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

[Bill Cheeseman]

On Jan 17, 2011, at 2:40 PM, Bill Cheeseman wrote:

> I love my Magic Trackpad -- when it works. I have to shut down my Mac, crawl 
> under the desk, unplug the power cord and all the USB cables, plug the power 
> cord back in, restart from the power button, plug all the USB cables back in, 
> and then log in, three times a day on average. The Magic Trackpad is a 
> BlueTooth device, but Apple's engineers tell me this is the correct 
> workaround for a firmware issue having to do with a USB conflict. When the 
> Magic Trackpad stops working, iTunes stops recognizing my iPhone 4 in its USB 
> charging cradle, and certain other USB devices go flaky. Apple is working on 
> it


Ffor the record, Matt Neuburg helped me figure out that my Magic Trackpad was 
failing BECAUSE I had the iPhone charging all the time in a USB charging cradle 
attached to the same computer. Now that I am charging my iPhone elsewhere, the 
Magic Trackpad is working reliably.

-- 

Bill Cheeseman - b...@cheeseman.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: NSString localizedStringWithFormat: and thousand separators

[David Duncan]

On Jan 21, 2011, at 3:21 AM, Nala Gnirut wrote:

> Hi all,
> according to Apple's documentation, localizedStringWithFormat supports
> format specifiers as detailed in IEEE printf
> specification
> .
> 
> Unfortunately, a simple test does not seem to work as expected when using '
> to request formatting with thousands' grouping character:
> 
> NSLog(@"Test: %'6.2f", 90.55);
> 
> Does localizedStringWithFormat support this or do I need to rely on
> NSFormatter?


How does your test prove or disprove the functionality you are trying to test? 
You seem to be assuming that NSLog calls -localizedStringWithFormat:, you 
probably want to try calling it yourself and logging the results instead.
--
David Duncan

___

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

Magazine Framework

[Fernando Aureliano]

Hi!

You guys know if exist some framework for help to build a magazine?

thanks

-- 
*Fernando
*
___

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

Prevent windows from opening multiple times

[Luc Van Bogaert]

Hi,

I've implemented a simple Preferences window using example code from a Cocoa 
handbook. When opening the window, the window controller is created and 
initialized with a nib file. When closing the window, the window object 
resources are (auto)released in the windowWillClose delegate method. 

This seems to work fine, except for one problem: it is possible for the user to 
open multiple instances of the same window. I would like to prevent this, but 
I'm not sure what would be the best way to do this.

Instead of using a local pointer variable in the action method to open the 
window, I thought about using an instance variable in my app delegate to hold a 
pointer to the windowcontroller object, and check its existance before opening 
the window. However, trying this failed, as now I can open and close the window 
just once, and the app crashes on subsequent attempts to open the window.

Any help would be appreciated.
Thanks,

-- 
Luc Van Bogaert
luc.van.boga...@me.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: NSBlockOperation with +[sendSynchronousRequest sendSynchronousRequest:...] or async?

[Ken Ferry]

Hi Rick,

I thought I'd pass along a message from Quinn in Apple's DTS group on this
topic.  Also, fyi,  is better for
networking questions

-Ken

Doing your NSConnection stuff synchronously is a mistake, even if
> NSBlockOperation makes it easier.  There are three major issues:


> o resource usage -- Threads are expensive, so having a bunch of threads
> sitting around literally doing nothing is not a great idea.  This is major
> concern on iOS, much less so on Mac OS X.


> o cancellation -- It's hard to implement cancellation in this sort of
> setup.


> o no delegate -- +[NSURLConnection sendSynchronousRequest:...] does not
> provide you with a delegate, which means you can't handle authentication
> challenges.  This is a problem because, even if the HTTP resource itself is
> not protected, you might be behind an authenticating proxy.  On iOS there's
> no avoiding this; you have to handle authentication challenges.  On Mac OS X
> this is only a problem if the existing proxy credentials (in the keychain)
> are wrong.


> You can resolve all of these issues, and stay within the NSOperation
> universe, by using a concurrent operation that manages an async
> NSURLConnection.  The QHTTPOperation class is a good example of this.


> 





On Thu, Jan 20, 2011 at 2:51 PM, Rick Mann  wrote:

> With the advent of code blocks and NSBlockOperation, it's a lot tidier, and
> easier, to write code using NSURLConnection, particularly in the presence of
> multiple operations. The approach is to use an NSBlockOperation and
> +[NSURLConnection
> sendSynchronousRequest:returningResponse:error:] to synchronously request a
> resource (which occurs on a separate thread).
>
> The alternative is to use the asynchronous methods, and then manage all the
> state necessary to keep track of multiple instances of the same request. I
> prefer the former approach, but does Apple still recommend the async
> approach? Or is there no real difference between the two?
>
> I'm running on iOS 4.x, on a single-core device, but I don't think these
> devices will remain single-core for long, and the same question applies to
> multicore Macs.
>
> Thanks,
> Rick
>
> ___
>
> 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/kenferry%40gmail.com
>
> This email sent to kenfe...@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: Prevent windows from opening multiple times

[Quincey Morris]

On Jan 21, 2011, at 10:48, Luc Van Bogaert wrote:

> Instead of using a local pointer variable in the action method to open the 
> window, I thought about using an instance variable in my app delegate to hold 
> a pointer to the windowcontroller object, and check its existance before 
> opening the window. However, trying this failed, as now I can open and close 
> the window just once, and the app crashes on subsequent attempts to open the 
> window.

Your approach is correct, so you have a bug in your implementation -- most 
likely a memory management error. You need to track this down like any other 
(likely) overrelease problem. If you post backtraces from the crash and/or 
relevant source, I'm sure people will be happy to help isolate what's gone 
wrong.


___

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: Prevent windows from opening multiple times

[John Joyce]

On Jan 21, 2011, at 2:27 PM, Quincey Morris wrote:

> On Jan 21, 2011, at 10:48, Luc Van Bogaert wrote:
> 
>> Instead of using a local pointer variable in the action method to open the 
>> window, I thought about using an instance variable in my app delegate to 
>> hold a pointer to the windowcontroller object, and check its existance 
>> before opening the window. However, trying this failed, as now I can open 
>> and close the window just once, and the app crashes on subsequent attempts 
>> to open the window.
> 
> Your approach is correct, so you have a bug in your implementation -- most 
> likely a memory management error. You need to track this down like any other 
> (likely) overrelease problem. If you post backtraces from the crash and/or 
> relevant source, I'm sure people will be happy to help isolate what's gone 
> wrong.
Check your settings for the window in Interface Builder...
don't change the defaults for 
Behavior : Release when closed (YES)
Memory : Deferred (YES)
Buffered

...unless you really know why you are changing them... 
you can get this crashing behavior with have fiddled with 
these...___

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: Magazine Framework

[Laurent Daudelin]

None that I'm aware of… but I don't pretend to know everything that is out 
there….

-Laurent.
-- 
Laurent Daudelin
AIM/iChat/Skype:LaurentDaudelin 
http://www.nemesys-soft.com/
Logiciels Nemesys Software  
laur...@nemesys-soft.com

On Jan 21, 2011, at 10:00, Fernando Aureliano wrote:

> Hi!
> 
> You guys know if exist some framework for help to build a magazine?

___

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

Tiling, applying it in my app.

[Gustavo Pizano]

Hello all.

I have seen the WWDC video a,d im checking the source code about Tiling & 
zooming in a UIScrollView.

Now, my app differs a little in it's content as from the view but as in the 
video was stated the technique is portable for proper zoom in a scrollview.

I have a UIScrollview, the scrollview's content's view (GridView) in its draw 
method has a series of CG calls to draw some paths inside it. This Subview is 
the one I have with a CATiledLayer.

Now, at startup I set up many UIImageView with an image 40X40 px, size, and add 
it to the  GridView, So when I zoom in ... I still see sharp the lines I draw 
using CG, but of course the UIImages I put previously gets blurred..


What should I do in order to have as a resutl of zooming these images still be 
sharp?... 

So here are my only thought... 

Get a bigger image and when zooming getting the image with the correct scale.

I also don't understand much about what they do in the example all those maths 
and things to get the correct tile and dequeee it.. and so on..  I mean I 
understand they don't create more tiles than needed, and just start reusing 
whatever is not used... in my case how can I apply this?



Thx

Gustavo

___

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

Undo in conjunction with core data

[Kenneth Baxter]

I am trying to work out an issue with undo in a few places in my application, and think 
if I "get it" with one of the places, I should be able to apply the same theory 
elsewhere.

I have a parent and children relationship, and need to have a few things happen 
during the process of adding and deleting a child so that the rest of the 
application stays in sync. The core data side of things manages the undoability 
of the data, but of course it doesn't know how to send the other messages at 
the right times, so I have tried to add the notification messages in the 
reverse order on the undo stack (prepareWithInvocationTarget), but then redo 
doesn't work properly All the undo and redo for the rest of my application is 
working fine (just fairly simple relationships and attributes), but I think 
there's a design pattern I'm missing here for the more complex case.

It's probably best for me to just post the things that need to happen during a 
normal add of a child and deletion of a child, and hopefully someone will be 
able to give me guidance on how to make it undoable and redoable.

- (MyNode *)createChild {
MyNode *child = [NSEntityDescription 
insertNewObjectForEntityForName:@"MyNodeEntity" inManagedObjectContext:[self 
managedObjectContext]];
    
// Set a bunch of properties on the new child.
...

    [[self mutableSetValueForKey:@"children"] addObject:child];

// Set a bunch more properties on the new child and other core data 
managed objects
...

// Let the front end of the application know about it

[[NSNotificationCenter defaultCenter] 
postNotificationName:@"ChildNodeAddedNotification" object:... userInfo:...];

return child;
}


- (void)deleteChild:(MyNode *)aChild {
NSArray *affectedChildren = [aChild selfAndAllDescendants];

[[NSNotificationCenter defaultCenter] 
postNotificationName:@"NodesWillBeRemovedNotification" object:self 
userInfo:[NSDictionarydictionaryWithObjectsAndKeys:affectedChildren, @"affectedChildren", 
nil]];

[[self mutableSetValueForKey:@"children"] removeObject:aChild];

if (self.parent) {
// Do some things that could affect some ancestor values
...
}

for (MyNode *tn in affectedChildren) {
// Do some special processing to clean up things that might be 
pointing to the descendants
...
// Set a non-persistent property on the tn node which will be 
picked up by KVO to show that the node will be removed, so we can kill 
observing etc.
...
[[self managedObjectContext] deleteObject:tn];
}
aChild.parent = nil;

// Do some post-processing to make sure some other values are kept in 
sync.
...

// Post a notification so the front end can be updated.
[[NSNotificationCenter defaultCenter] postNotificationName:@"NodeRemovedNotification" object:self 
userInfo:[NSDictionarydictionaryWithObjectsAndKeys:aChild, @"node", self, @"parent", 
affectedChildren, @"affectedChildren", nil]];
}


I have looked at some of the previous posts on related things, but haven't seen 
an answer that would explain what to do for this kind of thing (and some posts 
were suggesting turning off core data's undo completely and doing your own etc, 
which would not be good for me since I have a *lot* of places where it is 
working just fine for me and only about 6 places where it's not).

Thanks in advance for any advice on this.

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: Undo in conjunction with core data

[Dave Fernandes]

One way to do this through the MVC paradigm is to bind an NSArrayController or 
NSTreeController to your managed object context (in Entity mode), and then have 
your view layer bind or use KVO with the selectedObjects or arrangedObjects 
attribute of the controller.

On 2011-01-21, at 7:03 PM, Kenneth Baxter wrote:

> I am trying to work out an issue with undo in a few places in my application, 
> and think if I "get it" with one of the places, I should be able to apply the 
> same theory elsewhere.
> 
> I have a parent and children relationship, and need to have a few things 
> happen during the process of adding and deleting a child so that the rest of 
> the application stays in sync. The core data side of things manages the 
> undoability of the data, but of course it doesn't know how to send the other 
> messages at the right times, so I have tried to add the notification messages 
> in the reverse order on the undo stack (prepareWithInvocationTarget), but 
> then redo doesn't work properly All the undo and redo for the rest of my 
> application is working fine (just fairly simple relationships and 
> attributes), but I think there's a design pattern I'm missing here for the 
> more complex case.
> 
> It's probably best for me to just post the things that need to happen during 
> a normal add of a child and deletion of a child, and hopefully someone will 
> be able to give me guidance on how to make it undoable and redoable.
> 
> - (MyNode *)createChild {
>   MyNode *child = [NSEntityDescription 
> insertNewObjectForEntityForName:@"MyNodeEntity" inManagedObjectContext:[self 
> managedObjectContext]];
> 
>   // Set a bunch of properties on the new child.
>   ...
> 
>   [[self mutableSetValueForKey:@"children"] addObject:child];
>   
>   // Set a bunch more properties on the new child and other core data 
> managed objects
>   ...
> 
>   // Let the front end of the application know about it
> 
>   [[NSNotificationCenter defaultCenter] 
> postNotificationName:@"ChildNodeAddedNotification" object:... userInfo:...];
> 
>   return child;
> }
> 
> 
> - (void)deleteChild:(MyNode *)aChild {
>   NSArray *affectedChildren = [aChild selfAndAllDescendants];
>   
>   [[NSNotificationCenter defaultCenter] 
> postNotificationName:@"NodesWillBeRemovedNotification" object:self 
> userInfo:[NSDictionarydictionaryWithObjectsAndKeys:affectedChildren, 
> @"affectedChildren", nil]];
> 
>   [[self mutableSetValueForKey:@"children"] removeObject:aChild];
>   
>   if (self.parent) {
>   // Do some things that could affect some ancestor values
>   ...
>   }
> 
>   for (MyNode *tn in affectedChildren) {
>   // Do some special processing to clean up things that might be 
> pointing to the descendants
>   ...
>   // Set a non-persistent property on the tn node which will be 
> picked up by KVO to show that the node will be removed, so we can kill 
> observing etc.
>   ...
>   [[self managedObjectContext] deleteObject:tn];
>   }
>   aChild.parent = nil;
> 
>   // Do some post-processing to make sure some other values are kept in 
> sync.
>   ...
> 
>   // Post a notification so the front end can be updated.
>   [[NSNotificationCenter defaultCenter] 
> postNotificationName:@"NodeRemovedNotification" object:self 
> userInfo:[NSDictionarydictionaryWithObjectsAndKeys:aChild, @"node", self, 
> @"parent", affectedChildren, @"affectedChildren", nil]];
> }
> 
> 
> I have looked at some of the previous posts on related things, but haven't 
> seen an answer that would explain what to do for this kind of thing (and some 
> posts were suggesting turning off core data's undo completely and doing your 
> own etc, which would not be good for me since I have a *lot* of places where 
> it is working just fine for me and only about 6 places where it's not).
> 
> Thanks in advance for any advice on this.
> 
> 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/dave.fernandes%40utoronto.ca
> 
> This email sent to dave.fernan...@utoronto.ca

___

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

Core data autosave

[Kenneth Baxter]

I need to autosave my documents in my core data document based application

I must say I was surprised and disappointed when I found out that Core Data 
doesn't appear to have any autosave support built in and NSPersistentDocument 
doesn't support the superclass NSDocument autosave architecture.

I see there has been some discussion previously about possible approaches to 
solving this issue. I need something that works on 10.5 and 106.

In 2008, Ben Trumbull said "You could fake it by migrating the store to the backup 
location, creating a second context, pulling all the deltas from the original, save, and 
then tossing the second context."

Is this the current opinion on the best way to do autosave? It sounds like a 
very heavy approach, and I'm not sure on the actual implementation details of 
how to do what Ben says. If there is some common way of doing this, is there 
some sample code out there from Apple or someone else? 

Any feedback/suggestions would be very much appreciated.

Thanks

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: Core data autosave

[Gideon King]

Hi Ken, I have also been wrestling with this one, and last year had the 
following suggestion from Ben:


"The problem with autosave is that NSDocument wants the current document to 
stay dirty.  Save As pushes all the current edits to disk in the new document.  
Autosave is supposed to leave all the current edits as unsaved pending changes, 
even as it also saves those pending changes to a separate file.

There's no way to make an NSManagedObjectContext save, but leave everything 
dirty in memory.  

With some effort, you could replicate the current pending changes into a new 
stack and save them aside.  You could copy your existing document to a temp 
location, and then create a new PSC and new MOC and load the copied persistent 
store.  Then you could walk through all the inserted, deleted, and updates 
objects in the user's main NSManagedObjectContext and duplicate the changes in 
your new MOC.  You can clone over attributes directly with 
-dictionaryWithValuesForKeys and -setValuesForKeysWithDictionary.  You'll need 
to handle relationships by hand by asking for each related objects 
NSManagedObjectID and using "objectWithID" to rematerialize it in your new MOC. 
 Very tedious, although it should be straight forward if the autosave 
functionality is important."


So, a  slightly different approach and a little more detail there, but I kind 
of put it in the "too hard basket" for the moment because of all the stuff I 
would have to learn and implement, and was also concerned by the overhead of 
all that work on the performance of my application. 

I will need to implement it shortly, so am very keen to hear of a solution - 
especially if that comes with some code that does the job ;-).

BTW, I filed a bug on this because I think that autosave should be basic 
functionality supported by core data.

Regards


Gideon


On 22/01/2011, at 11:01 AM, Kenneth Baxter wrote:

> I need to autosave my documents in my core data document based application
> 
> I must say I was surprised and disappointed when I found out that Core Data 
> doesn't appear to have any autosave support built in and NSPersistentDocument 
> doesn't support the superclass NSDocument autosave architecture.
> 
> I see there has been some discussion previously about possible approaches to 
> solving this issue. I need something that works on 10.5 and 106.
> 
> In 2008, Ben Trumbull said "You could fake it by migrating the store to the 
> backup location, creating a second context, pulling all the deltas from the 
> original, save, and then tossing the second context."
> 
> Is this the current opinion on the best way to do autosave? It sounds like a 
> very heavy approach, and I'm not sure on the actual implementation details of 
> how to do what Ben says. If there is some common way of doing this, is there 
> some sample code out there from Apple or someone else? 
> 
> Any feedback/suggestions would be very much appreciated.
> 
> Thanks
> 
> 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: Undo in conjunction with core data

[Kenneth Baxter]

Thanks for that suggestion Dave. I'm trying to understand how this would work. 
While a tree controller would be able to represent the whole hierarchy, I think 
maybe for the things I am trying to achieve here, I would be easier to use an 
array controller on the children, and keep it at a manageable single level 
rather than affecting the architecture of the whole application.

So, completely separate from the UI, I create an array controller in my Node managed 
object, and set its entity name, MOC etc, and set the fetch predicate to be @"parent 
= SELF". It should then keep itself updated when the children get added or deleted 
in the MOC, right? (I have never used array controllers in this way before)

Now this is where I get a bit lost - so I presume that in my createChild 
method, I no longer need to post the ChildNodeAddedNotification, because I 
would be able to observe the change, and somehow know which object had been 
added?

And for the deletion, I'm not really clear on how to get the message to all the 
descendants that they are going to be removed etc.

So I am guessing that there must be some way to be notified when an object is 
going to be added, so I can do the pre-processing, and when it has been added, 
so I can do the post-processing, and ditto for the deletion, but I really don't 
see how this can be possible since the changes are percolating up from the MOC 
to the ArrayController, and I don't see anything in the array controller that 
seems to support this level of functionality.

Sorry for being dumb about this, but I think I must be missing the concept of 
what you are meaning in some fundamental way. 


On 22 Jan, 2011,at 10:28 AM, Dave Fernandes  wrote:

One way to do this through the MVC paradigm is to bind an NSArrayController or 
NSTreeController to your managed object context (in Entity mode), and then have 
your view layer bind or use KVO with the selectedObjects or arrangedObjects 
attribute of the controller.


___

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: Undo in conjunction with core data

[Jerry Krinock]

On 2011 Jan 21, at 16:03, Kenneth Baxter wrote:

> - (MyNode *)createChild {
> MyNode *child = [NSEntityDescription insertNewObjectForEntityForName:…

Core Data undo will take care of that automatically.

> // Set a bunch of properties on the new child.

Core Data undo will take care of that automatically.

> [[self mutableSetValueForKey:@"children"] addObject:child];

Core Data undo will take care of that automatically.

> // Set a bunch more properties on the new child and other core data managed 
> objects

Core Data undo will take care of that automatically as long as the other 
objects are in the same managed object context.  If they're not, think about if 
you really need multiple mocs.

> // Let the front end of the application know about it
> [[NSNotificationCenter defaultCenter] 
> postNotificationName:@"ChildNodeAddedNotification"…

Why?  As Dave Fernandes suggested, use bindings.  If you're using custom views, 
you have the choice of either adding bindings support so you can take advantage 
of Core Data's undo, or writing your own undo code, trying to slip your undo 
tasks into the undo stack without upsetting Core Data.  The former can take 
significant code but is straightforward.  The latter can be extremely dangerous 
to your mental health and those around you.

Now, regarding the inverse operation,

> - (void)deleteChild:(MyNode *)aChild {

you can pretty much read my comments above backwards.  One additional trick: 
Core Data will automatically (and undoably) delete child objects for you if use 
a Cascade Delete Rule in the relationship from parent to child.  This code…

> NSArray *affectedChildren = [aChild selfAndAllDescendants] …

is not necessary.  Rip that and subsequent code out of there.

___

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: Core data autosave

[Jerry Krinock]

On 2011 Jan 21, at 17:20, Gideon King wrote:

> I will need to implement …[algorithm suggested by Ben Trumbull]… shortly, so 
> am very keen to hear of a solution - especially if that comes with some code 
> … ;-).

No code, but some advice.  The required change tracking described by Ben seems 
like it could be done with the undo manager, or maybe a second/shadow undo 
manager.  In either case, you'll want to use GCUndoManager…

http://apptree.net/gcundomanager.htm

Let us know when your code is available :)

___

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: Core data autosave

[Gideon King]

Yes, I did wonder about using the undo manager instead - talked about it 
briefly with one of my staff, but haven't kind of worked out the details of how 
that would work yet though. I'll give it some more thought this afternoon.

And yes, I already use GCUndoManager - it has saved me countless hours 
debugging undo. I would second your opinion - I would never develop an app 
using the NSUndoManager now that I have seen the light ;-) Many thanks to 
Graham Cox for developing it.


Regards

Gideon

On 22/01/2011, at 12:57 PM, Jerry Krinock wrote:

> 
> On 2011 Jan 21, at 17:20, Gideon King wrote:
> 
>> I will need to implement …[algorithm suggested by Ben Trumbull]… shortly, so 
>> am very keen to hear of a solution - especially if that comes with some code 
>> … ;-).
> 
> No code, but some advice.  The required change tracking described by Ben 
> seems like it could be done with the undo manager, or maybe a second/shadow 
> undo manager.  In either case, you'll want to use GCUndoManager…
> 
> http://apptree.net/gcundomanager.htm
> 
> Let us know when your code is available :)

___

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: Undo in conjunction with core data

[Jerry Krinock]

On 2011 Jan 21, at 18:34, Kenneth Baxter wrote:

> So, completely separate from the UI, I create an array controller in my Node 
> managed object, and set its entity name, MOC etc, and set the fetch predicate 
> to be @"parent = SELF". It should then keep itself updated when the children 
> get added or deleted in the MOC, right? (I have never used array controllers 
> in this way before)
> 
> Now this is where I get a bit lost … Sorry for being dumb about this

No, you're not dumb.  If Mr. Spock beamed down here from the starship 
Enterprise, and you gave him the reference documentation and told him to build 
a user interface for a Core Data app from scratch, he couldn't do it either.  
There are too many ways to go wrong, too many checkboxes and popups in 
Interface Builder.

You need to download one of Apple's sample projects or follow one of their 
tutorials.  For Core Data with NSArrayController and NSTableView, there is 
DepartmentAndEmployees.

One warning though: Some years ago, I heard bad things about Core Data with 
NSTreeController and NSOutlineView, and for this reason have thus far shunned 
NSTreeController and stuck with my old-fashioned data source, using change 
notifications to trigger -reloadData messages.  Maybe someone who has 
successfully used NSTreeController and NSOutlineView with Core Data can suggest 
a good tutorial or sample project.

___

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

Community link blog

[Maurício Linhares]

Hi guys,

I've been searching around but could not find a community link blog
for Cocoa developers as we have in the ruby community (
http://www.rubyflow.com/ ).

Is there anything like that for Objective-C/iOS/MacOS dev?

-
Maurício Linhares
http://about.me/mauricio.linhares
___

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

starting with Cocoa!

[Janos Syd Nepthali Pao]

Hi all!

I'm glad to find this mailing list. I'm starting with Cocoa (side by  
side with iOS development), i wanted to learn software development  
(this totally rocks!).


I'd like to ask for your hints, advice and words of wisdom --anything  
you can share for someone just beginning his journey here.


Before anything else, i would also like to point out that i have  
several software hindrances (but i'd like to call them challenges). I  
own an old Macbook (this is the first generation macbook, 13inch  
white), it's still running on Tiger (i haven't updated to Leopard  
yet). I think the XCode that came with this OS is already obsolete?


One more thing, since I am on the go, i am also having a problem with  
my internet connection. I don't have a high speed one. and most of  
the time it depends on my location,.. oh man.


but the bottom line is i really wanted to join the team and this is  
passion. I wanted to meet great people all over the world working  
with software development.


thanks a lot for taking time to read this. more power to you all!

Regards,
Syd
___

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

how to change NSButton color

[Dianne]

Hi List,

I would like to know what you can suggest when changing the color of NSButton.
I have read everywhere that I need to subclass NSButtonCell and NSButton as 
well, is this the only way to do it for Mac?
I'm surprised that this is how complicated it is in Mac. Why NSButton doesn't 
have any property to set its color?

Thanks in advance for your help.
Thanks,
yani

___

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: Undo in conjunction with core data

[Dave Fernandes]

On 2011-01-21, at 10:47 PM, Jerry Krinock wrote:

> One warning though: Some years ago, I heard bad things about Core Data with 
> NSTreeController and NSOutlineView, and for this reason have thus far shunned 
> NSTreeController and stuck with my old-fashioned data source, using change 
> notifications to trigger -reloadData messages.  Maybe someone who has 
> successfully used NSTreeController and NSOutlineView with Core Data can 
> suggest a good tutorial or sample project.

NSTreeController was broken in Tiger, but works fine for Leopard and later. 
Can't remember which sample project I used to learn it, but AbstractTree seems 
to do the basics.

___

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: starting with Cocoa!

[Seth Willits]

On Jan 20, 2011, at 10:55 PM, Janos Syd Nepthali Pao wrote:

> I own an old Macbook (this is the first generation macbook, 13inch white), 
> it's still running on Tiger (i haven't updated to Leopard yet). I think the 
> XCode that came with this OS is already obsolete?

Completely. The latest tools (which is the only way to support the latest iOS 
releases) require Snow Leopard. Your MacBook can run Snow Leopard, so I suggest 
you upgrade.


Welcome to the club. I'm sure your embroidered jacket and fez with fluffy 
tassels is on its way in the mail.


--
Seth Willits



___

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: how to change NSButton color

[Kyle Sluder]

On Jan 20, 2011, at 11:49 PM, Dianne  wrote:

> Hi List,
> 
> I would like to know what you can suggest when changing the color of NSButton.
> I have read everywhere that I need to subclass NSButtonCell and NSButton as 
> well, is this the only way to do it for Mac?
> I'm surprised that this is how complicated it is in Mac. Why NSButton doesn't 
> have any property to set its color?

Because you're not supposed to change a button's color.

See the Human Interface Guidelines: 
http://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGIntro/XHIGIntro.html

--Kyle Sluder___

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: Undo in conjunction with core data

[Kyle Sluder]

On Jan 21, 2011, at 10:10 PM, Dave Fernandes  wrote:

> 
> NSTreeController was broken in Tiger, but works fine for Leopard and later. 
> Can't remember which sample project I used to learn it, but AbstractTree 
> seems to do the basics.

Not quite. NSObjectController and subclasses ignore any options you provide in 
-addObserver:forKeyPath:options:context:. This means you can't get "prior" KVO 
notifications, and therefore can't know the value you're changing *from* in 
response to a KVO notification.

Also, IIRC this means you cannot use +keyPathsAffectingValueForKey: to 
auto-observe through an NS*Controller.

We no longer use any NSObjectController subclasses in our apps, and will not 
until Apple fixes these issues.

--Kyle Sluder
(sent from the road)___

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: Undo in conjunction with core data

[Dave Fernandes]

On 2011-01-21, at 9:34 PM, Kenneth Baxter wrote:

> Thanks for that suggestion Dave. I'm trying to understand how this would 
> work. While a tree controller would be able to represent the whole hierarchy, 
> I think maybe for the things I am trying to achieve here, I would be easier 
> to use an array controller on the children, and keep it at a manageable 
> single level rather than affecting the architecture of the whole application.
> 
> So, completely separate from the UI, I create an array controller in my Node 
> managed object, and set its entity name, MOC etc, and set the fetch predicate 
> to be @"parent = SELF". It should then keep itself updated when the children 
> get added or deleted in the MOC, right? (I have never used array controllers 
> in this way before)

The fetch predicate would be @"parent != nil" if you want all children.

> 
> Now this is where I get a bit lost - so I presume that in my createChild 
> method, I no longer need to post the ChildNodeAddedNotification, because I 
> would be able to observe the change, and somehow know which object had been 
> added?

Can you say what it is your application does when it gets these notifications? 
Are you just updating a view?

> 
> And for the deletion, I'm not really clear on how to get the message to all 
> the descendants that they are going to be removed etc.

Again, what do the descendants need to do when they get this message? Why not 
just traverse the relationships to get each of the descendants and send it a 
message directly?

> 
> So I am guessing that there must be some way to be notified when an object is 
> going to be added, so I can do the pre-processing, and when it has been 
> added, so I can do the post-processing, and ditto for the deletion, but I 
> really don't see how this can be possible since the changes are percolating 
> up from the MOC to the ArrayController, and I don't see anything in the array 
> controller that seems to support this level of functionality.

It sounds like you may be using the notifications to modify the data model. If 
so, there is probably a better design pattern.

> 
> Sorry for being dumb about this, but I think I must be missing the concept of 
> what you are meaning in some fundamental way. 
> 
> 
> On 22 Jan, 2011,at 10:28 AM, Dave Fernandes  
> wrote:
> 
>> One way to do this through the MVC paradigm is to bind an NSArrayController 
>> or NSTreeController to your managed object context (in Entity mode), and 
>> then have your view layer bind or use KVO with the selectedObjects or 
>> arrangedObjects attribute of the controller.
>> 
>> 

___

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: starting with Cocoa!

[Conrad Shultz]

Janos Syd Nepthali Pao wrote:
> Hi all!
> 
> I'm glad to find this mailing list. I'm starting with Cocoa (side by
> side with iOS development), i wanted to learn software development (this
> totally rocks!).
> 
> I'd like to ask for your hints, advice and words of wisdom --anything
> you can share for someone just beginning his journey here.

It's unclear to me whether you are totally new to programming or just to
Cocoa development, so my answers might be a bit scattershot.
Nevertheless, in no particular order:

Especially if you are new to programming in general, find a good intro
book to help you out.  For desktop work I recommend Hillegass' "Cocoa
Programming for Mac OS X," and for iOS work, try whatever the current
incarnation of the Mark/LaMarche "Beginning iPhone Development" is.

Familiarize yourself with the documentation.  Every Cocoa class is
thoroughly (if not always coherently) documented in Xcode and on the
Apple developer site.  The "Programming Guides" (e.g.
http://developer.apple.com/library/ios/#featuredarticles/ViewControllerPGforiPhoneOS/Introduction/Introduction.html)
are often quite good at getting your feet wet with a new set of features
and/or classes.  While the documentation may be intimidating at first,
you will quickly come to appreciate its value.  Most beginner questions
can be addressed within the documentation.

Apple provides a lot of sample code, almost all (if not all) of which is
packaged nicely as a ready-to-build .xcodeproj.  Run it.  Modify it.
Make it crash, then fix it.  But beware: even Apple is known to have a
bug or two in their code, so treat the samples as guides, not as iron laws.

Learn the basics of using a debugger.  GDB is currently most prevalent,
though LLDB is the up-and-coming I believe.  If you don't know what
these terms mean yet, you will soon enough.

Learn the memory management rules.  Even if you plan to use garbage
collection.  Seriously.  See
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html.
 It seems like a quarter of the questions on this list boil down to
forgetting, ignoring, or improperly implementing these rules.  (I
certainly have done so myself on occasion.)

Even if you're working alone, choose and use a revision control system.
 I use mercurial (http://mercurial.selenic.com).  Most I think use git
(http://git-scm.com).  Some use Subversion
(http://subversion.tigris.org).  They're all free, and have their own
strengths and weaknesses.  Corollary: keep your computer backed up,
especially given how old your hard drive probably is from your
description below.

Most of all, have fun!  Don't be afraid to experiment.  You won't break
your computer, and you will learn a lot.

> Before anything else, i would also like to point out that i have several
> software hindrances (but i'd like to call them challenges). I own an old
> Macbook (this is the first generation macbook, 13inch white), it's still
> running on Tiger (i haven't updated to Leopard yet). I think the XCode
> that came with this OS is already obsolete?

What Seth said.

And: You have probably already discovered this, but there is a wealth of
developer tools (including the latest version of Xcode) at
developer.apple.com.  A not insignificant amount of material (esp.
pre-release stuff) requires an iOS or Mac developer program membership,
a _very_ small financial investment you will want to make if you start
doing this at all seriously.

> but the bottom line is i really wanted to join the team and this is
> passion. I wanted to meet great people all over the world working with
> software development.

Great to have you! As a relatively recently minted Cocoa developer I
know where you are coming from and have found the helpfulness and
welcoming nature of the community quite pleasant.

-- 
Conrad Shultz

Synthetiq Solutions
www.synthetiqsolutions.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