When creating a simple app with Monocross (using MonoTouch) and compiling for an iOS device I get some bad warnings, like this:
Warning MT4112: The registrar found a generic type: MonoCross.Touch.MXTouchViewController`1. Registering generic types with ObjectiveC is not supported, and will lead to random behavior and/or crashes. (MT4112).
I've read all I can find about using MonoTouch with generics on an iOS device and it's mostly not supported. My app currently works on an actual device, but the warnings worries me.
I guess my question is, what is the state of Monocross when you get these warnings even with the simplest of apps? Is it still not ready for professional use or are the warnings not relevant for the way generics is used in Monocross?
I can also add the following from Xamarin.iOS docs:
"Xamarin.iOS does not currently support creating generic subclasses of the NSObject class"
Which is exactly what Monocross does, with for example the MXTouchTableViewController class.
There is some history to this: creating generic subclasses of NSObject has never been a supported scenario, but unfortunately MonoTouch never enforced, nor warned about this fact. So people of course ended up doing exactly this.
Then one day I had to track down something that looked like a true heisenbug, and it turned out (after many hours of frustrating debugging) to be because the project in question was using generic subclasses of NSObject. The exact details are not important, but that's when the warning was added to MonoTouch.
My point here is people have been using generic subclasses of NSObject for a long time, without running into any problems. If you test your app extensively (which you should do anyway), don't worry about this.
But if you do run into strange and inexplicable behavior, we'll most likely ask you to fix these warnings before looking into any claims that you've found a bug in MonoTouch.
Related
So let me start of by saying I am new to Objective-C and pretty much all of my experience has been in very high-level languages like javascript and ruby so learning it has been tough and I know there are a lot of concepts I don't have a good grasp on.
I am currently building a cordova plugin to be able to integrate the MagTek eDynamo reader into cordova IOS apps. My plugin is based largely off of this plugin and I have been using the existing code along with the Magtek SDK Documentation/(the sample code in the SDK) to work my way through updating the plugin.
Now to my problem: Every time I call the openDevice function I am getting the error in the title. [corebluetooth] XPC connection invalid. I have looked this up and have gotten pretty confused by other answers on stack overflow and some blogs I found discussing the error. From what I understand it is thrown when there are multiple instances of CBCentralManager, or when it is referenced as a local variable instead of a strong reference to the class. To be honest I think this is where my lack of experience with objective-c and mid/lower level languages in general is really hurting me because I don't really understand these answers and from what I thought the SDK files and functions were taking care of the interaction with core bluetooth so I'm not really sure what I am doing to cause problems with core bluetooth at all.
I have been stuck on this for over a week now and I really don't know what to try next.
Thank you in advance for any insight and I am willing to provide any more code or logs that might be helpful although all of the code for the plugin is in this Github repo.
In https://github.com/kevinjung2/CardReaderPlugin/tree/ios-branch there is not a single reference to "XPC connection invalid".
In foundation there is a XPC connection invalid error from Cocoa framework.
https://developer.apple.com/documentation/foundation/cocoaerror/2293178-xpcconnectioninvalid/
In the lack of more information I'm guessing that your driver are not updated to what the Cocoa framework are expecting for open a connection.
MAYBE, and this is just a guess... Apple changed something in their API that needs to be updated in the driver.
On the repository provided there is a https://github.com/eGood/CardReaderPlugin/blob/master/src/ios/libMTSCRA.a file that is not open for change and further investigation with easy. Pehaps the needed-to-update-function that provides metadata to open a connection to bluetooth are created there. And, in this case, there is nothing to do unless ask for the Magtek to update their driver.
EDIT: Have you tried what the manufacturer said in section 3.3.2... they have a test app. Try to connect with theirs... if it works, then you know is something wrong in your app, but if theirs didn't work either. Is most likely my hypothesis above.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 1 year ago.
Improve this question
Previously with objective-c code, I could "Analyze" - CMD + Shift + B and Xcode would warn me of all kinds of wrongdoings on my part.
It seems that with Swift, I can do no wrong! No warnings of any kind! But clearly there is a memory leak in my code.
Is there some setting I have to enable to get Swift to analyze my code properly? (I am aware I should use the profiler and test on an actual device, which I do, but I wonder why "Analyze" doesn't do anything.
Unfortunately no. Even many releases later, the latest version of XCode (6.4) still cannot do Swift analysis. The 'Analyze' option only works for the Objective C files in your project.
Let's hope the next version will have it, along with the refactoring capabilities which also are still limited to Objective C code.
To this moment (Xcode 8.3.x) Static Code analysis skips Swift code. Some Swift warnings cover some of the issues previously detected by the analyzer.
Also the upcoming Xcode 9 (presented in WWDC 2017) does not announce any change in this direction.
Many issues detected by the static Analyzer of Obj-C are for the most part prevented by the actual Swift language (e.g. unintended fall-through in switch statements). Other issues and scenarios formerly caught by the analyser, are now caught directly by the Swift compiler.
Many flows and scenarios leading to program crash - (e.g. accessing null pointers, leaving dangling pointers, or accessing released memory blocks) are hardly possible in Swift. Swift strong typing, heavy use of optionals, the requirement to completely cover protocols, and switch-case over enums, etc. remove another bunch of issues previously found by the analyzer.
A Swift static code analyzer will need to go to another level in analyzing program logic, which is much harder, and theoretically impossible to do completely.
So - although I'm quite thrilled to think of some future Xcode Analyzer, I wouldn't hold my breath waiting for it
Update:
As more and more people are down voting my post, just small update from my side. It seems that indeed apple just did allow for pressing option "Analyze" but in the background it does nothing (state for 2016.04.21, though I am not working on iOS for the moment and probably I don't have the latest version of Xcode).
below my original post:
Just for next readers of this article. At this moment Xcode 7 is already able to analyze also Swift projects. Refactoring is still not working though.
BR,
Darek
I want to use this open-source component:
https://github.com/CEWendel/SWTableViewCell
On iOS 7 ++ works fine, but on iOS 6 it crashes.
I need to know if there is any built-in macro that will allow me to do something like this:
#if __CURRENT_IPHONE_OS_VERSION >= __IPHONE_7_0
#import "SWTableViewCell.h"
#interface PPTimerCell : SWTableViewCell
#else
#interface PPTimerCell : UITableViewCell
#endif
Thanks in advance!
As noted in comments, #if is a compile-time condition, not something that applies at run time. If you want to continue with your direction, you'll need a way to vary behavior at run time.
What do you mean, "If I want to continue?"
Also as noted in comments... is it really worth the extra development, maintenance, and support effort for this issue for the small number of users not on iOS 7.0 or later? Apple's latest usage statistics say that number is 4% (and most likely shrinking). You might have an easier time just cutting 6.0 support.
Note also that the swipe-for-actions functionality provided by SWTableViewCell is built-in on iOS 8. You could reduce your dependency on third-party code by just doing swipe actions on iOS 8 with the built-in API. (Not saying you should, just that it's worth considering how you spend your development/QA resources.)
Okay, so how do I change table cells at run time?
The general case of varying a superclass at run time is hard — see further down if you must. But you're doing this for table cells — a table view can easily have the class of each cell set at run time. You could refactor your code so that you instantiate a UITableViewCell subclass on one OS version and a SWTableViewCell subclass on another — and instead of duplicating the code that'd be shared by those classes, put that code in a third class, an instance of which is referenced by each of the other two.
But that's too easy. I have no fear, show me the crazy stuff!
So you're looking for a general solution to the conditional inheritance problem? Well, that gets into dark places real fast.
If you were working with a class that'd be present (i.e. linked) on one version of iOS and not on another, the compiler's #compatiblity_alias feature might help you. This declares one class name as a substitute for another — a couple of years ago it was handy for using third-party libraries like PSTCollectionView as a backward-compatible replacement for UICollectionView, but that was introduced in iOS 6 and nobody's seriously trying to go back to iOS 5 anymore. Anyhow, since #compatibility_alias depends on symbol linkage, to use it in your case you'd need to make the linker bring in your library on iOS 7+ but not on iOS 6, and I don't think that can be done.
If you really want to create a class whose parentage can be different at run time, you'll have to create that class at run time using the ObjC runtime API. Call objc_allocateClassPair to create the class. Beware that working with the ObjC runtime is not for the faint of heart, though there are some good writeups on it out there. Again, though, you probably don't want to do this.
I am pretty new to development for iOS devices with jailbreak. From what I am reading I understand that to be able to do all the cool things which you can't do on non-jailbroken phones you have to hook up to a given class and override some of its behaviour. Since there is no documentation how a developer tracks to which class exactly he should hook?
I imagine that for instance if I wanted to have my app respond to a given event such as phone boot, call hang up or user clicking on an icon I would manually generate the given event and see what invocations have been made. Is this the proper way to track where you should hook your code and if yes how is it done.
Note I am not interested in exactly those events mentioned above I am more interested the approach in general.
There are several approaches:
Disassemble binaries
You can disassemble a binary or just dump classes with something like class-dump.
So, you can see the whole hierarhy of classes.
Find dumped classes
Most of major iOS subsystems were dissasembled by somebody already. You can find quite a lot of useful stuff.
As example. Google search "Springboard headers" got this
Dump classes in a runtime.
Look at this question for explanation: List selectors for Objective-C object
I know this is a well known and discussed issue. And I've already search here for what I want to know and couldn't get any conclusion.
UniqueIdentifier is still working in iOS6.0.1 (although it's deprecated since 5.0, I know). But is it possible that it can be returning some different (or nil) string than in older OS versions? And possibly only in some specific devices? I've managed to test in 5.1 and the returned string is equal to the one in 6.0.1.
I've read a lot saying that it doesn't work anymore, but fact is it still works. Now the question is, does it still work exactly as before? Could something have changed due to deprecation? I know I shouldn't depend on uid anymore, but I'm just trying to analyze and debug some strange behaviors I'm having in an app lately.
Thanks,
Francisco
For iOS 6 and above you should use NSUUID:
http://developer.apple.com/library/ios/#documentation/Foundation/Reference/NSUUID_Class/Reference/Reference.html
I realize that doesn't answer your actual question. Apple doesn't want you to use the older method anymore for whatever reason and there have been cases of applications being rejected for using it. So whether or not it works is probably a lesser issue if you won't even be able to submit it ;). I don't think the mechanism has changed though.