I'm pretty sure Verma said you can still use traditional file operations when you don't need transactional guarantees; both are supported. However, any changes that are committed by another transactional action will show up for any app using non-transactional operations on the same file. So, use transactional operations if you need a guaranteed state either when reading or writing, otherwise, using traditional file operations are your best for less overhead. Or you can just do what the pros do, and wave a magnet over the platters in the correct sequenceph wrote:You talk about the performance cost of transactions...for applications that do not need transactions (not all applications do), can an application not use the transaction features and recoup the performance hit?
Here's a pretty simple overview of Interface Builder, but u get the idea: http://developer.apple.com/documentation/DeveloperTools/Conceptual/IBTips/Articles/MakingConnections.html
I'm new to Channel 9, and after watching this video, its very impressive, but I don't see how practical it is to make all these controls/views out of random 3D objects. It's flashy, sure, but in 3 years time you'll have a thousand applications which all have their own weird UI styles. As far as the creating usable UIs without a line of code, I fail to see how this is any different from Apple's Interface Builder (neglecting the 3D whiz-bang eye candy in Sparkle). Explanations? IB is really simple: When designing, you drag controls from pallets onto your window, menus, etc. You connect (click-drag, very intuitive) controls to actions, and object members to controls (not all are necessary, depends if you need input, output or both for a control). Command-R (Alt-R on a PC keyboard) and you run the UI, all elements are clickable, and even work if you connect them to stock actions. There is a lot more to it, but its such a powerful tool for Mac programmers. Is Sparkle supposed to be IB work-alike + Flash-like abilities?