I have lots of views - sub classes (UILabel, UIVIew, UIButton etc) using core graphics (within drawrect).
These show fine within normal interface builder.
However they do not show in the preview assistant editor for the storyboard (where you can see how views should look on actual devices).
I've been doing some research and found posts suggesting prepareForInterfaceBuilder should be used. However this doesn't show in preview for me.
I asked this question some years ago, IB_DESIGNABLE, having views show in preview? however I can't reproduce this, I'm not convinced it did work back then either.
I'm still following the same approach, with a framework and that link shows my implementation.
I know that prepareForInterfaceBuilder should be used to do something different, to show something basic. Therefore I believe that core graphics won't work.
However, I can't even get a simple change in background color to work in the preview, although it does work in normal interface builder.
I would like to know if this is a bug (that core graphics can not be used in preview) or still a limitation in xcode?
At the very least I'd like to do something simple (like a change in background color). I have a lot of views and an impossible task to make auto layout changes.
Previously I was producing lots of screen shots, different devices, languages etc (via automation) just so I could see my auto layout changes, which is really slow way to work.
I can verify this is a long standing bug. Apple doesn't care. Custom view be damned. All those dollars spent for more broken Xcode functionality.
Android?
Daniel
Related
I am fairly new to developing for iOS. I have a fully functioning program written in Swift and the UI was created in the scene builder on Xcode. I created an app for my work to simplify closing out the registers and other financial aspects. The app is complete and works perfectly, but was designed on the iPhoneX. The problem is that only a few of the employees have an iPhoneX, but they all have some kind of iPhone. I have tried setting up constraints but it never works. Ive tried scaling restraints and position restraints but I can't get the layout to look right on any other phone, and when I add the constraints it affects the view on the iPhoneX as well and doesn't look good on any iPhone. I need help getting this to work on all iPhones. I would like it to look and act the exact same regardless of the size of the phone, basically just scaled down. There are a lot of things on the screen and I can't figure out how to do this. Please help!!!
I have been working on this for a long time and I really need help. Please let me know if I need to clarify anything. I have posted links to some pictures of my UI so you have an idea of whats going on.
Constraints I tried adding, although I have played around with some other options.
Here's what it looks like on the iPhoneX, this is how I want it to look.
What it looks like on iPhoneSE (with constraints).
One thing I noticed in your Xcode project that none of your features are in UIView. Without it, it will be quite challenging and somewhat always different results. In theory, if you use AutoLayout features correctly it should work without UIView, but they make life so much easier. This is something I learned the hard way at the beginning of my iOS development. First set up your UIViews without any content inside it, give them some background colour to differentiate, once they are working on all devices. You can pin your features to superviews with no difficulty.
Since you have a repetitive features, you could also consider using Stack Views. You don't have complicated features, so as long as AutoLayout is set up correctly you should have no problems seeing it ok on all devices
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.
Background:
My workflow for developing interfaces for mobile apps depends on Illustrator and Photoshop. I'm not a fan of Interface Builder, nor am I impressed by the Android UI designer in Eclipse (haven't tried IntelliJ yet). It's awkward to take an experience of laying out UI from such apps, and translate into IB. Once in a while I try again to build a UI in IB, only to get bogged down in bad experiences.
The current problem I'm having is this:
When selecting a set of well-laid-out views within a View Controller's view from an iPhone storyboard, and then pasting into the corresponding View Controller view of the iPad storyboard, the views are all messed up. They get thrown all over the canvas, and the size manipulation handles are hidden because they're not within the bounds of the superview.
Is copying and pasting inappropriate behaviour in Interface Builder? Must I drag everything out of the library again?
Side note: I'm working on a 13-inch screen, and the iPad view is larger than the small area given to work with. I zoom out so I can actually see the whole thing, then select a component to adjust it, and find IB automatically zooming back in.
I've found question-answers saying the auto-zoom cannot be disabled, and so I have to just put up with that awkward UX.
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.
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.