Reality Distortion Field Theory
0x00000000.net
Wednesday, May 16, 2012
Cocoa:Google working on Chrome Web browser for iOS - report

Google working on Chrome Web browser for iOS - report: "Google is said to be planning to compete with Apple's own Safari by releasing a version of its Chrome Web browser for iOS devices.

The launch of Chrome for iOS on the App Store could be as soon as this quarter, according to Macquarie Equities Research (via GigaOm)."


I've done some testing with the Cocoa version of WebKit and it's clear that Chrome will probably always be a faster browser due to the significant overhead of calling/checking delegate methods as they are strewn through the Cocoa/WebKit APIs.

Don't believe me? Start with a bare

By : Cocoa Coder Google working on Chrome Web browser for iOS - report 0 comments

Thursday, July 29, 2010
Cocoa:Cocoa-Touch

I should really post another article.

By : Cocoa Coder Cocoa-Touch 0 comments

Friday, November 17, 2006
Cocoa:Action forwarding in NSControl-derived classes

The combination of Cocoa/Interface Builder would be more rightly termed "message passing" or perhaps "dataflow diagramming" rather than merely object-oriented programming.

Despite some of my "complaint posts", I am doing several significant projects with Cocoa/IB and am exercising the combination thoroughly. Xcode is kind of a bug-ridden, only-a-mama-could-love IDE, but that's another story - a topic for a later day, perhaps.

The strength of Cocoa/IB is in rapid prototyping. During the rapid prototyping phase of a project, you want to write the least amount of code, and get as much functionality or "show me the beef" as possible.

Here I introduce the idea of extending NSControl and NSView derived classes which already conform to the "takeObjectValue" and "takeIntValue" style of messaging protocol. For clarity in this example, I have subclassed both NSSlider and NSTextField to show how adding "forwarding" behavior to your arsenal of visual programming techniques can boost productivity during rapid prototyping. And, if it suits your needs, there is no reason you can't ship code like this.

-(IBAction) forwardActionEventFrom:(id)sender
{
[[NSApplication sharedApplication] sendAction:[self action] to:[self target] from:sender];
}

-(IBAction) takeDoubleValueFrom:(id)sender
{ NSLog(@"protocol_Forwarder::takeDoubleValueFrom\n");
[super takeDoubleValueFrom:sender];
[self forwardActionEventFrom:sender];
}


Basically, forwarding controls are simple derivatives of NSControl which, upon receiving a 'take_____ValueFrom' message, both call the superclass implementation, and then perform the action on the target of [self]. This allows a message instigated by the movement of an NSSlider to ripple through the view without any controller/logic code. In the sample, the horizontal slider is the source of the first message. It's action updates the label NSTextField which in turn calls the takeIntValueFrom message of the rotary slider and so on.

One of my beefs with IB connection logic is that it presents an impoverished view of logic/flow control in an interface. Other variations to consider would be NSControls which offer more than one target/action pair.

The Cocoa source code is here.

By : Cocoa Coder Action forwarding in NSControl-derived classes 0 comments

Monday, October 16, 2006
Cocoa:Cocoa Action Categories for Interface Builder (Multiple Inheritance)

So now we've got a fairly general method of doing multiple inheritance within Cocoa applications. Now for some fun stuff. Wouldn't it be great if we could define categories of IB Actions on NSWindow as protocols, and then make it real easy to wire them up using the connection logic of Interface Builder.

As it turns out, this was way easier to do than I thought. Interface Builder is able to read Objective-C header files to find classnames, outlets and actions, but the parser is very easy to fool. All we have to do is wrap our 'action declarations' from our NSWindow category with a preprocessor exclude:

#if 0
/* never compiled, but parsed by IB just fine*/
-(IBAction) dataGoryActionOne:(id)sender;
-(IBAction) dataGoryActionTwo:(id)sender;
-(IBAction) dataGoryActionThree:(id)sender;
/* the great part about actions is their function signature will not be changing!*/
#endif


And Interface Builder will parse out the action definitions and allow you to wire connections to them. But the trick is, you don't need to implement the actions - the category methods on NSWindow will take care of that for you.

REMEMBER: if you use this technique of adding actions to NSWindow using a category/protocol, be sure that your ACTION NAMES are VERBOSE, so as to distinguish them from any additions the Cocoa team might make to NSWindow in the future. You have been warned!


Source Code: Cocoa Action Categories.

By : Cocoa Coder Cocoa Action Categories for Interface Builder (Multiple Inheritance) 0 comments

Cocoa:NSWindow(Custom Categories) with instance variables (Multiple Inheritance)

Source Code: Cocoa Bonafide Multiple Inheritance



Here is the code update to my prior post which includes the changes to have a small std::map manage the private instance data.

I've added a third 'case'. I have one IB window which is a custom class derived from NSWindow, another NSPanel derived class, and a third NSWindow instance which is acted on by controller. All three equally adept at responding to methods from NSWindow(DataGory) with private instance data.

Since you're using accessor functions for all your instance data anyway (right!) it doesn't really matter that you can't access the virtual self directly, now does it?

By : Cocoa Coder NSWindow(Custom Categories) with instance variables (Multiple Inheritance) 0 comments

Sunday, October 15, 2006
Cocoa:Categories and Informal Protocols with virtual Instance Variables

Source Code: Cocoa Categories with Instance Data


One thing that I get a kick out of is how the so-called "expert" Cocoa programmers repeat over and over, ad naseum how "Categories" are cool, as long as you understand that you can add methods to existing base classes, but not instance variables.

While this may be true in a strict "syntactical sense", it is certainly not true in the semantic sense. Let's review some principles.

Objective-C categories have as their distant cousins, C++ multiple inheritance, and COM (component object model) aggregation. So if you're familiar with either of those, you will understand them easily.

First of all, an informal protocol is essentially an implementation free declaration of methods around an Objective-C classname.

For example:


/* NSObject_InformalProtocol.h */
@interface NSObject(InformalProtocol)
-(void) informalProtocolMethod;
@end


Categories allow classes which are organized in different places of the class hierarchy to implement groups of methods, or interfaces, which allow behavior to be systematically organized irrespective of position in the inheritance taxonomy.

The problem comes when we want to implement a protocol across some disparate range of objects in the class hierarchy, but to effectively do so, each class which understands the protocol needs some consistent 'private data' or instance variables.

Syntactically, categories define only methods, and as such cannot extend the private data structures of existing classes. However, it is possible to include, among the category methods a method which promises to return instance storage for implementors of the protocol. This basically allows us to defer the allocation of instance variables to some later time, just as we are deferring the implementation of methods to some later time.

I have provided a small, simple example which demonstrates one way this can be done. In the code example, any class adhering to (ie. implementing) the NSWindow(DataGory) is required, by the protocol definition (and enforced by the default implementation) to allocate private storage for the DataGory instance variables. This allows us to organize the 'virtual self' in a typedef, and include it in the exposed definition of NSWindow(DataGory):

/* additional virtual 'instance vars' required by this category */

typedef struct tagNSWindow_DataGory
{
id goryObject;
void* goryData;
} NSWindow_DataGory;


/* ok, here are the additional methods we are adding to NSWindow */

@interface NSWindow(DataGory)

/* public */
-(void)dataGoryMethodWithNothing:(void*)withNothing;

/* protected */

-(NSWindow_DataGory*) get_DataGory_vself; /*implemented by derived classes */


@end


The code example demonstrates adding NSWindow(DataGory) to both a class derived from NSWindow, and another class derived from NSPanel (which inherits from NSWindow). The example itself does nothing. The aim is demonstrate the organizational structure of the technique.

You protest. You say new categories of NSWindow are not useful unless they can be used without requiring the existing NSWindow 'know' anything about the new category. Under these circumstances, a slightly alternate strategy can be used. At least with NSWindow objects.

Basically, to make NSWindow(DataGory) applicable to all instances of classes derived from NSWindow, we alter the method:
-(NSWindow_DataGory*) get_DataGory_vself

Currently, in the code sample, this stub simply performs an NSAssert that always fails and returns a non-crashing set of instance variables. To add NSWindow(DataGory) to all NSWindow instances, we would need some additional static storage, something like a C++ map or a CFMutableDictionary. I'm using map and thus declare:

class class_NSWindow_DataGory : public NSWindow_DataGory
{
public:
class_NSWindow_DataGory()
{
/* initialize members to default values */
}
};
#include <map> /* stdc++ template library */

typedef id void_object_id_t;
typedef map<void_object_id_t, class_NSWindow_DataGory > map_objectid_to_DataGory_t;
static map_objectid_to_DataGory_t sMapObjectToDataGory;
-(NSWindow_DataGory*) get_DataGory_vself
{
NSWindow_DataGory* virtual_self = &sMapObjectToDataGory[self]; /* creates new storage if necessary */
/* register notification of NSWindow deletion/release here */
/* ie. something like
[[NSNotificationCenter defaultCenter]
addObserver:self
selector:@selector(dataGoryDeleteMe:)
name: NSWindowWillCloseNotification
object:self ];
where -(void)dataGoryDeleteMe cleans up the mapped storage for itself
*/
return virtual_self;
}


If you're going to be using categories to add new functionality to classes like NSWindow, I'm warning you now, you better prefix your method and category names with some serious disambiguation text.

Cocoa Source Code: Categories with Virtual Instance Data (Multiple Inheritance technique)

By : Cocoa Coder Categories and Informal Protocols with virtual Instance Variables 1 comments

 

 
 
 

 [Site Map]    
 Apple News    
 Opinion    
 Cocoa Programming    
 Reading List    
 About    
 Home    
 Reality Distortion Field    
 latest apple news iphone    
 latest mac apps news    
 ipad latest news apps    
 iSight Download    
 Best WebCam    
 Screen Capture    
 


Copyright © 1996-2006
All Rights Reserved
Reality Distortion Field Theory

search this site only.