I'm trying to develop a universal iOS app and ideally I'm trying to get as much code re-use as possible.
I'm using storyboards so the UI is segmented into scenes.
In the iPhone storyboard the particular scene in question is best suited to a table view.
In the iPad storyboard, the equivalent scene in the storyboard would ideally implement a UICollectionView and so render the content in a grid.
Both views should implement a pull-to-refresh control which in one case is going to call a [UITableView reloadData] and in the other a [UICollectionView reloadData].
Anybody any advice on how to get the maximum amount of code re-use, ie. what does the controller class look like?
1 option would be to have 1 monolithic class that conforms to both the UITableView protocols and the UICollectionView protocols but this doesn't feel right.
Another option would be to have a base class and then subclass it with specialisations for iPhone and iPad. Whilst this feels cleaner, I'm still thinking there might be a better way. In my first attempt at this it felt like there was more code in the specialisation classes than there was in the base class.
The third plan I've considered is simply to use a UICollectionView in both apps therefore eliminating the complexity of the controller. Hopefully I could force the layout of the collection view to be a grid on the iPad whilst tell it to mimic a table view on the iPhone.
Whilst on the face of it this sounds easy I'm struggling to make a UICollectionView work exactly like a table view would do normally.
Any advice guys?
Many thanks,
CA.
If you are not using some of the specific UITableView features[1], making UICollectionView look exactly like a table is trivial. I think I would go for using UICollectionView as it will allow more flexibility in the future and you will have to use it anyways.
When you are talking about code reuse you probably mean the DRY principle. It just says you should not write the same code or the same information twice, but I don't think this is your main issue here.
I would use a UITableViewController on the iPhone and a UICollectionViewController on the iPad. I think this is the cleanest and easiest way to go. What exactly do you hope to reuse among both controllers? The both require two different delegate protocols, so most of the methods will be specific to one platform. You will need two NSFetchedResultsController if you're using Core Data, but reusing the fetched results controller code only makes sense if you need the same data on both platforms.
If you create a new universal project in Xcode you will get a basic project setup that looks different on iPhone and iPad. Try to understand it (there are some details to pay attention to) before you start programming, I think it will answer at least some of your questions.
Related
I'm trying to understand how to properly implement MVC in swift. Heres my scenario:
I have a signup page with 9 UITextFields, and they're all being made programmatically, and therefore being anchored to the view programmatically. As you can imagine this would be a lot of repetitive code to have in the SignupViewController class file.
Is the convention when following MVC to keep the setup of these text fields in the SignupViewController file, or are you supposed to have a separate file such as SignupView that contains all the text field setup code?
Even though UIViewController has the word "controller" in it, I believe the majority of iOS devs these days assign the UIViewController to the "View" side of MVC. The UIViewController is chiefly specific to a particular view only, plus may manage its subviews as well (until this gets too messy and a container view is added to allow for a nested UIViewController).
In MVC on iOS, the view controller can easily become polluted with business logic, model management, etc... which is why many people jokingly refer to "MVC" in iOS as "Massive View Controller". To combat this, consider using an MVVM architecture instead, which not only keeps the VCs small, but also moves the business logic out to a separate "sidecar" coupled to that ViewController, called a ViewModel. This allows the business logic to be unit tested without any UI involved, making testing much more reliable and easier to read and maintain. With that said, the creation of these 9 controls would still belong in the ViewController.
As for programmatically adding UITextFields to your view vs viewController, if this is to be done just for this single scene, then I'd stick it into the viewController. If you expect to want to reuse the set of them in other scenes, then making a custom view or control containing them would be better, like is typically done for custom cells of a table.
Finally, consider simply using a Nib or Storyboard to layout your scene. Apple has provided so much power to layout and maintain scenes via nibs and storyboards that you're really missing out to go the programmatic route. I find it very rare that I side with programmatic approach. The auto-layout warnings in InterfaceBuilder alone are worth gold to me, and as Apple continues to raise the bar and change layout rules, I can't imagine trying to keep up programmatically when I can't afford to test every device and iOS version combination. And yes, it's possible to do MVVM with dependency injection and storyboards. I do it daily.
Answer to your question is that it has nothing to do with MVC .
AS iOS/Mac developers, we use Interface builder and auto_layout to achieve most UI #IBOUtlet/ #IBAction. This is the V side of MVC.
Typically, If you have data, database, json or whatever formats, you need to model them and handle logics. That'M of MVC.
The C(Controller) side of MVC is a kind of glue between M and V. In most cases of mobile , you can think Controllers are all C you need.
So controller class is the only portion you need to put code to simplify everything.
In your case, 9 UITextfields should be ideally put into V side job. Please don't write code for them unless there is no better way to do.
I don't agree with above statement about using Interface Builder... I prefer to write most of my views in code and also set the anchors that way as well.
to minimize the file you can create an extension of the ViewController in a separate file to contain all of this code.
so for SignupViewController you would create a new file called SignupViewController+SetupUI.swift.
import UIKit
extension SignupViewController {
// add your setup methods here
// as just an FYI you can call the methods you create from your
// SignupViewController file just like you would any other method.
}
you can read more about extensions here.
After reading about good practices to write maintainable and readable code you should do the whole design in interface builder. If you get good understanding of constraints you don't need to write any code to setup design in your view controller. The ViewController.swift file should not be used to fetch-handle data or to setup the UI. It should just be responsible to display and update values which are fetched and get handled in a separate ViewControllerDatasource.swift file. So to sum up, view controller does not have any logic implemented it just handles the show data and the design updates(not setup). I hope i helped you with your question.
I know this is a question that has been asked quite a bit, but it's iOS 9 and I still don't have a clear idea about what to do. For starters, here is what I seem to be surmising from all the data available:
Storyboards let you create segues. [I've never been a big fan of this answer because segues are often the least harrowing part of creating the UI layout for me.]
Xibs can let you create multiple top-level views. (Storyboards vs. the old XIB way) [I don't think I've ever used this much, though it seems rather helpful.]
Storyboards - Creating UITableViewCells is easier. [In my opinion, it's cleaner to create xibs for the cells and just invoke them in cellForRowAtIndexPath].
Storyboards can turn into one giant ultramassive file that is hard to edit. [I've seen this happen in practice and it is a big drawback, but at the same time...]
Storyboards let you arrange all your Views in one place with the layout shown as well. [This seems to be a big help for me. But then, over the years I've found doing this in code much easier. Which brings me to my final question.]
What is the performance aspect of both of these two things. My app is essentially the following :
A top level hierarchy of interconnected view controllers, not more than 5.
A large number of disparate, independent view controllers that range from Scroll Views to TableViews to static Imageviews.
Autolayout, size classes, the works.
For each of these view controllers, what is the performance of creating a storyboard for each of them vs. creating a xib for each of them. More importantly, what would be a good way to lay out an app like the one I've mentioned.
You definitely want to use storyboards for laying out view controllers - simply because you get access to topLayoutGuide and bottomLayoutGuide which the XIB editor won't give you.
For other views, it's a matter of preference. I tend to use XIBs for table view cells simply because I tend to reuse them on different screens and prefer to have them in their own files.
I would actually advise against manually writing view code where possible simply because it's much harder to read and work out how views are laid out, especially for developers who didn't write the code originally! For simple, dynamically sized things this can be fine, but if you're trying to lay out view controllers with different constraints depending on the size class it's going to end up a bit of a mess.
Yes, it's a pain to deal with merge conflicts of these files, but with iOS 9 you can split up view controllers into different storyboards a lot more easily using view controller references. Personally I find the inconvenience of merging storyboards/XIBs the lesser evil of having to write everything in code.
It sounds like a Storyboard is the right thing for your current project. However, my experience has been that Xibs and Storyboards are problematic in the real world, for these reasons:
extremely idiosyncratic from developer to developer, so it is tricky to build good storyboards as a team
black boxes, so they require a tremendous amount of knowledge to master (unbelievable amount of hidden behavior). Only the most superficial semantics are covered in the documentation.
internationalization is made much harder by being split up, especially if you have internationalized messages not contained in the Storyboard/Xib.
backwards compatibility breaks annually / deprecation guaranteed over time. This is especially difficult if you try to maintain compatibility with older devices.
As soon as more than two devs started touching our code we rewrote everything to avoid Storyboards and Xibs altogether, and we became much more productive.
If you have to deal with any of those real world situations, I heartily recommend programmatically creating all of your views. There is even an app that makes this easier (and is way more scalable). I have no relationship with this company or product, but it is hands down a better solution.
http://www.paintcodeapp.com/
I have to implement the layout of a single screen, which is not connected to the overall app flow, and I was wondering if it makes sense to use a Storyboard.
Storyboards make sense for flow/navigation (multiple controller), have some convenient features like, iirc prototype cells which are not available in xib. And it also makes sense if I think maybe later the screen may become a "story" (more view controllers). But none of this advantages are useful for my particular case.
I was thinking anyways in using Storyboard, as it seems to be a bit more flexible than xib generally, but is there any disadvantage? Maybe performance penalty or such? Is there a preferred way to setup single view controller?
Go ahead..take the advantages of using storyboard. There is no disadvantages or performance issues particular to storyboards when compared to xib files. Its all about your convenience. As you said the single view controller may become a story in future, then the storyboard would be a right decision. And when to use xib? thats upto you, one ideal situation where i will choose xib is, if i have an independent controller that i want to share with other project also then i would choose xib.
The performance penalty would only bother under the circumstance which too many controllers (more than 10) with segues were squeezed in one Storyboard. Everything would be totally fine before that.
And if you have more than two people are trying to edit same storyboard file than you have to resolve conflict, which will be more tedious job.
Storyboard benefits:
a. easy demo purpose and fast implementation.
b. small team like two person.
c. Storyboard is providing complete view and navigation model.
XIB benefits:
a. You can modularize your code.
b. More people can work on different-different controller without affecting your xib or code.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Currently we use Storyboard over xib in all projects. But in my view if you want to make reusable view (custom view or Tableview cell) which can be re-used in different view controllers, you must use xib files as in storyboard there is no way we can make single view object separately.
Note that I am using Storyboard for workflow (view controllers with segues all around) of entire application. Only for reusable tableview cells I am using XIB.
I have searched in lot of apple documents as well as WWDC videos but I could not find any concrete proof from Apple developers which says that XIBs are here to stay or you should use XIB for custom views.
If any of you guys have any kind of links which gives somewhat confidence that we can still use XIB without fear of apple removing it, it would really be appreciated.
Storyboards are recommended when you don't reuse views.
Once you want to reuse something in multiple views/storyboards, then you need XIBs. You already mentioned the example of custom cells. That is something I need quite often and I want to use the same cell in multiple table views. I do the same with charts. I create a chart view in which I set colors etc. and I reuse it everywhere, only putting different data in it. This saves me a lot of code in respect to style/appearance and makes the app easily maintainable. In case of change (e.g. because of new iOS version), I need to change everything on a single place.
Furthermore, I want to have views (e.g. cells) for iPhone and iPad and let the system determine which one to use. For this, again, I need XIBs. I use the notation with ~iphone or ~ipad at the end and I don't have to write code for retrieving the correct view.
This are two things that you simply cannot do without XIBs. So, following the Apple guidelines, my approach is to use storyboards whenever possible and XIBs only when I need them (mainly because of reusability). But there are real cases when one needs XIBs! Simply ignoring them is not a good practice for sure. Actually, in each project I have storyboards as well as XIBs.
Edit: I just found a great post explaining the disadvantages of storyboards. There are plenty of things that I was not aware of.
Also, you don't have to use either exclusively. You can still use XIB files even if most of your work is in storyboard. And using either also doesn't restrict you from creating a view that isn't built in IB at all.
Storyboard has plenty, plenty of advantages. Particularly when you start bringing new people in on the project. Without getting engulfed looking at hundreds of thousands of lines of code, a new developer can look at the storyboard and in 30 minutes or less get a quite good idea of the flow of the app.
With that said, you should never limit yourself to anything. Limiting yourself to just storyboard and never using XIB or building a view completely in code is like saying "We're only going to use NSArrays, and never NSDictionary or NSSet". Instead of a silly limitation, you should always just be sure you're using the right tool for the job.
My opinion is use which one is appropriate for that context, here is some guidelines:
When to use nibs
Modularity is key to well designed nib files
Use nibs to store views, subviews, custom controls or repeated views
There’s no way to represent the relationship between screens of related content
When to use Storyboards
Storyboards are best used to represent screens of content and the connections between those screens
Give due care and attention to the prepareForSegue:sender: method
Modularity is still applicable when designing storyboards
General Guidlines
Decompose your projects into nibs and storyboards
Views, subviews and custom controls should be contained within separate nib files
Use storyboards when designing full screen content and there are clear relationships between scenes
Consider whether the interface needs to be static or dynamic
Use separate storyboards to encapsulate reusable sequences of scenes
Use separate storyboards for unrelated scenes
Table view cells that can be reused across different controllers belong in nib files
I am working on a project where I need to display information in a similar fashion as the well known Calendar apps from Apple do.
I'm trying to figure out whether I should use an UICollectionView or a UITableView as a base class.
Which one is better fit for the task, why? Possible alternatives?
You can achieve similar look with UICollectionView with a custom layout. There's a great example, matching your target, in Custom Collection View Layouts at objc.io.