i have been following
apps
snowfall tutorial, but i am getting some issue in iOS 5, something like this
(source: appsamuck.com)
-
(void)onAnimationComplete:(NSString *)animationID finished:(NSNumber *)finished context:(void *)context {
UIImageView *flakeView = context;
****this is where the issue is: implicit conversion of a non objective c pointer type 'void *' to 'UIimageview' is disallowed when using ARC
Please suggest, how can I solve this problem.
Regards
Expanding on #fluchtpunkt 's comment which should really have been an answer ;)
ARC works by determining, at compile time, if the objects are needed or not - it then works out your retain/release for you.
If you pass an object as (void *) the compiler cannot work out that it has to retain this object so it might get released before you use it.
The __bridge explicitly tells the compiler that you are passing a 'real' object but using a void * to do it.
However, there might be a risk of a memory leak if you don't tell the compiler somewhere else that you are done with the object :)
Take a look at http://developer.apple.com/library/ios/#releasenotes/ObjectiveC/RN-TransitioningToARC/index.html and search for '_bridge' to see more details.
Related
I want to test my app's crash reporting out in the field by deliberately having it crash when the user performs a particular action that a real user is unlikely to do accidentally.
But what's a good reliable way of making the app crash that doesn't create a warning at compile time?
Edit: Note that many seemingly obvious answers to this question result in exceptions that get caught by Cocoa and thus don't result in the app crashing.
in Objective-C use C directly to cause a bad access
strcpy(0, "bla");
Note: while this works on any system I know -- in a future version of the C runtime OR the compiler this might not lead to a crash anymore. see Is null pointer dereference undefined behavior in Objective-C?)
(in swift you would have to bridge to objC to do this)
My current favourite:
assert(! "crashing on purpose to test <insert your reason here>");
A classic:
kill( getpid(), SIGABRT );
And some pr0n:
*(long*)0 = 0xB16B00B5;
All of them generate crashes captured by my crash reporting tool.
Since we all use Clang for iOS, this is fairly reliable:
__builtin_trap();
This has the benefit that it's designed for exactly this purpose, so it shouldn't generate any compiler warnings or errors.
How about a good old stack overflow :)
- (void)stackOverflow
{
[self stackOverflow];
}
abort(); causes abnormal termination… That is a crash.
Most popular one - unrecognised selector crash:
NSObject *object = [[NSObject alloc] init];
[object performSelector:#selector(asfd)];
Make sure you don't have -asdf method implemented in that class haha
Or index beyond bound exception:
NSArray * array = [NSArray array];
[array objectAtIndex:5];
And of course
kill( getpid(), SIGABRT );
I think in Swift you could easily throw a fatal error:
func foo() {
fatalError("crash!")
}
It is actually even intended to use this feature in case something goes wrong in order to make the app crash.
To avoid an if statement in a special case, you could use precondition, too. It's similar to assert, makes thus the intention (if wanted) pretty clear and is not removed in the final release as assert. It is used like precondition(myBoolean, "This is a helpful error message for debugging.").
Send a message to a deallocated object
exit(0);
(must... type... 30 characters)
You can also raise an exception:
[NSException raise:NSInternalInconsistencyException
format:#"I want to test app crashes!."];
Add a gesture recognizer to a view that recognizes a 10 finger tap (5 fingers for iPhone as 10 can get a bit crowded). The GR has a method attached to it that executes anyone of the previously mentioned surefire ways to get your app to crash. Most users are not going to lay 10 fingers down on your app, so you're safe from the general user accidentally causing the crash.
However you should be able to use something like Testflight or just deploying it to personal devices and test in the wild before ever submitting it to Apple. Having a forced crash could get your app rejected by Apple.
could try something like
NSArray* crashingArray = [NSArray arrayWithCapacity:1];
[crashingArray release];
should crash on an EXC_BAD_ACCESS (might need to release it a second time but normaly it should crash like this already)
I will go with:int raise(int sig);
To get more info >man raise
I would just kill the process normally:
kill(getpid(), SIGKILL);
So if you install a handler with signal you can also handle the crash, finishing to write opened files and these things.
I use
[self doesNotRecognizeSelector:_cmd];
When working with RubyMotion I use this:
n=Pointer.new ('c', 1)
n[1000] ='h'
Try this:
- (IBAction)Button:(id)sender
{
NSArray *array = [NSArray new];
NSLog(#"%#",[array objectAtIndex:8]);
}
a wrong NSLog statement will do it
NSLog(#"%#",1);
-(void)rotateView:(id)sender {
CGAffineTransform rotateTransform = CGAffineTransformRotate(CGAffineTransformIdentity, M_PI);
[sender setTransform:rotateTransform];//the error is shown here
}
I am getting this caution error that shows up and says Multiple methods named -setTransform: found. It only shows up when I have #import AVFoundation/AVFoundation.h in my header file. Any suggestions? Thanks
Cast sender to the proper class type and the warning should go away:
[(YourClassHere *)sender setTransform:rotateTransform];
As sender is passed to rotateView: as type id Xcode cannot know what actual class type it is and by that which method to call.
Edit: Coincidentally just today Matt Gallagher of Cocoa With Love fame published an article about all kinds of issues caused by calling an ambiguous method on id in Objective-C.
The Situation
My custom controller class has the following method:
- (void)requestViewControllerWithIdentifier:(NSString *)identifier fromObject:(id)object;
This causes object to receive this message:
- (UIViewController *)viewControllerWithIdentifier:(NSString *)identifier;
The Problem
Right now, object is just an id so there's no guarantee that it actually implements that method, and I get a compiler warning when I send the message.
The Solution
I came up with two solutions myself:
Use a protocol.
Make id an NSObject and create a category for NSObject.
They are both fine solutions probably and I don't mind choosing one of them, but...
The Question
...I noticed Apple is doing something odd in their GameKit API. GKSession has the following method:
- (void)setDataReceiveHandler:(id)handler withContext:(void *)context
handler is just an id, but Apple actually requires it to implement this method:
- (void) receiveData:(NSData *)data fromPeer:(NSString *)peer inSession: (GKSession *)session context:(void *)context;
Without making use of any protocol or category! I'm wondering how and why would they do this? Why don't use a protocol? Do they enforce the method in some other way? If I were to do this, how can I suppress the compiler warning?
You can assign a variable of type id to any object type. If you know that it must implement a given protocol you can assign it to a variable of that type within the method and invoke the method on that variable.
As a design point, I would say that it is better to make the protocol explicit and externalise it to the caller so that the compiler can do type checking properly. Some parts of Apple's code are better than others at this: from what you say GameKit is very much at the unhelpful end of things.
Defining a category is not what you want to do, because that tells the compiler that you will add the method to every NSObject.
If you have this protocol:
#protocol YourProtocol <NSObject>
- (UIViewController *)viewControllerWithIdentifier:(NSString *)identifier;
#end
And define your method as:
- (void)requestViewControllerWithIdentifier:(NSString *)identifier fromObject:(id <YourProtocol>)object;
It will probably do what you want. It may not be strictly necessary in this case but it's usually a good idea to have your protocol extend the NSObject protocol (as above) so that you can call useful stuff like -retain, -release, -autorelease, and -respondsToSelector. The alternative of declaring the method as follows prevents the user from using an NSProxy-rooted object as the object parameter.
- (void)requestViewControllerWithIdentifier:(NSString *)identifier fromObject:(NSObject <YourProtocol> *)object;
If it's just for your own use and you aren't using proxy objects this can be quite convenient, but you should avoid it in public APIs.
I think the answer you seek is the difference between a formal and an informal protocol. This answer has a good explanation.
I have started a new project on iPad.I would like to know the method name and class name from which a particular message is sent to console while printing the message.Is there any way to print class & method names along with the log statement automatically.Please help and make my debugging easier thanks in advance.
Try:
NSLog(#"%s", __FUNCTION__);
NSLog(#"%s", __PRETTY_FUNCTION__);
P.S. This question may also be useful.
NSLog(#"%# %s", [self className], sel_getName(_cmd));
As _cmd starts with an underscore, it's potentially something you might not be able to rely on in the future, but everybody seems to use it for diagnostic logging.
The below is the way I used in my app
NSLog(#"%#",NSStringFromClass([self class]));
Also see improved logging section in Apple documentation.
Improved logging in Objective-C
-anoop
If you want the classname as an NSString, use code below;
[[myObject class] description]
I have an NSDictionary with some values. Usually, the values in the NSDictionary are static, but in some rare cases (user changes settings), the NSDictionary changes.
The dictionary is used application wide and stored in the app delegate.
The problem that I have now: When the settings change, I release the old dictionary and create a new one. How do I now inform all the relevant parties? I thought of storing NSDictionary** pointers and deference them as I need, in order to get the NSDictionary* (there is never a case where the dictionary is released and not recreated).
NSMutableDictionary* dict = [NSMutableDictionary alloc] init];
...
NSDictionary** ref = &dict;
When I run the debugger I can see that dereferencing ref does get me dict initially. But after some time, it seems that ref is pointing to nirvana. Wondering whether I need to manage memory or sth. for NSDictionary**? Since it's not a pointer to an object, retaining it doesn't make sense. But it does seem like a memory issue?
I'm not going to comment on the complexity of pointers, because that's really not relevant to this situation. Furthermore, I'm not really sure what it is that you want, but I think you are looking for a way to observe changes from one object in another. The nice thing is that Cocoa provides this out of the box.
So, you'll need to have this dictionary as a property to something (your application delegate). Then, use key-value-observing in whichever objects care, to watch that property for changes:
[appDelegate addObserver:self forKeyPath:#"dictPropertyName"];
Then, implement -observeValueForKeyPath:ofObject:change:context::
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context {
if ([keyPath isEqualToString:#"dictPropertyName"]) {
// your property has changed; respond to that here
}
}
Let me know if this is something like what you wanted.
Jonathan's answer is correct. However, since this is a global sort of thing, it might make as much or more sense to simply use a notification to let all interested parties know that the dictionary has changed.
Specifically, see NSNotificationCenter and NSNotification.