So far I came across many developers are using Custom view controllers instead of .xib file often. Can anyone tell me that which one is the best way? using custom or static?
It's your wish, use what ever you feel is easy for you. I prefer custom , because it gives me much more freedom to play with my custom views. Yes it is much more laborious , but you have more control over it(what i personally feel).
It would be great if you elaborate your question...
here is a small example where i used custom. The data to create views (like textfields , buttons etc) was being provided to me in form of XML (from server). So this XML can be changed any time at server end. which means if my view is rendering 3 textfields today, on changing xml it shows 10 textfields. So if your view is not static or fixed, you should use custom method.
In IN SHORT - fixed or static view -use xib (you can use custom also). in case of dynamic,you can (should) do it programmatically.
if you are designing UI with code (not using Xib/Stotyboard) this will be good when you create UI dynamically so then you need not to spend more time on changes. what ever we use for development (Code/Xib/Storyboard) nothing will be changed in performance. As per user/developer comfort we will go for it. Suppose there are lot of UI need to be displayed few at the time viewdidload and rest after some button action then usually at the initially stage itself Xib and Story board will load all of them and hides un wanted and as per actions it will show the hidden UI. i feel coding is better for me.
Related
I am making modifications to an existing iPad application, and I'm having a hard time dealing with really messy scenes in storyboards. Almost every scene in the app consists of multiple views laid one on top of the other, each containing a different set of controls. Depending on the situation or data coming into the scene, some views are hidden, and others are shown.
It takes a LOT of time to decipher such scenes, and even when I figure out what changes I need to make it's terribly difficult to make those changes, and easy to screw up other things.
As an example, the following scene has 3 views that could appear (Start View, End View, Drawer History), depending on the situation, and they are all laid out on top of each other...
This seems like a terrible way to handle this, and I'm having a hard time believing this is standard practice, but I'm not finding much in the way of alternatives. I find very little in the way of questions where people are dealing with this problem, and the tutorials on how to design user interfaces seem to be too simplistic and never deal with scenes that are complex enough to run into this problem.
Unfortunately, this app is my primary introduction to doing user interfaces in iOS, so it has apparently become the default solution in my head. I've tried many tutorials, but they take a long time and don't seem to ever get to a situation that needs such a technique to solve it.
I would hope there would be a solution where each alternate view in the scene could be laid out on its own, and be made to appear within a placeholder view as needed.
What would be a more enlightened / more manageable approach?
That's what you'll get with Storyboards/Nibs/Xibs. I'm not saying coding your UI is better than using interface builder, but it is, at least for me. I believe, as far as I know, there's no other way to handle such multiple layers of views in one view controller in interface builder. I actually used to use interface builder before and that's how I add multiple layers of controls too. Sometimes some views are initially made hidden, but that would probably confused me or the other developer looking at the layout. Sometimes I extend the viewcontroller height to know that there's a view container with a constraint a thousand constant or a negative thousand constant to make it hidden and ready to animate when it's needed to be shown.
There are ways to somehow improve and organize your Storyboards. You can separate modules into different storyboard files; you can use references; avoid segues; and whatnot. It's still an individual or team's preferences.
Some ref:
https://cocoacasts.com/organizing-storyboards-with-storyboard-references
https://medium.com/#stasost/xcode-a-better-way-to-deal-with-storyboards-8b6a8b504c06
EDIT:
I'm thinking you could also layout separate view containers into a separate xibs, and then call them or layout them when needed. But that would add more files to your project.
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.
Thinking it over, this feels like a bit of a noob MVC question, but I can't come up with or find a definitive answer so I feel I should ask and get some clarity for myself.
I have a custom view that I created using a xib. It is going to be used in, currently, 4 other places in my app. Each usage has identical functionality, so I'm basically just creating a custom control object that I can reuse multiple times.
My "control object" consists of a UITextField, and two UIButtons.
The functionality I'm looking at implementing is, the first button will bring up a UIPicker and the 2nd button is essentially a done button and will just resignFirstResponder on the UITextField. As previously mentioned, this is consistent everywhere this will be used.
What I'm curious about is, is it ok for me to build this functionality directly into the custom UIView subclass since it is consistent behaviour for all instances of my control object? Or, do I need to create a custom UIViewController subclass to go along with it?
Currently, in my main UIViewController for my app I am creating instances of my custom UIView "control object" and treating them the same as any other control object. If I should actually be creating a custom UIViewController class to go along with it, well, I'll have more questions for another thread as to how I should be doing that (unless someone can direct me to a resource on this)
So far, searching the web has yielded nothing for me and from everything I've seen so far with iOS development in general, I've gotten the vibe that UIViewControllers are really only ever for a main, presentable view (that takes up the entire screen.. I might be missing some terminology for this).
My gut feeling is that no view controller is necessary in the scenario I'm describing, but I'd like to try to get some sort of confirmation, if possible.
There is no silver bullet, so no approach is absolutely right or absolutely wrong. What you describe here is just a view that changes its states. So putting everything in your UIView subclass is completely OK. It also conforms to the KISS principle.
However, as far as I understand, and correct me if I'm wrong, the input of your custom view - the text and the picked value from the picker does not really affects the view itself, but the viewController it's attached to. So you need to pass that input to the hosting viewController. This can be achieved by protocol with a default implementation. So the handling of the input data is written only once, but can be attached to whatever viewController you want.
Based off of everything that you've said, I see no need for another view controller. I can see where the answer could be a little unclear considering that the actions are something that ViewControllers usually handle, but I think you'll be just fine letting your custom view handle this by itself.
If you add more functionality or more complex operations, then perhaps it is time to explore other options but for now I think the single view will be fine.
I'm starting a new project and I have some doubts about storyboard good practices, specifically about optional hidden views (show only under certain circumstances).
Let's say you have an pdf downloader app, when the user select a download button a UIProgress bar appears and show the download progress. Should this progress bar be included in the storyboard or generated programmatically when the user press the download button?
It's a simple example but what about if there isn't only a UIProgressBar but also multiple hidden (optional) buttons? What if some of the buttons are overlapped? (I know overlapped button is bad design but just for the purpose of exemplify)
Should this ones be hidden or added programmatically? What about performance? Some say it takes more time to parse a Storyboard/Xib than a programmatically build view.
In DonaldKnuth's paper "Structured Programming With GoTo Statements", he wrote: "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
So, you are trying to solve a performance problem you do not really have (at the moment).
You decision to have a view permanently or temporarily should be based on context of the view usage, not some hearsay performance issues between xib/stb vs programmatic approach, that resembles platform-wars, but otherwise, given how LLVM compiler works today, and what the HW performance of iPhone 4 or higher is, is basically nonsense.
Here's a simple rule. Have all the views in IB, hide or unhide them as necessary, and add/remove a view programatically only if you can give a good reason why.
I understand you instinctive desire to make it right, so instead of trying to manage one milion views in one controller, take a look at the problem that is satirically called Massive View Controller.
Proper decomposition into custom views, separation of concerns, clearly defined responsibilities split into more view controllers, view controller containment, is the answer to to address your concerns.
You want your app first and foremost to work correctly.That you can achieve by having a sound architecture so that you will be able to stay in control. Users will not appreciate that you instantiated some button programatically, because they couldn't care less. But if the app has inconsistent state because your view controller has 7000 lines and is spaghetti hell or is crashing, that is a problem.
if you are planning to use storyboards; would suggest to have view/buttons etc included . you can always hide / unhide the same from the code.
have a thought process and not cluster your view. Have multiple views and make your app look neat
I am trying to write an iPad app with the basic purpose of form filling. I have 5 independent forms that I have designed in Interface Builder with each form having more than 50 UILabels and UITextFields along with a few Segmented controls in a UIScrollView (yes, its a really really long form). These forms need to be locally saved in the app itself which can later be emailed. After designing the forms I realised that creating IBOutlets for such a large number of different controls is going to be tedious and might also hamper the performance of the app. I am also worried about the complexity it will create in managing these outlets.
I am not sure if I have taken the right approach. Can anybody suggest me any alternatives. I am ready to start everything from scratch, all I need is a little guidance towards the right approach to solve this problem. I only need help with managing the input elements, the rest I can manage.
Any and all suggestions are welcome. Thank you very much.
There can be two kinds of UILabels and UITextFields.
1. Static/Fixed text inside.
2. Dynamic text.
You create outlets for dynamic values that changes at runtime. Or if you are implementing some thing from codes.
If you think 50 outlets are difficult to handle, you can create 5 separate controller classes for each forms, resulting in 10 outlets to handle in one controller class.