Re: Best Strategy to Control iTunes
Re: Best Strategy to Control iTunes
- Subject: Re: Best Strategy to Control iTunes
- From: "Luca C." <email@hidden>
- Date: Wed, 1 Apr 2009 23:04:34 +0200
2009/4/1 Ammar Ibrahim <email@hidden>
> On Wed, Apr 1, 2009 at 10:21 PM, Luca C. <email@hidden> wrote
>>
>>
>> I didn't realize the unsafety of NSAppleScript - so I have been quite
>> lucky, because my usage of applescript in non-main threads haven't caused
>> me
>> any problems.
>>
>> ScriptingBridge seems not to be thread safe, too. Adding a track to the
>> iTunes library using either applescript or SB will cause a block of the
>> app
>> if iTunes has dialog windows opened.
>>
>> The solution could be writing a command line application, wich does all
>> the work you need, either using AS or SB.
>>
>
> Right now, I'm more confused than I was, hehe. My question is: Why would I
> care about thread safety? Assuming that everytime I communicate with iTunes
> I create a thread and have the communication happen from there, even if it's
> blocking and times out, it wouldn't affect my main application. I'm I
> missing anything here? How would be the command line application any
> different from this?
>
You have to care about thread safety when using a multithreaded design.To
keep it simple:
The main thread of your application handles every event-related action and
the user interface. So if you perform a lenghty operation in it, your
application will not able to handle anything until your operation ends. To
avoid that, a solution could be creating a new worker thread, in wich
performing every action you need. Note that you can use only thread-safe
classes in your created threads.
For further information, you can read the Apple's documentation about
thread safety
<
http://developer.apple.com/documentation/Cocoa/Conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html
>
Creating an helper tool would be useful, since opening it will cause the
creation of a new process. Your application's main thread will not be
affected in any way by it.
--Luca C.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden