I've looked for this for a while, but I can't find any good guides or resources that explain it thoroughly (not even Apple's own documentation, which seems to not have as much information as I'd expect). I want to setup a basic interface that has 6 pages horizontally. Each page will have a bunch of labels and textboxes, but the layout will be the same for each page. Eventually, I want to be able to have each page scroll down to view all the content, but I'm assuming I just need to use scrollviews as the content for each page.
Also, each page will eventually have to have separate names for each textbox (and separate from the other pages too) because I'll need all the content of the whole app to be saved out later.
But really, for now, I just need to figure out how to get paging working. I tried following one demo but when I typed in the code, Xcode wasn't recognizing one of my classes (which I know I included it). Plus, I didn't understand what was going on really, and I feel that I need to understand what I'm coding.
Also as a side note, how do I start programming for iOS 5? I updated Xcode to the latest version which said it had support for iOS 5, but I only get up to 4.3 in my project target.
You can use this project http://cocoacontrols.com/platforms/ios/controls/icarousel, the only downside is it does not support cell reuse, so if you plan on having more than a 5 or so panels the app will really start to blog down.
For any future searchers that have found this thread, I was able to achieve what I wanted.
Basically, just make a scrollview the size of however many pages you want (multiply the width by how many pages you want and that will be the content width). Then just enable paging in interface builder and it will page through the view. Then you can just add content to the scrollview.
It's not hard. When I did it for some of my apps, I had a very detailed 'template view' which included primarily a tableview, but also lots of buttons and text fields and such. I was amazed at how well it all worked when put together -- no real trouble with gestures or anything. Apple's UIPageControl sample code is a good place to start.
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.
an iOS app page, which descirbes some item's detail
This is kind of what I want to make
This is exact what I want
Actually I am not an iOS developer.
But a member of our team lacks of knowledge of consisting of iOS app Page(Scene)
I think he usually use table view all the time. which I guess he can't handle very well.
He always struggle about height of UITableView in dynamic pages.
As you see in the picture, page has two views, which I don't know how to call it.
If round button on the right side of a woman is pressed those two views switches.
I guess it's kind of "TAB".
Is it normal that using UITableView in this kind of page. or Which is best practise?
Thanks in advance and sorry for my english.
The first image can be made using a UITableView or UICollectionView(UITableView will do the job with lesser hassle). For second image, you'd wanna use a segmented control.
The third can be built using UICollectionView, however, there are plenty of third party libraries out there on github for the same and you might wanna check them out.
Last but not the least, have some faith in your developer. He seems to be a newbie if he's facing troubles with tableviews but believe me, we've all been there some day.Encourage him to ask questions on various communities. If he's curious enough, he'll be just fine after a while.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
So I'm new to iOS development and I found it easier to write the views all programmatically. So my views have UIViews, ScrollViews, UIButton, UILabel all created and positioned programmatically. (So I never used AutoLayouts).
I've now pretty much finished my app and want to make the iPad views, and realized maybe it was a bad idea to do it like this.
Is this bad practice or should I really be using auto layouts as much as I can?
If it's ok to do it how I'm doing it right now, what is the correct way to add different views for iOS and iPad? I've seen this answer below on how to find the device, is a simple if else statement sufficient? - iOS: How to determine the current iPhone/device model in Swift?
I am using programatic views in a live app and its awesome. A bunch of people I know us this as well.
Here is a little algorithm I use to choose between the two methods:
Are you building a fast app for a client or a hobby? Use storyboard with autolayout.
Are you building an open source project that will be used by many people? Use programatic UI
Are you building an app for the long run? (1+ year) Use programatic UI
Its also harder to make an app thats supposed to be rotated without autolayout. Because doing that with code takes much more work than autolayout. Most good apps dont use this feature anyways so I don't see much problem.
A good tip is never to use constants while writing programatic UI.
If you are going to make a button thats 100px in width, do not type in 100px anywhere in the code. Instead figure out the screen sizes and place the main views according to screen sizes. Then place the subviews or secondary views according to the position of the main views. If you do this correctly you will have more powerful multidevice layout support than autolayout.
Here is a little library I wrote, please inspect and play with the code on how I place the view: https://github.com/goktugyil/CozyLoadingActivity/blob/master/CozyLoadingActivity.swift
Also here is a good article I like about this:
http://www.toptal.com/ios/ios-user-interfaces-storyboards-vs-nibs-vs-custom-code
This is only fine, If you have enough time, patience, good skill on calculations and relationship configurations between different UI elements.
However, using Auto Layout is pretty useful and low time consuming than manual calculations.
We can easily create a dynamic and versatile interface that responds appropriately to changes in screen size, device orientation, and localization with minimal effort.
Read Adopting Auto Layout,to implement the Auto Layout in your existing application
TL;DR
It depends
Longer version
Clearly one size does not fit all. AutoLayout is pretty powerful both in Interface Builder and code (be it visual language format, or simple constraint setting), but sometimes it just seems like you're "rubbing your right ear with your left hand" - that's when adding views programmatically comes in. But beware of not having it different in each view controller - you don't want to introduce too much complexity in your project, right?
I personally like using AutoLayout as much as I can and whenever I can't use it anymore, or the StoryBoard View would get too messed up with millions of constraints, I try to separate views into containers - have the container be resized by AutoLayout and have the subviews handled by code.
Example would be a custom Media Player - maybe I want to have two stripes below and above the video - I could have the video and two UIView extended stripes handled by the AutoLayout. But the subviews (controls) in the stripes themselves would be added by code. It gives me the control over my code but still it doesn't introduce too much complexity.
First of all - if you want to develop for iOS you have to learn Autolayout. There are already a lot of different devices with different resolutions and maybe will be even more in future.
Secondary - if you want to work effectively with IB you have to read guide / watch tutorial videos and have some practice. It could be difficult to start but then you will realize that IB is powerful, fast and often the best way to develop GUI. Often, but not always!
Code advantages:
Easy to copy-paste and reuse GUI. It could be critical if you have
several similar views or want to reuse some old code.
Easy to resolve merge conflicts and check commits.
Easier to make styles - like the same font for all labels depending on the country.
More powerful (there are things that could not be done with IB) so you have to use it sometimes.
IB advantages:
You can see your GUI during development for different resolutions/localizations so you do not have to compile and run a project on different devices/simulators to check is GUI ok or not. Also IB will show you warnings if you forget some Autolayout constraints or there are conflicts. Saves a lot of time if you have a complex GUI with non-trivial Autolayout constraints.
It is much easier to understand someones else code if it is developed in IB. Especially important for complex GUI - not so easy to find a required label or button in a few hundreds lines of code.
Small bonus - if you want to use a custom control developed via code you can make it IBInspectable and use it without problems in IB
Just to summarize - if you do not need IB benefits (for example GUI is quite simple and does not use Autolayout) developing GUI via code could be easier and faster. But in case you have to support different resolutions and/or you have hundreds lines of GUI code in each view controller I strongly recommend to try IB.
I want to display a number of book and magazine covers in my app (similar to the shelf view in iBooks). So far I have implemented my own UIScrollView which displays the covers just fine - unfortunately due to performance problems, I'm forced to rewrite the whole view; however I'm sure that someone else has solved this already and probably made it an open source project (possibly part of a bigger UI toolkit/library?).
Unfortunately I didn't get far by consulting Google, Google Code and github. There are a lot of projects, most of them are examples and tests or abadoned.
So basically I'm looking for a UIScrollView based class with the following features:
Possibility to define a cell size (of the thumbnail/cover)
Automatic layout depending on available space
Lazy loading (using a delegate which provides the cell contents)
Basically a UITableView, but for book shelfs.
Any pointers to existing projects or toolkits are highly appreciated!
Thanks!
Checkout AQGridView. In trying it out I was able to get a basic grid going pretty quickly, and there is support for bookshelves (as seen in Kobo for iPad), but I don't know how hard that would be.
Edit: I just noticed that it doesn't handle large quantities of items too well (after about 40 cells it started slowing down). After reading the 'Future Directions' part of the GitHub page it seems that he's going to something about it someday so it might be helpful to keep an eye on it.
Ended up writing a simple UIScrollView based class which loads contents as needed. It's not too complex to do, but I guess it would be nice if something like this was implemented in the core APIs of iOS.
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.