Я думаю, что здесь есть другой (лучший ИМХО) подход, чем создание подкласса CLLocationManager, как в
http://code.google.com/p/dlocation/
В ObjectiveC представляется возможным заменить существующий метод из класса, не переопределяя его. Это часто называют «методом метания»: вы определяете свою собственную категорию для существующего класса и внедряете в него существующий метод.
С точки зрения клиента все прозрачно: у него такое ощущение, что он имеет дело с реальным CLLocationManager, но на самом деле вы "взяли под контроль" . Так что ему не нужно иметь дело с каким-либо специальным подклассом или каким-либо специальным протоколом делегата: он продолжает использовать тот же класс / протокол, что и в CoreLocation.
Вот пример получения контроля над делегатом, который клиент вставил бы:
@implementation CLLocationManager (simulator)
-(void) setDelegate:(id)delegate {
//your own implementation of the setDelegate...
}
-(id)delegate {
//your own implementation of the delegate....
}
-(void)startUpdatingLocation {
}
-(void)stopUpdatingLocation {
}
//....
//same for the rest of any method available in the standard CLLocationManager
@end
Тогда в этой реализации вы можете иметь дело с заранее определенным набором координат (поступающих из любого файла), который будет «передан» делегату с использованием стандартного протокола CLLocationManagerDelegate.