Re: LGPL code in the Mac App Store?

[Quincey Morris]

I dunno, but it seems to me that this thread ran off the rails right at the 
start.

It would be the end of the App Store if it were possible to strip the code 
signature out of a downloaded app and then just run it. However, what happens 
after the code signature is tampered with is going to depend on what happens to 
the MAS receipt when the code signature is tampered with. (I have to assume 
that the receipt won’t be usable any more, otherwise that seems to open up a 
too easy security hole in itself.)

Anyway, I think the only viable way to let the purchaser substitute a rebuilt 
framework is to package the LGPL framework separately, and have it placed in 
/Library/Frameworks rather than inside the app bundle. Presumably that would 
satisfy the LGPL. (It’ll also require an installer.)

Unfortunately, that isn’t terribly viable either. In order to prevent conflicts 
between apps doing this with different versions or derivations of the LGPL 
code, the LGPL framework would have to have a unique name, which means it’s 
going to take a custom make file (at least) to build it, which means it’s 
always a derivative build, and you’re going to have to post instructions 
somewhere about how to build it.

But it’s worse than that. Open source libraries are *frequently* 
ABI-incompatible between versions. When you choose a particular version to use 
with your app, you have no particular guarantee that the source code of your 
version is going to continue to be available at the repository where you found 
it, or anywhere else. For that reason, to satisfy the LGPL you’ll have to 
maintain a public site with the source code so that *your* version can be 
rebuilt.

Lastly, I seem to recall that it was a bit doubtful whether the MAS’s 
intellectual property rules allowed even LGPL software to be part of MAS apps. 
Perhaps that’s long been resolved, but you’ve gotta be worried that the MAS 
rules are yet another legal cloud threaten to rain on the open source parade.

I’d be very happy to be proved wrong on any of this.



___

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: App Transport Security exceptions App Store signed app

[Ben Kennedy]

On 26 Jan 2016, at 9:55 pm, Trygve Inda  wrote:

> connection failed: (null) The resource could not be loaded because the App
> Transport Security policy requires the use of a secure connection.
> http://www.earthdeskcloudhost02.com/mosaic/free/clouds-2048.jpg

I'm no App Transport Security expert, but taking what you described at face 
value, that seems to make sense. You tried to load a resource from 
www.earthdeskcloudhost02.com, which is a subdomain of earthdeskcloudhost02.com, 
yet the Info.plist entries you described seemed to lack a NSIncludesSubdomains 
key for the latter domain.

I imagine that if you either drop the 'www.' or add the NSIncludesSubdomains it 
might work...?

-ben


___

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: LGPL code in the Mac App Store?

[Jake Petroules]

> On Jan 26, 2016, at 1:06 PM, Pascal J. Bourguignon  
> wrote:
> You cannot use dynamically loaded libraries on iOS.

Wrong, you can use dynamically loaded libraries in iOS 8 and above.

> Also, I think you won't be able to load a library yourself (as data) and jump 
> into it (as code), since I'd expect the iOS kernel and MMU to restrict 
> execution of data in iOS.

This was a matter of App Store policy only. You were always able to load shared 
libraries, although unsigned code cannot be loaded.

> No, the only way to use a library in iOS, is to link it statically.

See above.

> 
> -- 
> __Pascal J. Bourguignon__
> http://www.informatimago.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/jake.petroules%40petroules.com
> 
> This email sent to jake.petrou...@petroules.com

-- 
Jake Petroules - jake.petroules at petroules.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: App Transport Security exceptions App Store signed app

[Jens Alfke]

> On Jan 26, 2016, at 9:55 PM, Trygve Inda  wrote:
> 
> NSTemporaryExceptionAllowsInsecureHTTPLoads

The “Temporary” in those names was only needed for the first iOS 9 beta. It 
might still be supported, but the official names do not have Temporary in them. 
See the official docs at

https://developer.apple.com/library/prerelease/ios/documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html#//apple_ref/doc/uid/TP40009251-SW33

> Calls to http on my domain (xericdesign.com ) work. 
> Calls via http to my
> other domain (earthdeskcloudhost02.com ) do 
> not work.

I believe you’re using the wrong key. If you need non-SSL connections to work, 
the key you want is NSAllowsArbitraryLoads. The key you’re using is for 
situations where you make an SSL connection but the SSL server doesn’t meet 
ATS’s security requirements — e.g. its certificate is self-signed or expired.

Another useful article to read is

http://lithium3141.com/blog/2015/08/21/shipping-an-app-with-app-transport-security/

Also, have you looked into setting up HTTPS on those servers instead of working 
around its absence? Part of the reason Apple added ATS was to nudge app 
developers to make their network connections more secure, which will benefit 
users.

—Jens
___

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

App Transport Security exceptions App Store signed app

[Trygve Inda]

I am still getting an error despite my Info.plist beign configured correctly
(as far as I can tell).

Calls to http on my domain (xericdesign.com) work. Calls via http to my
other domain (earthdeskcloudhost02.com) do not work.

connection failed: (null) The resource could not be loaded because the App
Transport Security policy requires the use of a secure connection.
http://www.earthdeskcloudhost02.com/mosaic/free/clouds-2048.jpg

My Info.plist has:

NSAppTransportSecurity
- NSExceptionDomains

-- earthdeskcloudhost02.com
--- NSTemporaryExceptionAllowsInsecureHTTPLoads (YES)

-- xericdesign.com
--- NSTemporaryExceptionAllowsInsecureHTTPLoads (YES)
--- NSIncludesSubdomains (YES)

I have also tried the key: NSExceptionAllowsInsecureHTTPLoads

Since some docs say this key should be used.


Any ideas?

Trygve



___

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: LGPL code in the Mac App Store?

[Pascal J. Bourguignon]

On 26/01/16 22:17, Jens Alfke wrote:


On Jan 26, 2016, at 1:06 PM, Pascal J. Bourguignon 
> wrote:


I'm not sure it's allowed, you would have to check the App Store EULA 
and license, and your Apple Developer Program agreement, etc.


Why would Apple care one way or another about the license of the 
source code used to build your app? The license is between you (the 
app developer) and the owner of the source code. Apple merely 
distributes your binary.
Sorry, I thought the context was iOS (and therefore distribution thru 
the AppStore).


In case of MacOSX, of course, you can distribute thru any other channel, 
and indeed, use dynamically loaded libraries bundled in the application 
package.


--
__Pascal J. Bourguignon__
http://www.informatimago.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: Dodgy Code - Low Level Memory Management Question!

[Dave]

Hi Again
\
> On 25 Jan 2016, at 19:22, Quincey Morris 
>  wrote:
> 
> On Jan 25, 2016, at 10:48 , Dave  > wrote:
>> 
>> myNewObject = [super initWithSomething: something];
> 
> This is a dangerous thing to do. At this point ‘self’ might not be a properly 
> initialized object, if the ‘super’ call returns a different object from 
> ‘self’. You’re better off assigning the result to ‘self’ as usual.

Ok, great.

>> [LTWCacheManager addToCache: myID];
> 
> Huh? You’re not passing the object being cached, so how can you get it out of 
> the cache again later? If the ID is a string that contains the object 
> pointer, then at the very least the object isn’t being retained by the cache, 
> is it?

Sorry typeo in the pseudo code, it passes the object and it is retained….

>>  self = myNewObject;
> […]
>>  return self;
> 
>> self = myCachedObject;
>> return self;
> 
> These aren’t really meaningful. Assigning to ‘self’ doesn’t really achieve 
> anything, other than the possibility of getting it wrong. If you want to 
> return an object other than self, then just write ‘return myNewObject’ or 
> ‘return myCachedObject’.
> 

Ok, point noted. My question is, after then it is autoreleased, does this cause 
a problem, what happens after the first time? If its not in use by anything 
else, then the cached object will have a retainCount of 1, so it will need just 
one release (when the cache is cleared) which will cause it to dealloc, is this 
correct? IOW, the autorelease will basically just be a NOP?

Thanks for taking your time on this, just want to make sure I understand MMM 
correctly in this case as its been a while since I have had to do anything this 
horrid! 

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: Obj-C - your thoughts on hiding data members?

[Alex Zavatone]

On Jan 26, 2016, at 5:47 AM, Dave wrote:

> Hi,
> 
>> Yeah, the ivar for an @property called myThing is _myThing and we can know 
>> that by looking at it with our eyeballs.  How do we extend that type of 
>> visual exposure of information of the “thing” being inspected in a similar 
>> manner?
>> 
>> Do we have any standards for this?  
>> 
>> If not, should we create some?
> 
> There are no standards AFAIK and you will never get everybody to agree a 
> “standard” naming convention, I have my own scheme though:
> 
> Entry Parameters to Methods are prefixed the “the”, local Variables are 
> prefixed “my”, properties are prefixed “p”, Ivar’s “m”, constants “k” and I 
> always try to give some clue as to the type of the data in the variables, 
> e.g. myNameDict, myAddresssAddress, etc.
> 
> Cheers
> Dave

I'm a big fan of using my in front of local variables as well.

Since we're all computery and programmy and stuff, couldn't we put together a 
little matrix of the type of variable and come up with several loose standards?

The reason I ask this (am pressing on this) is that a large amount of what 
communicates to the programmer is in the naming and casing convention of the 
words used. 

All too recently, I have had to deal with code where the programmers used 
completely arbitrary conventions to casing absolutely everything.  Methods, 
classes, properties, ivars, methods, functions, all of them were arbitrarily 
named and cased, making converting the code into something manageable a multi 
month lesson in pain.

One very nice thing about Objective-C/Cocoa is that we have naming conventions 
that communicate to the user what we are looking at.  

As we now have the opportunity to take advantage of these techniques that Greg, 
Graham, Quincy, Snej, et al. are bringing to our attention, it's the perfect 
time to at least try out some conventions that clearly tell the programmer what 
the thing is simply by looking at it.

I think it's a prime opportunity to at least start this.

Just my 2 cents on the matter adjusted for inflation.

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/zav%40mac.com
> 
> This email sent to z...@mac.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

Array of Dictionaries as .userInfo

[Eric E. Dolecki]

I have a control which takes an array of dictionaries to construct it's UI
(as a distinct method).

Now I'd like to add a notification to supply the data as well. I'd like to
pass the data as userInfo.

When constructing the observer method, how do I constuct?

func weHaveData(notification:NSNoticiation){
   let dict = notification.userInfo as Array>
   control.loadData(dict)
}

*Can't convert value of type [NSObject:AnyObject]? to
Array> in coercion*

I've tried without the cast. Is there an easy work around?
___

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: Array of Dictionaries as .userInfo

[Roland King]

> On 26 Jan 2016, at 23:12, Eric E. Dolecki  wrote:
> 
> I have a control which takes an array of dictionaries to construct it's UI
> (as a distinct method).
> 
> Now I'd like to add a notification to supply the data as well. I'd like to
> pass the data as userInfo.
> 
> When constructing the observer method, how do I constuct?
> 
> func weHaveData(notification:NSNoticiation){
>   let dict = notification.userInfo as Array>
>   control.loadData(dict)
> }
> 
> *Can't convert value of type [NSObject:AnyObject]? to
> Array> in coercion*
> 
> I've tried without the cast. Is there an easy work around?
> ___


the userInfo of an NSNotification is an NSDictionary, so of course you can’t 
cast it to an Array. There’s no workaround, they aren’t the same thing at all. 

If you want to pass an Array of Dictionaries in the userInfo, you need to put 
it in the userInfo *dictionary* under a key, then retrieve it, then cast 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: Array of Dictionaries as .userInfo

[Eric E. Dolecki]

That makes perfect sense - thanks. I forgot about the userInfo type!

On Tue, Jan 26, 2016 at 10:31 AM Roland King  wrote:

>
> > On 26 Jan 2016, at 23:12, Eric E. Dolecki  wrote:
> >
> > I have a control which takes an array of dictionaries to construct it's
> UI
> > (as a distinct method).
> >
> > Now I'd like to add a notification to supply the data as well. I'd like
> to
> > pass the data as userInfo.
> >
> > When constructing the observer method, how do I constuct?
> >
> > func weHaveData(notification:NSNoticiation){
> >   let dict = notification.userInfo as Array>
> >   control.loadData(dict)
> > }
> >
> > *Can't convert value of type [NSObject:AnyObject]? to
> > Array> in coercion*
> >
> > I've tried without the cast. Is there an easy work around?
> > ___
>
>
> the userInfo of an NSNotification is an NSDictionary, so of course you
> can’t cast it to an Array. There’s no workaround, they aren’t the same
> thing at all.
>
> If you want to pass an Array of Dictionaries in the userInfo, you need to
> put it in the userInfo *dictionary* under a key, then retrieve it, then
> cast 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: Array of Dictionaries as .userInfo

[Clark Cox]

The notification’s userInfo *must* be a dictionary, trying to force it to be 
something else is just asking for trouble. You could create a dictionary that 
contains your array of dictionaries if you want to be able to pass it through 
an NSNotification.

That said, IMHO, this use of notifications has a little bit of code smell. 
Ideally, I would expect a notification to tell the control to 
reload/refresh/relayout itself by asking an appropriate delegate or controller 
for the data it needs (rather than getting the data out of the notification 
itself). It helps to have a strictly defined path that your data can follow; if 
it’s in an NSNotification, it could potentially have come from *anywhere*

-- 
Clark Smith Cox III
clarkc...@gmail.com

> On Jan 26, 2016, at 07:12, Eric E. Dolecki  wrote:
> 
> I have a control which takes an array of dictionaries to construct it's UI
> (as a distinct method).
> 
> Now I'd like to add a notification to supply the data as well. I'd like to
> pass the data as userInfo.
> 
> When constructing the observer method, how do I constuct?
> 
> func weHaveData(notification:NSNoticiation){
>   let dict = notification.userInfo as Array>
>   control.loadData(dict)
> }
> 
> *Can't convert value of type [NSObject:AnyObject]? to
> Array> in coercion*
> 
> I've tried without the cast. Is there an easy work around?
> ___
> 
> 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/clarkcox3%40gmail.com
> 
> This email sent to clarkc...@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: Array of Dictionaries as .userInfo

[Eric E. Dolecki]

I agree with you there in terms of passing the data in the notification.
I've requested that the developer in charge of some of the appDelegate
backend allow for the explicit data request. It's an extra call or two, but
keeps the pipeline known and clean.

On Tue, Jan 26, 2016 at 10:37 AM Clark Cox  wrote:

> The notification’s userInfo *must* be a dictionary, trying to force it to
> be something else is just asking for trouble. You could create a dictionary
> that contains your array of dictionaries if you want to be able to pass it
> through an NSNotification.
>
> That said, IMHO, this use of notifications has a little bit of code smell.
> Ideally, I would expect a notification to tell the control to
> reload/refresh/relayout itself by asking an appropriate delegate or
> controller for the data it needs (rather than getting the data out of the
> notification itself). It helps to have a strictly defined path that your
> data can follow; if it’s in an NSNotification, it could potentially have
> come from *anywhere*
>
> --
> Clark Smith Cox III
> clarkc...@gmail.com
>
> > On Jan 26, 2016, at 07:12, Eric E. Dolecki  wrote:
> >
> > I have a control which takes an array of dictionaries to construct it's
> UI
> > (as a distinct method).
> >
> > Now I'd like to add a notification to supply the data as well. I'd like
> to
> > pass the data as userInfo.
> >
> > When constructing the observer method, how do I constuct?
> >
> > func weHaveData(notification:NSNoticiation){
> >   let dict = notification.userInfo as Array>
> >   control.loadData(dict)
> > }
> >
> > *Can't convert value of type [NSObject:AnyObject]? to
> > Array> in coercion*
> >
> > I've tried without the cast. Is there an easy work around?
> > ___
> >
> > 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/clarkcox3%40gmail.com
> >
> > This email sent to clarkc...@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: Array of Dictionaries as .userInfo

[Alex Zavatone]

Shouldn't the notification be as dumb as possible and let the notification 
receiver/processor handle any decisions on what to process or read from?


On Jan 26, 2016, at 10:37 AM, Clark Cox wrote:

> The notification’s userInfo *must* be a dictionary, trying to force it to be 
> something else is just asking for trouble. You could create a dictionary that 
> contains your array of dictionaries if you want to be able to pass it through 
> an NSNotification.
> 
> That said, IMHO, this use of notifications has a little bit of code smell. 
> Ideally, I would expect a notification to tell the control to 
> reload/refresh/relayout itself by asking an appropriate delegate or 
> controller for the data it needs (rather than getting the data out of the 
> notification itself). It helps to have a strictly defined path that your data 
> can follow; if it’s in an NSNotification, it could potentially have come from 
> *anywhere*
> 
> -- 
> Clark Smith Cox III
> clarkc...@gmail.com
> 
>> On Jan 26, 2016, at 07:12, Eric E. Dolecki  wrote:
>> 
>> I have a control which takes an array of dictionaries to construct it's UI
>> (as a distinct method).
>> 
>> Now I'd like to add a notification to supply the data as well. I'd like to
>> pass the data as userInfo.
>> 
>> When constructing the observer method, how do I constuct?
>> 
>> func weHaveData(notification:NSNoticiation){
>>  let dict = notification.userInfo as Array>
>>  control.loadData(dict)
>> }
>> 
>> *Can't convert value of type [NSObject:AnyObject]? to
>> Array> in coercion*
>> 
>> I've tried without the cast. Is there an easy work around?
>> ___
>> 
>> 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/clarkcox3%40gmail.com
>> 
>> This email sent to clarkc...@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/zav%40mac.com
> 
> This email sent to z...@mac.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: Array of Dictionaries as .userInfo

[Eric E. Dolecki]

Yes probably in most cases. One can send an object and a NSDictionary
(userInfo) though too. So there are some implied options. I was about to
over-use my userInfo ;)

On Tue, Jan 26, 2016 at 11:46 AM Alex Zavatone  wrote:

> Shouldn't the notification be as dumb as possible and let the notification
> receiver/processor handle any decisions on what to process or read from?
>
>
> On Jan 26, 2016, at 10:37 AM, Clark Cox wrote:
>
> > The notification’s userInfo *must* be a dictionary, trying to force it
> to be something else is just asking for trouble. You could create a
> dictionary that contains your array of dictionaries if you want to be able
> to pass it through an NSNotification.
> >
> > That said, IMHO, this use of notifications has a little bit of code
> smell. Ideally, I would expect a notification to tell the control to
> reload/refresh/relayout itself by asking an appropriate delegate or
> controller for the data it needs (rather than getting the data out of the
> notification itself). It helps to have a strictly defined path that your
> data can follow; if it’s in an NSNotification, it could potentially have
> come from *anywhere*
> >
> > --
> > Clark Smith Cox III
> > clarkc...@gmail.com
> >
> >> On Jan 26, 2016, at 07:12, Eric E. Dolecki  wrote:
> >>
> >> I have a control which takes an array of dictionaries to construct it's
> UI
> >> (as a distinct method).
> >>
> >> Now I'd like to add a notification to supply the data as well. I'd like
> to
> >> pass the data as userInfo.
> >>
> >> When constructing the observer method, how do I constuct?
> >>
> >> func weHaveData(notification:NSNoticiation){
> >>  let dict = notification.userInfo as Array>
> >>  control.loadData(dict)
> >> }
> >>
> >> *Can't convert value of type [NSObject:AnyObject]? to
> >> Array> in coercion*
> >>
> >> I've tried without the cast. Is there an easy work around?
> >> ___
> >>
> >> 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/clarkcox3%40gmail.com
> >>
> >> This email sent to clarkc...@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/zav%40mac.com
> >
> > This email sent to z...@mac.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: Dodgy Code - Low Level Memory Management Question!

[Quincey Morris]

On Jan 26, 2016, at 06:00 , Dave  wrote:
> 
> IOW, the autorelease will basically just be a NOP?

An autorelease is never a NOP. It’s a “release later”, not a “release if 
necessary”.

Rather than trying to count or balance retains globally, I think it’s easier to 
think in terms of ownership (+1 references) and non-ownership (+0 references). 
An init method must provide an owned (+1) reference to the object it returns. 
The cache, of course, must have a +1 reference to the cached object, too. So, 
rewriting your code to account for things already discussed, and simplifying 
your cache into a simple static variable, you get something like this:

> static id cachedObject;
> 
> -(instancetype) initWithID:(NSString*) something
> {
>   self = [super initWithSomething: something] // This ‘self’ is +1 
> according to init semantics
>   if (self == nil)
>   return nil;
> 
>   id myCachedObject = cachedObject; // A +0 local reference
> 
>   if (myCachedObject == nil)
>   {
>   cachedObject = [self retain]; // The cache needs its own +1 
> reference to keep the object alive until the cache is cleared
>   return self; // ‘self’ is still +1 according to init semantics: 
> this is unrelated to the retain in the previous line
>   }
> 
>   else
>   {
>   [self autorelease]; // The “temporary” self is being discarded, 
> so it needs to be released, eventually
>   return [myCachedObject retain]; // Returning a +1 reference 
> according to init semantics
>   }
> }

(It been years since I’ve actually *written* any MRR code, so I apologize in 
advance for any stupid errors.)

If you do want to count retains, you’ll see that the object returned from this 
method, via either path, has a +2 retain count. That’s because +1 of that 
“belongs” to the caller, and you have no control over whether or when the 
caller does a corresponding release. The other +1 belongs to you, and is what 
keeps the cached object alive.

___

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: Obj-C - your thoughts on hiding data members?

[Jens Alfke]

> On Jan 26, 2016, at 6:32 AM, Alex Zavatone  wrote:
> 
> Since we're all computery and programmy and stuff, couldn't we put together a 
> little matrix of the type of variable and come up with several loose 
> standards?
> The reason I ask this (am pressing on this) is that a large amount of what 
> communicates to the programmer is in the naming and casing convention of the 
> words used. 

There is a very longstanding convention in Objective-C — going back to the NeXT 
days — to prefix instance variables with underscores. You’ll see that in many 
of Apple’s headers (the ones that still list ivars in the @interface) and in 
some Apple sample code.

(There was a time when Apple was warning 3rd party developers not to do this 
because of name collisions with inherited ivar names, but that’s a non-issue 
with the modern Obj-C runtime.)

I would strongly urge that anyone prefixing ivars use this convention, for 
consistency. Additionally, I find that the underscore adds less visual clutter 
than a letter like “m”. Your brain doesn’t see it as a letter, so it doesn’t 
get in the way of reading the variable name.

Beyond that it’s a matter of preference. I prefix static variables with “s”, a 
convention that dates back to MacApp (~1988!). I don’t see any reason to prefix 
function parameters or locals in general, since they’re the default, although I 
sometimes use an “out” prefix for a by-reference parameter like an NSError**.

—Jens
___

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: Dodgy Code - Low Level Memory Management Question!

[Jens Alfke]

> On Jan 26, 2016, at 6:00 AM, Dave  wrote:
> 
> Sorry typeo in the pseudo code, it passes the object and it is retained….

Dave, if you want us to debug your code for you, then SHOW US THE ACTUAL #*$&% 
CODE! Don’t show us something else that _looks_ like real Obj-C but that you 
just typed into your mail app. It’s a waste of our time.

Select the code in Xcode, press Cmd-C, then to go the mail window and press 
Cmd.V.

—Jens
___

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

LGPL code in the Mac App Store?

[thatsanicehatyouhave]

Hi,

I’m working on a program that I will be submitting to the Mac App Store that 
uses LGPL code. I have recently learned that the license requires the 
capability for the end user to create their own version of the LGPL library to 
link against the application (I have been compiling the source directly into 
the library). This means at run time I need to either load the library from 
what I provide in the application bundle (default, obviously), or, if present, 
load one that the user provides. I can imagine wrapping the library in a 
framework could be an answer. It would be up to the user to build a framework 
in the correct format (I could easily make an Xcode project to do so available 
on GitHub).

Is this possible/allowed for an App Store application? If so, is this the best 
approach? How would I load the library at runtime given that I normally link 
against it when I build the application?

Cheers,
Demitri
___

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: LGPL code in the Mac App Store?

[Jens Alfke]

> On Jan 26, 2016, at 11:23 AM, thatsanicehatyouh...@me.com wrote:
> 
> I’m working on a program that I will be submitting to the Mac App Store that 
> uses LGPL code. I have recently learned that the license requires the 
> capability for the end user to create their own version of the LGPL library 
> to link against the application (I have been compiling the source directly 
> into the library). This means at run time I need to either load the library 
> from what I provide in the application bundle (default, obviously), or, if 
> present, load one that the user provides. I can imagine wrapping the library 
> in a framework could be an answer.

Yes, the usual solution is to build the LGPL code as a shared library (either a 
framework or just a dylib) and embed it in the app.

> It would be up to the user to build a framework in the correct format (I 
> could easily make an Xcode project to do so available on GitHub).

I don’t think you’re required to do this. As long as the entry points (exported 
symbols) of the dylib correspond to the public API of the library, building an 
equivalent library from the LGPL source is straightforward and can be "left as 
an exercise for the reader” as they say in textbooks.

> Is this possible/allowed for an App Store application?

The only issues I can think of are with code signing. Changing the framework 
inside the app bundle will invalidate the app’s signature. But I’m pretty sure 
you can just strip all signatures from the app using the codesign tool, and 
then run it.

> How would I load the library at runtime given that I normally link against it 
> when I build the application?

You’re still linking against the library at build time. But it’s a dynamic 
library, so it gets loaded at runtime. The build steps are the same as those 
when you integrate a 3rd party framework (like, say, Sparkle) into your app. 
Add the framework to your app’s link build phase, and add a copy-files build 
phase to copy the framework into the app’s Frameworks subdirectory.

—Jens


___

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: Obj-C - your thoughts on hiding data members?

[Alex Zavatone]

On Jan 26, 2016, at 2:10 PM, Jens Alfke wrote:

> 
>> On Jan 26, 2016, at 6:32 AM, Alex Zavatone  wrote:
>> 
>> Since we're all computery and programmy and stuff, couldn't we put together 
>> a little matrix of the type of variable and come up with several loose 
>> standards?
>> The reason I ask this (am pressing on this) is that a large amount of what 
>> communicates to the programmer is in the naming and casing convention of the 
>> words used. 
> 
> There is a very longstanding convention in Objective-C — going back to the 
> NeXT days — to prefix instance variables with underscores. You’ll see that in 
> many of Apple’s headers (the ones that still list ivars in the @interface) 
> and in some Apple sample code.
> 

That's the exact first convention that I am aware of which I am referring to.  



> (There was a time when Apple was warning 3rd party developers not to do this 
> because of name collisions with inherited ivar names, but that’s a non-issue 
> with the modern Obj-C runtime.)
> 
> I would strongly urge that anyone prefixing ivars use this convention, for 
> consistency. Additionally, I find that the underscore adds less visual 
> clutter than a letter like “m”. Your brain doesn’t see it as a letter, so it 
> doesn’t get in the way of reading the variable name.

Additionally, when creating an @property, the compiler does this automatically, 
when it create the iVar, correct?

> Beyond that it’s a matter of preference. I prefix static variables with “s”, 
> a convention that dates back to MacApp (~1988!). I don’t see any reason to 
> prefix function parameters or locals in general, since they’re the default, 
> although I sometimes use an “out” prefix for a by-reference parameter like an 
> NSError**.
> 
> —Jens

So, as now as options, we also have:

s to prefix for a static
k for a constant or #define 
my to prefix locals 

With @public and @protected and @private sadly starting with the letter p this 
leaves us without obvious options to connote the style of the variable.

I'm going to step out on a limb and since Xcode has supported editing in UTF-8 
and 16, that we look into those character sets and pick some symbols that 
accurately represent public, protected and private.

These symbols should mean what they represent, and be visually distinct.

They could be put in a little template for copying and pasting when we use them.

The goal here is that when we eyeball our code, we want as much information to 
be presented to us as possible about the nature of each element that we are 
looking at, it's got to be easy to use and visually make sense.

Any ideas for valid characters to prefix @public and @protected and @private 
with?

Here are a few I just pulled up that should display well enough in Menlo 
Regular, but might not make it through email.

  public (megaphone - search the character panel for public)

⊖ ⊗ ⊘ ⊙ ⊞ ⨳ ☒ ⨷ ✖︎ private

℗  ✔︎  protected (second item is the lock character, +1F512)




Reference
http://www.g8production.com/post/69593399838/private-protected-and-public-vars-in-objective-c

UTF-8 Character set
http://www.fileformat.info/info/charset/UTF-8/list.htm
___

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: LGPL code in the Mac App Store?

[Pascal J. Bourguignon]

On 26/01/16 20:23, thatsanicehatyouh...@me.com wrote:

Hi,

I’m working on a program that I will be submitting to the Mac App Store that 
uses LGPL code. I have recently learned that the license requires the 
capability for the end user to create their own version of the LGPL library to 
link against the application (I have been compiling the source directly into 
the library). This means at run time I need to either load the library from 
what I provide in the application bundle (default, obviously), or, if present, 
load one that the user provides. I can imagine wrapping the library in a 
framework could be an answer. It would be up to the user to build a framework 
in the correct format (I could easily make an Xcode project to do so available 
on GitHub).

Is this possible/allowed for an App Store application?
I'm not sure it's allowed, you would have to check the App Store EULA 
and license, and your Apple Developer Program agreement, etc.



If so, is this the best approach? How would I load the library at runtime given 
that I normally link against it when I build the application?

You cannot use dynamically loaded libraries on iOS.

Also, I think you won't be able to load a library yourself (as data) and 
jump into it (as code), since I'd expect the iOS kernel and MMU to 
restrict execution of data in iOS.


No, the only way to use a library in iOS, is to link it statically.

However, you can still respect the terms of the LGPL with statically 
linked programs. All you have to do, is to provide the binaries of your 
program as object files (or a library of them), with a Makefile or a 
script to link your object files with the LGPL static libraries into a 
new final executable.


Now, given the complexity of the the Xcode/iOS build process, it may not 
be simple to collect the required object files, and to write a Makefile 
or script to do this final link, but you copy-and-paste the output of 
the compilation/link in Xcode, and extract the commands used, that would 
be a good start to write your linking script. (You would also have to 
provide the resource bundles, if your application has such).



Now of course, the question is what will a user (even a programmer!) do 
with a set of object files and a linking script?  I mean, he could 
always link a new executable with his modified LGPL libraries, but he 
would still have to be a registered developer to be able to sign the 
application and install it on his iDevice.  He couldn't push it on the 
AppStore, since it would be basically a duplicate of your application in 
the AppStore, and Apple forbids duplicates (theorically; there are still 
tons of implementations of the same game or utility in general).  As an 
registered Apple Developer, he could use Xcode to install his copy of 
the program only on a limited number of test iDevices, and he could 
certainly not _distribute_ it in any term.



This, AFAIK.  A closer reading of Apple licenses and legal agreements 
would have to be performed to refine this question.


--
__Pascal J. Bourguignon__
http://www.informatimago.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: Obj-C - your thoughts on hiding data members?

[Jens Alfke]

> On Jan 26, 2016, at 12:43 PM, Alex Zavatone  wrote:
> 
> Additionally, when creating an @property, the compiler does this 
> automatically, when it create the iVar, correct?

Only if you have auto-synthesis turned on. (Which it is, by default, but I 
always turn it off because I think it’s a very bad idea: it means a typo in an 
explicit accessor method’s name isn’t a build error, but causes weird runtime 
bugs.)

You have to use `@synthesize foo=_foo`, which is a little annoying. If you just 
say `@synthesize foo`, for some reason it names the ivar `foo` :-p

> With @public and @protected and @private sadly starting with the letter p 
> this leaves us without obvious options to connote the style of the variable.


I don’t see a need to distinguish ivar names by access level. For one thing, it 
should be rare to have protected ivars, and extremely rare to have public ones. 
And besides, it doesn’t seem like such an important distinction that it has to 
be in your face whenever you use the variable. IMHO, it’s _scope_ that’s the 
important thing to make clear in the name.

> I'm going to step out on a limb and since Xcode has supported editing in 
> UTF-8 and 16, that we look into those character sets and pick some symbols 
> that accurately represent public, protected and private.

Now you’re pulling our legs, right Alex?

—Jens
___

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: LGPL code in the Mac App Store?

[Jens Alfke]

> On Jan 26, 2016, at 1:06 PM, Pascal J. Bourguignon  
> wrote:
> 
> You cannot use dynamically loaded libraries on iOS.

(a) No. You can use dylibs/frameworks in iOS 8 or later.
(b) But this is irrelevant since the OP is writing a *Mac OS* application.

—Jens
___

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: LGPL code in the Mac App Store?

[Jens Alfke]

> On Jan 26, 2016, at 1:06 PM, Pascal J. Bourguignon  
> wrote:
> 
> I'm not sure it's allowed, you would have to check the App Store EULA and 
> license, and your Apple Developer Program agreement, etc.

Why would Apple care one way or another about the license of the source code 
used to build your app? The license is between you (the app developer) and the 
owner of the source code. Apple merely distributes your binary.

—Jens
___

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: LGPL code in the Mac App Store?

[Britt Durbrow]

Mac App Store, not iOS.

I would consider a: packaging a version of the library in your resources; and 
loading that if there is not one in the app’s Application Support folder; and 
b: providing the library on github. If the user wishes to modify the library 
for whatever reason, they download it; modify it; and stick it in the app’s 
container’s Application Support folder in the appropriate location; and the app 
loads that version instead of the version packaged from the app store.

Disclaimer: I haven’t actually tried it; so YMMV...


> On Jan 26, 2016, at 1:06 PM, Pascal J. Bourguignon  
> wrote:
> 
> 
> 
> On 26/01/16 20:23, thatsanicehatyouh...@me.com wrote:
>> Hi,
>> 
>> I’m working on a program that I will be submitting to the Mac App Store that 
>> uses LGPL code. I have recently learned that the license requires the 
>> capability for the end user to create their own version of the LGPL library 
>> to link against the application (I have been compiling the source directly 
>> into the library). This means at run time I need to either load the library 
>> from what I provide in the application bundle (default, obviously), or, if 
>> present, load one that the user provides. I can imagine wrapping the library 
>> in a framework could be an answer. It would be up to the user to build a 
>> framework in the correct format (I could easily make an Xcode project to do 
>> so available on GitHub).
>> 
>> Is this possible/allowed for an App Store application?
> I'm not sure it's allowed, you would have to check the App Store EULA and 
> license, and your Apple Developer Program agreement, etc.
> 
>> If so, is this the best approach? How would I load the library at runtime 
>> given that I normally link against it when I build the application?
> You cannot use dynamically loaded libraries on iOS.
> 
> Also, I think you won't be able to load a library yourself (as data) and jump 
> into it (as code), since I'd expect the iOS kernel and MMU to restrict 
> execution of data in iOS.
> 
> No, the only way to use a library in iOS, is to link it statically.
> 
> However, you can still respect the terms of the LGPL with statically linked 
> programs. All you have to do, is to provide the binaries of your program as 
> object files (or a library of them), with a Makefile or a script to link your 
> object files with the LGPL static libraries into a new final executable.
> 
> Now, given the complexity of the the Xcode/iOS build process, it may not be 
> simple to collect the required object files, and to write a Makefile or 
> script to do this final link, but you copy-and-paste the output of the 
> compilation/link in Xcode, and extract the commands used, that would be a 
> good start to write your linking script. (You would also have to provide the 
> resource bundles, if your application has such).
> 
> 
> Now of course, the question is what will a user (even a programmer!) do with 
> a set of object files and a linking script?  I mean, he could always link a 
> new executable with his modified LGPL libraries, but he would still have to 
> be a registered developer to be able to sign the application and install it 
> on his iDevice.  He couldn't push it on the AppStore, since it would be 
> basically a duplicate of your application in the AppStore, and Apple forbids 
> duplicates (theorically; there are still tons of implementations of the same 
> game or utility in general).  As an registered Apple Developer, he could use 
> Xcode to install his copy of the program only on a limited number of test 
> iDevices, and he could certainly not _distribute_ it in any term.
> 
> 
> This, AFAIK.  A closer reading of Apple licenses and legal agreements would 
> have to be performed to refine this question.
> 
> -- 
> __Pascal J. Bourguignon__
> http://www.informatimago.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/bdurbrow%40rattlesnakehillsoftworks.com
> 
> This email sent to bdurb...@rattlesnakehillsoftworks.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: Dodgy Code - Low Level Memory Management Question!

[Dave]

> On 26 Jan 2016, at 19:15, Jens Alfke  wrote:
> 
> 
>> On Jan 26, 2016, at 6:00 AM, Dave > > wrote:
>> 
>> Sorry typeo in the pseudo code, it passes the object and it is retained….
> 
> Dave, if you want us to debug your code for you, then SHOW US THE ACTUAL 
> #*$&% CODE! Don’t show us something else that _looks_ like real Obj-C but 
> that you just typed into your mail app. It’s a waste of our time.
> 
> Select the code in Xcode, press Cmd-C, then to go the mail window and press 
> Cmd.V.

I didn’t have any real code at that point and I should have pointed that out, 
sorry. I wanted to know if that *kind* of technique would work and to 
understand the finer details of MM.

Thanks Jens and Quincey for your help.

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: LGPL code in the Mac App Store?

[Jens Alfke]

> On Jan 26, 2016, at 1:17 PM, Britt Durbrow 
>  wrote:
> 
> I would consider a: packaging a version of the library in your resources; and 
> loading that if there is not one in the app’s Application Support folder

Loading a library at runtime is somewhat awkward, because instead of being able 
to use its symbols directly you have to look them up by name (with function 
calls like dlsym) and call them through function pointers.

Also, are sandboxed apps allowed to load libraries that are outside of their 
app bundle?

IMHO putting the library inside your app bundle is enough to abide by the terms 
of the license. It’s not like a lot of actual users are going to be replacing 
the library, so there’s no point going to more work to make it easier. :)

—Jens
___

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: Obj-C - your thoughts on hiding data members?

[Alex Zavatone]

On Jan 26, 2016, at 4:08 PM, Jens Alfke wrote:

> 
>> On Jan 26, 2016, at 12:43 PM, Alex Zavatone  wrote:
>> 
>> Additionally, when creating an @property, the compiler does this 
>> automatically, when it create the iVar, correct?
> 
> Only if you have auto-synthesis turned on. (Which it is, by default, but I 
> always turn it off because I think it’s a very bad idea: it means a typo in 
> an explicit accessor method’s name isn’t a build error, but causes weird 
> runtime bugs.)
> 
> You have to use `@synthesize foo=_foo`, which is a little annoying. If you 
> just say `@synthesize foo`, for some reason it names the ivar `foo` :-p
> 
>> With @public and @protected and @private sadly starting with the letter p 
>> this leaves us without obvious options to connote the style of the variable.
> 
> 
> I don’t see a need to distinguish ivar names by access level. For one thing, 
> it should be rare to have protected ivars, and extremely rare to have public 
> ones. And besides, it doesn’t seem like such an important distinction that it 
> has to be in your face whenever you use the variable. IMHO, it’s _scope_ 
> that’s the important thing to make clear in the name.
> 
>> I'm going to step out on a limb and since Xcode has supported editing in 
>> UTF-8 and 16, that we look into those character sets and pick some symbols 
>> that accurately represent public, protected and private.
> 
> Now you’re pulling our legs, right Alex?

Yeah, I know.  It's really non conventional, buuut… I've started using some of 
the characters such as the block and non breaking line to make better 
formatting for comments and logging.  Other people who are on the Swift side of 
things are even using smilies and emoticons in their code.  Or so they claim.  
That scares me.

I think of it this way, "people have been allowed to program in Xcode in 
Japanese, Chinese and Korean for a while now.  Why not take advantage of the 
graphics in extended character sets if it doesn't break the universe in all 
sorts of ways."

I am more than happy to be proven wrong and be told that this is an utterly 
horrible idea.

Cheers,
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: LGPL code in the Mac App Store?

[Dru Satori]

Now you are getting into the nitty gritty of LGPL wording and implementation, 
at that point, it becomes more about working with the copyright holder to 
ensure you are complying with the intended spirit of the license, or engaging a 
lawyer to get him to sign off on a willingness to defend the implementation in 
courtroom.

I know a lot of people denigrate the LGPL without enough information, but to 
me, this is the real issue with the LGPL as it stands.  There remains too much 
grey area.

That said, I’m with Jens. an embedded .dylib meets the letter of the LGPL. 
IIRC, the question of static linking against a .a has also been upheld, so long 
as application provides value above the library, and the app could function 
(albeit with lesser functionality) if built without the library.


On Jan 26, 2016, at 4:33 PM, Jens Alfke 
> wrote:

y the terms of the license. It’s not like a lot of actual users are going to be 
replacing the library, so there’s no point going to more work to make

___

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

Music App-style search

[Rick Mann]

I've got an app that's structured a lot like the iOS Music App: tab bar 
controller, navigation controller, search button in nav bar. Tapping that 
brings the search UI down from the top and a keyboard up from the bottom, and 
hides the displayed content. The search results can be tapped and will push 
either detail or whatever children they have.

The problem I have is that the search UI remains on top. But in the Music app, 
it slides off to the left as the push happens, and reveals a normal 
UINavigationBar, complete with back button.

How do I get that behavior?

TIA,

-- 
Rick Mann
rm...@latencyzero.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