I was wondering what would be the best configuration of view controllers and views for an app that I’ve been planning out. Conceptually, the way I would like to lay out the app is with an initial loader/browser view, likely with document thumbnails. When a user chooses to open one, a new view comes up that forms the main document-editing mode. The user can also choose to bring up a third view that contains an alternative document-editing mode.
I suppose this is very much like the way the Pages for iPad works, with first a row of document thumbnails to choose from, then the main word processing view, and accessible from a popover a third page setup view. Document browser view, and two document editing views.
Now, I can think of, and have been playing around with a few different set-ups, but in each case I can see problems that I’ll be running into later. So really, I’m looking for advice on a configuration that you think would keep things as neat and manageable as possible.
I hope this is not too open a question, and I would very much appreciate any answer.
Thank you,
I will probibly get shot in the head for making a suggeston like this, but I'll make it anyway:
In learning iOS programming, I spent a lot of time studying (as most people do - and as is taught by every tutorial on the planet) on how to use Navigation Views, and toolbars, and all the standard type views that assist in different types of navigation.
On the latest app I have been working on - I spent a lot of time and frustration trying to figure out how to best characterize what I was doing - and moreso trying to fit it into what the iOS frameworks would use to implement this stuff. Then (of course) I got stuck trying get things to do what they weren't supposed to - like when a navigation view wouldn't let me use the "back" button to jump out of the navigation herirarchy I'd set-up, etc.
In short - when I stopped worrying about the specifics of what all these different types of views and controllers were - and how they interacted and how I was supposed to do it - and started worrying about how I wanted my application to work - and working from a basis of generic views, custom toolbars, etc - the whole think made a whole lot more sense.
In my case, I liked the look-and-feel of the Mapquest app - and they way it dealt with toolbars that your could open and close from the top and bottom of the screen - which had buttons - which could switch to other views etc. So I started using "generic" views to implement this functionality - and the whole entire thing clicked together.
So in-short:
1 . I'd decide how you want it to look and what you want it to do
Use a third-party app as your inspiration, if needed
Decide when/where/if some of the "standard" practices apply - and use them where/when they do.
Have fun!
-BKG
Related
I am trying to get a wiki page to display on IOS. This is the first assignment in my 8-week course and I am completely lost. I have only worked with Java, Swift is a completely new language and I cant seem to find a starting point. My professor has only showed us how to bring objects into the view controller such as segmented control bars and buttons, but has not showed us how to implement code into program to interact with the objects.
I know this is a long shot, and I have exhausted all other options (even bought an IOS 9 book) but if anyone can provide a starting amount of code for me to see and work with I would be extremely grateful. I am not asking for the whole project, I just need to be able to see an example of some starting code that I can hopefully follow and progress with.
Project Details /
Project Example Images
From reading the instructions, it seems like you'll need to have a multi-component UIPickerView (this is a basic tutorial, you can use it to get the delegate methods used to interact with the pickerView, here's a more in depth tutorial) and definitely will need to use multiple UIViewControllers in order to achieve the desired result. Add BarButton Items to the bottom of the view, and control+drag on those to connect them to additional ViewControllers which can be used to select Plant/Animal Name, and to change the textColor.
On the initial viewContoller, you'll need a WKWebView above your imageView, learn more about their implementation here (note that this shows a programmatic approach, your wkWebView will likely be connected to your code from Interface Builder using an IBOutlet).
Continue to ask questions as they arise.
I’m a relatively new app developer working on a couple of individual projects. I’ve dumped at least one hundred hours into coding using Swift in Xcode, and, as embarrassing as it may be to admit, it seems I can’t fully grasp or find information pertaining to how popular apps such as Facebook, Instagram, YouTube, or Tinder implement non-linear view navigation via a menu bar at the bottom of the screen.
I’ve seen one particular app tutorial series that exemplifies how to go about making this menu bar style possible using a collection view of horizontally-placed views each equivalent to the size of the screen. I understand this gets rid of the issue of loading new views on top of existing old ones that sit in the background (my primary worry, outside of unnecessarily reloading information), but is this the typical method of implementing non-linear menu navigation in an app? I suppose a more pressing question at this point is “How can I go about making something like this using SwiftUI?”
If anyone can offer information, explanations, and/or sources, they would all be much appreciated. Thank you for your time!
So, upon receiving TylerTheCompiler’s comment on my post, I started researching the UITabView. It appears that this is used for creating exactly what I was trying to explain in the initial post. I subsequently searched for a way to implement this in SwiftUI and found the “tabbed view.” The tabbed view seems very easy to implement and is exactly what I’ve been looking for. I still wonder if popular applications have been utilizing the UITabBar rather than something else more practical that I am still unaware of. If you happen to know, please comment on this post — I would love to know, myself. As always, thank you for your time, everyone!
This question already has answers here:
Adding Views. Storyboard VS. Programmatically [closed]
(2 answers)
Closed 6 years ago.
Is it more efficient to add views and subviews programmatically than using a storyboard to add them ?
What is be the best practice ? Does the best practice depend on the situation ? If so, when is it preferable to use the one method over the other ?
Storyboard vs Code comes up an awful lot. And I think looking at it as which is better often starts flame wars. So instead I'll list out pros and cons for each, then you can hopefully make an informed decision.
This is by no means an exhaustive list. I'd love to see edits or comments adding additional bullet points.
Storyboard Pros
Storyboards are great for getting a concept working quickly.
They're great for seeing your actual app and previewing it on multiple devices.
They make it really easy to customize appearances and explore whats possible.
They're fantastic for beginners as they remove one barrier and let you focus on code for your app rather than some boiler plate UI.
Storyboard Cons
Storyboards and Xibs are not great for merging. Its possible to read the XML and make decisions about merge conflicts, but its certainly not enjoyable.
Overtime as you customize your app and build the custom parts that make it special, Storyboards can't keep up. This means that the benefit of seeing and previewing your app as you see it on device slowly loses its value as more and more of your app is done in code out of necessity.
Storyboards don't have a huge performance hit for actual users, but they definitely slow Xcode down on even the fastest machines.
You can't customize everything in Interface Builder that you can in code, so its inevitable you'll have some code and some Storyboard customization. Later when you want to change something, you'll have to check at least two places for the right place to change it.
If you're using the same fonts and colors throughout the app, its easy to change in code in one place. In Storyboard you'll need to change it for every single label or view you've set up. You can easily set fonts and colors in code while using Storyboard for the rest of your layout, but over time you'll find your storyboards represent less and less of your actual app.
While its possible to have pixel perfect designs in Storyboard, drag and drop isn't as precise as entering specific numbers. Storyboard does support entering those numbers, but you need to navigate to multiple places and if you drag it later the numbers are all reset.
Reusing views typically involves copy and pasting them. These causes issues later when you need to make changes.
Showing and hiding views at certain times is doable, but again leaves your storyboard in an unrealistic state compared to your actual app.
Programmatic Pros
All your code is in one place making it easier to debug or change later.
Subclasses and custom properties are no different from first class views and properties. Your customizations will be easy to manage.
Views that are reused throughout the app only need to be created once.
Merge conflicts are often easy to understand and make decisions.
Dependency Injection is one of the safest ways to instantiate UIViewControllers and ensure necessary information is passed in, its not possible with Storyboards leading to less straight forward and more bug prone code.
Programmatic Cons
The additional complexity can be a stumbling block for beginners.
Writing a few lines of code can take longer than clicking a few checkboxes.
When working with layouts, you'll need to visualize it in your head or run your app to see what your layout looks like as you make changes. This can be difficult or slower for some.
Storyboard exposes checkboxes and buttons for many customizable properties like background color, font, etc. This makes it easy to see at a glance what you can customize. (Though as mentioned above its not everything) In Code, you'll need to look at documentation or headers to understand what you can customize.
I am working on an app in which there are several screens and each screen has the same layout, just different data passed in, then I want the user to be able to swipe from one screen to the next.
So far I got something working using the UIPageViewController project template using the transition style UIPageViewControllerTransitionStyleScroll. What I have done so far works ok, although its resource intensive because it instantiates a new view controller each time I swipe to a new page but I am loooking into working around that.
The thing I am concerned about is that it is not strictly a page application in the sense of ibooks so even though I am able to make it look like a scrolling app, using the transition style setting, I wonder if there is a reason why people seem to only use this template for book type apps, unless I am mistaken
Also there seems to be an alternative approach of using a UIScrollView and PageControl to do similar functionality
http://developer.apple.com/library/ios/#samplecode/PageControl/Introduction/Intro.html
I am not sure which approach is better to solve the problem I am trying to fix, so am looking for some feedback. Each page will need to be a separate instance of a view controller as there are several elements to display on each page.
Using UIScrollView is much more difficult. If you're targeting iOS 6 you should almost certainly use UIPageViewController. If you're targeting iOS 5 then UIPageViewController might not be perfect because the only page transition available is "scroll" which looks like a page flip.
If you're worried about the resource usage, you can reuse view controllers.
See the WWDC 2012 session 223:
https://developer.apple.com/videos/play/wwdc2012/223/
New to iOS, coming from the Java / Swing world, where I'm used to creating UIs programmatically, letting components size themselves and using various clever layout managers to arrange things.
It already seems clear that the iOS way is to make heavy use of Interface Builder, with a lot of fixed sizing and positioning. I'm not sure IB is ever going to come naturally, but I guess fixed layouts make sense given that you're working with limited space and a fixed window size.
It still seems like I'm writing a lot of boilerplate, though, and violating DRY, and so on.
Can somebody point me to a good primer on laying out iOS UIs, particularly programmatic UIs?
You don't really need to use IB to write MonoTouch apps. I almost never do. The CocoaTouch API is fairly simple and straightforward to develop on.
I haven't really found any writeup on UI development other than the apple documentation (which is really good, by the way, worthy reading), so here goes a couple of tips, based on my experience:
Inheritance is key to maintaining the code clean. You can inherit from basically any class in the API, like buttons, controllers, views, etc. Inherit and add your customizations in those classes. Don't shove everything in the AppDelegate like many examples show. You'll thank me later on.
Have I mentioned inheritance already?
The one thing iOS doesn't have is a layout manager, so if you're used to Java like you mentioned, this will sound a little strange. Different from what Java people think, this is not a big deal. UITableViews help tremendously with this (vide next point).
A lot of iphone apps are built on top of the UITableViewController, even apps that don't look like tables. It's a great framework to do anything related to scrolling. Learn to use it well. Almost anything that scrolls vertically is a UITVC. Follow the guidelines that define when you create and when you dispose cells and objects.
Be careful every time you add a Frame location in your control. Instead of setting hardcoded values, try using offsets from other locations (x+40, for example) whenever possible.
Make sure you add your views to the proper container as necessary. For example, if you're adding a global "Loading" view, add it to the Window object, while if you're adding a image on the left side of a table cell, use the ContentView. iOS changes those special views automatically all the time (resizing screen to fit "on call" bar at top, or rotating phone).
Miguel de Icaza has created a great framework for managing forms and tables, called MonoTouch Dialog. Take a look, and enjoy.