Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I am building a basic app interface which will have a mixture of text, inputfields and buttons. In order to get a working version for project deadline, I thought I would use the default Interface Builder (IB) components for the first iterations and then if there is suffiecient time, I would like to 'jazz up' the interface by adding customised components..
How easy is it to swap over IB components with customised ones at a later stage?
It depends on what you mean exactly by swap over IB components, but in general I would say that IB has full support for customization of your UI within its own conceptual framework. On the other hand, it is pretty obvious that defining your UI programmatically will give you all the customization possibilities you might think of.
In a sense, you can see IB as a way to declare graphically the elements of your UI, their relationships, and have them automatically instantiated for you when the IB xib file is loaded. This is a very flexible mechanism in itself and allows you plenty of possibilities.
Say, for example, that you have a button somewhere in your IB view. In a first release, you could set the class of that button to a plain UIButton; later, you simply specify that that button class is actually a YourCustomClass and you have it, your UI will use your custom button without you having to change much of code (maybe one line or two apart from the custom button implementation). The same holds true for many other kinds of UI elements.
Besides that case, there are classes, like UITableView, that I think are better customizable outside of IB (i.e., by specifying the customization, e.g., the custom cell, programmatically). But still in this case, having the interface defined in IB in the first place is not a big hindrance either, and you simply add the code that you need to your program.
Anyway, there are some customization that are not easily possible with IB. One example could be having more control on how and when your UI components are allocated; so, say, you are restricted to your xib file to be instantiated all at once, while programmatically you could trick every aspect of that. Or, there might be UI elements that are intrisically better suited for a programmatically definition (say, a scrollable grid of pictures), so IB would not fit the bill, or give little support for that (but you would not be able to define that UI elements with it in the first place).
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
apologies still relatively new to programming/swift. I've created a concept for a messaging app that has sliding buttons to filter/scroll messages but I can't work out the best way to achieve this functionality, so after some guidance on the best way to approach this.
I've considered:
Hacking a tab bar so it sits along the top (to switch between sent/received views etc)
Using a horizontal scroll view (not sure how to jump between the views using a button)
Using buttons to show and remove views programatically
I'm thinking of showing the individual message tiles using a collection view rather than a table view.
I'm also wondering if the design I've came up with is actually completely wrong as I can't seem to find any UI elements that behave in the way I expected (like the slider switches on my mock) and if I should completely rethink the layout. I'm open to that option if that's the case.
Any help/suggestions welcome!
You're asking a lot of questions - your post should focus on one task. Review How to Ask
But, to give you a couple ideas...
Take a look at UISegmentedControl. Here's an example only slightly customized:
A little searching will show you how to do that, or how to customize it even more (making the round-ends appear more like your mockup).
Below those, you could put two table views in a horizontal UIStackView. When you select a "Received / Sent" segment, animate the stack view to show the corresponding table view.
When you select a segment on the lower control, filter your data and reload the table view.
What you want to do, though, is just get started on it.
Begin with learning about UISegmentedControl and how to customize the appearance.
Then work on putting two views side-by-side and learn about animating their positions.
Then work on filtering your data source.
At each step along the way, if you run into a specific problem/question, come back and make a new post about that issue.
When I started with IPhone development I preferred using Interface builder for creating views in my application. With time I considered the option of creating the application via code which I really feel comfortable working with.
Now, when I know both ways to create my user interface, I have doubts which way to follow. I keep thinking where to use IB and where to use code. How can I figure out before starting with my application, which way should I create my UI?
There are a number of factors that can influence your choice. It can come down to personal taste, but there are some advantages to using Interface Builder.
The first thing to recognize is that UI design is inherently a visual task. Interface Builder can allow you to create and modify a UI much faster than you can in code. Rather than endlessly tweaking CGRect values in code, then recompiling, testing, and repeating this process, you can instead get direct visual feedback about your changes. This means you can refine and polish the UI much more efficiently, and even test out radically different layouts without too much time or effort.
Another important point is that if you can create and layout a control in Interface Builder, that means there is less code in your view controller. Less code is always a good thing (less bugs, easier to maintain, ...).
So I believe you should try to define as much of the layout and properties in Interface Builder as you can. This can be hard for people who prefer "full control" over things. Many years ago, visual GUI editors were renowned for doing the wrong thing, and developers often shunned their use over doing everything by hand. But Interface Builder is pretty good at what it does, and you can easily dive into code when you need to.
The situations where you would create controls purely in code are when you need to dynamically create a number of objects, for example thumbnail buttons for a photo gallery, or if you have custom layout requirements.
For example, if you have a label whose height is dynamic at runtime, and you want to layout a bunch of controls underneath it (taking its height into consideration), that can only be done in code (UPDATE: iOS 6's Auto-layout can do this now). You can either create and layout everything in code, or you can still create the controls using Interface Builder and just give them arbitrary positions in the XIB which are modified when you lay them out in code. It's not uncommon to see this in some of my XIBs:
The buttons along the top can be created and layed out fully in IB, but the image views below need their images and positions to be calculated at runtime. So we just give them arbitrary positions in the XIB. Some might find this ugly, but it saves time and effort on writing code to create the image views and set up their properties. Again, less code is a good thing.
Other times you may want to use code is setting certain explicit properties. Let's say you have an image view which needs to receive touch events because it has some gesture recognizers added to it. You need to set the "User Interaction Enabled" property to TRUE. It can be better to do this in code because the requirement is more visible and you can leave appropriate comments as to why you are setting the property. It's also harder to 'lose' the setting like you can in interface builder if you need to delete and recreate a bunch of views.
I think for many applications that use the stock UI, Interface Builder is a great tool to rapidly get things up and linked with the underlying code. Also, it really stresses the paradigm of the View being separated from the Controller as you really can't push code into places where it shouldn't be.
That being said, I use it less and less the more I learn about how to rapidly code interfaces due to the fact that they may need to be more flexible or need a variable number of UI elements based on the Model behind it.
Use interface builder as per your requirement. It's depend on you that how you manage things. See creating a custom cell using interface builder is much easier to update at a later stage while using code you have to do a lot of changes if layout changes. Also you can visualize the view before running the actual app but in code you cannot you just have to assume.There are both prons and cons of both things.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Is it possible to add a standard-looking badge to a standard UIButton?
If it's not supported semi-natively, what would be the simplest way to achieve this?
Example image:
Here's a VERY NICE class by Sascha Paulus called CustomBadge, that builds and renders custom badges using Core Graphics. They're just UIView subclasses, so you lay them out using their frame just like any other UIView subclass.
I've used this library many times and always been pleased with the results. Flexible, easy to use. Totally recommend it.
You can check for several options here: CocoaControls Badges
The class that Apple uses is _UIBadgeView (https://github.com/nst/iOS-Runtime-Headers/blob/master/Frameworks/UIKit.framework/_UIBadgeView.h), but of course, this class is private (note the underscore) and not documented.
Here's another class that implements this view with the same look and feel as Apple's while also allowing you to customize it: https://github.com/JaviSoto/JSBadgeView. The great thing about this one is that it lets you position the badge relative to another view automatically, in one of its corners.
We have a badge view in Nimbus that's super easy to use and well documented:
NimbusBadge
I don't know how this is done out of the box and I honestly doubt that Apple built that into the SDK.
Anyway, you could create a custom view with a button on it, add the background of the badge as a UIImageView and place a label on it to hold the badge count.
That's a quick solution, it might be better to create a custom subclass of UIButton and add your badge stuff as a subview
I'd go a similar way as #Björn Kaiser: Use the button as you like it, and then add a custom view with that badge as a subview to it - I've done it and it works well.
As for the view, you can draw it as you like. You can draw it manually or use CoreAnimation and let it make the main part, i.e. theBadge.layer.cornerRadius = ...; to give it a round shape, draw the text/number in drawRect: or add it as a label etc.
I'm the programmatic guy, and I simply don't want to use Interface Builder. I feel out of control, and besides that my GUI is about 90% custom all the time.
Literally every book does everything in Interface Builder and claims that this is the one and only great way to have real MVC going on.
Example: One of those books mentions that programmatically creating an UINavigationController with an Root View Controller and everything else that belongs in there is a big mess and won't be reusable when porting to the iPad, while doing this in XIB is a clever decision. Then the port to iPad using UISplitViewController will be a simple task.
So when I make iPhone apps and want to port those to the iPad too, what strategies work to reuse as much code as possible? I'd like to learn more about how to separate my code and achieve a better overall architectural design without using Interface Builder.
For those who want to tell me I must go with IB: Again, I do a lot of custom UI where IB is often just in the way. And not to mention all the animations. I really have my reasons. For people who make default UI IB is really fine - but please, I don't want to start a fight for IB vs programmatical UI or default UI vs custom UI! It's all about how to achieve great reusable code when doing everything programmatically, and both have their pros and cons.
Although you did not ask for it, I feel compelled to make the case for why people in general (perhaps not you) should consider IB, and then address the issue of custom components.
I use a lot of animations and custom components. And I love to use IB...
The key is to use IB for its strengths, and then decide what to do with the rest from there. What then are the strongest points of IB? Connections, placement, auto-resizing and customizations.
Connections are linking aspects of views and controllers together. It's faster in IB to drag out a few connections to delegates or references, than it is to write the code that forms the connections. And, it's a quick place to review all links to the UI you are building.
Placement IB also does well at. There's a fair amount of code involved in setting up any GGRect correctly. Not only is it easier to enter and review coordinate and size details in IB, but the tool automatically sizes a lot of elements properly for the container and the control, and offers many guides to help things line up properly - that kind of thing can take a lot of repeated testing to get right.
Related is auto-resizing. Although I don't feel that many screens can actually have auto-reiszing rules that rotate the screen and come out the other side looking just right (I almost always do rotated views as a separate XIB file), there still are a lot of shifts that can occur in the course of running your application that make it really useful to have these defined just right. The best example of this is the enlarged status bar while you are on a call.
Lastly comes customization. This again can be a lot of tedious code to write; try setting up all of the properties on a UILabel manually and it'll have you yearning for quick changes in IB.
With all that said, what is a good approach to custom components? I like to use UIViews in IB screens, with the class type set to a custom UIView that then fills out the display at runtime. But at least IB helps me get composition, placement and auto-resizing just right with minimum fuss, and also wire aspects of that custom view into a controller.
The one thing that would really lend IB to use with custom components is if it would simply let me set values for any simple properties the custom view had - then I could adjust parameters like a corner radius or whatever else I had going on.
I urge you to think on IB a little more, as it's a huge productivity boost when used correctly. There should be nothing about IB that gets in the way, it's there to boost your output.
One book I really liked was Erica Sadun's iPhone Cookbook 1st edition. It did everything programmatically.
Unfortunately the second edition is bloated.
If you reuse lots of your custom UI objects, it would make sense to write a code which
reads a plist (or a more general XML file) specifying how the custom UI objects should be placed / animated
and then creates your custom UI objects accordingly.
It's like writing a mini-xib file format tailored to your UI objects; you can also feel that you're in control of everything, as an added bonus.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I've just had a nagging question for a while regarding iPhone app user interfaces. For example, consider WeightBot's User Interface. I am wondering, how are most of these user interfaces created? In general, of course.
Is there a way to simply design controls (that is, the images) in a program like Photoshop, then use that 'skin' for controls in UIKit? I realize that there are some controls that are probably created by the programmer (custom controls), but I'm referring to the ready-made ones that come in UIKit.
In other words, is the concept similar to 'splicing' web site designs? Where a designer draws out the design of the website in something like Photoshop, and then it is cut up into pieces which can be applied to form the actual website? I know this can be done for UIButtons, can this also be done for other controls, and is this how it is usually done?
Or perhaps this is done with Core Animation? I've heard this from time to time, so does this mean that the User Interfaces are 'hard-coded'? Or is Core Animation only used for the 'effects', such as applying the glowing effect to the numbers in WeightBot?
If there are any resources you can point me to I would really appreciate it.
I've asked myself the same question and just like you i couldn't find any examples. After playing around i've managed to create a similar control. You can check it out on github http://github.com/kompozer/HorizontalSliderControl
Its very simplistic but i hope you get an idea. Basically its a UIScrollView, not much core animation needed.
I can't think of any written resource about this practice. But you are on the right track about Photoshop. Designers create assets visuals for the different controls in some design app such as Photoshop. Developer then assigns these assets to controls, e.g different states of a button are loaded as images, and maybe text added in code.
Looking at WeightBot UI and the big blue glowing numbers, I can think of two ways doing them:
1) precreate all the digits 0-9 in photoshop, and put them together at runtime (just load UIImageViews into UIView, calculating the sizes and positions at runtime)
2) create the text with something like UILabel and then apply effects to it programmatically at runtime.
Both ways are fine and both have different tradeoffs about app size, code maintenance, developer/designer skill required, performance etc. It is also common to mix these all over the place, especially with something like a fancy background image + text created at runtime on top of it.
You are correct that all of this is quite similar to web slicing and requires you to think about what elementary pieces the interface consists of and how to composit them together.