I am fairly new to swift and iOS programming, and I've been watching video tutorials of people making things visible and not visible. When it comes to large scale projects I am start to doubt that they have one million features toggling between visible and not visible on the tiny screen.
So my question is, is I am making a tiny app how do I transition from basic view such as logging into a game and changing the login view to actually ingame. How do these type of things work?
What you're asking is the basics of programming on Apple platforms. This can't be simply explained in a single answer. Please, start reading this tutorial from Apple to get the understanding of the MVC concept and storyboards.
In short. You use the storyboard in Xcode to build your screens. Each screen is a scene in your program and represents a view controller. The view controller organizes how data is displayed on a screen and how to react to user input. You can create view controllers in code in Xcode and link these to the scenes (that are also view controllers) in the storyboard. In the code you can program the behavior of the different views that you put in each scene. Moving from onze scene to another is done with segues.
A segue can be made programmatically, you drag iT from onze view controller to the other. Or, in the storyboard boy dragging it from, e.g., from a button to the next view controller. You give the segue na identificeren and in prepare for segue (a method) you can program what data needs to be transferred from the existing to the destination view controller.
Related
I am trying to figure out how to create a "Now Playing" view similar to the one in the Music app and the Spotify app.
Here are a few images of what I'm trying to re-create:
Creating the view is not the problem. The part I'm having trouble with is how to keep the view on the screen at the bottom with the now playing information on it, but then when clicked, flicked, or swiped up, make it show like a modal.
Is this something that can be set up in Storyboard, or is it completely custom? How would you set this up?
Thank you in advanced for the help.
My guess is for Spotify it's custom as their implementation predates storyboards being... I'll use the term "friendly" to 3rd party developers.
However if you're building with the latest Xcode and iOS SDK this should be fairly easy to accomplish by building a container view controller wherein the child view would be everything in the upper quadrant, and you would effectively make that parent viewcontroller (with the now playing view area on the bottom) the root view controller.
As for the flicking / tapping, that's probably just a typical gesture recognizer that loads a modal. I can't recall if Apple's implementation is panning, but Spotify's is. My guess with them is as you as you tap down they load a new VC that's mostly obscured off screen and that's what actually gets panned in.
I'm building an app with an MKMapView as background, and I would like to have a "slide-up/down"-view, just like in Google Maps or Spotify (example.gif), that can be dismissed by dragging it down.
The 'slide-up/down-view' will hold quite a lot of info, including a UITableView, so I would probably like it to have its own ViewController, instead of just a UIView alone. What could be a good approach for this?
Is it possible "just" to add a childViewController/ContainerView and give it a UIPanGestureRecognizer? All help is appreciated!
These view controller transitions are, sigh, unfortunately very complicated to do but there are lots of good tutorials online about them. You are correct in putting the subview into its own view controller. There are several other moving parts required. Fully detailing them would be enough material to write a book on the topic, but the high level overview is this:
Chapter 1: The Container
Think of the view controller with the map view as view controller A. Think of the slide-up/down view as view controller B. We want to transition seamlessly from A to B (and B to A). Cocoa provides an API for doing this, but first you'll need a container view controller that contains both A and B as a child view controller. This could be a navigation controller or your own custom container controller.
Chapter 2: Noninteractive Custom Container View Controller Transition
Once you have the container view controller, code it up so that you can go from A to B and back by pressing a button. (Throw a debug button somewhere into your app.) So you tap a button and you go from A to B and then you tap it again to go from B to A. To do this, there are the noninteractive custom container view controller transition APIs (it's a mouthful). This will require implementing an animation controller and a transitioning delegate, as detailed in that excellent objc.io tutorial and its corresponding GitHub repository.
Chapter 3: Interactive Custom Container View Controller Transition
But, of course, you want users to swipe up and down to trigger the transition. This will take you into the world of interactive blah blah blah APIs, where you implement an interaction controller and connect it to a pan gesture recognizer. The corresponding GitHub repository to that blog post actually uses a pan gesture like you would. This is particularly finicky work, as you would want the transition to be canceled should the user decide to stop panning midway through, but all that is detailed in the code and article.
Chapter 4: View Sharing
I'm actually not sure what this is called. The problem here is that you want the Google Maps / Spotify look and feel where a part of view controller B's view actually is visible while you're in view controller A. And the pan gesture recognizer is attached to B's view so that when you slide it up, B's view gets bigger and bigger until the interactive animation finishes and you've transitioned from A to B. Is there a good tutorial on this? I haven't found one, but it's becoming more and more common as an iOS UX idiom.
I myself have a small demo project illustrating how to do this. What I do is I have a navigation controller as my container view controller. The navigation controller's root view controller is my home view controller (view controller A). In view controller, I have view controller B as a child. So that's navigation controller owns A owns B.
When the user taps on B, I push B onto the navigation stack, thus reparenting it. At that point, my noninteractive animation controller kicks in as a custom navigation controller push animation. And so it looks like B is smoothly transmogrifying from its small bounds to its larger bounds. (I recommend running the xcodeproj to see the effect as I have done a terrible job of describing it.)
This technique would work just as well for an interactive animation. As to whether it's the best technique, I think that's up for debate — there are lots of ways of doing what you see in the Google Maps and Spotify apps. Apple could certainly do a lot better job of documenting the APIs for complex, interactive animations.
I would caution you to avoid using Auto Layout until you have your animations tweaked and ready, as it doesn't really interact well with your animation controllers. Good ol' frame rectangle math is best here until you find your bearings. Auto Layout is magic and, as you might be able to tell from how exhaustingly long this answer is, there's already enough magic to go around.
See Also
Session 803 from WWDC 2015: Designing with Animation
Session 214 from WWDC 2014: View Controller Advancements
Session 218 from WWDC 2013: Custom Transitions Using View Controllers
You can click on the purple Apple logo in the top right of asciiwwdc.com pages to watch the videos of the talks or grab the PDFs from the Resources tabs. Some of the best documentation for iOS is locked up in these WWDC talks.
I am creating my application without using StoryBoard, basically creating Widgets (UIViews) and adding them to my rootController.view
self.view.addSubview(view)
My question is fairly basic, but I would like to have some guidance in it. How do I bring up a new activity (as in Android) programmatically and have its rootViewController set to an object of a different UIViewController.
Is the concept of a window the same as an activity (in Android)?
How can I make the new window/activity slide in from the right, say when a button is clicked?
p.s I am building this application in Swift.
So, I haven't done much Android development, only some small projects. I have done quite a bit of iOS development though. While the concepts are similar, they are not exactly the same.
The piece of code you posted where you add a subview to your existing superview (current view controller) will not get you the effect you're looking for. What you want to do is push your next view controller on to the screen.
self.navigationController?.pushViewController(yourNewVC, animated: true)
This will give the effect of sliding the view controller being pushed in from the right as you described.
Window is not activity.
ViewControllers are activity.
You can push or present new view controller to go to new activity (viewcontroller)
You can see here how can you push or present view controller.
I'm trying to build an app that has lots of similarities to the Facebook App in terms of the "Storyboard". I'm tempted to do everything in code as I know best but I'd really like to figure out how to storyboard these more complicated UI's.
The Facebook App starts with a login view. When you log in, you get a tab view. In the main tab view, you have a table view. Within each table view are a user, post, and comment buttons which push to a new view.
So the way I am understanding it is we have UINavigationController with the .navigationBarHidden set to false. The first view controller here is the loginViewController. When the login button is pressed and the user is logged in, we performSegueWithIdentifier to a UITabBarController. The first tab is a UINavigationController with a UITableViewController as the first view controller. Clicking user, post, or comment pushes the appropriate view controller onto the NavigationController.
This all begins to seems a bit more complicated than just writing this all out in code. I'm also not even sure this implementation is correct with all these nested view controllers. I'm not sure this is all possible with storyboard as well: for example a navigation controller for pushing to comment, user, or post views doesn't seem possible with storyboard.
I'd like to know the correct way of implementing this kind of UI design. And should / could this be implemented using Storyboards?
Your design team may layout the app using a "storyboard" (physical objects -- not the digital version). Large apps are hard to piece all the little things together on a storyboard. Just too many wires going every which way.
Look at the FB app without internet access and you can see their basic building blocks easier. Its built in units (post at a time) that are added to a scrolled view. Search bar and menus at the top and buttons at the bottom with the scrolled view in the middle. The posts probably have some common base class with various types derived from it (picture, video, links, etc).
There is some sort of background process monitoring the position of the scroll view to dynamically load new stories if you get down within 1/3 of the way to the bottom. Within each post you can see the components if you look closely and think about what sort of block that is.
I am a beginner at best when it comes to xcode, iOS, and objective-c. I have been working on a project that has had me looking up information a lot. I have already been learning a lot, but I realized lately that I have forming some bad practices.
I have used Storyboard to lay out the abstract view of the app. The first thing I noticed I was doing dealt with popover views for iPad. I did not know how to dismiss them via button press, so I was creating a new modal segue from the popover button back to the main view.
I realized that this was creating a new view and placing it over my existing view. This would start to chain until the program eventually crashed. Last night I learned the importance of delegates and how they can help me gracefully dismiss the popover view.
Based on the documentation I have read for modal views, it appears that I need to be dismissing those types of views as well.
My question regards to proper practice when building an app. What if I have a ViewController that has 10 buttons, each of which will spawn a popover that is similar yet features slightly different content. Is it OK to create 10 new views in storyboard and drag and drop the UI elements on there? This means that the main view controller is going to have 10 delegates, one for each.
OR would it be best to create one general view, load the content dynamically, and only worry about one delegate in the presenting view controller?
EDIT: As far as the differences between them, they each have a list of labels (questions) and a UISegmentedControl to match the label. This will allow the user to fill out a survey. There are currently 10 views because I have 10 sets of questions that I feel deserve different views. At the bottom of each view there are 4 buttons. Every view must include these 4 buttons.
It's "ok" but not practical to have those 10+ delegates. If these ViewControllers only differ slightly - have you considered creating a "base" view controller and then adding/updating some of the differences programmatically depending on the content? I think it all depends on what you want to display and how much these differ. I would definitely not recommend 10+ delegates all delegating back to the same controller.
Basically, I'm saying yes to your "OR" question.