SIGABRT on any UIView touch

I think the problem is that somewhere you assign a view to a property that should hold a window. The code is trying to send a UIWindow message to a UIView which does not have the method. (UIWindow is a subclass of UIView.)

I don't see the immediate cause but this his app shows severe design problems. You have a UIView subclass of WPGameState which itself has a UIView property called window. This breaks the Model-View-Controller design pattern badly.

None of the logic in either WPGameState nor IntroStateView belong in a view, that logic belongs in a view controller. You should have a single view controller that manages both views and handles their display, timers etc. The views should only know how to draw themselves in response to commands from the view controller.

(And why the explicative-deleted is there a singleton view? This is the kind of singleton abuse that gets singletons banned from use in some shops.)

Neither should the "game state" be in either a view or a view controller but instead should reside in its own custom data model object.

The kind of problem you are seeing is why MVC is used in the first place. By cramming so much logic into your views, you can set off an unpredictable cascade of errors just by touching the interface. If your design was more modular with clear separation of function, you would know automatically where this problem was coming from.

rolling my own. the app delegate loads up a singleton class responsible for taking over the entire application. this is where a UIWindow is declared and alloc'd the following way (window is a class variable with a retain property): window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]]; [window makeKeyAndVisible];from then on, the view controller is loaded, makes its own self.view and attaches THAT to the [window addSubview:(the single VC self.view)]

bitcruncher 2010-04-23 16:20:15

Where is UIView *window; set up? Can you please post your startup code? The stuff that is usually in - (void)applicationDidFinishLaunching:(UIApplication *)application... What is viewOutlet initialized to?window = [theGame viewOutlet];--- TIP -----In your init code, you call [super init] and then ..initWithFrame (Which also calls [super init]. This is not good, just subclass (id)initWithFrame:(CGRect)aRect or don't call [super init] explicitly.

Kenny 2010-04-23 16:45:10

@Kenny - the UIWindow *window was declared as a class variable in the game singleton header. it was allocated in the singleton implementation file as described in my comment above. thanks for the tip on initWithFrame calling super init. i had my doubts about that, but took a chance. (+1)

bitcruncher 2010-04-23 22:13:32

@TechZen - ok, i see where you're coming from, though i disagree. here, i have one view controller running as the display server, while the views (individual and unique gamestates), implemented through singletons, are attached to the display server's self.view, as needed. this is why the class holds no critical logic, save for device rotation and generalized view management. in this shop, we respect the MVC approach for certain tasks, but this is not one of them. however... i will gladly upvote your answer here because it did help me to find the actual bug.

bitcruncher 2010-04-23 18:18:56

I won't tell you your business but I would advise that you match your design to the API. I can tell from your terminology that you're coming from a strong C++ (or similar) background and that your trying to map that experience onto this API. Objective-C and the API are flexible enough that you can do whatever you want but if you don't build around a strong MVC design you will be fighting the API all the way instead of letting it help you.

TechZen 2010-04-24 13:11:08

ansaurus

tags:

views:

answers:

SIGABRT on any UIView touch

related questions