Методы SKPhysicsContactDelegate, вызываемые с типами PhysicsKit?

Я добавил несколько удобных методов в SKPhysicsBody, чтобы легче с ними справляться внутри метода didBeginContact класса SKPhysicsContactDelegate.

@interface SKPhysicsBody (MyCategory)
-(void)convenience;
@end

Похоже, что делегат использует другие типы, а затем задокументированные. Когда я пытаюсь использовать этот удобный метод в didBeginContact, я получаю исключение.

При попытке следующего тестового кода

-(void)didBeginContact:(SKPhysicsContact *)contact {
    NSLog(@"%@, %d", [contact.bodyA class], [contact.bodyA isKindOfClass:[SKPhysicsBody class]]);
}

он будет регистрировать

PKPhysicsBody, 0

PKPhysicsBody является частью (частной) среды PhysicsKit.

В то время как SKPhysicsContact в документации четко указано

bodyA
The first body in the contact. (read-only)
@property(readonly, nonatomic) SKPhysicsBody *bodyA

Есть ли способ обойти это, чтобы я все еще мог использовать категории классов SKPhysicsBody? Или я что-то неправильно истолковываю, и это ожидаемое поведение?


ios sprite-kit skphysicsbody skphysicscontact
person Pieter    schedule 07.05.2014    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Что ж, PhysicsBody, вероятно, использует методологию Class Cluster, широко используемую во фреймворках Apple. Вы должны использовать встроенные контактные маски для идентификации ваших физических тел. Как описано в документах:

categoryBitMask Маска, определяющая, к каким категориям принадлежит данное физическое тело.

person Dvole    schedule 07.05.2014
comment
Я думаю, что есть некоторая путаница, под категориями я подразумеваю категорию Objective-C, а не категорию физического тела. т.е. Я хочу использовать методы из чего-то вроде @interface SKPhysicsBody (myextension) - person Pieter; 08.05.2014
comment
@Pieter Да, я понимаю, что вы хотите различать типы своих физических тел и проверять их путем самоанализа, но я предлагаю вам использовать для этого специальный способ - categoryBitMask. То, как вы хотите это сделать, не сработает. Проверьте, почему — developer.apple.com/ библиотека/ios/документация/общие/ - person Dvole; 08.05.2014
comment
Нет, я думаю, вы все еще запутались, я не хочу ничего различать с помощью самонаблюдения. Я не думаю, что это проблема кластера классов. Если бы существовал абстрактный суперкласс SKPhysicsBody, который бы передавался, все было бы в порядке. Проблема в том, что переданный класс не распознается во время выполнения как класс SKPhysicsBody. Если я просто добавлю @interface SKPhysicsBody (extra) с одним методом -(void)doSomething { NSLog(@"Boo!"); }, вызов этого метода для тела внутри SKPhysicsContact приведет к сбою с исключением. - person Pieter; 08.05.2014
comment
@Pieter, это именно то, о чем кластер классов. Например, NSArray или NSDictionary и то же самое с SKPhysicsBody НЕ гарантируют свой класс в любой момент. Таким образом, вы не можете просто добавить к ним новые методы и ожидать, что это сработает. У них разные внутренние классы в разное время по разным причинам, и это нормально. Документация, вероятно, неверна, не упоминая об этом. - person Dvole; 08.05.2014
comment
Конечно, иметь разные внутренние классы - это нормально, моя проблема в том, что переданный тип не относится к типу абстрактного суперкласса, как это должно быть в кластере классов. Речь идет не о том, чтобы иметь другой внутренний частный класс, обрабатывающий вещи, а о том, что тип не является абстрактным общедоступным классом, согласно документации A class cluster is an architecture that groups a number of private, concrete subclasses under a public, abstract superclass. Но, возможно, я совершенно неправильно понимаю, как все это работает. - person Pieter; 08.05.2014