Re: Triggering a segue from code

[mail...@ericgorr.net]

Based on stuff I have been playing with, #2 seems like the “right” solution 
based on the design of the framework. A segue is currently not designed to 
support this behavior and it is always a mistake, I have learned, to try to 
fight the framework (which eliminates #1 & #4).


> On Sep 25, 2016, at 3:52 PM, Quincey Morris 
>  wrote:
> 
> On Sep 25, 2016, at 11:59 , mail...@ericgorr.net 
>  wrote:
>> 
>> 2. The reason why I do a performClose is because I want it to do the same 
>> thing as when the user presses the close button on the panel, which they are 
>> allowed to do. Unless I were to remove the close button from the inspector 
>> panel (which I do not want to do), my overall problem remains. 
> 
> 
> There are a couple of different approaches you can take:
> 
> 1. You know now that if you performClose or close the panel, a storyboard 
> segue is going to create a new instance. You can deal with that by keeping 
> enough panel state outside the panel view controller to re-configure a new 
> panel if it’s created. That is, you don’t need the existence of the panel to 
> be continuous. All you need is one panel at a time.
> 
> 2. Don’t use segues for this. Move the panel to its own storyboard or XIB 
> file. (Instantiate the storyboard in code, or load the NIB via the view 
> controller initWithNibName initializer.)
> 
> 3. Don’t do the performClose behavior. The point of the button-highlighting 
> behavior is to indicate the window being affected when the user does 
> something non-specific like choosing File -> Close or typing Command-W. 
> Neither of those (presumably) will affect your inspector panel — otherwise 
> it’d be too confusing for the user, whether a document window or the 
> inspector was going to be closed.
> 
> If the user has to click a button (e.g. toolbar or regular window button) to 
> hide the inspector, the animated interaction *is* that button’s down/up 
> transition, so there’s no need for it in the panel’s title bar.
> 
> 4. You could, I suppose, subclass NSPanel and override the “close” method. 
> The documentation says that “performClose” invokes “close”. You should be 
> able to have the “close” override  do an “orderOut:” instead.
> 

___

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

Detecting user termination of an iOS auto-renewing subscription

[Lou Zell]

Hi all,

Using the App Store receipt verification system, is there a way to detect
when an auto-renewing iOS subscriber terminates their subscription _before_
the expiration date of their current subscription passes?

I am referring to a user going through:
iTunes > Account > View My Account > Settings > Subscriptions > Manage and
choosing to end their subscription.

AFAIK it is impossible to terminate a subscription via the sandbox purchase
system (a monthly subscription renews automatically at five minute
intervals for a total of 6 times and then stops), so I don't know how to
test this situation.

I believe the "cancel_date" and "cancel_date_ms" properties of a receipt
from the purchase system will _not_ be set in this case, as the guidance
around these terms say to "Treat a canceled receipt the same as if no
purchase had ever been made", which is not the same as terminating a
subscription before the next auto-renew date.

Are there any receipt fields that I could use to determine that a user has
terminated their auto-renew subscription?

At the end of the day we'd like to identify customers that are about to
leave!  Any guidance on this would be much appreciated!

Thanks,
Lou
___

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: Triggering a segue from code

[Quincey Morris]

On Sep 25, 2016, at 11:59 , mail...@ericgorr.net wrote:
> 
> 2. The reason why I do a performClose is because I want it to do the same 
> thing as when the user presses the close button on the panel, which they are 
> allowed to do. Unless I were to remove the close button from the inspector 
> panel (which I do not want to do), my overall problem remains. 


There are a couple of different approaches you can take:

1. You know now that if you performClose or close the panel, a storyboard segue 
is going to create a new instance. You can deal with that by keeping enough 
panel state outside the panel view controller to re-configure a new panel if 
it’s created. That is, you don’t need the existence of the panel to be 
continuous. All you need is one panel at a time.

2. Don’t use segues for this. Move the panel to its own storyboard or XIB file. 
(Instantiate the storyboard in code, or load the NIB via the view controller 
initWithNibName initializer.)

3. Don’t do the performClose behavior. The point of the button-highlighting 
behavior is to indicate the window being affected when the user does something 
non-specific like choosing File -> Close or typing Command-W. Neither of those 
(presumably) will affect your inspector panel — otherwise it’d be too confusing 
for the user, whether a document window or the inspector was going to be closed.

If the user has to click a button (e.g. toolbar or regular window button) to 
hide the inspector, the animated interaction *is* that button’s down/up 
transition, so there’s no need for it in the panel’s title bar.

4. You could, I suppose, subclass NSPanel and override the “close” method. The 
documentation says that “performClose” invokes “close”. You should be able to 
have the “close” override  do an “orderOut:” instead.

___

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: Triggering a segue from code

[mail...@ericgorr.net]

Thank you again for your reply Quincey. 

1. I have updated the code to keep a reference to the window controller instead 
of the window as you suggest. As you suspected, the bad behavior does not 
change.

2. The reason why I do a performClose is because I want it to do the same thing 
as when the user presses the close button on the panel, which they are allowed 
to do. Unless I were to remove the close button from the inspector panel (which 
I do not want to do), my overall problem remains. 

At this point, I may be left with simply using one of my TSI’s to resolve this 
problem and determine what the correct behavior is. It will be interesting if 
this turns out to be a bug that needs to be reported.

If anyone has any ideas on how I can get this working as expected, please let 
me know.

Again, the sample test project is located at:

https://github.com/ericgorr/nspanel_show 




> On Sep 19, 2016, at 11:07 PM, Quincey Morris 
>  wrote:
> 
> On Sep 19, 2016, at 18:10 , mail...@ericgorr.net 
>  wrote:
>> 
>> The strange behavior I am now seeing is that when I show & hide the panel 
>> using the buttons are what appears to be two (not three, not four, etc.) 
>> different instances of the inspector panel. The autosave information only 
>> appears to apply to one but not the other.
> 
> A couple of things:
> 
> 1. You’re keeping the panel window instance reference in 
> InspectorWindowController.sharedInstance, but not keeping a reference to its 
> window controller. That causes its window controller to be deallocated early, 
> although that likely has nothing to with the rest of the problem, since the 
> panel doesn’t have any custom behavior yet. You should keep a reference to 
> the window controller instead, and that will keep the panel alive too.
> 
> 2. You’re doing a “performClose” to hide the panel. If you do an orderOut 
> instead, you get the behavior you want.
> 
> Note that you are getting a new instance of the panel because the window 
> segue mechanism decides the first one has disappeared. Again because it’s not 
> documented how window segues work, there’s no way of knowing what the 
> “correct” behavior is supposed to be. (Your panel window is correctly set to 
> “Single” mode in the storyboard, which is what’s supposed to prevent multiple 
> instances from appearing.)
> 
> Also undocumented — forever AFAIK although others on this list may know more 
> about this — is what a window “close” (or “performClose”) does, other than 
> ordering out the window and (if it’s set to release on close) to release it. 
> Whatever a “close” actually does, it’s making the storyboard mechanism unable 
> to find the panel instance, so it creates a new one. (Your panel is *not* set 
> to release on close, and I was able to verify that it’s not being released 
> regardless, so this is not anything you appear to be doing wrong.)
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Subclassing and Archiving/Unarchiving

[Graham Cox]

> On 25 Sep 2016, at 8:12 PM, Dave  wrote:
> 
> Is there any way that I can get the archiver to just select the Base Class 
> and ignore the extra properties in the Subclass? Or is there a better way of 
> doing this?


You mean the dearchiver.

It can have a delegate (NSKeyedUnarchiverDelegate, 
https://developer.apple.com/reference/foundation/nskeyedunarchiverdelegate?language=objc).
 It can be called when it encounters a class it doesn’t recognise, and the 
delegate can return a different class, for example the base class. It is given 
a list of the class hierarchy (as strings) so that it can do this easily.

There are also class methods for setting up class substitutions.

You could also add the extra information as a subobject within the base class, 
and simply ignore it when dearchiving.

—Graham



___

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: ITMS-90171 libswiftRemoteMirror.dylib

[Torsten Curdt]

As it turns out xcodebuild logs the actual error somewhere before and just
gives the summary at the end.
The error building the archive was a library that didn't have bitcode
enabled.

Oh well.

Still would love to understand why "build" adds the
" libswiftRemoteMirror.dylib" though.


On Sun, Sep 25, 2016 at 12:07 PM, Torsten Curdt  wrote:

> Current reading suggests that (whatever ibswiftRemoteMirror.dylib is)
> this is a difference between xcodebuild archive vs build (for whatever
> reasons). Since I can't find any further information on this I tried the
> archive approach:
>
> xcodebuild
>   -project "Foo.xcodeproj"
>   -scheme "App"
>   -configuration "Release"
>   -sdk "iphoneos10.0"
>   -archivePath "/foo/build/iphoneos10.0/Release.xcarchive"
>   archive
>   PROVISIONING_PROFILE="48d27476-3d52-45a5-9a56-798dc440f66a"
>   CODE_SIGN_IDENTITY="iPhone Distribution: Foo (L9EV9UUBV1)"
>
> unfortunately that fails with very little information
>
> ** ARCHIVE FAILED **
>
> The following build commands failed:
>   Ld /Users/tcurdt/Library/Developer/Xcode/DerivedData/Foo-
> btjldebpjrkpqcgbdqvakwjpfyim/Build/Intermediates/ArchiveIntermediates/App/
> IntermediateBuildFilesPath/Foo.build/Release-iphoneos/
> Foo.build/Objects-normal/armv7/Foo normal armv7
> (1 failure)
>
> Looking at the target for "Ld" I find
>
> ls -la /Users/tcurdt/Library/Developer/Xcode/DerivedData/Foo-
> btjldebpjrkpqcgbdqvakwjpfyim/Build/Intermediates/ArchiveIntermediates/App/
> IntermediateBuildFilesPath/Foo.build/Release-iphoneos/
> Foo.build/Objects-normal/armv7/Foo*
>
> -rw-r--r--  1 tcurdt  staff  136881 Sep 25 11:48
> [...]/Foo.build/Objects-normal/armv7/Foo-OutputFileMap.json
> -rw-r--r--  1 tcurdt  staff   26533 Sep 25 11:48
> [...]/Foo.build/Objects-normal/armv7/Foo-Swift.h
> -rw-r--r--  1 tcurdt  staff8672 Sep 25 11:48
> [...]/Foo.build/Objects-normal/armv7/Foo-master.swiftdeps
> -rw-r--r--  1 tcurdt  staff   18599 Sep 25 11:48
> [...]/Foo.build/Objects-normal/armv7/Foo.LinkFileList
> -rw-r--r--  1 tcurdt  staff 608 Sep 25 11:48
> [...]/Foo.build/Objects-normal/armv7/Foo.swiftdoc
> -rw-r--r--  1 tcurdt  staff  521816 Sep 25 11:48
> [...]/Foo.build/Objects-normal/armv7/Foo.swiftmodule
> -rw-r--r--  1 tcurdt  staff   68757 Sep 25 11:48
> [...]/Foo.build/Objects-normal/armv7/Foo_dependency_info.dat
>
> Any idea?
>
> cheers,
> Torsten
>
>
> On Sun, Sep 25, 2016 at 2:02 AM, Torsten Curdt  wrote:
>
>> I was just trying to upload an IPA to Testflight I am getting:
>>
>> ERROR ITMS-90171: "Invalid Bundle Structure - The binary file
>> 'Foo.app/libswiftRemoteMirror.dylib' is not permitted. Your app can’t
>> contain standalone executables or libraries, other than the
>> CFBundleExecutable of supported bundles. Refer to the Bundle Programming
>> Guide at https://developer.apple.com/go/?id=bundle-structure for
>> information on the iOS app bundle structure."
>>
>> What's libswiftRemoteMirror.dylib? And where is it coming from?
>>
>> Google and SO were not particularly helpful yet.
>> Any pointers would be great.
>>
>> cheers,
>> Torsten
>>
>
>
___

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: ITMS-90171 libswiftRemoteMirror.dylib

[Torsten Curdt]

As for going with "build" instead of "archive" I see this in the log

builtin-swiftStdLibTool --copy --verbose --sign
99D83694482D58B0EBB9A85D9528ECC7247A7DB1
--scan-executable /project/build/iphoneos10.0/Applications/Foo.app/Foo
--scan-folder
/project/build/iphoneos10.0/Applications/Foo.app/Frameworks
--scan-folder /project/build/iphoneos10.0/Applications/Foo.app/PlugIns

--scan-folder
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS10.0.sdk/System/Library/Frameworks/SystemConfiguration.framework
...the frameworks from the platform...

--scan-folder /project/Carthage/Build/iOS/HockeySDK.framework
...the frameworks from Carthage...

--platform iphoneos
--toolchain
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain
--toolchain
/Applications/Xcode.app/Contents/Developer/Toolchains/Swift_2.3.xctoolchain
--toolchain
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain
--destination
/project/build/iphoneos10.0/Applications/Foo.app/Frameworks
--strip-bitcode
--resource-destination /project/build/iphoneos10.0/Applications/Foo.app
--resource-library libswiftRemoteMirror.dylib

Besides the weird toolchain parameter (twice the default and Swift 2.3
while I am using Swift 3.0) there is "--resource-library
libswiftRemoteMirror.dylib"

Not that this makes me any wiser.


On Sun, Sep 25, 2016 at 2:02 AM, Torsten Curdt  wrote:

> I was just trying to upload an IPA to Testflight I am getting:
>
> ERROR ITMS-90171: "Invalid Bundle Structure - The binary file
> 'Foo.app/libswiftRemoteMirror.dylib' is not permitted. Your app can’t
> contain standalone executables or libraries, other than the
> CFBundleExecutable of supported bundles. Refer to the Bundle Programming
> Guide at https://developer.apple.com/go/?id=bundle-structure for
> information on the iOS app bundle structure."
>
> What's libswiftRemoteMirror.dylib? And where is it coming from?
>
> Google and SO were not particularly helpful yet.
> Any pointers would be great.
>
> cheers,
> Torsten
>
___

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

Subclassing and Archiving/Unarchiving

[Dave]

Hi All,

I have an App that produces Archives files that are loaded by another App. The 
Classes that get archived are in a set of common files that both Apps share. 

During the build process I need to carry extra information that only the writer 
app knows about. My first instinct was to create a subclasses in the writer App 
for each Class I need the “extra” information, but of course this won’t work 
because the App that loads the files won’t know about the subclasses.

I was thinking of putting a wrapper around these classes but it is quite ugly 
compared to subclassing. The other thing I could do is to builder a new base 
class from the subclass that mean a lot of  deep copying.

Is there any way that I can get the archiver to just select the Base Class and 
ignore the extra properties in the Subclass? Or is there a better way of doing 
this?

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: ITMS-90171 libswiftRemoteMirror.dylib

[Torsten Curdt]

Current reading suggests that (whatever ibswiftRemoteMirror.dylib is) this
is a difference between xcodebuild archive vs build (for whatever reasons).
Since I can't find any further information on this I tried the archive
approach:

xcodebuild
  -project "Foo.xcodeproj"
  -scheme "App"
  -configuration "Release"
  -sdk "iphoneos10.0"
  -archivePath "/foo/build/iphoneos10.0/Release.xcarchive"
  archive
  PROVISIONING_PROFILE="48d27476-3d52-45a5-9a56-798dc440f66a"
  CODE_SIGN_IDENTITY="iPhone Distribution: Foo (L9EV9UUBV1)"

unfortunately that fails with very little information

** ARCHIVE FAILED **

The following build commands failed:
  Ld
/Users/tcurdt/Library/Developer/Xcode/DerivedData/Foo-btjldebpjrkpqcgbdqvakwjpfyim/Build/Intermediates/ArchiveIntermediates/App/IntermediateBuildFilesPath/Foo.build/Release-iphoneos/Foo.build/Objects-normal/armv7/Foo
normal armv7
(1 failure)

Looking at the target for "Ld" I find

ls -la
/Users/tcurdt/Library/Developer/Xcode/DerivedData/Foo-btjldebpjrkpqcgbdqvakwjpfyim/Build/Intermediates/ArchiveIntermediates/App/IntermediateBuildFilesPath/Foo.build/Release-iphoneos/Foo.build/Objects-normal/armv7/Foo*

-rw-r--r--  1 tcurdt  staff  136881 Sep 25 11:48
[...]/Foo.build/Objects-normal/armv7/Foo-OutputFileMap.json
-rw-r--r--  1 tcurdt  staff   26533 Sep 25 11:48
[...]/Foo.build/Objects-normal/armv7/Foo-Swift.h
-rw-r--r--  1 tcurdt  staff8672 Sep 25 11:48
[...]/Foo.build/Objects-normal/armv7/Foo-master.swiftdeps
-rw-r--r--  1 tcurdt  staff   18599 Sep 25 11:48
[...]/Foo.build/Objects-normal/armv7/Foo.LinkFileList
-rw-r--r--  1 tcurdt  staff 608 Sep 25 11:48
[...]/Foo.build/Objects-normal/armv7/Foo.swiftdoc
-rw-r--r--  1 tcurdt  staff  521816 Sep 25 11:48
[...]/Foo.build/Objects-normal/armv7/Foo.swiftmodule
-rw-r--r--  1 tcurdt  staff   68757 Sep 25 11:48
[...]/Foo.build/Objects-normal/armv7/Foo_dependency_info.dat

Any idea?

cheers,
Torsten


On Sun, Sep 25, 2016 at 2:02 AM, Torsten Curdt  wrote:

> I was just trying to upload an IPA to Testflight I am getting:
>
> ERROR ITMS-90171: "Invalid Bundle Structure - The binary file
> 'Foo.app/libswiftRemoteMirror.dylib' is not permitted. Your app can’t
> contain standalone executables or libraries, other than the
> CFBundleExecutable of supported bundles. Refer to the Bundle Programming
> Guide at https://developer.apple.com/go/?id=bundle-structure for
> information on the iOS app bundle structure."
>
> What's libswiftRemoteMirror.dylib? And where is it coming from?
>
> Google and SO were not particularly helpful yet.
> Any pointers would be great.
>
> cheers,
> Torsten
>
___

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