Here image from AliExpress iphone app.Kindly view this first
I had to implement it. Now that i have implemented the custom segmented control programmatically(not the default segmented control interface builder component), i am unable to perform some action once it's clicked. The situation is: As i posted below, i have that code in a class. and i have two container views linked to another class. What i want is that once i click these, the container views data gets changed. I have implementing it by creating instance of other class and accessing the methods but i am getting nil value errors and app is crashing. Can you please tell me how to do that? I can't directly link those as outlets to containers views classes as they are not interface components but programmatically implemented segmented controls.
Please help. thanks
The answer is that you are looking for a segmented control using containers.
Related
I'm working on a Dialog for my iOS app, and have decided that the default boxes don't allow for the level of customization I am looking for.
So, I have created a view inside a storyboard. It is embedded in a view called DialogBoxView inside DialogLayout.storyboard with a view controller called DialogLayoutViewController.
In short, I want to be able to open the specific view as a Dialog. (Like this below.)
But, as previously mentioned, I want the View inside the Storyboard to inflate as the dialog's layout.
What I need is a way to call into the ViewController handling the Storyboard [I can do this] and open the specific DialogBoxView inside.
See:
My Hierarchy
See:
My Layout
Please note that I have browsed around a bit on Google, and nothing is useful. It is either outdated (OBJ-C) or not what I really need.
Additionally, is it possible just to (like in Android/Java) "inflate" the View layout as the Dialog's view?
Summary:
Can anyone give me an example on how to inflate a specific view (inside a Storyboard) as the dialog programmatically from the ViewController?
I'm still kinda new to Swift and iOS development in general, and I have come across some functions that may work, I just can't put them together in a way that actually works.
NOTE: I have found a way around custom layouts, but am still curious as to how this might work.
Swift 5
Some time ago, I created one project similar: You can see in: https://github.com/MaatheusGois/custom-alert
I actually just posted, but I am re-asking to give a better concept.
I'm trying to use a segmented control change through multiple views inside a container view. I'm also not sure how to embed multiple views inside the container view. I saw a tutorial how to do it in Objective-C, but I am coding in Swift.
This is a perfect example of what I'm looking for. There is a UITabBarController on the bottom, but there is a segmented control to alter between "Tweets" "Photos" and "Favorites." How could I achieve this?
Thanks in advance!!
I'm assuming you have a collection view or table view or something below the segmented control. If that's the case, I've had good luck using the segmented control to switch data sources (and delegates, if necessary) for the collection. If you just have views, you can use the segmented control to show one and hide the others.
Do you have any code or more specific questions?
I'm a beginner programmer and could do with as many 'pointers' as possible (or not!) :/
Just wondering if anyone can give me some guidelines on when controls, etc., added via the interface builder to your storyboard in Xcode 6, need to be connected to in your code?
I guess I'm looking for some general, and more specific, guidelines on what exactly you do in interface builder needs to be qualified in your code?
If there is something you do in the interface builder that you need to tell your code?
I know there is a lot but I am just looking for a kind of summary overview I think.
If you need to get or change the property of some object you made in IB, then you should make an IBOutlet to it.
If you have a control (button, switch, slider, etc.) that sends an action method, you should connect it to an IBAction in your code. You don't need to do this if you connect a segue up from a control since the segue is executed by touching the control (a button or cell generally).
You don't need to connect a view with the code, if you're not accessing it. For instance, some views might just be containers to hold other views, so you might not need to do anything with them.
There are exceptions to these generalizations of course. You could make an IBOutlet to a button, and add its action and target in code, but that's not generally how you would do it (except for buttons in table view or collection view cells, where this technique is quite common). You can also access views by their tag (with viewWithTag:), so it's not an absolute necessity to have an IBOutlet to access a view, though generally it would be better to have one.
I have noticed the UI Component in XCode: Container View.
Based on the description provided I would like to make use of it to display a reusable component of my app in several different screens. I have been looking around online to try and find a basic tutorial or some documentation on it, however I havent found anything of use.
Please could someone advise on how to wire this up and make use of it? At the moment it also appears that the container view doesn't seem to resize which is problematic. Any tips on how to enable this would be appreciated too.
Cheers.
Well let's break this into some simple steps:
Drag a container view to the main view of one of your controllers. When you drag the container view, IB will create an embed segue for you and you can resize the container's view by dragging the resize control points as usual. Any changes in the size will be automatically reflected to the view that the segue is pointing to. The idea is that this view will be managed by a different controller, the embedded one.
Set your custom subclass as the class of the embedded controller.
Now you're good to go. Note that any containers you add will be available through the childViewControllers property on your main controller.
This is obviously an oversimplified workflow but it's enough to get you started. For more information on the subject, see Apple's documentation here.
I have a UIView subclass which contains some labels, a tableview, and a few other bits an pieces. It is currently the delegate and datasource for the tableview, and also manages many UI actions, none of which rely on data. For example, when an 'edit' button is pressed, it knows how to update its controls, but it won't do anything when 'save' is pressed besides switch the controls back to the previous state. All of this is done in code, I'm not using IB at all in this application.
I now want to plumb in all the data model changes that it can provoke. But I would like to put these in a new controller class, which I guess is the MVC compliant way to do things. I'm not sure how to get there.
First, I need to create a custom controller class. Should I be exposing from the UIView subclass a few of the controls so that the view controller can access them? For example, I will need to read and write to a textfield in the view, so should I provide a getter/setter for this?
Secondly, the tableview - instead of the UIView being the delegate, should I expose this also, and make the view controller the delegate? I.e. view.tableView.delegate = self from the UIViewController?
And finally, how do I launch the view from another view? Specifically, this is a paged scrollview application similar to the weather app, so I have a mainView UIView that specifies the single paged scrollview and then adds multiple custom UIViews, one for each page. How do I replace [scrollView addSubview:myCustomView] and instead add the viewController? And how do I connect the view to it's controller and vice versa?
I've not tried all of this without IB before so thanks for helping.
Your question is very broad, and part of the answer would depend on how you code your solution. I will try replying with a few hints of what works for me:
View: As a general rule of thumb, keep in mind that a view object should be something very generic, that knows nothing about other views outside of its own hierarchy. As such, a view should not rely on any specific interaction with other views, but rather communicate back to its delegate / owner / creator through callbacks, protocols, blocks, etc, when needed.
View Controller: Any time you need to make two views in different hierarchies interact with one another, my suggestion is that you stick to handling that interaction through the view controller. By doing so, you'd be making sure your view is not contaminated by code that would be useless in a different screen.
Also please keep in mind that UIViewController for iOS is intended to be a class that you use for handling the complete visible view hierarchy, as opposed to acting as the controller for a single view. As such, I recommend that you don't attempt have a controller for each view, but rather a single one to handle them all.
Publishing view elements: How much a UIView exposes as public in its header file is up to your implementation. Any method that handles the way the view looks, that looks to be generic and reusable, and that doesn't need anything from outside the scope of the view's tree, is surely something you want to include in it's implementation and publish in the header file.
The same goes for any property that you feel is highly probable that someone from the outside will need to access.
Suggestion: publish only what's really needed. Usually publishing new methods and properties is easier than removing them later on.