Is it possible to add MVC to an UIScrollView?
Currently i dragged three UIView's from the button category and put them inside the scroll view hierarchy, does the UIView's get stacked on top of each other instead of pushing them out on each side? I wrote some code but that did not do anything for now, for now i am wondering if it is possible to add MVC to the UIScrollView and how can i do that?
Swift language preferred.
note: i am new to xcode and would like to get some tips on where to learn some basics about different view controllers and using MKMapKit with GeoLocation if possible!
Related
I want to create a basic version of the slide out menus that apps like Barclays Bank and Facebook use, I don't want to use a pod that has already been created as it adds complexity to the project when new versions etc comes out (have to wait for the developer to update compatibility etc).
So I have the idea to present the menu view under the current on screen view and then slide the current view part way over which will expose the uiview that is under this.
This works fine however I have an issue and just trying to work out the best way around it....
When the top view slides over to expose the underneath view (menu) I also want to pass control to that exposed view so I can interact with it and not the top view?
Any ideas on best way to achieve this?
topViewController.view.userInteractionEnabled = false
Eventually sorted it, had to create a view controller that had a uiview and a container view, with the container view over the uiview. This allowed me to move the view over and still interface with the uiview as I want swapping view controllers on the nav stack.
my designer created this layout:
How can I mimic that on iOS? I tried creating a Segmented Control but didn't work well because it can't be customized after iOS7. So at the moment I'm thinking about a UIPageControl with custom dots like explained here: Customize dot with image of UIPageControl at index 0 of UIPageControl
My problem is also with the concept. Segmented controls are said to be used to flatten/filter results according to iOS human guidelines while UIPageControl has actually different pages...
Is this the best approach? If so, can I make it look like the Android Tab bar?
Segmented control with custom image
UIPageControl with custom image
UITabBar on top (read too many bad things about this approach)
something else
If UIPageControl is indeed the best/correct/possible approach how can I make it look as close as the image? And also move it to the top?
Thanks!
Short answer: Don't do that. You're trying to implement Android controls on iOS. That leads to user confusion and an app that doesn't feel like a native app.
Instead, have your designer create a native app design for both platforms.
It looks to me like the closest analog to what you're trying to do is a tab bar and a tab bar controller (UITabBarController).
EDIT:
If you must implement this UI on iOS, you might have to roll your own. You'd create a new custom parent view controller with a child view controller that you could swap out, and a custom control that triggers the swapping. Conceptually it would be a lot like a tab bar controller.
You could probably set it up using a container view and an embed segue (The embedded view controller would be the starting child view controller) and then use the built-in support for managing child view controllers to swap out the child view controller when the user taps on your control. I've done this sort of thing before. It isn't that hard, and is pretty well documented.
Is it a good practise to creates views in xcode and hide them and when required show them?
I am asking that because I prefer to create views visually and not in code.
If the view is to complex(a lot of subviews) should I create a new view controller to it?
I know there isn't a specify question here but I really need a clarification on this matter.
Regards
One of my first iOS applications had a tab bar and views that the user could switch between. Originally it was done by hiding and showing the right views depending on what the user pressed on the tab bar. This ended up being a complex disaster.
I then rewrote the app so that each tab bar view had its own UIViewController with its own set of views. That turned out to be so much easier to manage. (I also changed from using Interface Builder to straight code for creating the views, but that's beside the point and you can continue to use IB if you want.)
As for me, I prefer folowing practice:
Usually, a use storyboards,where views are placed, but if a view is complex, I create a separate XIB file, arrange all subviews there, and then in storyboard drag an UIView subclass and connect my XIB view with it.It helps to avoid mess in storyboard.
As for hiding views, I also don't recommend such practice as it can become very complex to understand your code and all those views are allocated when XIB is loaded, so the mobile developing rule "do as lazy as u can" is not met. We should try to spend as less memory as it's possible.
UIView is the best way to create iOS app, esp. if you want to reuse the code.
For example if you have same view to present in iPad n iPhone then using UIView can result in lots of similar code in View-controller
In another case if your view might need to have multiple table view it can be quite complex to handle each with delegates in ViewController. But separate view will solve this problem.
I have made my 1st open source code after learning how to use View
https://github.com/bishalg/BGRadioList
which I had learned from
http://www.raywenderlich.com/1768/uiview-tutorial-for-ios-how-to-make-a-custom-uiview-in-ios-5-a-5-star-rating-view
About the hiding view - I have used lots of hide and show view codes in my apps but believe me at one point it will become complex and unmanageable if you have lots of views.
I am writing an iPad app in XCode 4 and would like to create a UISplitViewController instance that displays its viewController references horizontally on the screen. I have been referring to the XCode example provided by Apple (SplitViews) but that example uses a xib to embed two horizontal NSTextViews manually created by the developer.
Is there a way to force a split view to display horizontally using the standard XCode libraries? I've seen a few references to Matt Gemmell's MGSplitViewController class but I am wondering if this can be done using just XCode's standard libraries.
I've also read the thread concerning programmatic split views (here) but there is no mention of forcing the display to horizontal vs. vertical.
UISplitViewController splits the screen into left and right parts. There is no public API (as of iOS 6.1) to tell it to split into top and bottom parts.
You could embed the UISplitViewController's view in a custom view with a rotation transform, and then make each of the contained views use a rotation transform in the opposite direction. That would require you to implement some extra view controller subclasses (and maybe view subclasses). It would be much simpler to just use MGSplitViewController, or to implement your own split view controller.
I have a ViewController (with navigation) that needs to show 7 different content layouts. I want to keep the same background and nav, the only thing that needs to change is the central UIView.
If I have 7 different UIViews on the same xib/storyboard, can I hide the ones I'm not using or will that ding performance?
Using segues won't work either because they make a mess out of my custom navigation and animations.
Is there a better way to accomplish what I am trying to do? Thanks for suggestions
solution
My design is too custom for using view controller containment so I decided to mimic the idea with a custom UIViewController and two UIViews. It's not too bad and it works rather quickly.
You should look into using view controller containment, then you can load your views from separate nib files and still provide your custom navigation and animations from your container view controller.
Note: This is only really supported from iOS 5.
Generally, it's a good idea to unload views that aren't visible, however, if your views aren't using too much memory (and/or cpu time) hiding them when they're not in use should work fine.
View controller containment is probably what you should be doing if each view has its own unique functionality (i.e. view 1 is a map, view 2 shows some about text, view 3 is an image gallery). UITabBar might be useful, but it depends on your app.
The performance hit would depend on your views' contents. If you haven't done so already, invest some time into learning how to use Instruments (apple's diagnostic tool). Watching the video titled "Optimizing App Performance with Instruments" in the developer resources would be a good start.
My design is too custom for using view controller containment so I decided to mimic the idea with a custom UIViewController and two UIViews. It's not too bad and it works rather quickly.