Re: Core Data Multiuser
Am 13.07.2012 um 21:38 schrieb Flavio Donadio: > What do you guys think about it? Is it a bad idea? I've studied a lot of > alternatives (BaseTen, ODBC, Web Services), but I can't wrap my head around > them... Use WebObjects and EOF (the big mature brother of CoreData) on the server! We feed multiple hundred thousand iOS devices daily with it - as does Apple with iTunes and the Store. atze ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Core Data book for OSX
I really want to learn more about CoreData on the Mac and am looking to get a book, besides the Apple docs. I already get the basics, but there are still many things that make me scratch my head. Often recommended is the book by Marcus Zarra, but this is out of print, and I wouldn't be surprised if they are working on an update, but no idea when that's going to be on the market. Is it still relevant, or already outdated when using (M)Lion? I can find a copy through Abebooks if needed. Or am I better off getting a more recent book about CoreData for iOS (there are several on the market, e.g. Imsted & Harrington)? I would guess that in the core (no pun) it is the same for OSX and iOS, so I may go that route. Or is a book about CoreData on iOS completely useless when developing for OSX? Thanks for any input, - Koen. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re-targetting URL Handler in users' systems
I have an app in the field which handles a url. I mean, it has one of these in its Info.plist… CFBundleURLTypes CFBundleURLSchemes myapp LSIsAppleDefaultForScheme In order to fix a longstanding issue, I've now moved this entry, and the code to support it, into a helper app which is shipped in the main app's Contents/Helpers. The idea is that the helper app now handles this URL instead of the main app. I'm going to ship this as an update. It works for me, but due to past experience with the black-boxiness of Launch Services, I'm worried that users' experiences in the field will vary. I'm not sandboxed. So I've added some code which, upon first run of the updated app, spawns an NSTask to run lsregister, giving it the path to my app obtained from [[NSBundle mainBundle] bundlePath]. Since there are two paths to lsregister in Mac OS X history, I first try the new path, then if that does not return 0, the old path [1]. Running this command takes 80-100 milliseconds on my Core 2 Duo. I'm worried there will still be trouble for some users, and would appreciate any feedback, design or test suggestions. Thanks, Jerry Krinock [1] Here are the two commands I use: Using new path to lsregister: /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -R /path/to/MyApp.app Using old path to lsregister: /System/Library/Frameworks/ApplicationServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -R /path/to/MyApp.app The arguments are passed in -[NSTask setArguments:], whose documentation indicates that I "do not need to do special quoting", which I interpret to mean that I need not quote the /path/to/MyApp.app. The option "-R" means "Recursive directory scan, descending into packages and invisible directories", which I presume is necessary in order to find my helper buried in Contents/Helpers. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Re-targetting URL Handler in users' systems
Use the LSRegisterURL() function in Launch Services. -Jeff On Jul 14, 2012, at 7:20 AM, Jerry Krinock wrote: > I have an app in the field which handles a url. I mean, it has one of these > in its Info.plist… > >CFBundleURLTypes > > >CFBundleURLSchemes > >myapp > >LSIsAppleDefaultForScheme > > > > > In order to fix a longstanding issue, I've now moved this entry, and the code > to support it, into a helper app which is shipped in the main app's > Contents/Helpers. The idea is that the helper app now handles this URL > instead of the main app. I'm going to ship this as an update. > > It works for me, but due to past experience with the black-boxiness of Launch > Services, I'm worried that users' experiences in the field will vary. I'm > not sandboxed. So I've added some code which, upon first run of the updated > app, spawns an NSTask to run lsregister, giving it the path to my app > obtained from [[NSBundle mainBundle] bundlePath]. Since there are two paths > to lsregister in Mac OS X history, I first try the new path, then if that > does not return 0, the old path [1]. Running this command takes 80-100 > milliseconds on my Core 2 Duo. > > I'm worried there will still be trouble for some users, and would appreciate > any feedback, design or test suggestions. > > Thanks, > > Jerry Krinock > > [1] Here are the two commands I use: > > Using new path to lsregister: > > /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister > -R /path/to/MyApp.app > > Using old path to lsregister: > > /System/Library/Frameworks/ApplicationServices.framework/Frameworks/LaunchServices.framework/Support/lsregister > -R /path/to/MyApp.app > > The arguments are passed in -[NSTask setArguments:], whose documentation > indicates that I "do not need to do special quoting", which I interpret to > mean that I need not quote the /path/to/MyApp.app. > > The option "-R" means "Recursive directory scan, descending into packages and > invisible directories", which I presume is necessary in order to find my > helper buried in Contents/Helpers. > > > ___ > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/publicposting%40lapcatsoftware.com > > This email sent to publicpost...@lapcatsoftware.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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Re-targetting URL Handler in users' systems
On 2012 Jul 14, at 06:42, Jeff Johnson wrote: > Use the LSRegisterURL() function in Launch Services. Very good! Thank you, Jeff. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTableView Sends Null Column to Delegate/DataSource
On Jul 13, 2012, at 10:44 PM, John Terranova wrote: > A nil tableColumn means to treat the whole row as one wide column, rather > than the individual columns. It is useful for section headers. The docs for > the applicable methods should explain the nil tableColumn. Thanks for the suggestion--although I knew this fact it did get me to re-read the docs more carefully and to experiment more, and I found the solution. I was experimenting with implementing group rows in a vanilla NSTableView, but when things were going awry I commented out tableView:isGroupRow:, thinking that this would eliminate group row handling, but no, it does not! For the archives, it is not safe to assume that tableView:isGroupRow: will determine which rows are actually group rows, at least if you implement tableView:dataCellForTableColumn:row:. It seems that regardless of whether you implement tableView:isGroupRow:, NSTableView will always send tableView:dataCellForTableColumn:row: a nil tablecolumn argument to determine whether the row is a group row (ostensibly). If you return an NSCell object, it will assume that the row is a group row and as a consequence will assume that *every* row is a group row unless the row returns nil. The solution was to both check for a nil tablecolumn value in tableView:dataCellForTableColumn:row *and* call my own implementation of tableView:isGroupRow: to make sure that the row is in fact a designated group row. > On Jul 13, 2012, at 11:21 PM, Keary Suska wrote: > >> I am having a strange issue I haven't encountered before--for all of my data >> source and delegate methods the table view is sending nil for the table >> column, which obviously prevents me from fulfilling any of the requests. Has >> anyone seen this? >> >> Xcode 4, targeting 10.6. Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data book for OSX
While not a book, I heartily recommend the Core Data video training course from ideveloper.tv. Marcus Zarra is the presenter and there was a follow-up supplement for Lion. (Sent from my iPhone.) -- Conrad Shultz On Jul 14, 2012, at 5:06, Koen van der Drift wrote: > I really want to learn more about CoreData on the Mac and am looking to get a > book, besides the Apple docs. I already get the basics, but there are still > many things that make me scratch my head. > > Often recommended is the book by Marcus Zarra, but this is out of print, and > I wouldn't be surprised if they are working on an update, but no idea when > that's going to be on the market. Is it still relevant, or already outdated > when using (M)Lion? I can find a copy through Abebooks if needed. > > Or am I better off getting a more recent book about CoreData for iOS (there > are several on the market, e.g. Imsted & Harrington)? I would guess that in > the core (no pun) it is the same for OSX and iOS, so I may go that route. Or > is a book about CoreData on iOS completely useless when developing for OSX? > > Thanks for any input, > > - Koen. > > > > ___ > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/conrad%40synthetiqsolutions.com > > This email sent to con...@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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data book for OSX
On Jul 14, 2012, at 1:56 PM, Conrad Shultz wrote: > While not a book, I heartily recommend the Core Data video training course > from ideveloper.tv. Marcus Zarra is the presenter and there was a follow-up > supplement for Lion. Unfortunately the original course has been discontinued. I had a look at the sample video for the Lion supplement, and am not sure yet if I like the format of the video watching two guys chatting on a couch. I think I prefer reading to learn something new. But thanks for the link, - Koen. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTableView Sends Null Column to Delegate/DataSource
On Jul 14, 2012, at 10:08 , Keary Suska wrote: > For the archives, it is not safe to assume that tableView:isGroupRow: will > determine which rows are actually group rows, at least if you implement > tableView:dataCellForTableColumn:row:. It seems that regardless of whether > you implement tableView:isGroupRow:, NSTableView will always send > tableView:dataCellForTableColumn:row: a nil tablecolumn argument to determine > whether the row is a group row (ostensibly). If you return an NSCell object, > it will assume that the row is a group row and as a consequence will assume > that *every* row is a group row unless the row returns nil. A group row is one drawn with with different style characteristics. (In a normal table, for example, it has a gradient shaded background.) This is controlled by 'tableView:isGroupRow:'. A group cell is one that draws the *entire row* as a single cell (and cells are not drawn per column). This is controlled by 'tableView:dataCellForTableColumn:nil row:'. The two things are orthogonal, although in many cases you'll want the the group row to use a group cell to span the width of the table. One case where you might use a group cell *not* in a group row is in an outline view, where expandable rows might not need to show column information like detail rows. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
ABPerson does not have interface properties ?
This one has to be pretty simple.
There is a category of ABPerson which provides this interface. So what have I
missed ?
OSX, 10.7
#import "RSAppDelegate.h"
#import
#import
@implementation RSAppDelegate
- (void)applicationDidFinishLaunching:(NSNotification *) notification {
addressBook = [ABAddressBook addressBook];
// this line works and loads 81 records into the content array...
// [peopleArrayController setContent:[addressBook people]];
for(ABPerson * person in [addressBook people]) {
NSArray * props = [person properties]; // No visible
@interface for 'ABPerson' declares the selector 'properties'
NSMutableDictionary * d = [[NSMutableDictionary alloc] init];
for( NSString * propName in props ) {
[d setObject:[person valueForProperty:propName]
forKey:propName];
}
[peopleArrayController addObject:d];
}
NSLog(@"%s- [%04d] Number of people records loaded: %lu",
__PRETTY_FUNCTION__, __LINE__, [[peopleArrayController content] count]);
}
@end
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: ABPerson does not have interface properties ? SOLVED
My mistake. 'properties' is a class method, returning the keys; not an
instance method, as I was using it below.
On 2012-07-14, at 7:01 PM, Erik Stainsby wrote:
> This one has to be pretty simple.
> There is a category of ABPerson which provides this interface. So what have I
> missed ?
> OSX, 10.7
>
>
> #import "RSAppDelegate.h"
> #import
> #import
>
> @implementation RSAppDelegate
>
> - (void)applicationDidFinishLaunching:(NSNotification *) notification {
>
> addressBook = [ABAddressBook addressBook];
> // this line works and loads 81 records into the content array...
> // [peopleArrayController setContent:[addressBook people]];
>
>
> for(ABPerson * person in [addressBook people]) {
>
> NSArray * props = [person properties]; // No visible
> @interface for 'ABPerson' declares the selector 'properties'
>
> NSMutableDictionary * d = [[NSMutableDictionary alloc] init];
> for( NSString * propName in props ) {
> [d setObject:[person valueForProperty:propName]
> forKey:propName];
> }
> [peopleArrayController addObject:d];
> }
>
> NSLog(@"%s- [%04d] Number of people records loaded: %lu",
> __PRETTY_FUNCTION__, __LINE__, [[peopleArrayController content] count]);
> }
>
> @end
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Core Data Multiuser
On Jul 14, 2012, at 5:18 AM, Alexander Spohr wrote: > > Am 13.07.2012 um 21:38 schrieb Flavio Donadio: > >> What do you guys think about it? Is it a bad idea? I've studied a lot of >> alternatives (BaseTen, ODBC, Web Services), but I can't wrap my head around >> them... > > Use WebObjects and EOF (the big mature brother of CoreData) on the server! > > We feed multiple hundred thousand iOS devices daily with it - as does Apple > with iTunes and the Store. Um, what? Hasn't WebObjects effectively been orphaned [as in, Apple may still be using it internally, but they are no longer publicly updating it or providing support for it]? And yes, I agree it was kickass technology that I wish Apple would at least sell to somebody else to make a product out of instead just letting it die. As for the OP's request, might I suggest using the BaseTen framework. Its an open-source PostgreSQL-backed database framework that works like CoreData [it even uses the CoreData database layout file to configure PostgreSQL]. Eli ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
