It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Right now my StoryBoard is like this:
X->X->X
I want it to be like this:
X->Y->X->X
Y will be a simple Tableview connected to the navigation controller on one end and to masterviewcontroller on the other end with a basic cell pushing to it. I don't want to change anything in the app besides that.
but when I'm trying to do so I'm getting an error:
ScaryBugs[1768:11303] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[UITableViewController setBugs:]: unrecognized selector sent to instance 0x71d0940'
I'm guessing it's because I don't completely understand what those 3 lines are doing.
AppDelegate.m:
UINavigationController * navController = (UINavigationController *) self.window.rootViewController;
MasterViewController * masterController = [navController.viewControllers objectAtIndex:0];
masterController.bugs = bugs;
Source of code
That third line is just assigning the bugs property of the masterController to the array that was created in the app delegate with the local variable name, bugs. The first 2 lines are just getting references to the controllers that were created in the storyboard.
By putting another controller in as the root view controller of the navigation controller, you're screwing up the references. After adding it, the MasterController is now not even instantiated until you push to it, so there's no way to set its bugs property. Your new controller just doesn't belong there. It wouldn't really make sense to push from your list of bats, sharks, etc. to a list of bugs -- usually, that push (especially if it's from a table view cell) means you're going to present some information that gives more details about the cell you touched. IF you're trying to expand upon the tutorial, you really need to change the overall structure of the app, and that could require quite a few changes in the code.
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
Ok - can't quite make sense of what's going on here. I'm building a simple card game. I created a Category of UIView that handles all the stuff a "Card" should be. I figure this is irrelevant, but perhaps it's not.
Anyway, in my view controller, I'm just creating 2 NSMutableArrays to hold the dealer and players hands. Then I'm calling a method to set the card value. In that method, I do an NSLog to see the particular card object's value - and it all looks good. But if I try to get that value from my view controller, it always comes back for ALL the objects with the value of the last object in the array.
some code:
playersCards = [[NSMutableArray alloc] initWithObjects:[[UIView alloc] init],[[UIView alloc] init],nil];
[[playersCards objectAtIndex:0] setCardValue];
[[playersCards objectAtIndex:1] setCardValue];
NSLog(#"1: %i",[[playersCards objectAtIndex:0] returnValue]);
NSLog(#"2: %i",[[playersCards objectAtIndex:1] returnValue]);
So when I get the NSLog after calling setCardValue (this is within the Category) - again, all is fine. But those NSLogs right there - they return the value of index 1 for both. What's happening here?
There is no way that the setCardValue method can know what index the Card is at unless you are doing something convoluted. Therefore, it is likely that you do have two cards, but they are identically initialized.
However, there is a bigger problem here. You really don't want to use UIView instances as data like this. You really want to separate the bits that render stuff on screen [View] from the bits that hold the state of the game [model]. Typically there is a layer in between that manages the model state based on user interaction with the view [controller].
See the documentation on Model-View-Controller for more information.
Hanging stuff off of existing classes with categories may seem convenient, but it really shouldn't be used as the primary pattern for encapsulating data, state, and/or logic in your application.
You really want to keep that data [the game state] isolated from how the data is drawn on the screen [the views].
In terms of your specific question in your comment, another question:
Imagine that your code was written like this:
Card *c = [cardArray objectAtIndex: 0];
[c doSomething];
How would c know what index it is at in that code? Now, note that said code is identical to [[cardArray objectAtIndex:0] doSomething];.
If I were designing some kind of a Card game, I would likely create a handful of classes:
a Card class that simply stores a suit and value. Supports NSCoding for archival purposes.
a CardView subclass of UIView which, given a suit and value, knows how to render a card.
a GameFieldView and GameFieldController set of classes that know how to draw the playfield (former, UIView subclass) and how to move CardViews about the playfield (latter, a UIViewController)
specific subclasses of GameFieldController that add logic for things like hands, stacks, piles, and/or whatever else you might need to create a card game.
.... etc ....
That is, I'd break the game down into a series of classes that fit into the iOS or OS X model view controller patterns such that I'm writing a minimal amount of code and letting the system do the heavy lifting it is designed to do.
This may seem like overkill, what with all those classes and all, but, really, the individual classes are relatively simple and quite flexible.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I have a simple counter application, i.e. the user presses a button to increase it by a value of their choice. I started the application production on a single view application. I now have the need to make it so that when the app is closed it saves the last value of the counter. Then when the app reopens it needs to load the value of the counter back into place. The value needs to be saved and reloaded simply by closing and opening the app i.e. no buttons are needed to be pressed.
My counter variable is an Int value called counter. The view controllers are simply named viewController.h/m.
I have no idea how to set all of this up, I assume I need coreData to do this. How do I set up coreData? Do I code in my delegate of viewController? If this is not the best way to do it please provide a way to do it in a more effective way!
Thanks very much for any help, simple instructions appreciated most of all.
I have had a look at other example of this but none seemed to provide what I need or were simple enough to understand. Please provide an answer on this thread!
Hugh
It's easiest to simply use NSUserDefaults instead of Core Data.
To save:
[[NSUserDefaults standardUserDefaults] setInteger:counter forKey:#"counter"]
To read:
NSInteger counter = [[NSUserDefaults standardUserDefaults] integerForKey:#"counter"];
Take a look at UIApplicationDelegate to find what methods you should place the code in. It will likely be in your AppDelegate in one of the following methods:
Where to load the value:
-application:didFinishLaunchingWithOptions:
–applicationWillEnterForeground:
Where to save the value:
-applicationDidEnterBackground:
–applicationWillTerminate:
Exactly where depends on if you need to load and save the value when the user switches to another app, which is almost certainly the case as the app might be terminated when it is in a frozen state due to memory pressure. In this case you would want to make sure the value was saved when the app was backgrounded (the user switched to a different app) and the value was restored when the app became the foreground app (the user switched back to your app).
You can use NSUserDefaults.
You can store a variable creating an NSUserDefaults variable with
NSUserDefaults * standardUserDefaults = [NSUserDefaults standardUserDefaults];
Then save the integer with
[standardUserDefaults setInteger:1 forKey:#"integer"];
And synchronize all with [standardUserDefaults synchronize];
Then retrieve the integer creating a variable:
NSUserDefaults *standardUserDefaults = [NSUserDefaults standardUserDefaults];
and then recover it with
NSInteger myInt = [standardUserDefaults integerForKey:#"integer"];
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
My app has a problem that if I click a button to open a window, close the new window, and click the button again, it crashes and xcode says:
Thread 1:EXC_BAD_ACCESS (code=13, address=0x0)
Your button is attached to a method, that much is certain.
That method is being called on the second push, that's logical too.
So an object pointer that is alive in the first push is being assigned nil after the first push.
My guess, without any code from you to help give any further insight, your window is already created before pushing the button. Later, when you close the window, the pre-existing object is assigned nil. Then you try opening it again, you reference it without checking it being nil.
That's my guess of an answer, without any code to see. Feel free to accept this answer, it's perfectly reasonable, without seeing any code. :)
I fixed it, so if anyone has this problem, just go into your xib, click on your windows, and uncheck release when closed
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
This is my crash log.
2012-09-24 00:06:16.711 DMJ[10021:c07] -[DMJAppDelegate application:supportedInterfaceOrientationsForWindow:]: unrecognized selector sent to instance 0x84abe70
2012-09-24 00:06:16.713 DMJ[10021:c07] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[DMJAppDelegate application:supportedInterfaceOrientationsForWindow:]: unrecognized selector sent to instance 0x84abe70'
*** First throw call stack:
(0x2553012 0x1e04e7e 0x25de4bd 0x1e187ea 0x2542cf9 0x254294e 0x82a332 0x91266d 0x90d046 0x90d246 0x85601f 0x476e8e 0x4769b7 0x875573 0x4a1428 0xa420cc 0x1e18663 0x254e45a 0xa40bcf 0xa4298d 0x824ceb 0x825002 0x823ed6 0x835315 0x83624b 0x827cf8 0x2c88df9 0x2c88ad0 0x24c8bf5 0x24c8962 0x24f9bb6 0x24f8f44 0x24f8e1b 0x8237da 0x82565c 0x2ded 0x2d25 0x1)
libc++abi.dylib: terminate called throwing an exception
(lldb)
Optional in the context of protocols means that you don't need to implement the method.
But you must also take care not to call these methods or you are going to get an exception.
Normally before calling an optional protocol method you would do the following:
if ([object respondsToSelector:#selector(application:supportedInterfaceOrientationsForWindow:)])
result = [object application:myApp supportedInterfaceOritentationsForWindow:myWin];
As mentioned, the method probably gets called because your info.plist does not contain the correct keys (UIInterfaceOrientation).
Have you made sure your Delegate class conforms to the UIApplicationDelegate Protocol?
Your DMJAppDelegate.h should have
#interface DMJAppDelegate : NSObject <UIApplicationDelegate>
Also as mentioned in the Apple Developer Documentation about UIApplicationDelegate, if your application Info.plist does not have the key UIInterfaceOrientation specifying the valid orientations then it will call the supportedInterfaceOrientationsForWindow to the delegate (thus not being optional in this case) so you need to make sure you've specified the orientations in your Info.plist if you have not implemented the delegate method
This is how it should be specified within Xcode when you open your Info.plist (separate for iPhone and iPad if you are developing a Universal app)
Alternatively you can see the Supported Interface Orientations by choosing your Target in the Project Summary
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I know this is an easy one, but I just thought I could spare myself some (more) time searching through the documentation.
Usually, when I have an "Add" and a "Remove" button, along with an NSArrayController, I simply have to click-drag from each button and connect them to the add: and remove: actions of the NSArrayController.
Now, I'm trying to do the very same thing, programmatically with NSArrayController (co) :
[addButton setAction:#selector(add:)];
[addButton setTarget:co];
What am I doing wrong?
The rest of the NSArrayController operations, handling an NSMutableArray of dictionaries, etc works fine.
My psychic debugger* tells me that you're probably doing this in an init method, where neither of the outlets, to the array controller or the button, are connected yet.
Put this into awakeFromNib or a method which you know is called after the xib is loaded.
*psydb, of course.