I have a project that compiles with some warnings. It's an iPhone project that uses some methods on NSDate, that are seemingly not the headers of the iPhone SDK, but work flawlessly none the less. When I call these methods I get warnings like:
NSDate warnings http://beautifulpixel.com/assets/NSDate_Warnings-20090215-235727.png
So how do I silence the warnings permanently, in order to tell XCode "it's OK, really."
Or how do I correct the warnings? This code works great on the device and Apple has already approved an app that uses these same methods, so surely I can get XCode to understand that the methods really are there.
I would very strongly advise you to not use these methods. Just because they are declared in Mac OS X's Foundation framework, does not stop them being private API on the iPhone. Apple would be well within their rights to discontinue your app from the store. Likewise, there's nothing to stop Apple tidying up Foundation a bit for an iPhone OS 2.2.2 or later release and removing those two methods, thereby breaking your app.
You can write a short interface extension early in you .m file to suppress these warnings
Example:
#interface NSDate (SuppressSomWarnings)
- (void)dateWithNaturalLanguageString:(NSString*)_str;
#end
It's strange, I do not get any warning when I type the same two lines... Did you correctly import the headers and frameworks into your project?
I see that they are defined in NSCalendateDate.h, which is in Foundation.framework.
Failing that, you can try and include the interface definitions directly into your code, e.g., at the top of your .m file, to see if that gets rid of the warnings. (See epatel's answer that came while I was writing this!)
Do you have the correct SDK configured?
You might be liking against the newest version, but using old header files.
Your code may work in the simulator but does it work on the phone?
The simulator uses the OS X Foundation framework which is a superset of what is available on the iPhone.
Related
Am struggling to get TestFlight working with my MonoTouch app (Monotouch 5, IOS5) and have not found any MonoTouch documentation for TestFlight.
Here is what I tried so far.
Downloaded TestFlight bindings from https://github.com/mono/monotouch-bindings/tree/master/TestFlight -- after adding this as a reference it seemed that the TestFlight methods were actually not exposed at all, so I looked for another set of bindings.
Downloaded ayoung's TestFlight bindings from https://github.com/ayoung/monotouch-testflight. Built monotouch-testflight.dll with Make, copied it to the project and added to References -- this time the TestFlight methods were all visible.
Added libTestFlight.a to the Lib folder in my MonoTouch project with BuildAction set to Nothing. (I also have RedLaser in there).
Per ayoung, I enabled LLVM compiler (with ARMv7); ayoung states it is required. In Project Options -> iPhone Build my additional mtouch arguments are:
-cxx -nosymbolstrip -nostrip -gcc_flags "-lgcc_eh -framework SystemConfiguration -framework CFNetwork -framework CoreVideo -framework CoreMedia -framework AVFoundation -framework OpenGLES -framework Security -L${ProjectDir}/Lib -ltestflight -RedLaserSDK -ObjC"
Note: The app worked ok with RedLaser before TestFlight was added to the project.
Here -lgcc_eh is as per ayoung -- I have not been able to find out what it is or what it is for. Perhaps I should have a gcc_eh.dll (?) but I don't AFAIK, and I don't know where I could find such a thing.
In Main.cs I added
using TestFlightSdk;
and In FinishedLaunching I added
TestFlight.TakeOff( "(downloaded team token is here)" );
Compiled and installed with no error (Release|iPhone).
When I now run the app on the device, it exits immediately with no diagnostic that I can discover.
The app also exits immediately if compiled to Debug|iPhone. In this case, however, if I turn off LLVM despite ayoung's strictures then in Application Output I see the following:
TestFlight: Started Session
TestFlight: Crash Handlers are installed
Thread started:
Thread started:
TestFlight: Team Token is recognized
TestFlight: End of Session
TestFlight: Communication with TestFlight is currently disabled, check earlier in your log for details
This might be because I have not yet uploaded the app's .ipa file to TestFlight?? (The app does launch in this case however.)
I am trying to find out how to generate a .ipa file. TestFlight documentation shows how to do this from XCode but my app is code-only with no .xib so that option seems to be out? TestFlight documentation also shows how to generate a .ipa from the .app file. Here my problem is, how do I lay my hands on the .app file for a device build?
Any help with these issues would be so much appreciated.
-lgcc_eh is needed to include the Exception Handling GCC library, which is often required if you link with C++ libraries.
You also have a lot of -framework options that do not look required (MonoTouch already adds them) - but that won't be the cause of your problem. If you're curious about what mtouch use/provide at compilation time then you can add "-v -v -v" to the "additional touch arguments" in your project options (and look at the build output).
As for the main issue I think it's related to the fact the TestFlight handlers are not compatible (presently) with MonoTouch (5.0). MonoTouch exception handling already provides it's own crash handlers (e.g. for NullReferenceException) and adding other handlers needs to be done with care (how and when to do it is very important). This is likely why the current bindings in monotouch-bindings don't include every feature available in testflight.
I suggest you to open a bug report at bugzilla.xamarin.com and you'll get email updates on the progress (and know exactly when the feature will become available).
p.s. try to break your issues into several (stack overflow) questions, you're more likely to receive answers that way since not everyone knows all the answers to every question you might have :-)
I was going down the wrong track entirely. Finally found the MonoTouch documentation which describes the built-in support for TestFlight:
http://docs.xamarin.com/ios/tutorials/TestFlight_Support
Will try this, it should solve the problem.
Distributing throug testflightapp is a different thing than using the testflightsdk in you app.
The first one is by clicking the upload to testflight button in the menu.
The second is by including the actual sdk.
In the last few day they (xamarin) released new testflight sdk bindings. That don't recuire you to modify the mtouch parameters. So it should be much easier to include it.
Personally i really like the testflight sdk... Helps me better (let) test my apps.
From the sound of this Xamarin bug report, it seems as though even if you get the TestFlight SDK native library working with MonoTouch bindings or by linking it yourself, you're still going to have the problem that TestFlight is not going to properly handle any NullReference exceptions and is simply going to crash the app when it encounters one. This makes the whole point of the TestFlight SDK kind of pointless until either a) MonoTouch is re-tooled to deal with it or b) TestFlight releases a managed Mono library.
Don't get me wrong, I REALLY want to be able to use the TestFlight SDK with MonoTouch. I've been beating my head against the wall trying to get it work all day. Something is failing when I call the TestFlight.TakeOff("MyKey") method. Control does return from the method, but then it crashes shortly thereafter...about 1 second after it's called. Weird.
If anyone else has gotten it work, I'd love to hear about your experiences. Thanks.
Does anyone know if version 2.2 (the latest) of Apple's iOS 'Reachability' example code will run on iOS 3.0?
I want to support iOS 3.0, and Reachability.h and .m is the first non framework code I'm using in my app. In my own code I usually read the docs for all methods I use, and use respondsToSelector: to implement methods that won't run on 3.0.
When people use third party code, how do they confirm which iOS it supports without checking every method individually against the docs?
Alternatively, does anyone know how I can get my hands on the old version of the example code? (Reachability version 2.1 might help.)
I don't mean to snipe an answer from #Matt and #Martin, but I feel like this question deserves an answer for posterity. If they come back and post their comments as answers please feel free to accept them.
Anyway, my own answer is that I would highly advise against using Apple sample projects directly in a production application, especially Reachability. Many of their examples are badly written and, as you've noticed, outdated. I've filed a lot of bugs against them without many results.
That said, one other point is that you should really think twice about relying on Reachability for control logic. If you just want to notify the user when their connection changes or something, okay. But don't rely on what Reachability says to decide whether to try communicating with the network or not. It's often wrong about your network status. Just open up a connection, and if it succeeds great, otherwise you'll get an error response letting you know there's no connection.
EDIT - Regarding your other question about how to tell what IOS a third party app supports. The answer is, unless they've documented it, you might not be able to. Best indicator is usually taking a look at the build target's "Base SDK" and "iOS Deployment Target" settings. Base SDK will be the latest iOS version they've built against, and Deployment Target will be the earliest iOS version they support.
Cheers
iOS development is now done using only the latest SDK.
Is there any way to search my code base for calls not present in older SDKs, generate warnings when compiling code that requires newer SDKs, or some other way to find where the code will fail on older iOS versions?
A workaround that broke compiling entirely would also be acceptable. This is not something I want to ship with, just something I want to do to verify that I've handled everything properly. The application seems to run on devices running earlier versions of iOS, but I'd like to be able to prove this.
No, I don't believe that there is a good way to find new calls not available in older SDK's. It's something I've wanted for a while.
The best thing I know of is to test your app thoroughly on a device running the oldest version of the OS that you plan to support.
It looks like this will do it...
Add this to your prefix:
#define __IPHONE_OS_VERSION_MAX_ALLOWED __IPHONE_3_1
Do not ship without removing this, though. In fact, you'll probably have to disable huge chunks of code to get your app to build this way. And even so, the coverage is nowhere near complete. But it's better than nothing.
Dear Scholars.
I have created a simple application using the latest SDK (4.2.1), Which runs smoothly and error free on all devices with iOS 4.x.x.
Lately I am getting some comments from users with older iOS version complaining the application is crashing on start, on Apple's crash log I see nothing at all.
Pushing my investigation forward, the only suspect I have at the moment is the use of EventKit class, which if memory serves, where introduced only after iOS4.
I am using it very lightly in one of my classes, and it works perfectly on iOS4.2.1
#import <EventKit/EventKit.h>
//some time later
[self setADateInCal: [MyTimeArray objectAtIndex:0] :formatterDate];
Thus my Questions:
Can this be the issue that crashes my application on iOS < 4 ?
How can I prevent it without dropping the feature for people with iOS4
In general, How can I test this? I have the latest official iOS on my device and SDK, the simulator is limited to how back it can go in regrading to iOS version... any magical way to do so?
1.) Yes. If it wasn't in the API in <4.0 than anyone not running >4.0 will crash.
2.) Test to see if the class is available using NSClassFromString (Google for examples) and respondsToSelector in correspondence to see if the method you want is available to use in the OS version the client is running. You will also probably need to weak link the EventKit framework (again Google for how to do this).
3.) The only real way to test this is to keep a device at the OS you want to test. Personally, I have an old iPhone that I never update running 3.1.3 for things just like this. Alternatively, you can keep old installs of xcode+iOSSDK on different partitions or something and use their simulator. (for future updates i guess since you obviously haven't done this for <4.0). But no, there is no magical way to do this. sorry.
edit for clarity on Number 2: Basically you will check to see if the class/method you want is available on the OS version you are currently running, if it is you can use it, if not you will have to find a work around (omit completely or do it another way that is compliant with older versions).
Yes it could be causing the crash. Issues with missing libraries do not report anything in the apple crash log.
To prevent it from happening you need to do two things,
Weak link the event kit library in xcode.
Check for its existence in your code with something like
,
if(!NSClassFromString(#"EKEventKit")){
//do stuff with event kit
}
The only way to test on the actual iOS version is to get hold of a physical device running ios < 4.
I have an application designed for iPhone OS 2.0 and I am adding some new 3.x functionality to it. My idea is to maintain compatibility with older versions.
I have managed so far, to test for deprecated functions using "if respondToSelector...". This is just fine for calls inside a method but how to deal with method name changes? For example, the OS 2.x method
-imagePickerController:didFinishPickingImage:editingInfo:
changed in OS 3.x to
-imagePickerController:didFinishPickingMediaWithInfo:
How can I test for the OS version and direct the application to the proper method in this case?
thanks for any help.
You can use NSObject's -respondsToSelector method to dynamically determine if the method exists, then call it. You might also want to use -performSelector:withObject: to call the methods, so you don't get compiler warnings.
OK.
After a second read, I found, that I did not get your problem completely. If you implement both methods, either one will be performed at runtime. If it is a 2.x the -imagePickerController:didFinishPickingImage:editingInfo: will be performed, if it is 3.x the other one will be called
This is the crap I have written prematurely and where the comments are related to:
you may use
#ifdef __IPHONE_3_0
// iPhone 3.0 specific stuff
#else
// iPhone 2.2 specific stuff
#endif
see also this post:
What #defines are set up by Xcode when compiling for iPhone