I'm writing a simple cocoa program that should use the swipe gesture.
I've implemented in my NSView subclass the method swipeWithEvent: but when i try the program the method is never called. rotateWithEvent: method works instead.
I'm using a Xcode 4.1 on Mac OS 10.7 Lion.
Is there a difference between rotateWithEvent: and swipeWithEvent: ?? Why the first is called when I'm under the view and do a rotate gesture and the second in the same condition is never called if i do the swipe gesture?
Update :
I built also a simple project only to check the swipeWithEvent: and rotateWithEvent: methods but the behavior is the same.
Take a look at this sample code I wrote https://github.com/oscardelben/CocoaNavigationGestures
I think it would be helpful if you posted your code, reduced down to the bare essentials if possible.
One thing to look at is to make sure the method signature exactly matches the definition. In this case it should be:
- (void) swipeWithEvent: (NSEvent*) event
{
NSLog( #"A swipe happened" );
}
Make sure your definition matches this. Since you have a rotateWithEvent: that is working correctly this is probably unlikely but sometimes a typo can creep in.
Another thing you can do is to make a sample project that does nothing but respond to a swipe by logging (or whatever). This can help identify if there is something else ii your code or view hierarchy that is getting in the way.
Related
This question already has an answer here:
Closed 10 years ago.
Possible Duplicate:
How to know when the device is charging?
I am kind of a noob at Xcode so sorry if I make I fool out of my self. I am trying to make an app and one of the functions is to check if the iphone/ipod/ipad is charging or not. If not charging I want it to play a sound perhaps and flash LEDs. Also if it is charging, I want to make it display text such as "Device Charging :) " . By the way I am using the method with the FlipsideViewController, but these features will be in the MainView. I have looked at various examples and have seen the one below as well as many test applications, but I don't know how to use it. Thank you in advance!!
Code:
[[UIDevice currentDevice] setBatteryMonitoringEnabled:YES];
if ([[UIDevice currentDevice] batteryState] != UIDeviceBatteryStateUnplugged) {
//Device is connected (charging or fully charged)
}
It sounds like you might want to start with some tutorials on writing iPhone apps because the code above looks ok (though I haven't tried this specifically). If you don't understand how to do some of the things I describe below (or some of the terms are unfamiliar), I'd recommend getting a good book or checking out some tutorials:
Book: iOS 6 SDK Development (Amazon)
Tutorials: Ray Wenderlich has many good tutorials on his site
Apple Documentation is quite good
There's no point in just writing the code for you because you presumably want to learn how to program and you won't learn much if someone just does it for you.
Here are some pointers on how to think about this, though the behavior you desire isn't completely obvious from what you've said.
If I understand you you want two different actions to happen when the main view is displayed.
To start with, why not get it to set the text string in a field to match the state of charging / not charging?
So you'd add a UILabel to the main view .xib file in Xcode and add an outlet to it in the view controller so that you can set it's text at runtime.
Then you'll want to call the first line above somewhere once to start monitoring (parameter is: YES) and again with NO to stop monitoring once the view goes away. If you look at the documentation for UIViewController at developer.apple.com near the top you'll see a list of methods that UIViewController implements. In this case you probably want to override (create your own version of) viewWillAppear and viewWillDisappear and put the setBatteryMonitoringEnabled call with YES and NO into these two methods respectively.
So that takes care of enabling / disabling battery status monitoring. Now you need to test the state and take action (this is call to batteryState in your code above).
One question about design which isn't obvious from your description is if you want to do this once when the view appears or if you want it to continually monitor the state.
If you want to do it once, you could put the call to the above in viewDidAppear, say, and then use the outlet to the UILabel to set the message in the label to "Charging" or "Not Charging" based on the result from the batteryState method.
If you want something that watches for changes in the state of charging then you need to subscribe to the notification and put your code to change the UILabel (or whatever you finally do in response to a change) in the handler for that notification.
You figure this out by reading the documentation for UIDevice at developer.apple.com or in Xcode's Organizer window's Documentation section. If you read the documentation for the UIDevice method batteryMonitoringEnabled you can see that the "See Also" section includes two entries for the notifications you can subscribe to to find out when the Level or the State changes: UIDeviceBatteryLevelDidChangeNotification and UIDeviceBatteryStateDidChangeNotification. To learn how to subscribe to notifications you'll want to look at NSNotificationCenter documentation.
Then once you get this working you can add your fancier alerts (be careful about putting them up repeatedly!) and sounds (though playing a sound when the battery isn't charging will use battery which is somewhat questionable.. just make sure not to do it repeatedly perhaps).
good luck!
Add this to the appDelegate.m
- (void)applicationDidBecomeActive:(UIApplication *)application{
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(batteryStateDidChange:) name:UIDeviceBatteryStateDidChangeNotification object:nil];
[[UIDevice currentDevice] setBatteryMonitoringEnabled:YES];
}
- (void)applicationWillResignActive:(UIApplication *)application {
[[UIDevice currentDevice] setBatteryMonitoringEnabled:NO];
}
- (void)batteryStateDidChange(NSNotification*)notif {
// check the status here.
// See if it is charging, or not and respond to the change.
}
(edited to make code more explicit)
To play video in my app, I set MPMoviePlayerController and add it to subview. The user can change to full screen mode using pinch gesture.
In this viewController (that contains the Movie Player View), I set the viewWillDisappear to set objects to nil.
But, in iOS 6, when activating fullscreen mode the MPMoviePlayerController in the view controller that contains the Movie Player View calls the methods viewWillDisappear and viewDidDisappear.
In iOS5, those methods were not called.
I came across this issue as well and it caused me a lot of headache. My temporary solution until the bug is fixed is to check the player's fullscreen Boolean value in viewWillDisappear: and/or viewDidDisappear:. If it returns YES, the movie is entering fullscreen mode and you should refrain from doing anything that might interrupt it.
To everyone has noticed that and having problem with this, I found this report in community Open Radar: http://openradar.appspot.com/12327997
I am not sure this is a question but in case someone has a problem with the issue herein stated, that is, someone using a viewController (that contains the Movie Player View), I found the solution:
I was using a view controller with the Movie Player Controller and then presented this view controller as a subview. I just got rid of it and used the MoviePlayer.view as a subview directly and it works just fine.
Not a problem with iOS 5, but now, it is. Fix it and enjoy!
I'd really appreciate an answer to this, but can't afford a bounty (!).
Here we have a very simple GUI: the user just enters a source word and a target word in two text boxes, then presses a button. Then a lot of whirring takes place, and half a second later an answer is shown. The user goes on doing this until bored, then closes the app. Naturally, when the app restarts, the focus should be on the source, and I am hoping there is a neater way of achieving this than the one described. The commenter below has confirmed my feeling that the problem was an artefact of Lion persistence, which is a real nuisance in simple cases like this.
I set an NSTextField as First Responder (using the window's makeFirstResponder) in the awakeFromNib method of a simple 'controller' class, in a simple Cocoa application in Xcode 4.3, running under Lion.
The makeFirstResponder works fine the first time the app is loaded after reboot, but on every rerun the focus is set to the last field accessed. (I had tried connecting the window's initialFirstResponder outlet to the desired NSTextField, but got the same problem).
I fixed it finally by calling an initialisation function from the NSApplication delegate, and putting the makeFirstResponder call there.
The fix is a bit messy - I added a global variable to the controller, and initialised it to self in awakeFromNib.
I add the information that the Cocoa part of the app is simple, but the bulk of it is a mass of STL stuff in .cpp files, ported from Windows.
Deselect the "Restorable" check box in the attributes inspector for your window in IB. Of course, you then won't have the other behaviors you get with a restorable window like remembering its position and size.
In Cocoa/Objective-C if I have created a button programmatically, what do I put in for my control event?
[btnMakeChar addTarget:self action:#selector(makeChar:) forControlEvents:WHAT GOES HERE?];
In iOS you can write it like so forControlEvents: UIControlEventTouchUpInside
I can't find anything to show what I would use for just cocoa, not cocoa touch
I'm not sure if I understand you correctly, but if you're programming a Mac,
[theHappyButton setTarget:self];
[theHappyButton setAction:#selector(doStuff)];
it is two separate lines, rather than the one combined line of code on an iPhone.
I hope that is what you were after??
To find it in the doco: choose on the 10.6 doco (not iOS) and search on "setAction:". You'll see it in NSControl Class Reference. NSButton is of course a subclass of NSControl.
The method you're asking about does not exist in Cocoa, so nothing goes there. Cocoa controls have a single target with a single action, and either use a different addTarget:-type method for each kind of action or expect a delegate object that will handle all the events they generate.
http://iphonedevelopment.blogspot.com/2009/02/alert-view-with-prompt.html
I'm using that code to get my iPhone app to display an alertView with an included UITextField and matching CANCEL and OK buttons.
The user can enter text, hit CANCEL or OK... and I see the text the user entered... using my code inside the clickedButtonAtIndex method.
It all works except for 1 thing: Instead of OK, the user might hit DONE on the keyboard.
I'm using dismissWithClickedButtonIndex to simulate an OK click... but then clickedButtonAtIndex never gets called.
Shouldn't dismissWithClickedButtonIndex also call clickedButtonAtIndex?
I'm trying to get clickedButtonAtIndex to get called if CANCEL, or OK, or even DONE is hit.
Since this is an old question you've probably figured it out by now, but I was incredibly frustrated with this and couldn't find any help from Google, so for anyone who comes across this in the future: when you call dismissWithClickedbuttonIndex, the method that gets called is alertView:didDismissWithButtonIndex, not alertView:clickedButtonAtIndex. It behaves exactly the same way, and I can't figure out why they'd be two separate methods for what seems to be the same action, but there it is.
clickedButtonAtIndex is called when user actually clicks the button. Clicking the button may or may not dismiss the alert. the standard OK/Cancel buttons have the effect of dismissing the alert on click. If a click translates to dismiss or a dismissWithClickedbuttonIndex method is called, then did DismissWithButtonIndex is called.
I'm not sure whether I fully understand your question, but here is my try:
Firstly, you need to remove the if (buttonIndex != [alertView cancelButtonIndex]) from the example. This should work for the OK and CANCEL buttons.
To recognize the DONE key of the keyboard, use - (BOOL)textFieldShouldReturn:(UITextField *)textField of the UITextFieldDelegate. Here you could call [textField resignFirstResponder] to dismiss the keyboard.
Also, what to you do in clickedButtonAtIndex? Couldn't you create your own method and the call it when you need it?
I had the same problem with UIAlertView(Blocks) categoty
UIAlertView-Blocks
My solution:UIAlertView(Blocks) -> MYAlertView : UIAlertView
Sometimes method:- (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex called. Sometimes it didn't call.
So... I tried to find solution in many sources. Then I'he created subclass of UIAlertView with absolutely same code. And my problem was solved. In fact it is little bit more difficult to use. But no more this intrusive bugs.