I am using IBA Forms Framework and I cant resize the width of the single section? I cant even find the IBA help on internet.
Like it's been answered here, there is no easy way to resize a single section width. You might want to find an other way to implement your tableView.
IBA Forms Framework is not longer updated. I suggest you to try an other framework such as RETableViewManager, which also provides iOS7 inline pickers.
https://github.com/romaonthego/RETableViewManager
Related
Hi all I would like to make a horizontal scroll bar like below in iOS APP.
I read through lots of iOS programming book, none of them teaches me how to do custom UI. Can someone tell me, what knowledge I should learn in order to make this?
Thank you.
You should be using UICollectionView to make your life easier. There are many tutorials on that in which you probably just want to lay out your cells in one row and many columns to achieve the horizontal scrolling effect. Otherwise you may want to employ external libraries like this if you prefer a plug and play solution.
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 am under one project.In that I am using some image files and some button.
When i use to place button in my viewcontroller and see that preview using
assistants editor. My button are mis placed in different places.so i thought to use autolayout.But small confuse in that. I am beginner to ios.I have some question?
METHOD 1
When I uncheck this autolayout option like image (A)shown below.its working perfect in all iphone simulator(3.5, 4, 4.5, 5.5). By setting autolayout using below option (B)
[A]
[B]
METHOD 2
At the same time when i put check mark autolayout option and use like this image show below.I am getting some misplace (Not in arrangement].I know I miss some constraints.But its not better than my above question
please give me some suggestion about this.Which one should I use?
METHOD 1 (OR) METHOD 2. I am new to ios .kindly suggest me something about this?
Method 2! Autolayout. It is very powerful and (if you get the hang of it) quite easy and intuitive to use. You can create pretty much arbitrarily complex user interfaces using it. It has its limits, but in most of the cases you don't encounter them and most of the times they are fixable using constraints set up via code instead of the interface builder if needed.
Method 1 was fine while it was the only option and may still be okay for simple layouts. But as soon as you want to have a little bit more complex relations between different UI elements, like one UILabel being half the size of a UIImage, you will run against a wall.
You may check here for differences between autolayout(Method 1) and autoresizing mask(Method 2). Apple suggests devs to have their view layouting using Autolayout so there is not actually a question in here.
You probably messed up with constraints as every beginner does so I would recommend you to take a time in here and try to finish this tutorial.
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.
I'm currently scoping out a project for the iPad which is rather text and font heavy. There are many pages of styled text, which also need custom fonts. I have toyed with the idea of simply rendering PDF or PNG files on-screen, but I think we need to be able to dynamically repaginate the text.
We've used UIWebView in a previous project quite successfully, however there are a few things I don't like about it... Firstly, you have to hide all the silly drop shadow elements to stop them showing when the user scrolls beyond the bounds, and we had to add some JavaScript to find out actually when a page had fully loaded. Overall, the experience seemed a bit clunky, as well as worrying if the project could potentially break if Apple decided to update the subviews...
The other thing we've been looking at is Core Text, which looks very powerful. The only worry with this is that it appears to be a rather steep learning curve for us since we've mainly been working in UIKit (with a bit of Core Graphics). I couldn't even work out how to change the size of the font after a morning's work.
Are there any other alternatives*? Should I stick with Core Text? Is there any way of using UITextView with multiple fonts and styles?
Thanks!
:-Joe
EDIT: *by alternatives, I am really looking for built-in iPhone SDK alternatives only please... I would rather not mess with third party frameworks because I don't have the time... Thanks :)
You could use Pango, which uses CoreText when on iOS.