I've yet to make a Auto-Layoutless Storyboard to running on iOS 5 so my code won't even run on iOS 5 at the moment. However, I do plan on supporting it. At the same time, I also want to incorporate collection views in my app. I will support it on iOS 5 through the use of the publicly available PSTCollectionView on github. I figure, define the collection view IBOutlet as an id and then everything else is simple. Expect one thing...
Defining the delegate and datasource the collection views is a must.
So my question is, upon defining the UICollectionViewDelegate and UICollectionViewDataSource in my view controller
a. will my project even compile for iOS5 devices?
b. if not, how do I add a macro to conditionally define the respect protocols on iOS5 and iOS6?
Related
I have a project originally targeting iOS7 using a storyboard. I've added a UIStackView to a view controller and get an error that "UIStackView before iOS 9.0". The build fails because of this error.
How can I keep my project as iOS7, while conditionally including newer storyboard elements from iOS9 if device supports them?
I already have conditional code in the project that only runs on iOS8+, but how can I do something similar with a storyboard?
The class UIStackView (and its software) is provided by iOS 9, but is not provided by iOS 8 or 7. When the app tries to instantiate an object from the storyboard in iOS 8, it will fail because it cannot find the class.
The only ways around this:
have different storyboards for different iOS vesions
build a custom class that does the same thing. Then you can use it in the older versions of the iOS. You might find open source libraries that already do this for the class you want.
Since iOS 5.1 was released, the default for showing the Master view controller in split views is a slide in type of thing. In order to present a popover it seems like you have to enable it using a UIPopover controller instead. Does this mean that the popover is going to going out of style?
When it comes to Apple's API's, deprecated means that Apple has specifically stated that something is in the process of going away. It's usually accompanied by advice regarding a new way to accomplish the same thing. So, if Apple ever deprecates UIPopoverController, you'll know it just from reading the documentation.
That said, it's also a good idea to read the release notes for each new version of iOS that comes along. In the iOS 5.1 release notes you'll find a note that explains what you're seeing:
In 5.1 the UISplitViewController class adopts the sliding presentation
style when presenting the left view (previously only seen in Mail).
This style is used when presentation is initiated either by the
existing bar button item provided by the delegate methods or by a
swipe gesture within the right view. No additional API adoption is
required to obtain this behavior, and all existing API, including that
of the UIPopoverController instance provided by the delegate, will
continue to work as before.
I'm an iOS developer just starting to develop for OS X. In iOS, I always follow the MVC pattern, and put appropriate code in UIViewController subclasses. The App Delegate simply initializes the main view controller, and that's it. After that the view controllers handle all logic.
But in OS X, I seem to put everything in the app delegate. My app delegate class is now about 300 lines long and I am wondering how I can follow the same pattern I did in iOS. There are no view controllers!
What I mean is, what is the common accepted way to organize code for Mac Application?
You can create your own controller classes, and put an instantiation of these controller classes between the app delegate or model objects, and your view objects. Just because there is no pre-built view controller class, does not mean that you can't make your own similar partition, by creating custom controller classes of your own, as needed.
I am trying to make a simple app from a tutorial that does not have a viewController at all. All the code is in the AppDelegate. I am on xcode 4.2 and I am getting this error:
Applications are expected to have a root view controller at the end of application launch
I'm not sure how to deal with this. There are some blogs out there with fixes but none of them are working for me and I really would like to understand what is going on here. And, how to fix it.
I do have a view that contains some buttons and labels. But I have no "ViewController". The files contained in my project are: AppDelegate.h, AppDelegate.m, and Window.xib only. There is no ViewController.h, ViewController.m
** edit **
I ended up making the app from a 'view based application' instead and just moving all the logic from the app delegate to the view controller. So, I didn't really solve the problem per se. The app works now though. Thanks for the help
It's not possible to have an iOS app that doesn't have a view controller. You can always create a trivial view controller, i.e.,
[[UIWindow alloc] initWithFrame:UIScreen.mainScreen.bounds].rootViewController =
[[[UIViewController alloc] init] autorelease];
It sounds like you're looking at an old tutorial. UIWindow got a rooViewController property in iOS4. I believe it became required in iOS5 to help keep controller hierarchies and view hierarchies in sync with the addition of custom container controllers (and to fix a corner case where replacing the "root controller" of a UIWindow could stop orientation changes from propagating). There was a WWDC presentation in 2011 that explained this in some detail. I think it was Session 102, Implementing UIViewController Containment.
At then end of the day, there's no good reason not to have a root view controller. Apple wants to be able to assume it's there in their APIs going forward. If the tutorial you're looking at doesn't account for that, it's broken.
While I agree that there may be workarounds, another question to address is: why do you want an app without a view? Even if it's designed to run in the background and present no visual interface, at least make a simple view showing the application name and version, a largeish icon and perhaps a status. This kind of idle screen uses very little system resources, especially when the app is backgrounded, but improves the overall experience of the app.
If you set your deployment target to 4.3 and run on the iPhone 4.3 simulator, you won't get the warning.
To install the iOS 4.3 simulator, go to Xcode > Preferences > Downloads.
I'm coding my first app in XCode 4.2 supporting iOS 4.x through the current releases. To support iOS 4.0, I'm not using Storyboard feature and also using unsafe_unretained for weak references. I have AppDelegate files (.h and .m) along with several view controllers with UITabBarController. In my first view controller, in the -viewDidLoad method, I initialize two NSDictionaries and also start a timer with 1 sec interval. In the selector method, I have to pickup a random number between 0 and 7 to pick a corresponding value in both the dictionaries. The dictionaries are used only in the first view controller and not anywhere.
My first question is
where do I load those two dictionaries - in the AppDelegate -didFinishLaunchingWithOptions: method or in the first view controller's -viewDidLoad method?
I also wanted to support iPad. If that's the case, do I create a common class library to support iPhone/iPod/iPad?. If that is the recommended way, can I move the common functionality to the AppDelegate .m file instead?
Please advise.
You can move your common data and business logic into a separate set of model classes outside of the UI layers and appdelegates. This is one of the main benefits of the MVC pattern - by separating and making a clear distinction, it's easy to have separate view layers (one for phone and one for iPad).
That means all the data (dictionaries), logic with your random numbers and timers would be encapsulated and shared. That also allows you to cleanly unit test the majority model and logic programmatically. It also means you can make substantial changes to your algorithms and minimize the code churn.
When the timer goes off it can either post a notification or you can have a delegate pattern where it does a call back.
Related Post: Delegates vs. events in Cocoa Touch
If you do a shared model, one option is to use a singleton pattern where you access the model like:
[MyModel sharedInstance];
You should keep your code and data together if possible, which means that if you only access the dictionaries in your view controller then you should initialize them in the view controller's viewDidLoad.
I recommend keeping stuff out of the app delegate if possible or else you'll end up with a weird monster class that does too much stuff for which it shouldn't be responsible. If necessary, create one or more classes that manage common data (for example using the singleton pattern).
Whether you can/should use a common file for both iPhone and iPad depends on a number of factors. The main factor is: how different are the UIs? If they are very similar then use one class for both. You can also create a base class with common functionality and sub classes for iPhone and iPad which implement the necessary differences.