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.
Related
I'm using GLKit's GLKView in one of my projects. As per Apple's documentation it is deprecated. I can still use it in my app and it is fully functional (for what I want it to do) with latest iOS versions. I'm using it because of an older SDK that I'm using has good functionality for it. What are reasons not to use it anymore?
If something is deprecated, that means they may remove it in future versions. If you continue to use it, your code may break next time you update the library.
They left it in despite being deprecated to give you an opportunity to switch to a new solution.
A function being deprecated means that it is still supported for now, but they are planning on deleting it. Often times this is because there is other better ways to achieve the same. A reason to not use it anymore is because it will very probably be deleted eventually.
You can use it now,but maybe can't in the future.Such as UIWebView just like Apple said:
Apple will stop accepting submissions of apps that use UIWebView APIs.
It's the same.
It's available on iPad, but unfortunately not on iPhone. I want to use a service such as this to display some options to the user without summoning a new viewcontroller, and I'm curious what the best library/way to do this is.
I found this one: https://github.com/runway20/PopoverView
Which seems fantastic, but it is a little outdated, and hasn't been updated for iOS 6 (gives a lot of warnings in regards to deprecated methods being used).
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.
A couple of months ago, I posted a question asking if and how phonegap users can alter the keyboard appearance to the dark alert ui keyboard (UIKeyboardAppearanceAlert) without targeting individual textfields. I did some extnsive reaearch myself and offered a bounty but yet the question remained unsolved.
Alter keyboard appearance in native, phonegap/Cordova built iOS App
As of today, I'm still struggling to get this resolved and simply over with. I do realize much probably hasen't happened since last time I bothered you with this question, however, two things have in fact changed which somewhat justifies this seemingly double post:
Phonegap has released version 2.1 which does some new stuff, perhaps this is possible now?
As my client expects me to solve this in any way possible, this time I would also like to ask you for an alternative approach. If it still can't be done, would it be possible to custom make a "keyboard" of my own? I know this of course is technically doable, but is it in any way a recommended approach that would be considered in at least some way smart and justified? As I said, my client pushes hard for this and is not in favor of rebuilding the app completely natively.
Conclusively, as of today is there any way to do this with phonegap / Cordova? If not, would you recommend me to custom make a keyboard using HTML CSS and JavaScript, bearing in mind this is a major comsern for my client? If so, are there any good plugins that I can use as a start? Please check out my old post (linked above) to see what has already been tested.
Thanks in advance,
Jonathan
I know this is quite old but I came accross it looking for the same thing. Anyway, I have found a possible solution which would be to create a plugin for Cordova http://cordova.apache.org/docs/en/2.6.0/guide_plugin-development_index.md.html#Plugin%20Development%20Guide
It does require some native coding but would atleast avoid starting an app from scratch which has already been built in Cordova.
I'm using some methods in some apps that are now marked as deprecated since iOS5. I'd like to know when these updates will become urgent.
So, usually, when does a deprecated method becomes obsolete ? Is there a chance that this will be with iOS 5.1 ? Or is this always with a major version like iOS 6.0 ?
This depends and changes from method to method and property to property. If you look at something like the
cell.textColor
it has been deprecated since iOS 3.0 and can still be used. So unfortunately there's not a specific answer to the general thing about stuff being deprecated.
As far as I know, no published API has actually been removed from iOS yet, but that's no reason to be complacent. There's no reason to keep using deprecated methods as long as the replacement is available in all the versions of iOS that you need to support.
As for when they'll actually be removed, that's entirely speculation. Keep an eye on the release notes for new versions as they become available. My guess is that they'd only remove them in a major release but there are no guarantees...
For the most part, its in Apple's favor to keep backward-compatibility with older apps.
So when they finally do cut something out, it will be because maintaining it has gotten too expensive or because maintaining it would make adding some new feature difficult or impossible. (And that reasoning might include cutting deprecated code out because the system is getting too big to fit into the device.)
A better reason to avoid using deprecated methods is the app approval process. Apple may require new submissions to avoid deprecated code well in advance of actually cutting out that code.