According to Apple documentation it is possible to pass CFDictionaryRef auxiliaryInfo when creating/beginning a transparency layer, but I cannot find any documentation or examples on what key-value pairs might be appropriate for this or how it might be used. Can anyone shed light on this or should it always be null?
The auxiliaryInfo dictionary is intended for future use to be used for layer options, however currently it is not being used in the Quartz 2D API. So for now it should always be NULL for this function.
Related
Is it possible to lookup elements by key with the object API just like it's possible in the non-object API with the "LookUpByKey" method?
I can't find any method that seems to do that.
Am I supposed to implement a binary search by myself on the vector?
Is the vector assumed to be already sorted?
I think you need to use mini-reflection or full reflection for this task.
You can read more about reflection in the docs or see an example where it's used in their testing code.
Here's a nice tutorial by jorenjoestar from someone using reflection that I found helpful myself.
Also the vectors are not assumed to be sorted but you can pre-sort a vector and set the flatbuffer contents to that sorted vector.
I'm new to Reactive Programming. I have gone through the documentation of Reactive Cocoa but couldn't realize the differences between RACAble(), RACObserve() and RACBind().
Please, help ,me in understanding the aspects by some example code snippets.
I think the RACAble() is replaced with RACObserve() with some options/arguments. If I am not correct then please correct me in this regard.
Is RACObserve() skip: similar to RACAble()?
I think one big source of confusion here is that 3 months ago the ReactiveCocoa team released v2.0, which had quite a few breaking changes. This was a great release - and has some amazing features, but it does mean that much of the information you will find on the web is now out-dated.
To your specific points:
RACAble has been replaced with RACObserve
RACBind has been replaced with RACChannelTo
RACObserve is used to create a signal from an object and a keypath, in other words it allows you to take regular properties and 'lift' them into the ReactiveCocoa world. It is a handy replacement for KVO.
RACChannelTo provides a mechanism for two-way binding. In other words you can keep two properties synchronised. A good example of this is if you want to have a property in your view controller, or some model class, bound to a property on a UIKit control.
Another macro you will probably come across is RAC, this provides one-way binding. In other words it will set the value of the given property based on the latest value from a signal.
While implementating aspect oriented programming i am getting confuse
Why Dojo having to two differentaspect library files?
When to use
dojo.aspect and dojox.lang.aspect ?
I have never heard about dojox.lang.aspect before, but according to git log the latest commit dates to 2008.
You can find an explanation why dojox.lang.aspect exists in an article by its author Eugene Lazutkin: AOP aspect of JavaScript with Dojo.
While it doesn't make much sense in some cases, we should realize that the primary role of dojo.connect() is to process DOM events.
[...]
To sum it up: events != AOP. Events cannot simulate all aspects of AOP, and AOP cannot be used in lieu of events.
So AOP in JavaScript sounds simple! Well, in reality there are several sticky places:
Implementing every single advice as a function is expensive.
Usually iterations are more efficient than recursive calls.
The size of call stack is limited.
If we have chained calls, it'll be impossible to rearrange them. So if we want to remove one advice in the middle, we are out of luck.
The “around” advice will “eat” all previously attached “before” and “after” advices changing the order of their execution. We cannot guarantee anymore that “before” advices run before all “around” advices, and so on.
Usually in order to decouple an “around” advice from the original function, the proceed() function is used. Calling it will result in calling the next-in-chain around advice method or the original method.
Our aspect is an object but in some cases we want it to be a static object, in other cases we want it to be a dynamic object created taking into account the state of the object we operate upon.
These and some other problems were resolved in dojox.lang.aspect (currently in the trunk, will be released in Dojo 1.2).
As of the latest Dojo 1.7, there is a strong tendency to differentiate between events and aspects, i.e. between dojo/on and dojo/aspect (both were implemented via dojo.connect before).
From a usage standpoint, dojo/aspect is a very simplified version of dojox/lang/aspect.
With dojo/aspect, you can create aspects corresponding to a named function (e.g. the "get" method in the "xhr" class), allowing you to create a before, after or around advice anytime xhr.get is called.
On the other hand, (TMHO) only dojox/lang/aspect provides enough features to play with aop.
It allows you to define your pointcuts with regular expressions, therefore allowing things like "execute an around advice for any functions whose name starts with get on any object"...
You can even pass-in an array of function names or regular expressions to which your aspects will be applied.
The blog post pointed by phusick gives good examples of that.
I have objects containing Quartz-2D references (describing colors, fill patterns, gradients and shadows) in Cocoa. I would like to implement the NSCoding protocol in my objects and thus need to serialize those opaque Quartz-2D structures.
Possible solutions might be:
Define a set of properties in my objects that allow to setup the data structures from scratch whenever they are needed. Those can then be serialized easily. Example: Store four floats for red, green, blue, and alpha, then use CGColorCreate. Disadvantage: Duplication of information, thus potential consistency and (so far minor) space consumption issues. I would need to write property setters manually that recreate the Quartz structure whenever a component changes. That would bloat my code substantially.
Read out the properties using Quartz functions. Example: Use CGColorGetComponents for colors. Disadvantage: It seems to work for colors. But there are no equivalent functions for other structures, so I don't see how this could work for things like gradients, shadings, shadows etc.
Read out the properties directly from the raw, opaque structures. Disadvantage: As the documentation says, the structures are supposed to be opaque. So in case something changes under the hood, my code will break. (Apple certainly would not have provided a function like CGColorGetComponents if that was supposed to be done.) Furthermore, things like the CGFunctionRef inside a CGShadingRef would really be asking for trouble.
What is the best practice for serializing Quartz structures?
The answer pretty much varies from one class to the next:
CGImage: Use CGImageDestination to make a TIFF file of it. (Equivalent to NSImage's TIFFRepresentation method.)
CGPath: Write an applier function you can use to describe the path's elements as, say, PostScript code. Write a simple interpreter to go the other direction.
CGColorSpace: You can export the ICC representation.
CGColor: As you described, but don't forget to include the color space.
CGLayer: Convoluted: Make a bitmap context, draw the layer into it, and dump an image of the context, then serialize that.
CGFont: The name should be enough for most applications. If you're being really fancy (i.e., using the variations feature), you'll want to include the font's variations dictionary. You'll have to maintain your knowledge of the font size separately, since CGFont doesn't have one and CGContext doesn't let you get the one you set in it.
CGPDFDocument: From a quick look, it looks like CGPDFObjects are all immutable, so you'd just archive the original PDF data or the URL you got it from.
CGGradient, CGPattern, CGShading, and most other classes: Yup, you're screwed. You'll just need to maintain all of the information you created the object with separately.
I'm trying to create a subclass of NSCoder, but I really don't know where to start. Apple's documentation lists which methods are required, but not much else. Maybe my Google-fu is weak, but I can't find any examples of an implementation of, e.g. encodeValueOfObjCType:at:, anywhere. (Though I assume it involves a lot of cases.)
Anyone know of a sample subclass of NSCoder I can look at, or have an idea of what a case or two of encodeValueOfObjCType:at: and decodeValueOfObjCType:at: should look like?
I just open-sourced a NSCoder subclass here
It basically is a replica of the deprecated NSArchiver.
Should get anyone who stumble into this question started.
I've also been wanting to (ab)use NSCoder to generate simpler XML than what NSKeyedArchiver produces and have implemented some classes for it. The classes are called RWPlainXMLTreeEncoder and RWPlainXMLTreeDecoder, and I've written some test code for them too.
RWPlainXMLTreeEncoder assumes that the object graph you're encoding is a tree (in case the same object is encoded twice, the decoded tree will contain two different copies instead of one shared copy; if you try to encode a cyclic graph it raises an exception). Per encoded object it generates an XML element that looks roughly like the one for this example, an encoding of an array containing the string "A string":
<ROOT type="#NSArray"><NS.object.0 type="#NSString"><NS.bytes>4120737472696E67</NS.bytes></NS.object.0></ROOT>
I wanted to further improve the above by using a different method instead of the object's own encodeWithCoder: for objects such as arrays and strings, so that the above would become:
<ROOT type="array"><item.0 type="string">A string</item.0></array></ROOT>
I'm however not sure if I will continue working on this. My overall goal was to have a fairly generic, simple way of saving an object tree to a file that leverages of the encodeWithCoder: methods I've already written, while producing a file that is not as Cocoa-dependent as when using NSKeyedArchiver. This would allow others to write applications that open those files on other platforms.
But I've now come to understand there have been similar efforts which may already be more advanced anyway, and furthermore, with XML being a document markup language it may not be the best target format and some non-markup language might be better suited.
Nevertheless, if you want to continue with this or have some other reason to look at a fairly simple NSCoder subclass, feel free to use my code. You could also take a look at MAKeyedArchiver. Oh, and my code is covered by a BSD-style license (at least the version that is in SVN revision 424 is, I might change this for future versions). Improvements and feedback are welcomed.