I love those collection views Apple introduced in iOS6 SDK. But my iPad is not getting an upgrade to 6.0, so theres a question. If I set the deployment target to 5.1, will I be able to use those new GUI elements they added in 6.0? Or do I have to code something like a Collection View myself?
You might want to take a look at PSTCollectionView.
Open Source, 100% API compatible replacement of UICollectionView for iOS4.3+
UICollectionView class is only available for iOS 6.0 or later. You have to set the deployment target to 6.0 (or later) in order to use it. Xcode 4.5 or later supports iOS 6 development.
Building on what ohho said, you don't have to build for 6.0 and later to use this, you can use it if it's available by checking the presence of the class at runtime, you can still set your deployment target to say 4.3.
All this means is that you must check at runtime if you have the UICollectionView class. If you don't then you must do whatever you did before, I usually used AQGridView.
To find out how to check at runtime for a class and or feature, please check out this post: https://stackoverflow.com/a/12590035/662605
Related
Some background info: Syntax color/highlighting and auto-suggest stopped working correctly. I read a lot of questions about how to fix this but none of them helped me as they were related to Derived Data.
I'm learning Swift from some online tutorials, and noticed my syntax highlighting was different to that of the course teacher's. Then I noticed that when I create an instance of my struct, and use the dot syntax after the instance, Xcode didn't auto-suggest the struct's functions and variables, whereas it does in the downloaded version of the project. After some investigation I noticed that a key difference between my project and the teacher's is that my project has a Deployment Target of 8.1, whereas the teacher's has 8.0. I changed mine to 8.0 and immediately the syntax highlighting was restored and I could access the struct instance's functions and variables.
I'm guessing this may be a bug in Xcode, but perhaps I have something misconfigured in Xcode? I'd be grateful if anyone could explain how/why this bug occurred and what is best practice when choosing the Deployment Target.
The setting is located at Project > General > Deployment Info
I hope the above info may help others who encounter this issue.
Deployment Target is the iOS version that your app is intended for. This does not mean it is incompatible with other versions, simply that it is designed to work best on that version. Generally, using the app on a device with a newer version of the OS is much safer and less likely than using the app on a device with an older version of the OS. There's actually a lot of restrictions around installing an app with a deployment target higher than the OS version on the phone.
The most common deployment target right now is going to be 7.x, as most apps were updated when iOS 7 first came out (there was a pretty big change in UI standards and SDK functionality from 6 to 7), and iOS 8 isn't too terribly different from 7, so there's no need to restrict it and/or write new versions of the app for the new SDK. By having a deployment target of 7.x, you should ensure that the app works well on 7.x and all higher versions, including 8.x. You should also have the lowest deployment target you can that's reasonable - so, a purely iOS 8 app should ideally be targeting iOS 8.0. You'll save yourself a lot of PR and invalid bug reports from users who don't understand versioning.
In your scenario, it sounds like there may be a bug in Xcode when using the iOS 8.1 deployment target. You might want to check and see if your docs are downloaded. Go to Xcode -> Preferences -> Downloads and ensure everything is downloaded. I'm not sure if these are actually used in syntax highlighting and completion code, but it's possible. I would also do clean the build folder (Product -> Hold Alt -> Clean Build Folder). Again, I'm not sure, but I think there's just some small thing that's not clicking here. I'm assuming you cleared Derived Data based on your first paragraph - if not, do that (Window -> Organizer -> Select Project -> Delete).
I made a project with MonoTouch 5. After upgrading to MonoTouch 6 my UIViewControllers are not auto-rotating anymore. These are hosted inside a tabviewcontroller. I get this warning:
ShouldAutorotateToInterfaceOrientation(MonoTouch.UIKit.UIInterfaceOrientation)' overrides obsolete member `MonoTouch.UIKit.UIViewController.ShouldAutorotateToInterfaceOrientation(MonoTouch.UIKit.UIInterfaceOrientation)'. Add the Obsolete attribute to ShouldAutorotateToInterfaceOrientation(MonoTouch.UIKit.UIInterfaceOrientation)' (CS0672)
But the method still gets called when I am debugging. The new ShouldAutorotate never gets called. Any ideas? Thanks!
There can be a few reasons. One of them is that you should be (if not already) setting the RootViewController in your AppDelegate (another link here). That was not required before iOS6.
Another one is starting to use the new iOS6 API, without keeping a fallback for earlier iOS versions. That would match your comment, i.e. works on 6.0 but not on 5.1.
Note that since you're still targeting iOS 5.x you can safely ignore the obsolete warnings. iOS 6 introduced new API to handle rotation but it will automagically fallback to the old API to keep compatibility with existing applications.
That also means that if you start using the new (iOS6 only) API then you'll need to handle the old API yourself or rotation won't work with iOS 5.x.
Honestly I think that's a testing nightmare - you're better off letting iOS handle this and keep a single code path to handle rotation. That why I strongly suggest you to keep using the older API until your deployment target minimal version becomes iOS 6.0.
I had the same issue after upgrading and I got the answer to my problem over here. Here is the heart of the problem, quoted from the link:
Application windows are expected to have a root view controller at the end of application launch
So if previously like me you have this in your FinishedLaunching(UIApplication app) method in main.cs:
window.AddSubview(mainVC.View);
Replace it with this:
window.RootViewController = mainVC;
That's it! Happy days! Rotation works again. :) At least it solved the problem for me.
I don't know whether this small thing causing the application to go wrong is Apple's fault or Monotouch/Xamarin's fault, but I think that the Xamarin team should do something about this. Surely this is something that could be detected and corrected at compile time?
Anyway. Hope this information saves other people the hours that this issue has cost me!
It is a best practice to detect if a certain feature's class exists and degrade user's features depending on availability. I created UICollectionView in storyboard and a standard tableview to support ios 5.1 users. I then simply check if the user has this feature and segue to the appropriate scene. However, when I now try to compile my code I get a "dyld: Symbol not found: _UICollectionElementKindSectionHeader" This seems very anti-pattern of apple to not allow ios6.0 features in storyboard with a ios 5.1 deployment target.
if ([UICollectionView class]) {
[self performSegueWithIdentifier:#"UserShow" sender:self];
} else {
[self performSegueWithIdentifier:#"UserShowTable" sender:self];
}
The above seems like a pretty reasonable approach to me...
I know this is not proper to put only link answers but her it is not possible to include the whole files.
Please see this.
A controller is designed to provide the same functionality as UICollectionController of iOS 6 but still supports to iOS 4/5
What developer is telling
PSTCollectionView Open Source, 100% API compatible replacement of
UICollectionView for iOS4.3+
You want to use UICollectionView, but still need to support iOS4/5?
Then you'll gonna love this project. I've originally written it for
PSPDFKit, my iOS PDF framework that supports text selection and
annotations, but this project seemed way to useful for others to to
keep it for myself :) Plus, I would love the influx of new gridviews
to stop. Better just write layout managers and build on a great
codebase.
The goal is to use PSTCollectionView on iOS 4/5 as a fallback and
switch to UICollectionView on iOS6. We even use certain runtime tricks
to create UICollectionView at runtime for older versions of iOS.
Ideally, you just link the files and everything works on older
systems. Practically, it's not that easy, and especially when you're
using subclasses of UICollectionView-classes, since they can't be
replaced at runtime.
You can't. As soon as you drop the collections view controller to the storyboard, it will try to reference it automatically, what will result in the compilation error you've got.
There's no compatibility solution for pre-6.0 deployment via storyboards, but PSTCollectionView does support iOS 5.0+ and is actively maintained. It does work at runtime to use UICollectionView* on 6.0 and later, and should be storyboard compatible.
I have to make apps for that work on both iOS 4 and iOS 5. The iOS 5.0 SDK has nice features like ARC, storyboard etc, which are not available in iOS 4.
My question is: In order to make an app optimized for iOS 4 and 5 what should do? Should I develop an app in a classic way without ARC, storyboard etc?
For instance, how can I switch off automatic garbage collection for iOS 4? If I do, of course iOS 5 will not benefit from having ARC. Also, if you mark reference as weak/string - that will not compile for iOS4, won't it?
As Andrey indicates in his comments, while automatic reference counting was introduced with the LLVM Compiler 3.0 that came with Xcode 4.2 and the iOS 5.0 SDK, you can use it in applications that target back to iOS 4.0. There's no good reason not to use it for applications that will run on iOS 4.0+. Also, it's different from garbage collection, as I explain in this answer.
__weak pointers are only available for applications that use ARC and target iOS 5.0 and greater. For iOS 4.0, you'll need to fall back to using __unsafe_unretained as a pointer type when you want to avoid retain cycles.
However, storyboarding is not available for applications targeting anything earlier than iOS 5.0. It's a nice convenience, but I don't personally use it for anything. Jonathan Wight has, and he has some complaints about its current implementation, so you might not be missing much if you gave that feature a pass.
I'm developing an iPad app and I'd like to use something like the NSCollectionView on it. There are SEVERAL 3rd party libs that do that. The problem is that none of them seem to support iOS 4.x. I really need to support this version of iOS. Does anyone knows a NSCollectionView-ish control for iOS that supports iOS 4.0?
Thanks!
I used AQGridView (https://github.com/AlanQuatermain/AQGridView) last year in an app whose deployment target was 3.1.3 (not 3.2 as mentioned by Scott in another answer -- that's the SDK version it requires, not the deployment target) so you should be able to use it for your project.
Here's a couple of other options I am evaluating for upcoming projects:
https://github.com/gmoledina/GMGridView
https://github.com/zorn/BCCollectionView
I'm not sure what their requirements are, I've just bookmarked them for checking out. GMGridView looks nice, I like its support for full-screen paging.
This one requires ARC and so you can't use it in 4.0:
https://github.com/kolinkrewinkel/KKGridView
But it does look nice. Overall, right now, I think AQGridView is the best fit for you.
AQGridView Supports 3.2 or greater.