Re: addObserver:forKeyPath:options:context: memory management in GC
On Nov 18, 2009, at 2:14 AM, Sean McBride wrote: The docs for addObserver:forKeyPath:options:context: say Neither the receiver, nor anObserver, are retained.. They don't comment on the garbage collected case specifically. Does any know for sure? Does calling this method add a strong reference between the receiver and 'anObserver'? (I'm assuming not.) The Foundation Release Notes in Snow Leopard mentions Automatic Removal of Finalized Key-Value Observers When Running Garbage-Collected (new in SL), so there is some differences between how that's handled in 10.5 and in 10.6... Lukhnos ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
[ANN] ObjectiveFlickr 2.0, a Flickr API framework for Mac and iPhone
Hi all, ObjectiveFlickr is a Flickr API framework written in Objective-C, designed for both Mac and iPhone app development. Version 2.0 is a complete rewrite aiming to target different Apple platforms/SDKs and to simplify class interface design. This version also comes with an example iPhone app that demonstrates how to perform app auth and upload photos on iPhone or iPod Touch. An example Mac app and a command line example app are also supplied. The README contains instructions on how to embed the framework in your Mac or iPhone app project, how to use the framework to call Flickr API, how to design the auth process, and how to read out the API response. ObjectiveFlickr is an open source software released under the MIT License. The project is no longer hosted on Google Code. It is now hosted on github at: http://github.com/lukhnos/objectiveflickr Feedbacks and patches are welcome and appreciated. If your app uses the framework, I'd love to hear from you too! Cheers, Lukhnos D. Liu ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
[ANN] InputMethodKit backporting component for OS X 10.4 Tiger
Hi All, InputMethodKit Backporting Component, or IMK-Tiger for short, helps input method developers backport their IMK-based input method apps to OS X 10.4 Tiger. It is what we use to backport the latest OpenVanilla, a popular input method toolset in Taiwan, to 10.4. You can find the project at: http://code.google.com/p/imk-tiger/ A summary: OS X 10.5 introduced InputMethodKit (IMK), arguably the best OS-level input method framework in the industry. IMK is pure Cocoa and greatly simplifies input method development with a client-server design, powered by Objective-C's distributed object mechanism. Input method developers only need to talk to a very slim and object-oriented interface to provide input method service to OS X. This allows developers to concentrate on algorithms and user experience. On other platforms, OS X 10.4 included, input method development involves many platform-specific details and debugging headaches that can be a big distraction. There is a catch--IMK is Leopard-only. In a market like Taiwan, where Traditional Chinese is the main written language, there are still 45%-55% of users still having their Tiger machines around, and this is a market we want to continue supporting. What if we could replicate IMK on Tiger? In fact we can and have. IMK- Tiger is the result. We're now working on an IMK-based OpenVanilla, and using IMK-Tiger to build the Tiger version. Please find the details in the project home mentioned above. We have supplied a sample project, with a working, IMK-based input method (SimpleIME) and necessary project settings to produce a TSM-based counterpart. Note that we call it a backporting component, not a library, because it is not as trivial as linking to a library and voilà. But the crux is to customize IMK-Tiger's ComponentConfig.h so that the TSM component provided can establish connection to your IMK server process (and launch it if it hasn't). But once you have finished knitting everything together, you can concentrate on improving your IMK-based code. For now IMK-Tiger doesn't support -[IMKInputController recognizedEvents:] and -[IMKInputController currentKeyboardLayout], and you must implement -[IMKInputController handleEvent:client:] to handle the keyboard event. IMK-Tiger is open source released under the BSD License. Feedback and participation are welcome and appreciated. Thanks! d. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: DO Chat Example
On Jul 26, 2008, at 3:38 AM, Justin Giboney wrote: It works so far... well mostly. It isn't very consistent. I don't have a lot of experience with ports, and I was hoping that someone could look at it and see if they can find out why some messages go through while others don't. Here are the projects: www.justingiboney.com/code/DOChat.zip www.justingiboney.com/code/DOChatServer.zip Might be better if you tell more about in which way your code behaves inconsistently, it's easier to pinpoint the problem. :) Also, passing client-side objects to server might not be a good idea, especially if you are keeping them on the server side and intend to use them later (immediate callbacks are generally ok in my experiences). You might want to make your client a server itself too, and let the server talk to the client via another DO. d. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: NSURLConnection vs CF and other ideas
On Jun 29, 2008, at 9:11 AM, Alex Kac wrote: I've got a working HTTP Post with file upload using NSURLConnection, but I don't seem to see any ways to get progress on the upload beyond the connectionDidFinishLoading: delegate. Is there a better way to be able to get progress info so we can display that to the user? You might want to check out CFNetwork Programming Guide and CFHTTP request. You might want to try this too:http://objectiveflickr.googlecode.com/svn/trunk/Source/ . It's an Objective-C wrapper of the CF layer and reports the progress to its delegate, among other things. Hope this helps. d. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
