Re: Background fetch with localNotification

2015-09-01 Thread Quincey Morris 
On Sep 1, 2015, at 07:54 , Diederik Meijer  wrote:
> 
> What I’m not sure off is whether I need to place this call inside a 
> dispatch_async(dispatch_get_main_queue(), ^ { }) block, or not?

I don’t know the answer, but since no one else has jumped in with facts, I’ll 
venture an opinion.

It seems very likely to me that you don’t need to do it from the main thread. 
The notification itself is presented by a completely different process (I 
assume), so it’s probably hopped across a couple of dispatch queues before it 
got there. That means it’s *not* a case of your app modifying UI from a 
background thread, which is what you normally are being careful of.

In addition, the documentation states that you don’t need to retain the 
notification after return from the presentation method. That tends to reinforce 
the idea that it’s thread safe (at least it does in my mind, although it 
doesn’t prove anything).

OTOH, I don’t see a downside to dispatching via the main thread if you’re 
worried. Well, not unless you’re planning to *block* the main thread before the 
notification can go out. ;)



___

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: Mantaining legacy APIs in a framework

2015-09-01 Thread Graham Cox 

> On 2 Sep 2015, at 4:41 am, Maxthon Chan  wrote:
> 
> This seems like a bit of code smell - next time when you plan to ask the user 
> of your libraries override a method, put it into a delegate protocol. By 
> doing this the end user does not need to actually subclass you and hence 
> internal call structure no longer is part of the contract you have to keep 
> all the time and internal refactoring like this can be done easier.


I don’t think I agree. Taken to its logical conclusion, you’re saying that 
subclassing anything is a code smell.

If you end up making all of your “overridable” entry points delegate methods, 
you’re basically reimplementing the whole method table dispatch in an ad-hoc 
fashion, which really subverts the point of having on object-oriented 
framework. Delegate callbacks definitely have their place, but only where they 
really ease an implementation, not make it more trouble.

Let’s suppose Apple didn’t allow you to subclass NSView, but instead all of the 
customisation points were delegate callbacks. Creating even a trivial custom 
view would be a ton of work, and would likely underperform. That’s pretty much 
the case I have here - my GCBase class is a very fundamental class which 
implements many behaviours which are fairly non-trivial, but on its own doesn’t 
do very much. You need to override a few key methods to get it to do anything 
concrete. In simple cases this is probably only one or two methods, but in 
other much rarer cases it can end up being dozens.

One of these commonly overridden methods is to do with hit-testing against the 
mouse point. In my original design, the hit test method took only the local 
mouse point as a parameter. This was enitirely adequate for many years, but due 
to a new requirement, the state of the modifier flags and potentially other 
event state information is now needed when hit-testing, so the modern version 
of this method passes both the local mouse point and the original event as 
parameters. Trouble is, the client code that has been overriding the original 
hit test method only knows about the single parameter version, which is still 
adequate in almost all cases. So either the client code can be revved to 
include the event parameter (which it then usually ignores) or else the 
framework can arrange to fall back to the original method as necessary to keep 
all that client code working unchanged. Because the class in question is a key 
class analogous to NSView, revving client code represents a significant amount 
of work across a number of different applications, and there’s always the 
chance that you’d forget one that snuck through testing. So keeping the old APi 
alive is worth it.

If these were delegate methods it wouldn’t change the picture very much - you 
could extend the delegate protocol for the new methods easily, and arrange to 
call the old ones easily, and that probably represents the same amount of 
effort on the framework side of things. But on the client side, implementing 
these objects as delegates would always have been a lot more effort than 
subclassing. I don’t see that the effort is worthwhile just to avoid the 
possibility in the future that one of the override points turns out to need 
more parameters. 

—Graham

P.S. Anyway, thanks to Jens and Ryan, I have got around the problem as needed.
___

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: Mantaining legacy APIs in a framework

2015-09-01 Thread Maxthon Chan 
This seems like a bit of code smell - next time when you plan to ask the user 
of your libraries override a method, put it into a delegate protocol. By doing 
this the end user does not need to actually subclass you and hence internal 
call structure no longer is part of the contract you have to keep all the time 
and internal refactoring like this can be done easier.

> On Sep 1, 2015, at 07:09, Graham Cox  wrote:
> 
> Hi all, a fairly general question.
> 
> Suppose I have a framework class - e.g. GCBase - that has a public method 
> -foo:  Application code that links to the framework can freely subclass 
> GCBase and commonly overrides -foo:
> 
> Later, I decide that the method would be much better in a different form, 
> let’s call it -foo:withBar:  Code that links to the framework now should 
> override this method instead. However, the framework can’t force this change 
> on its clients, for a while it will need to support the older method -foo: if 
> it has been overridden by a subclass. So the framework needs to arrange that 
> if -foo:withBar: wasn’t overridden, but -foo: was, it should invoke the older 
> override for backward compatibility until the client code is revised.
> 
> Apple’s frameworks do this quite often, but I’m not sure how to achieve this 
> in my own. Something simple like -respondsToSelector: isn’t any good, because 
> of course it always does respond to the selector in the base class, and the 
> framework has no knowledge of subclasses beyond its own borders. Seems like 
> I’d need to drop down into the runtime functions but it’s still not really 
> obvious what would work. How do Apple do this?
> 
> —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/max%40maxchan.info
> 
> This email sent to m...@maxchan.info



smime.p7s
Description: S/MIME cryptographic signature
___

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: How to terminate an NSTask whenever my app terminates?

2015-09-01 Thread Jens Alfke 

> On Aug 31, 2015, at 11:44 PM, Bavarious  wrote:
> 
> There was a 2010 cocoa-dev thread about this:
> http://www.lists.apple.com/archives/cocoa-dev/2010/Aug/msg00512.html 
> 

Yes, this seems to be what I’m looking for — setting a process group ID — 
except that when I try it, it doesn’t work. But this is getting off-topic for 
cocoa-dev so I’ll probably ask further on darwin-userlevel.

—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

Background fetch with localNotification

2015-09-01 Thread Diederik Meijer 
Hi list,

I have added backgroundFetch to my app.

If new data is available, I have the app store it to disk and then inform the 
user with a localNotification by calling:

[[UIApplication sharedApplication] 
presentLocalNotificationNow:notification]

What I’m not sure off is whether I need to place this call inside a 
dispatch_async(dispatch_get_main_queue(), ^ { }) block, or not?

This being in the background, it seems sensible to do so? On the other hand, 
since the notification is handed by iOS, not by the app itself, this may be 
superfluous?

Additional question: since this uses presentLocalNotificationNow, is there 
still any need to call cancelAllLocalNotifications in order to ensure the 
notification is only fired once?


Thank you,




Diederik



___

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: How to terminate an NSTask whenever my app terminates?

2015-09-01 Thread Scott Ribe 
On Aug 31, 2015, at 10:55 PM, Ken Thomases  wrote:
> 
> Try the following program.  The parent will print the child's PID and exit 
> (by falling out of main()).  Then do a "ps xww -p ".  You'll 
> see the child is still running.  You can kill it when satisfied.

Yep, I got it backwards. Nothing special for the child to keep running, special 
to make it die.

Simple old trick is to periodically check ppid to see if it changed. OSX 
specific way, and not requiring any nasty polling loop, is to use kqueue and an 
EVFILT_PROC for NOTE_EXIT. I don't know if there's any Cocoa or CF equivalent.

Sorry for the confusion, this is actually something I've gotten backwards 
before. I've written the code for the child to monitor for the parent's exit, 
yet I still forget that it's necessary. Go figure...


-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
https://www.linkedin.com/in/scottribe/
(303) 722-0567 voice






___

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

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

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

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

Re: NSTableView: Rows from bottom up

2015-09-01 Thread Gary L. Wade 
One way to do this is to not use a table view but just a simple scroll/clip 
view setup and embed your content within it, pinning it only to the left, 
right, and bottom edges of the clip view and do your drawing in that view. You 
might be able to do it with a table view (and the typically associated 
scroll/clip view) if you disconnect the top connection of the table view from 
its clip view. I think they use the autolayout/alignment setting, but you might 
need full autolayout. After doing that, just draw your items in the 
reverse-order or insert from bottom of a table view to get it to grow up. 
Half-awake right now, but hope that gets you started.
--
Gary L. Wade (Sent from my iPad)
http://www.garywade.com/

> On Aug 31, 2015, at 6:51 PM, Eric Gorr  wrote:
> 
> Normally when one adds the first row to a NSTableView, it will appear at the 
> top of the view and additional rows will appear below it. Is it possible to 
> have the first row appear at the bottom of the NSTableView and for new rows 
> to appear above it?
> 
> No doubt this would require some extensive customization. I am open to 
> alternative solutions, but the one invariant will remain…first row at the 
> bottom and additional rows appearing above.
> 
> I could fake it by creating a large enough number of rows so the view is 
> filled and setting the scroll position to the bottom, but I find that to be a 
> bit inelegant…although, I would go that route before doing something 
> completely custom.
> 
> If you are wondering why someone might need such a thing, consider the case 
> of a calculator where the most common way to view the numbers (at least for 
> RPN entry) is for the most recent entry or calculation is to appear at the 
> bottom and previous entries to appear above 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: NSTableView: Rows from bottom up

2015-09-01 Thread Roland King 
Again that is not the question he was asking. He wants to know how to have a 
tableview which, if it has say one single row, shows that one single row at the 
bottom of the enclosing scrollview instead of at the top. 

Inserting the rows in order is not his problem, its’ getting the table view to 
be ‘bottom heavy’

> On 1 Sep 2015, at 18:48, dangerwillrobinsondan...@gmail.com wrote:
> 
> Data order is the simplest way to do what you want. 
> Just insert everything at the end. 
> Then also ensure no sorting. 
> 
> Sent from my iPhone
> 
>> On Sep 1, 2015, at 7:27 PM, Eric Gorr  wrote:
>> 
>> 
>>> On Aug 31, 2015, at 10:00 PM, Keary Suska  wrote:
>>> 
>>> On Aug 31, 2015, at 7:51 PM, Eric Gorr  wrote:
 
 Normally when one adds the first row to a NSTableView, it will appear at 
 the top of the view and additional rows will appear below it. Is it 
 possible to have the first row appear at the bottom of the NSTableView and 
 for new rows to appear above it?
 
 No doubt this would require some extensive customization. I am open to 
 alternative solutions, but the one invariant will remain…first row at the 
 bottom and additional rows appearing above.
 
 I could fake it by creating a large enough number of rows so the view is 
 filled and setting the scroll position to the bottom, but I find that to 
 be a bit inelegant…although, I would go that route before doing something 
 completely custom.
 
 If you are wondering why someone might need such a thing, consider the 
 case of a calculator where the most common way to view the numbers (at 
 least for RPN entry) is for the most recent entry or calculation is to 
 appear at the bottom and previous entries to appear above it.
>>> 
>>> Unless something changed before I used it last, the insert location will 
>>> depend on how you add an object, i.e. -add: vs -insert:, as well as any 
>>> sorting settings. Using -add: should always append to the end of the 
>>> collection as long as it is unsorted or does not re-sort automatically. If 
>>> you use your own method to add new objects, you can do whatever you want. 
>>> No need to customize much.
>> 
>> I am talking about the location where the rows are drawn, not how the data 
>> is ordered.
>> 
>> 
>> 
>> ___
>> 
>> 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/dangerwillrobinsondanger%40gmail.com
>> 
>> This email sent to dangerwillrobinsondan...@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/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: NSTableView: Rows from bottom up

2015-09-01 Thread dangerwillrobinsondanger 
Data order is the simplest way to do what you want. 
Just insert everything at the end. 
Then also ensure no sorting. 

Sent from my iPhone

> On Sep 1, 2015, at 7:27 PM, Eric Gorr  wrote:
> 
> 
>> On Aug 31, 2015, at 10:00 PM, Keary Suska  wrote:
>> 
>> On Aug 31, 2015, at 7:51 PM, Eric Gorr  wrote:
>>> 
>>> Normally when one adds the first row to a NSTableView, it will appear at 
>>> the top of the view and additional rows will appear below it. Is it 
>>> possible to have the first row appear at the bottom of the NSTableView and 
>>> for new rows to appear above it?
>>> 
>>> No doubt this would require some extensive customization. I am open to 
>>> alternative solutions, but the one invariant will remain…first row at the 
>>> bottom and additional rows appearing above.
>>> 
>>> I could fake it by creating a large enough number of rows so the view is 
>>> filled and setting the scroll position to the bottom, but I find that to be 
>>> a bit inelegant…although, I would go that route before doing something 
>>> completely custom.
>>> 
>>> If you are wondering why someone might need such a thing, consider the case 
>>> of a calculator where the most common way to view the numbers (at least for 
>>> RPN entry) is for the most recent entry or calculation is to appear at the 
>>> bottom and previous entries to appear above it.
>> 
>> Unless something changed before I used it last, the insert location will 
>> depend on how you add an object, i.e. -add: vs -insert:, as well as any 
>> sorting settings. Using -add: should always append to the end of the 
>> collection as long as it is unsorted or does not re-sort automatically. If 
>> you use your own method to add new objects, you can do whatever you want. No 
>> need to customize much.
> 
> I am talking about the location where the rows are drawn, not how the data is 
> ordered.
> 
> 
> 
> ___
> 
> 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/dangerwillrobinsondanger%40gmail.com
> 
> This email sent to dangerwillrobinsondan...@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: NSTableView: Rows from bottom up

2015-09-01 Thread Willeke 
You can move the table view to the bottom of the scroll view in an override of 
-[NSScrollView tile].

Déjà vu
http://cocoa-dev.apple.narkive.com/cwH1sLmk/nstableview-with-reversed-rows

- Willeke


___

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

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

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

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

Re: NSTableView: Rows from bottom up

2015-09-01 Thread Roland King 

> On 1 Sep 2015, at 18:27, Eric Gorr  wrote:
> 
>> 
>> On Aug 31, 2015, at 10:00 PM, Keary Suska  wrote:
>> 
>> On Aug 31, 2015, at 7:51 PM, Eric Gorr  wrote:
>>> 
>>> Normally when one adds the first row to a NSTableView, it will appear at 
>>> the top of the view and additional rows will appear below it. Is it 
>>> possible to have the first row appear at the bottom of the NSTableView and 
>>> for new rows to appear above it?
>>> 
>>> No doubt this would require some extensive customization. I am open to 
>>> alternative solutions, but the one invariant will remain…first row at the 
>>> bottom and additional rows appearing above.
>>> 
>>> I could fake it by creating a large enough number of rows so the view is 
>>> filled and setting the scroll position to the bottom, but I find that to be 
>>> a bit inelegant…although, I would go that route before doing something 
>>> completely custom.
>>> 
>>> If you are wondering why someone might need such a thing, consider the case 
>>> of a calculator where the most common way to view the numbers (at least for 
>>> RPN entry) is for the most recent entry or calculation is to appear at the 
>>> bottom and previous entries to appear above it.
>> 
>> Unless something changed before I used it last, the insert location will 
>> depend on how you add an object, i.e. -add: vs -insert:, as well as any 
>> sorting settings. Using -add: should always append to the end of the 
>> collection as long as it is unsorted or does not re-sort automatically. If 
>> you use your own method to add new objects, you can do whatever you want. No 
>> need to customize much.
> 
> I am talking about the location where the rows are drawn, not how the data is 
> ordered.
> 
> 

Yes that was pretty clear from your original mail. Have you tried flipping the 
tableview or the containing scrollview, or both? 
___

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

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

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

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

Re: NSTableView: Rows from bottom up

2015-09-01 Thread Eric Gorr 

> On Aug 31, 2015, at 10:00 PM, Keary Suska  wrote:
> 
> On Aug 31, 2015, at 7:51 PM, Eric Gorr  wrote:
>> 
>> Normally when one adds the first row to a NSTableView, it will appear at the 
>> top of the view and additional rows will appear below it. Is it possible to 
>> have the first row appear at the bottom of the NSTableView and for new rows 
>> to appear above it?
>> 
>> No doubt this would require some extensive customization. I am open to 
>> alternative solutions, but the one invariant will remain…first row at the 
>> bottom and additional rows appearing above.
>> 
>> I could fake it by creating a large enough number of rows so the view is 
>> filled and setting the scroll position to the bottom, but I find that to be 
>> a bit inelegant…although, I would go that route before doing something 
>> completely custom.
>> 
>> If you are wondering why someone might need such a thing, consider the case 
>> of a calculator where the most common way to view the numbers (at least for 
>> RPN entry) is for the most recent entry or calculation is to appear at the 
>> bottom and previous entries to appear above it.
> 
> Unless something changed before I used it last, the insert location will 
> depend on how you add an object, i.e. -add: vs -insert:, as well as any 
> sorting settings. Using -add: should always append to the end of the 
> collection as long as it is unsorted or does not re-sort automatically. If 
> you use your own method to add new objects, you can do whatever you want. No 
> need to customize much.

I am talking about the location where the rows are drawn, not how the data is 
ordered.



___

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