I have been looking at this issue for several weeks now. I could easily do what you suggest, or I could design the app with the “resume on re-launch” functionality and have it quit periodically based on memory criteria.
Both are last resort to me. I would rather like to figure out what in GCD / Appkit / Core Animation / cocoa bindings is preventing my app from running smoothly for years at a time. That said, since the UI is causing the mess, having it disconnected from the rest is a more elegant way to proceed than having it exit regularly. > On 17 sept. 2015, at 00:00, Kevin Meaney <k...@yvs.eu.com> wrote: > > I can't help but think that there should be a way to use xpc services as a > nice solution to this problem. > > Unfortunately xpc services are mostly designed around the idea that if the > service dies the app can restart it when it needs. Whereas you need the > service running your experiment and collecting data to stay running even if > the app displaying the results dies. When the user restarts the application > it connects to the still running service. > > Kevin > > Sent from my iPad > >> On 16 Sep 2015, at 22:28, Jean Suisse <jean.li...@gmail.com> wrote: >> >> >>> But I agree that this all (meaning the contortions to get updates onto the >>> main thread) seems like too much flash and not enough bang. The easiest way >>> would be to dispatch the original update code in blocks onto the main >>> thread asynchronously, thus serializing them and generating KVO >>> notifications safely. >> >> I thought of that at first, to solve the uncommitted CA transactions issues. >> But the syntax is ugly. And I didn’t want to post blocks from all over the >> place to the main thread (I have 100+ NSTextfields with number formatters >> updated every second… meaning as many blocks...). >> So I went for the updateUI solution, which is cleaner: It only requires me >> to duplicate instance variables. >> >> At this point, I would like to add that instance variables (and their >> UI–bound property counterpart) are mostly double with a few int, so they >> aren’t retained objects subjects to leaks. >> >>> When I think about it in those terms, it’s clear (to me, at least) that the >>> *real* problem is one of coalescing a potentially large number of updates >>> over time. In other words, this thread is really about premature >>> optimization and its ugly consequences. >> >> The issue, to me, is to get my app to run for a few days without crashing. >> The only way I have to make it work, currently, is by not updating the UI. >> This is a shame considering the time I spent arranging all those textfields >> in a nice fashion to make it easily readable despite the large number of >> displayed values (and also, IB gets really really slow with that many >> controls on a view, making the design part a real pain). >> >> _______________________________________________ >> >> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >> >> Please do not post admin requests or moderator comments to the list. >> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >> >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/cocoa-dev/ktam%40yvs.eu.com >> >> This email sent to k...@yvs.eu.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
