iOS Calendar Question
Hi, I've had a request for the following functionality and I'm not sure from the docs if it is possible, this App is for iOS 5+. The App has presented a number of events in a table view. The request is to add a button to an item that saves it to the User's Calendar. This seems easy enough, BUT: 1. If possible they don't want to have the "Application XXX has requested access to your Calendar" Alert. 2 They don't want it to just be added blindly to the underlying Calendar Database, but rather then want to launch the Native Calendar App with the Event Details and have the event all setup in the UI so that all the user has to do is tap Save or Cancel. I can't figure from reading the docs if this is possible or not? All the examples I've seen trigger the Alert Box the first time access is requested. All the Best Dave PS. If the word "Cancel" was replaced with "Camel" in every button on every computer in the world, what percentage would notice and how would they interpret it? ___ 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: iOS Calendar Question
On 19 Sep 2013, at 15:17, Mike Abdullah wrote: > > On 19 Sep 2013, at 15:00, Dave wrote: > >> Hi, >> >> I've had a request for the following functionality and I'm not sure from the >> docs if it is possible, this App is for iOS 5+. >> >> The App has presented a number of events in a table view. >> >> The request is to add a button to an item that saves it to the User's >> Calendar. This seems easy enough, BUT: >> >> 1. If possible they don't want to have the "Application XXX has >> requested access to your Calendar" Alert. >> >> 2 They don't want it to just be added blindly to the underlying >> Calendar Database, but rather then want to launch the Native Calendar App >> with the Event Details and have the event all setup in the UI so that all >> the user has to do is tap Save or Cancel. >> >> I can't figure from reading the docs if this is possible or not? All the >> examples I've seen trigger the Alert Box the first time access is requested. > > You don't say what you've already tried. Have you looked at the EventKitUI > framework? > Yes, I've looked at it, but all the examples assume Access has been Granted or explicitly asks for it. I can't run on a device at the moment so I can't test it. All the searches I've done do the same. I think don't its possible because it might be a security threat? All the Best Dave ___ 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: iOS Calendar Question
The answer to both of those is no, with a caveat or two. The first is Apple's explicit permissions policy since iOS 6 (so 5 still works but 5 is a small installed base now). You have to ask permission the first time and permission can be revoked by the user randomly on the setup screen later. I don't honestly recall the details of how you keep track of your current state so you can enable/disable buttons or put up a sheet asking the user to turn it back on again (once they turn it off, going to setup is the only way to put it back). This is a regrettable result of the kind of idiots who would, and probably did, write apps which spewed the calendar with 'events' full of click-to-pay links and other trash. So the rule is, you have to ask once, you can be shut off at any time, and once the user says no, they mean no, the app won't ask again on your behalf, they have to turn you back on from settings. Finding the nicest way to gracefully deal with that in an app is challenging. The second, there is no URL scheme for opening the calendar, certainly not a published one and the .. reverse engineered one you may find on the net only opens the calendar at a certain place, if it even works at all any more, doesn't let you add a putative event and switch to the app. On the bright side, a custom piece of UI to show the calendar event(s) designed for your app would probably look nicer than the stock calendar UI anyway and linking fully with the calendar in the app, depending on what it does, might give you some nice ways to show upcoming events for that app. On 19 Sep, 2013, at 10:00 pm, Dave wrote: > Hi, > > I've had a request for the following functionality and I'm not sure from the > docs if it is possible, this App is for iOS 5+. > > The App has presented a number of events in a table view. > > The request is to add a button to an item that saves it to the User's > Calendar. This seems easy enough, BUT: > > 1. If possible they don't want to have the "Application XXX has > requested access to your Calendar" Alert. > > 2 They don't want it to just be added blindly to the underlying > Calendar Database, but rather then want to launch the Native Calendar App > with the Event Details and have the event all setup in the UI so that all the > user has to do is tap Save or Cancel. > > I can't figure from reading the docs if this is possible or not? All the > examples I've seen trigger the Alert Box the first time access is requested. > > All the Best > Dave > > PS. > > If the word "Cancel" was replaced with "Camel" in every button on every > computer in the world, what percentage would notice and how would they > interpret it? > > > > > ___ > > 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/rols%40rols.org > > This email sent to r...@rols.org ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: iOS Calendar Question
On 19 Sep 2013, at 15:28, Roland King wrote: > The answer to both of those is no, with a caveat or two. > Thanks a lot. > The first is Apple's explicit permissions policy since iOS 6 (so 5 still > works but 5 is a small installed base now). You have to ask permission the > first time and permission can be revoked by the user randomly on the setup > screen later. I don't honestly recall the details of how you keep track of > your current state so you can enable/disable buttons or put up a sheet asking > the user to turn it back on again (once they turn it off, going to setup is > the only way to put it back). You don't have to keep track of it, you just need to requestAccess in your App (as many times as you like), if the App already has permission you get "Granted" status, otherwise it puts up a dialog asking the User if its ok and you get back "Granted" if they allowed. Until you get "Granted" Status, any of the other API calls will return an error. > This is a regrettable result of the kind of idiots who would, and probably > did, write apps which spewed the calendar with 'events' full of click-to-pay > links and other trash. So the rule is, you have to ask once, you can be shut > off at any time, and once the user says no, they mean no, the app won't ask > again on your behalf, they have to turn you back on from settings. Finding > the nicest way to gracefully deal with that in an app is challenging. Yes, plus it's a back door to reading info too. > > The second, there is no URL scheme for opening the calendar, certainly not a > published one and the .. reverse engineered one you may find on the net only > opens the calendar at a certain place, if it even works at all any more, > doesn't let you add a putative event and switch to the app. > > On the bright side, a custom piece of UI to show the calendar event(s) > designed for your app would probably look nicer than the stock calendar UI > anyway and linking fully with the calendar in the app, depending on what it > does, might give you some nice ways to show upcoming events for that app. > They are worried most people will say NO and want to avoid it if possible. All the Best Dave > > On 19 Sep, 2013, at 10:00 pm, Dave wrote: > >> Hi, >> >> I've had a request for the following functionality and I'm not sure from the >> docs if it is possible, this App is for iOS 5+. >> >> The App has presented a number of events in a table view. >> >> The request is to add a button to an item that saves it to the User's >> Calendar. This seems easy enough, BUT: >> >> 1. If possible they don't want to have the "Application XXX has >> requested access to your Calendar" Alert. >> >> 2 They don't want it to just be added blindly to the underlying >> Calendar Database, but rather then want to launch the Native Calendar App >> with the Event Details and have the event all setup in the UI so that all >> the user has to do is tap Save or Cancel. >> >> I can't figure from reading the docs if this is possible or not? All the >> examples I've seen trigger the Alert Box the first time access is requested. >> >> All the Best >> Dave >> >> PS. >> >> If the word "Cancel" was replaced with "Camel" in every button on every >> computer in the world, what percentage would notice and how would they >> interpret it? >> >> >> >> >> ___ >> >> 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/rols%40rols.org >> >> This email sent to r...@rols.org > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: [OT] iTunes 11.1 Beta
You can use Google to search Apple's dev site... site:https://developer.apple.com iTunes You can also use it to search the archive for this list... site:http://lists.apple.com/archives/cocoa-dev iTunes Jeff >Found it now, thanks. It's ok I am an Apple Mac and iOS Developer. The Apple Developer site Search Engine sucks - I did a lot of different searches for iTunes 11.1 and it found zilch!! ___ 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
Still can't get autolayout to work the way I want
Xc5, iOS 7, simulator. I have a popover that comes up fine. But when I click on a cell, and it segues to the next scene, it then grows the popover in width to fill the iPad screen. The target scene is a static table view. It has two custom cells with labels in one group, and a cell used as a button: http://cl.ly/image/0Z3R2M0a1T0m I don't know of any easy way to show the constraints, but the labels have fixed width and height, baselines are aligned, the editable fields are vertically centered and have fixed height, and left, middle, and right space is fixed. If the editable field widths are left unconstrained, the whole thing grows. If I try to constrain the width, I get unsatisfiable constraints, it breaks the width constraint, and then grows the popover only a little in width: 2013-09-19 14:41:15.303 MatterScan[5864:a0b] Unable to simultaneously satisfy constraints. Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. (Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints) ( "", "", "", "", "", "", "", "", "" ) Will attempt to recover by breaking constraint I am never able to get this shit right 100% of the time, and I don't know if it's because I'm doing something wrong, or iOS is broken and I need to do something else. Any ideas? -- 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Still can't get autolayout to work the way I want
On Sep 19, 2013, at 15:22 , Hunter Hillegas wrote: > If you haven’t seen it, Apple did expand the AutoLayout Programming Guide > about a week ago to be more expansive. > > Also, it’s probably been said a million times but doing AutoLayout w/ Xcode 4 > was terrible and with Xcode 5, it works a ton better. I'm having HUGE problems in Xc5. My comments just now are wrt Xc5 and iOS 7. You wouldn't believe how buggy IB is in Xc5 for me. I'd venture to say it's worse in a lot of ways. -- 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Still can't get autolayout to work the way I want
That’s too bad. My experience has been quite good but of course, each project is different and some things are more complex than others. On Sep 19, 2013, at 3:24 PM, Rick Mann wrote: > I'm having HUGE problems in Xc5. My comments just now are wrt Xc5 and iOS 7. > You wouldn't believe how buggy IB is in Xc5 for me. I'd venture to say it's > worse in a lot of ways. ___ 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: Still can't get autolayout to work the way I want
On Sep 19, 2013, at 2:45 PM, Rick Mann wrote: > I am never able to get this shit right 100% of the time, and I don't know if > it's because I'm doing something wrong, or iOS is broken and I need to do > something else. As a second to Rick's request, auto-layout has given me fits on both iOS and OS X. I have not found the Auto-Layout Guide doc or various blog / other posts or WWDC sessions (unless I missed one that had this in it) on it to be a silver bullet. I find the pre-autolayout springs/struts approach to be easy to understand, but more importantly, it behaves consistently and the IB UI doesn't seem to get confused. With auto-layout, I've had no such success -- the IB UI seems to have a will of its own, and the UI seems to continually generate or change various things inexplicably in response to what are by all other indications proper constraints you create. If anyone out there has THE definitive guide on how to use auto-layout and accomplish various common use cases of relative resizing, you have money waiting in my wallet. Thanks, Brad ___ 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: Still can't get autolayout to work the way I want
On Sep 19, 2013, at 15:26 , Hunter Hillegas wrote: > That’s too bad. My experience has been quite good but of course, each project > is different and some things are more complex than others. It's complex to describe the issues I'm seeing. I've made a half-dozen screen casts for bugs I sent to Apple, but they show proprietary info so I can't post them. But basically, IB adjusts scenes all over my storyboard even though I'm not editing them. It constantly changes autolayout constraints I've put in place, even though I'm not editing those scenes. It fails to size views to the size I specify. It arbitrarily changes sizes or constraints all over my storyboard. -- 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Modifying the save path in an NSDocument based application
The answer, if anyone else is thinking of answering this question, is to use
NSFileWrapper - ensuring that "Document is distributed as a bundle" is
unchecked for the folder that you generate.
Simples. And my apologies to all here for not investigating further before
posting a question.
On 18 Sep 2013, at 20:54, Pax <45rpmli...@googlemail.com> wrote:
> Okay, the plot thickens. I've now updated my app for the app store -
> sandboxing is now enabled. Sandboxing breaks the save path modification,
> and particularly my creation of a folder:
>
> if(![fileManager createDirectoryAtPath:directory
>withIntermediateDirectories:NO
> attributes:nil
> error:&error])
> {
> NSLog(@"Failed to create directory \"%@\". Error: %@ - this
> save will most likely fail entirely.", directory, error);
> }
> else
> { ... }
>
> With sandboxing enabled, the creation of the directory always fails - unless
> the user opts to save in the Downloads directory. Most odd.
>
> The user can choose to save an undecoded version of the file wherever they
> like. I have set read/write access for the Downloads Folder - which probably
> explains this. How can I get read/write access to wherever the user chooses
> to extract the files (most likely Documents, loose in their home folder, or
> the desktop?)
___
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: Still can't get autolayout to work the way I want
I love the power of auto-layout, but I'll be damned if I can make it behave when working on the GUI .xib file. I've taken to using auto-layout without .xib, building the UI elements in the viewController.m and attaching NSLayoutContraints manually. It's a bit of a pain, but if the layout is complicated I think it's time saved. On Sep 19, 2013, at 6:18 PM, Brad O'Hearne wrote: > On Sep 19, 2013, at 2:45 PM, Rick Mann wrote: > >> I am never able to get this shit right 100% of the time, and I don't know if >> it's because I'm doing something wrong, or iOS is broken and I need to do >> something else. > > As a second to Rick's request, auto-layout has given me fits on both iOS and > OS X. I have not found the Auto-Layout Guide doc or various blog / other > posts or WWDC sessions (unless I missed one that had this in it) on it to be > a silver bullet. I find the pre-autolayout springs/struts approach to be easy > to understand, but more importantly, it behaves consistently and the IB UI > doesn't seem to get confused. With auto-layout, I've had no such success -- > the IB UI seems to have a will of its own, and the UI seems to continually > generate or change various things inexplicably in response to what are by all > other indications proper constraints you create. > > If anyone out there has THE definitive guide on how to use auto-layout and > accomplish various common use cases of relative resizing, you have money > waiting in my wallet. > > Thanks, > > Brad > ___ > > 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/caoimghgin%40gmail.com > > This email sent to caoimgh...@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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Still can't get autolayout to work the way I want
On Sep 19, 2013, at 15:29 , Kevin Muldoon wrote: > I love the power of auto-layout, but I'll be damned if I can make it behave > when working on the GUI .xib file. I've taken to using auto-layout without > .xib, building the UI elements in the viewController.m and attaching > NSLayoutContraints manually. It's a bit of a pain, but if the layout is > complicated I think it's time saved. Does IB not put in any constraints when you lay out the basic nib? Or do you do the "Clear Constraints" command when you're done? Do you remove them programmatically? How do you deal with the autoresizing constraints iOS still seems to apply? -- 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Window controllers and memory leaks
Although the problem in this thread has been solved, a project I'm working needed a systematic way to hang on to transient windows. And subclassing NSWindowController as I suggested last week is costly due to lack of multiple inheritance in Objective-C. So today I wrote a new class which… /* @briefProvides a place for window controllers that control transient windows to "hang out" without being deallocced, so that you don't junk up your app delegate with repeated boilerplate code and instance variables. */ Now any time I want a window controller to simply stick around until its window closes, [SSYWindowHangout hangOutWindowController:windowController] ; A little more code this time. Also comes in a demo project. https://github.com/jerrykrinock/SSYWindowHangoutDemo ___ 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: Still can't get autolayout to work the way I want
Yes, IB does automagically pop in constraints and for simple layouts, it works. But, with more complicated layouts, moving a single element around will rearrange one or more other constraints, generally breaking everything. I'm not familiar with the clear constraints command in IB, but like I was mentioning earlier, I'm avoiding the creation and use of .xib files for anything but the simplest layouts. Maybe iOS7 constraints have improved drastically, I just haven't had the time to dig into it. Anyway, this link is a nice intro into building UI from code with constraints... http://ioscreator.com/auto-layout-in-ios-6-adding-constraints-through-code/ On Sep 19, 2013, at 6:31 PM, Rick Mann wrote: > > On Sep 19, 2013, at 15:29 , Kevin Muldoon wrote: > >> I love the power of auto-layout, but I'll be damned if I can make it behave >> when working on the GUI .xib file. I've taken to using auto-layout without >> .xib, building the UI elements in the viewController.m and attaching >> NSLayoutContraints manually. It's a bit of a pain, but if the layout is >> complicated I think it's time saved. > > Does IB not put in any constraints when you lay out the basic nib? Or do you > do the "Clear Constraints" command when you're done? Do you remove them > programmatically? How do you deal with the autoresizing constraints iOS still > seems to apply? > > -- > 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: iOS Calendar Question
On 19 Sep 2013, at 15:00, Dave wrote: > Hi, > > I've had a request for the following functionality and I'm not sure from the > docs if it is possible, this App is for iOS 5+. > > The App has presented a number of events in a table view. > > The request is to add a button to an item that saves it to the User's > Calendar. This seems easy enough, BUT: > > 1. If possible they don't want to have the "Application XXX has > requested access to your Calendar" Alert. > > 2 They don't want it to just be added blindly to the underlying > Calendar Database, but rather then want to launch the Native Calendar App > with the Event Details and have the event all setup in the UI so that all the > user has to do is tap Save or Cancel. > > I can't figure from reading the docs if this is possible or not? All the > examples I've seen trigger the Alert Box the first time access is requested. You don't say what you've already tried. Have you looked at the EventKitUI framework? ___ 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: iOS Calendar Question
On Sep 19, 2013, at 8:41 AM, Dave wrote: > > They are worried most people will say NO and want to avoid it if possible. Then they have missed the entire point of the feature. Ironically, they're doing a fantastic job of illustrating why Apple made it mandatory and unavoidable in the first place. --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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: iOS Calendar Question
On 19 Sep 2013, at 17:12, Kyle Sluder wrote: > On Sep 19, 2013, at 8:41 AM, Dave wrote: >> >> They are worried most people will say NO and want to avoid it if possible. > > Then they have missed the entire point of the feature. > > Ironically, they're doing a fantastic job of illustrating why Apple made it > mandatory and unavoidable in the first place. > > --Kyle Sluder I agree but the PM was adamant that it was possible - maybe he worked on a project that was <= iOS 5. Anyway, I've told him we can't do it and waiting to see what he says. Cheers Dave ___ 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: Still can't get autolayout to work the way I want
If you haven’t seen it, Apple did expand the AutoLayout Programming Guide about a week ago to be more expansive. Also, it’s probably been said a million times but doing AutoLayout w/ Xcode 4 was terrible and with Xcode 5, it works a ton better. On Sep 19, 2013, at 3:18 PM, Brad O'Hearne wrote: > If anyone out there has THE definitive guide on how to use auto-layout and > accomplish various common use cases of relative resizing, you have money > waiting in my wallet. ___ 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: Still can't get autolayout to work the way I want
On Sep 19, 2013, at 3:50 PM, Kevin Muldoon wrote: > Yes, IB does automagically pop in constraints and for simple layouts, it > works. But, with more complicated layouts, moving a single element around > will rearrange one or more other constraints, generally breaking everything. > I'm not familiar with the clear I have yet to spend much time in Xcode 5 with auto-layout constraints, but what both Kevin and Rick are describing sounds similar to what I'm experiencing. I have no problem with a smart tool inserting constraints when a constraint I add necessitates the ones being auto-generated (if such a thing exists, though this would raise the logical issue of whether the UI ought to display those other constraints as a package-deal per se, rather than just inserting them, because in that case, you are really deciding on more than just the constraint you are adding, you are deciding on the others constraining the UI too). But that is not what I'm seeing. I'm seeing completely random, in some cases wholly unrelated, and in others conflicting constraints being added that completely change the layout visually to something unintended. It's like the Miss Cleo of development tools, trying to read my mind repeatedly but being completely wrong. (Sorry, I don't know why the ebaum's World Miss Cleo soundboard prank call popped into my head as an analogy for this). Anyway, you get the point. I have found myself actually devoting time to trying to reverse-think how some of these auto-generated constraints appear, because some of them are so wacky I find myself wondering that it must be something ridiculously simple I'm missing. Brad ___ 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: Still can't get autolayout to work the way I want
On Sep 19, 2013, at 4:23 PM, Brad O'Hearne wrote: > > Anyway, you get the point. I have found myself actually devoting time to > trying to reverse-think how some of these auto-generated constraints appear, > because some of them are so wacky I find myself wondering that it must be > something ridiculously simple I'm missing. All of this is so vastly improved in Xcode 5 that I honestly can't compare them. Xcode 5 doesn't insert any constraints for you at design time. You are free to drop anything you want wherever you want on the canvas, and no blue tentacles will emerge from your views. When Xcode compiles your nib, any views without constraints attached to them will get fixed top, left, width, and constraints that reflect their position in the canvas. This means you can test our your interfaces while getting reasonable, if not ultimately desired, autoresizing behavior. Once you add a constraint to a view, IB now starts providing hints as to what other constraints you need to add to correctly define that view's size and position. But it never forces those constraints on you. Even if you install a consistent and unambiguous set of constraints on a view, you can then drag that view willy-nilly around its container. IB will warn you that what you get at runtime will look wildly different from where the views are right now, and it will let you quickly snap the views back to their runtime frames (which are represented by a dotted outline). IB also has support for marking individual constraints as "placeholders", meaning they are removed at compile time. This lets you design your interface with constraints that mimic ones which will get installed at runtime. You can also provide a placeholder intrinsic content size, which is very useful for placing custom controls. --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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Still can't get autolayout to work the way I want
On Sep 19, 2013, at 17:29 , Kyle Sluder wrote: > Xcode 5 doesn't insert any constraints for you at design time. You are free > to drop anything you want wherever you want on the canvas, and no blue > tentacles will emerge from your views. This is not the behavior I'm experiencing. Well, I guess it is, but IB keeps changing the values of my constraints all the time, even when I'm editing unrelated scenes. -- 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Still can't get autolayout to work the way I want
On Sep 19, 2013, at 5:30 PM, Rick Mann wrote: > > > This is not the behavior I'm experiencing. Well, I guess it is, but IB keeps > changing the values of my constraints all the time, even when I'm editing > unrelated scenes. Is IB changing the *values*, or the *numbers* that appear on the constraints? If a view’s frame is out of whack with its constraints, the constraints in conflict will be drawn in orange, with a number badge atop them. This badge represents the difference between the calculated value of that dimension and the view’s current value. For example, if you add a horizontal centering constraint to a view, then move that view 10pt to the right, the vertical centering constraint will draw in orange and have a “+10” badge atop it. If you’re actually seeing the constraint *constants* change, then you’ve certainly found a bug. --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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Still can't get autolayout to work the way I want
On Sep 19, 2013, at 17:36 , Kyle Sluder wrote: > Is IB changing the *values*, or the *numbers* that appear on the constraints? > > If a view’s frame is out of whack with its constraints, the constraints in > conflict will be drawn in orange, with a number badge atop them. This badge > represents the difference between the calculated value of that dimension and > the view’s current value. > > For example, if you add a horizontal centering constraint to a view, then > move that view 10pt to the right, the vertical centering constraint will draw > in orange and have a “+10” badge atop it. > > If you’re actually seeing the constraint *constants* change, then you’ve > certainly found a bug. Nope, it's changing constants. Even after I fix the frames, it moves them or changes the constraints, or something. -- 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Still can't get autolayout to work the way I want
To get the new Xcode 5.0 auto layout workflows, check to make sure that you don't have your development target for the nib set to 4.6. You can check this by selecting the document, opening the file inspector, and under "Interface Builder Document" make sure "Opens In" is set to "Default (5.0)" or "Xcode 5.0". Xcode 5.0 provides new workflows but also maintains compatibility with the 4.6 workflow if you want it. When you open a 4.6 document we will prompt you to upgrade to the 5.0 format. If you clicked "Skip" when opening one of these documents they you still have the Xcode 4.6 behavior (which does automatic constraint insertions and deletions). Kevin On 19 Sep 2013, at 17:29, Kyle Sluder wrote: > On Sep 19, 2013, at 4:23 PM, Brad O'Hearne wrote: >> >> Anyway, you get the point. I have found myself actually devoting time to >> trying to reverse-think how some of these auto-generated constraints appear, >> because some of them are so wacky I find myself wondering that it must be >> something ridiculously simple I'm missing. > > All of this is so vastly improved in Xcode 5 that I honestly can't compare > them. > > Xcode 5 doesn't insert any constraints for you at design time. You are free > to drop anything you want wherever you want on the canvas, and no blue > tentacles will emerge from your views. > > When Xcode compiles your nib, any views without constraints attached to them > will get fixed top, left, width, and constraints that reflect their position > in the canvas. This means you can test our your interfaces while getting > reasonable, if not ultimately desired, autoresizing behavior. > > Once you add a constraint to a view, IB now starts providing hints as to what > other constraints you need to add to correctly define that view's size and > position. But it never forces those constraints on you. Even if you install a > consistent and unambiguous set of constraints on a view, you can then drag > that view willy-nilly around its container. IB will warn you that what you > get at runtime will look wildly different from where the views are right now, > and it will let you quickly snap the views back to their runtime frames > (which are represented by a dotted outline). > > IB also has support for marking individual constraints as "placeholders", > meaning they are removed at compile time. This lets you design your interface > with constraints that mimic ones which will get installed at runtime. You can > also provide a placeholder intrinsic content size, which is very useful for > placing custom controls. > > --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: > https://lists.apple.com/mailman/options/cocoa-dev/cathey%40apple.com > > This email sent to cat...@apple.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: Still can't get autolayout to work the way I want
On 19 Sep 2013, at 17:37, Rick Mann wrote: > > On Sep 19, 2013, at 17:36 , Kyle Sluder wrote: > >> Is IB changing the *values*, or the *numbers* that appear on the constraints? >> >> If a view’s frame is out of whack with its constraints, the constraints in >> conflict will be drawn in orange, with a number badge atop them. This badge >> represents the difference between the calculated value of that dimension and >> the view’s current value. >> >> For example, if you add a horizontal centering constraint to a view, then >> move that view 10pt to the right, the vertical centering constraint will >> draw in orange and have a “+10” badge atop it. >> >> If you’re actually seeing the constraint *constants* change, then you’ve >> certainly found a bug. > > Nope, it's changing constants. Even after I fix the frames, it moves them or > changes the constraints, or something. This would be a very serious issue and the constants of CONSTRAINTS should never get automatically changed in Xcode 5. Are you sure it's not just changing the frames? According to some of the bugs you've filed the constraints are intact but the frames are getting messed up because of a different bug (to be fixed in an upcoming update). Kevin > > > -- > 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: > https://lists.apple.com/mailman/options/cocoa-dev/cathey%40apple.com > > This email sent to cat...@apple.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: Still can't get autolayout to work the way I want
That might be. It's hard for me to tell at a glance what's going in (might help to add the constants to the geometry tab list of constraints in the inspector. Sent from my iPhone On Sep 19, 2013, at 18:17, Kevin Cathey wrote: > > On 19 Sep 2013, at 17:37, Rick Mann wrote: > >> >> On Sep 19, 2013, at 17:36 , Kyle Sluder wrote: >> >>> Is IB changing the *values*, or the *numbers* that appear on the >>> constraints? >>> >>> If a view’s frame is out of whack with its constraints, the constraints in >>> conflict will be drawn in orange, with a number badge atop them. This badge >>> represents the difference between the calculated value of that dimension >>> and the view’s current value. >>> >>> For example, if you add a horizontal centering constraint to a view, then >>> move that view 10pt to the right, the vertical centering constraint will >>> draw in orange and have a “+10” badge atop it. >>> >>> If you’re actually seeing the constraint *constants* change, then you’ve >>> certainly found a bug. >> >> Nope, it's changing constants. Even after I fix the frames, it moves them or >> changes the constraints, or something. > This would be a very serious issue and the constants of CONSTRAINTS should > never get automatically changed in Xcode 5. > > Are you sure it's not just changing the frames? According to some of the bugs > you've filed the constraints are intact but the frames are getting messed up > because of a different bug (to be fixed in an upcoming update). > > Kevin > >> >> >> -- >> 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: >> https://lists.apple.com/mailman/options/cocoa-dev/cathey%40apple.com >> >> This email sent to cat...@apple.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: iOS Calendar Question
> >> The first is Apple's explicit permissions policy since iOS 6 (so 5 still >> works but 5 is a small installed base now). You have to ask permission the >> first time and permission can be revoked by the user randomly on the setup >> screen later. I don't honestly recall the details of how you keep track of >> your current state so you can enable/disable buttons or put up a sheet >> asking the user to turn it back on again (once they turn it off, going to >> setup is the only way to put it back). > > > You don't have to keep track of it, you just need to requestAccess in your > App (as many times as you like), if the App already has permission you get > "Granted" status, otherwise it puts up a dialog asking the User if its ok and > you get back "Granted" if they allowed. Until you get "Granted" Status, any > of the other API calls will return an error. > Hmm - and I thought that once the user said "No" and denied access, then requestAccess would just return No instantly without putting up the dialog box again until you went to settings. ie I thought there were 3 states, Yes, No and Don't Know and the dialog box would only pop up for 'Don't know'. I'll go test that again, haven't done it in ages. ___ 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: Still can't get autolayout to work the way I want
On Sep 19, 2013, at 5:50 PM, Kevin Muldoon wrote: > Yes, IB does automagically pop in constraints and for simple layouts, it > works. But, with more complicated layouts, moving a single element around > will rearrange one or more other constraints, generally breaking everything. > I'm not familiar with the clear constraints command in IB, but like I was > mentioning earlier, I'm avoiding the creation and use of .xib files for > anything but the simplest layouts. Maybe iOS7 constraints have improved > drastically, I just haven't had the time to dig into it. Anyway, this link is > a nice intro into building UI from code with constraints... > > http://ioscreator.com/auto-layout-in-ios-6-adding-constraints-through-code/ Not anymore in Xcode 5. As others have pointed out, XC5 no longer adds any constraints automatically, but in addition to that, moving things around doesn't break or change constraints anymore, either. You should give it a try — it's much improved. Charles ___ 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
