Re: iOS 9 features in iOS 8 targeted projects with swift #availability check
On Aug 16, 2015, at 09:20 , Sasikumar JP jps...@gmail.com wrote: But i am getting compilation error on Main.storyboard UIStackView before iOS 9.0 What’s the “Build for” setting in the File inspector for Main.storyboard? The default is “deployment target”, which means iOS 8 in your case, but you’ll need to set it to iOS 9 explicitly, to use the new features. ___ 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: Nullability annotation best practice
Really? This list has no opinions? That's hard to imagine :-) -- Seth Willits On Aug 8, 2015, at 1:15 PM, Seth Willits sli...@araelium.com wrote: Let's stipulate that _Nullable and _Nonnull are great to have because they can catch bugs and express API intent better than before, so we want them. The question is where to put them? _Nullable and _Nonnull make perfect sense to specify in the @interface. Since those annotations existing in the @interface will produce applicable warnings and errors in the counterpart @implementation,there's really no _need_ to respecify them in the @implementation of those same methods. It makes sense for private methods to have nullability annotations for all the same reasons public Now let's assume that private methods aren't specified in any @interface, even the anonymous one. In that case, those methods would naturally have no annotations on their parameters or return values unless they're specified within the @implementation. But specifying them on the private methods in the @implementation while *not* specifying them for the public methods in the @implementation is inconsistent and potentially confusing. So I see two choices here: 1) Always add nullability annotations, for all methods and properties in both the @interface and @implementation. (Private methods may or may not be declared within @interfaces — but these days I think it's generally not done?) 2) Only add nullability annotations in the @interface, and always declare private methods within an @interface. Is there a third choice I'm not thinking of? Thoughts? I'm curious how Apple is adopting these annotations themselves. -- 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
iOS 9 features in iOS 8 targeted projects with swift #availability check
Hi,
I have an existing iOS application which is supports from iOS 8. i want
to add new features only for iOS 9.
I have created a new storyboard for iOS 9(Main.storyboard) which is using
the iOS 9 features like UIStackView. Appropriate storyboard file is
instantiated based on the Device OS version.
func application(application: UIApplication,
didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -
Bool {
let storyboard: UIStoryboard
if #available(iOS 9, *, *) {
storyboard = UIStoryboard(name: Main, bundle: nil)
} else {
storyboard = UIStoryboard(name: MainOld, bundle: nil)
}
let mainViewController =
storyboard.instantiateInitialViewController()
window?.rootViewController = mainViewController
window?.makeKeyAndVisible()
return true
}
But i am getting compilation error on Main.storyboard UIStackView before
iOS 9.0
I am using Xcode 7 beta 5.
How to use the iOS 9 related features on the iOS 8 supported projects using
Swift 2 #availability check
Regards
Sasikumar JP
___
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: Nullability annotation best practice
On Aug 16, 2015, at 09:10 , Seth Willits sli...@araelium.com wrote: Really? This list has no opinions? That's hard to imagine :-) Well, I do, but I didn’t post it because I didn’t think you’d like it. I don’t think it’s worth annotating private methods at all (in general — I’m sure there are specific cases where it’s a clear benefit). It seems to me there are 2 main reasons why you’d want to: 1. Documentation/API contract When creating methods for *others* to use, such as at the API boundary of a framework, the more clarity the better, and the more the compiler can check the better. But for methods that are internal to an implementation, the chances are that the “client code will have been written before the nullability is settled — or the nullability is obvious enough that the annotation isn’t needed. 2. Swift compatibility This is the important case, because the nullability changes the type of the interface when bridged into Swift. When neither of the above is a controlling consideration, for the majority of pure Obj-C code, nullability annotations seem rather redundant. I see 3 issues: a. Origination For a method that originates an object pointer — typically an ‘init’ method or a factory class method that basically wraps an ‘init’ — I think it’s better not to return nil at all, in most cases. That is, if super init may itself return nil, then you should test for that and crash, rather than just passing on the nil. If the originating method does need to indicate failure by returning nil, the pattern I’ve adopted is *always* to return a NSError via a NSError** parameter in the normal way. Not only is this self-annotating, both in the interface and at every call site, it also promotes proper error handling by making it clear when you’ve left an error unhandled at the call site. b. Propagation Once you’ve adopted a consistent origination pattern, then propagating object pointers (that is, passing them around as parameters) stops being problematic, mostly, since they mostly aren’t nil by accident … c. Optionality … except in the the case where you specify nil literally, as in the case of an optional parameter value. Some such cases are already covered by Obj-C coding patterns. For example, if you’re passing a dictionary of options, passing nil instead of an empty dictionary is probably all the same to the called code. Sometimes it does matter. For example, when passing a completion block, it really matters whether it can be nil or not, because invoking a nil block pointer will crash. In such cases, the implementation (having decided whether it will check for nil or require non-nil) *should*, I think, annotate the method parameter, but I’d be inclined to do that in *both* the @implementation and @interface if both exist, just like you would for something like ‘const’. My argument in all this is that Obj-C has its own characteristic patterns for handling nil object pointers, which may be diverse and situational, but have been honed by time. The new annotations (including NS_DESIGNATED_INITIALIZER and generics) seem to me to be geared towards reducing the impedance mismatch with Swift, and I think it distorts Obj-C to Swift-ize it if it’s not actually being bridged. In the relatively rare cases where annotations resolve an existing pain point (such as nil vs. non-nil completion block pointers), then use them. But I’m unconvinced about the need for wholesale adoption. ___ 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: Nullability annotation best practice
I’ve annotated the public methods of the API of a framework and though I haven’t yet I will annotate internal methods and functions as well. I found a small number of issues where my thinking had not been clear, and that having to stop and consider what was intended when annotating the public API for nullability exposed my lack of clarity. I did not have any recorded bugs in this case but I could see how the API could be used that would result in bugs, crashing or otherwise. I would not be surprised if the same could be said of the private methods. I feel that there is value in annotating the private methods and functions and that this value is not insignificant. The private API is much larger than the public, so a lot more work is required and it will probably be done incrementally, but that also means there is likely a lot more potential bugs. I can understand why you might not annotate private methods, but I think a blanket ruling does not make sense. Kevin On 16 Aug 2015, at 18:47, Quincey Morris quinceymor...@rivergatesoftware.com wrote: On Aug 16, 2015, at 09:10 , Seth Willits sli...@araelium.com wrote: Really? This list has no opinions? That's hard to imagine :-) Well, I do, but I didn’t post it because I didn’t think you’d like it. I don’t think it’s worth annotating private methods at all (in general — I’m sure there are specific cases where it’s a clear benefit). It seems to me there are 2 main reasons why you’d want to: 1. Documentation/API contract When creating methods for *others* to use, such as at the API boundary of a framework, the more clarity the better, and the more the compiler can check the better. But for methods that are internal to an implementation, the chances are that the “client code will have been written before the nullability is settled — or the nullability is obvious enough that the annotation isn’t needed. 2. Swift compatibility This is the important case, because the nullability changes the type of the interface when bridged into Swift. When neither of the above is a controlling consideration, for the majority of pure Obj-C code, nullability annotations seem rather redundant. I see 3 issues: a. Origination For a method that originates an object pointer — typically an ‘init’ method or a factory class method that basically wraps an ‘init’ — I think it’s better not to return nil at all, in most cases. That is, if super init may itself return nil, then you should test for that and crash, rather than just passing on the nil. If the originating method does need to indicate failure by returning nil, the pattern I’ve adopted is *always* to return a NSError via a NSError** parameter in the normal way. Not only is this self-annotating, both in the interface and at every call site, it also promotes proper error handling by making it clear when you’ve left an error unhandled at the call site. b. Propagation Once you’ve adopted a consistent origination pattern, then propagating object pointers (that is, passing them around as parameters) stops being problematic, mostly, since they mostly aren’t nil by accident … c. Optionality … except in the the case where you specify nil literally, as in the case of an optional parameter value. Some such cases are already covered by Obj-C coding patterns. For example, if you’re passing a dictionary of options, passing nil instead of an empty dictionary is probably all the same to the called code. Sometimes it does matter. For example, when passing a completion block, it really matters whether it can be nil or not, because invoking a nil block pointer will crash. In such cases, the implementation (having decided whether it will check for nil or require non-nil) *should*, I think, annotate the method parameter, but I’d be inclined to do that in *both* the @implementation and @interface if both exist, just like you would for something like ‘const’. My argument in all this is that Obj-C has its own characteristic patterns for handling nil object pointers, which may be diverse and situational, but have been honed by time. The new annotations (including NS_DESIGNATED_INITIALIZER and generics) seem to me to be geared towards reducing the impedance mismatch with Swift, and I think it distorts Obj-C to Swift-ize it if it’s not actually being bridged. In the relatively rare cases where annotations resolve an existing pain point (such as nil vs. non-nil completion block pointers), then use them. But I’m unconvinced about the need for wholesale adoption. ___ 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/ktam%40yvs.eu.com
Re: iOS 9 features in iOS 8 targeted projects with swift #availability check
Quincey, Thank you for the information. I changed the build for value to iOS 9. it works fine now. I am able to run the application on both iOS 9 and iOS 8. Regards Sasikumar JP On Sun, Aug 16, 2015 at 10:24 PM, Quincey Morris quinceymor...@rivergatesoftware.com wrote: On Aug 16, 2015, at 09:20 , Sasikumar JP jps...@gmail.com wrote: But i am getting compilation error on Main.storyboard UIStackView before iOS 9.0 What’s the “Build for” setting in the File inspector for Main.storyboard? The default is “deployment target”, which means iOS 8 in your case, but you’ll need to set it to iOS 9 explicitly, to use the new features. ___ 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: Help understanding Apple's approach in documentation a little better.
If the debugger's variable pane exposes it, it's misleading if it doesn't somehow indicate that it's not for the developer to access. It is there for the developer to access -- when debugging. Might even be useful. I sometimes find the information useful when trying to understand how something is put together. But don’t use it for development. At the least, it's confusing, because the docs say it's not supposed to be there, yet there it is. The docs say no such thing or did I miss explicit statements that only documented methods and properties will ever exist? I think Ken is correct in saying Their non-presence in the documentation and headers” is what shows them as private. Private is not that same as “not supposed to be 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSViewController view not showing in NScrollView
Hello.
I have a window controlled by a NSWindowController subclass with a standard
nsscrollview. (Outlets are connected).
I load a custom view via a NSViewController subclass. (view outlet is
connected).
The custom view is not visible.
@implementation AppDelegate
- (IBAction) newWindow:(id)sender {
mwc=[[MonWindowController alloc]
initWithWindowNibName:@MonsterWindow];
subLayout=[[PRMLayout alloc] initWithNibName:@StdLayout bundle:nil];
subLayout.view; // force view to load. Necessary?
[mwc setPRMLayout:subLayout];
[mwc showWindow:self];
};
@end
@implementation MonWindowController
- (void) setPRMLayout:(PRMLayout*)layout {
[scrollView setDocumentView:layout.view];
};
@end
Before I added in a custom NSWindowController, the window belonged to the
AppDelegate (standard app template with a single window connected to
AppDelegate). The window had the standard NSScrollView.
When I added the custom view (NSViewController subclass and nib) to the
scrollview, the custom view actually displayed.
Changing to custom NSWindowController broke this somehow.
What am I missing?
TIA
Mark
___
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
Help understanding Apple's approach in documentation a little better.
I'm currently writing a storyboard inspector for helping to create more modular
app pieces in iOS (8)
The idea is if you have enough functionality that is self contained enough, it
should (I hope) be organizationally more efficient to create a storyboard that
handles the desired functionality and can be launched and disposed of as needed.
Naturally, I'm relying on Apple's docs to help me build this and access
UIStoryboard properties, methods and set up my little methods to manage this
process.
So, I look at UIStoryboard.h and the docs and see that there are 3 methods. No
properties.
OK.
That seems sparse.
While building this out and finding out where I screw up with UIStoryboard, I
am using the little category to extend NSObject that dumps all the properties,
property classes and where appropriate, the property values of any object
instance that originates.
And in using it, I find out that in addition to the 3 methods within
UIStoryboard.h, inside a an instance of UIStoryboard, there are a bunch of
properties that appear to be stupidly useful.
Like so:
designatedEntryPointIdentifier
identifierToNibNameMap
storyboardFileName
name
bundle
That seems sparse.
In my case, we have these values which appear in an instance of the
ForgotPassword module I'm creating.
[UIStoryboard {identifierToUINibMap: NSMutableDictionary = (null);
designatedEntryPointIdentifier: NSString = (null);
identifierToNibNameMap: NSDictionary = {
Forgot Password View Controller = Forgot Password View Controller;
Nav Controller = Nav Controller;
Password Has Been Changed View Controller = Password Has Been Changed
View Controller;
};
storyboardFileName: NSString = ForgotPassword.storyboardc;
name: NSString = ForgotPassword;
bundle: NSBundle = NSBundle
/private/var/mobile/Containers/Bundle/Application/F965FA03-0B4C-4BCC-BCAF-F7339A190492/SomeSillyApp.app
(loaded);
}]
This is really great. I can see if any of my view controllers' scenes'
identifiers are misspelled, I can see what Cocoa's using and verify where or if
I screwed up somewhere.
This is really useful information.
Why isn't it in Apple's documentation for storyboards?
Is it in Apple's documentation for storyboards but I don't know where to look?
If it is, what concept am I missing about understanding Apple's way of
documenting their classes that would help me better understand how to look and
where to look when researching?
I find it really, really odd that the docs go to great extent to try and
present the information they have in an educational and seemingly complete
manner and then find that oh, we didn't bother to tell you about this stuff
and we're not going to make it easy to find it at all.
See, Apple's docs RARELY say oh, and you might also want to look here if
you're looking for XXX about YYY.
They give you the impression that these are complete and that's all the
information you should need to know about the subject. We're giving you all
that you need.
Well, identifierToNibNameMap tells me where/if I screwed up my identifier names
for scenes for my view controllers.
I never would have known about these unlisted (yet accessible and valuable)
properties unless I used a special tool to show what's in each object that
derives from NSObject. That feels really really, um, deceiving (for lack of a
better term).
Am I doing it wrong?
Thanks,
Alex Zavatone
___
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: Help understanding Apple's approach in documentation a little better.
On Aug 16, 2015, at 3:09 PM, Alex Zavatone z...@mac.com wrote: So, I look at UIStoryboard.h and the docs and see that there are 3 methods. No properties. And in using it, I find out that in addition to the 3 methods within UIStoryboard.h, inside a an instance of UIStoryboard, there are a bunch of properties that appear to be stupidly useful. Like so: designatedEntryPointIdentifier identifierToNibNameMap storyboardFileName name bundle This is really great. I can see if any of my view controllers' scenes' identifiers are misspelled, I can see what Cocoa's using and verify where or if I screwed up somewhere. This is really useful information. Why isn't it in Apple's documentation for storyboards? Because these are private implementation details. They are subject to change without notice. You can't rely on them in any shipping code. Is it in Apple's documentation for storyboards but I don't know where to look? If it is, what concept am I missing about understanding Apple's way of documenting their classes that would help me better understand how to look and where to look when researching? The concept you're missing is the existence of private implementation details. I never would have known about these unlisted (yet accessible and valuable) properties unless I used a special tool to show what's in each object that derives from NSObject. Because you weren't supposed to know about them. That's why they're unlisted. That feels really really, um, deceiving (for lack of a better term). The fact that classes can have private details is deceiving? Or the fact that Objective-C's run time allows introspection that reveals them? Am I doing it wrong? Yes. If it's not in the documentation or headers, you shouldn't be using it (except for recreational/educational exploration or debugging). 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Help understanding Apple's approach in documentation a little better.
On Aug 16, 2015, at 5:35 PM, Ken Thomases wrote: On Aug 16, 2015, at 4:18 PM, Alex Zavatone z...@mac.com wrote: On Aug 16, 2015, at 4:49 PM, Ken Thomases wrote: On Aug 16, 2015, at 3:09 PM, Alex Zavatone z...@mac.com wrote: Why isn't it in Apple's documentation for storyboards? Because these are private implementation details. They are subject to change without notice. You can't rely on them in any shipping code. If they were private shouldn't there be a naming convention that states they are private? No, there's no naming convention for properties to indicate they are private. If I look at an instance of a storyboard object in the Variables View in the Debugger, I can expand the object and they are all listed. And? You've already shown they are visible in the runtime's information about the class. It's not surprising that the debugger also has access to this information. Is there some sort of naming or visual convention that communicates you might be see these, but they're private and not for you to mess with? No. As soon as I saw them exposed by the runtime tool, and I saw that expanding the storyboard instance exposed them, I thought that the docs and header files were hiding information that was accessible. They are accessible through these (and probably other) mechanisms, but that doesn't mean they are _appropriate_ to access. Working with the frameworks or a library is always subject to a design contract. There are plenty of times when it's _possible_ to do something but, if the design contract doesn't specifically allow it, it's disallowed. Accessing private properties is just a particular case of this general rule. Is there anything that shows that they are private? Their non-presence in the documentation and headers. Would be REALLY nice if there was something visual that simply communicated to you that they are not for public consumption. If I see it in the left pane of the debugger, and no visual indicators are stating that it's restricted, It's telling us that it's available - unless we spend the time to look up the internals for everything that's displayed in the variables pane that exposes an object instanced from a framework class. I know it's too simplistic to assume that a color change would be enough and appropriate to indicate to the programmer that you can see there, but you really don't have access to them, but SOME sort of treatment to the private data would be really nice when displaying it, so that it's painfully obvious to the developer that it's private freaking data. The developer should just have to look and instantly see that it's data that's used behind the scenes and they can't play with it. If the debugger's variable pane exposes it, it's misleading if it doesn't somehow indicate that it's not for the developer to access. At the least, it's confusing, because the docs say it's not supposed to be there, yet there it is. Fun. Thanks, Ken. Dearly appreciated. - Alex Zavatone ___ 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: Help understanding Apple's approach in documentation a little better.
On 16 Aug 2015, at 22:18, Alex Zavatone z...@mac.com wrote: On Aug 16, 2015, at 4:49 PM, Ken Thomases wrote: On Aug 16, 2015, at 3:09 PM, Alex Zavatone z...@mac.com wrote: So, I look at UIStoryboard.h and the docs and see that there are 3 methods. No properties. And in using it, I find out that in addition to the 3 methods within UIStoryboard.h, inside a an instance of UIStoryboard, there are a bunch of properties that appear to be stupidly useful. Like so: designatedEntryPointIdentifier identifierToNibNameMap storyboardFileName name bundle This is really great. I can see if any of my view controllers' scenes' identifiers are misspelled, I can see what Cocoa's using and verify where or if I screwed up somewhere. This is really useful information. Why isn't it in Apple's documentation for storyboards? Because these are private implementation details. They are subject to change without notice. You can't rely on them in any shipping code. If they were private shouldn't there be a naming convention that states they are private? If I look at an instance of a storyboard object in the Variables View in the Debugger, I can expand the object and they are all listed. Is there some sort of naming or visual convention that communicates you might be see these, but they're private and not for you to mess with? As soon as I saw them exposed by the runtime tool, and I saw that expanding the storyboard instance exposed them, I thought that the docs and header files were hiding information that was accessible. Is there anything that shows that they are private? Yes, whether they’re in the header or not! And even then, any instance variables that appear in headers are almost always marked as private there, either using @private or a comment, depending on the age of the code. ___ 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: Help understanding Apple's approach in documentation a little better.
On Aug 16, 2015, at 4:18 PM, Alex Zavatone z...@mac.com wrote: On Aug 16, 2015, at 4:49 PM, Ken Thomases wrote: On Aug 16, 2015, at 3:09 PM, Alex Zavatone z...@mac.com wrote: Why isn't it in Apple's documentation for storyboards? Because these are private implementation details. They are subject to change without notice. You can't rely on them in any shipping code. If they were private shouldn't there be a naming convention that states they are private? No, there's no naming convention for properties to indicate they are private. If I look at an instance of a storyboard object in the Variables View in the Debugger, I can expand the object and they are all listed. And? You've already shown they are visible in the runtime's information about the class. It's not surprising that the debugger also has access to this information. Is there some sort of naming or visual convention that communicates you might be see these, but they're private and not for you to mess with? No. As soon as I saw them exposed by the runtime tool, and I saw that expanding the storyboard instance exposed them, I thought that the docs and header files were hiding information that was accessible. They are accessible through these (and probably other) mechanisms, but that doesn't mean they are _appropriate_ to access. Working with the frameworks or a library is always subject to a design contract. There are plenty of times when it's _possible_ to do something but, if the design contract doesn't specifically allow it, it's disallowed. Accessing private properties is just a particular case of this general rule. Is there anything that shows that they are private? Their non-presence in the documentation and headers. 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Sharing Prefs between Main and Helper App
On Wed, 12 Aug 2015 15:50:35 -0600, Alex Kac said: I have an OS X app signed with Developer ID. It is NOT sandboxed (I suppose I could, but I'd prefer to stay away from that for a bit longer). I need my helper and main app to share prefs. There must be a simple way to do this for now. I know that initWithSuite works with App Groups and sandbox…but again I don't want to be sandboxed just yet. I suspect initWithSuite works without App Sandbox too... Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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: Help understanding Apple's approach in documentation a little better.
On Aug 16, 2015, at 4:49 PM, Ken Thomases wrote: On Aug 16, 2015, at 3:09 PM, Alex Zavatone z...@mac.com wrote: So, I look at UIStoryboard.h and the docs and see that there are 3 methods. No properties. And in using it, I find out that in addition to the 3 methods within UIStoryboard.h, inside a an instance of UIStoryboard, there are a bunch of properties that appear to be stupidly useful. Like so: designatedEntryPointIdentifier identifierToNibNameMap storyboardFileName name bundle This is really great. I can see if any of my view controllers' scenes' identifiers are misspelled, I can see what Cocoa's using and verify where or if I screwed up somewhere. This is really useful information. Why isn't it in Apple's documentation for storyboards? Because these are private implementation details. They are subject to change without notice. You can't rely on them in any shipping code. If they were private shouldn't there be a naming convention that states they are private? If I look at an instance of a storyboard object in the Variables View in the Debugger, I can expand the object and they are all listed. Is there some sort of naming or visual convention that communicates you might be see these, but they're private and not for you to mess with? As soon as I saw them exposed by the runtime tool, and I saw that expanding the storyboard instance exposed them, I thought that the docs and header files were hiding information that was accessible. Is there anything that shows that they are private? Is it in Apple's documentation for storyboards but I don't know where to look? If it is, what concept am I missing about understanding Apple's way of documenting their classes that would help me better understand how to look and where to look when researching? The concept you're missing is the existence of private implementation details. I never would have known about these unlisted (yet accessible and valuable) properties unless I used a special tool to show what's in each object that derives from NSObject. Because you weren't supposed to know about them. That's why they're unlisted. That feels really really, um, deceiving (for lack of a better term). The fact that classes can have private details is deceiving? Or the fact that Objective-C's run time allows introspection that reveals them? Am I doing it wrong? Yes. If it's not in the documentation or headers, you shouldn't be using it (except for recreational/educational exploration or debugging). Yeah, in this case that leads to other questions of, well, how can I get access to that functionality those private variables expose, because it's damn useful, but that's for another day. 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
