Simple question. Does anyone know why Interface Builder doesn't allow for applying custom styles on UI elements? Why is it only possible to do this programmatically?
I can see how this might be difficult for custom UIView subclasses but the default controls definitely only have a tiny subset of the style options available through IB, such as background color or changing font colors. Why is this the case? Is there any way to approach a concept like application themes through IB?
My personal feeling is that Apple does this right. They provide the elements and styles that fit the HIG. If they start adding other elements/styles then where do the start, and where do they draw the line?
Also, it isn't like Apple actively prevents using custom elements/styles, they just don't include it in the tool set.
The last thing we need is a tool set full of bloat.
You'd really have to ask Apple as to the why. I'd guess that it's some combination of promoting consistent use of standard interface elements and limited development resources.
You can, of course, build interfaces using your own custom subclasses of the standard interface elements in IB. It's a little more work, since you have to change the type of each object you add from UIButton to MyGreenButton or whatever, but it's not difficult.
It's also not hard to imagine coming up with a controller-type class that could connect to all your controls and whatnot to customize their appearance in some consistent, theme-like manner. Add an instance of that to each nib, connect all the controls, and let it do it's thing. You wouldn't see the effect until you actually run the app, of course, but it sounds like you're talking about customizing colors and fonts rather than size.
Unfortunately you are at the mercy of the Almighty Apple Deity..... Bow at their feet and give thanks that you have what they give you..... lol...
Seriously tho. Apple puts in what apple wants and you can request additions, but the IB is fairly minimal in the way of features.
I think this may be by design. Somehow an Elegant Simplicity ?
The ability to customize the controls is given to the programmer however I think they want the controls standardized. I just dont know why they didnt give a little more variety in the controls that are available. Like a few more button styles for the ios devices...
If you find out otherwise I would definitely be all ears.
I think that apple should let you to customize more the controls, for games it takes too much time to make the custom control ( you can make it faster in android as you can configure it in xml)
Btw PaintCode is another option to make your own style for components, it will generate the code but its more like interface builder
http://www.paintcodeapp.com/
Related
For an iOS app i am currently working on, I need to manage the controls displayed on the screen based on the type of device the app is running on.
I will try to explain with a theoretical example (the actual numbers used below are not important, what interests me is best method to achieve the desired result).
Example:
In the case of the app in the screenshots, the button that overlaps the UIImageView should not be displayed at all OR displayed in another place on the screen.
So far I've worked with autolayout , but , from what i could figure, there's no way to say to xcode something like: hey, for a class size "Compact Width / Compact Height" , I want you to hide these buttons...but show them for "Regular Width / Compact Height" .
I also did some googling and saw some people talk about using different storyboards based on the device; I am also thinking, I could add/remove buttons dynamically based on the device type , but I think it's not so pleasant to have to add all of the constraints by hand (programatically that is).
So to resume, I would appreciate a suggestion of a 'best' way to do this , best meaning a combination of 'not so hard' + ' not so long'. Also, some code example (or links) would be highly appreciated.
Thank you all in advance !
I think it all depends how sophisticated it gets what you are doing overall. When you look at developer's code for large app projects very little is actually done in interface builder since the apps are so dynamic it's just too much work in IB.
Using multiple storyboards 'sounds' like a good idea, but often isn't. If you want to update/change one, in most cases you then have to change the other ones as well.
What I think is handy:
Use one storyboard (or multiple but for different parts of you app and not parallel ones) and then put in very 'special' cases multiple ViewControllers of the same class for the different size into the single storyboard. That way you won't forget about updating the second (and third) because they are all right there.
I would only use multiple 'parallel' storyboards for apps that support iPhone and iPad and it makes sense to really split them up..
Also:
I would as fas as possible still use just one representation and derive the other 'versions' from that in code. If you build a structured user interface you can then reuse (or just inherit) the code that 'hides' parts of the first viewController in the next. That way your code AND your IB files won't get cluttered.
Also think about internationalisation (if that is part of your future plans), since multiple IB documents and multiple instances of the same viewController layout really don't help for that ;)
I am looking to implement a custom toolbar that sits above my keyboard for a text field with some custom values. I've found a ton of tutorials online but this question is for asking what's the best way to do this.
This tutorial here http://blog.carbonfive.com/2012/03/12/customizing-the-ios-keyboard/ provides the most common way I can see across many tutorials, with creating a new subclass of UIView and using delegates to get that information across.
That's the commonality. However, I came across this tutorial which in the view controller itself just creates the toolbar, assigns it to the textField inputAccessory and it's good to go. In fact, I tried out the code and without any effort, I have now a custom keyboard.
http://easyplace.wordpress.com/2013/03/29/adding-custom-buttons-to-ios-keyboard/
This just seems a bit too easy to me though and I'd think the proper, Apple recommended way would be to create that UIView subclass and use delegates so that the view controller with the text fields acts as that delegate.
I'm specifically targeting iOS 7 in my app.
What are people's thoughts on this? If the second easier link is supported and is likely to pass Apple's guidelines, it's a good starting point but if delegates are the way to go, I'd rather look into that from the start.
Your thoughts will be appreciated.
There is no 'Apple Approved' way to do this, and its hard to believe anything you do here would get your app rejected. The custom keyboard you reference in your post has the iOS6 look and will appear outdated in an iOS6 app. I'll mention some iOS7 suggestions shortly, but the constant danger of mimicking what the System looks like today is guaranteed to look outdated later. In Mac/Cocoa development, Apple use to say at the WWDC that if you did something custom, make it look custom, don't take a standard Apple widget and try to duplicate it. But that advice is mostly ignored.
For iOS 7, you can create buttons that appear just like the system ones do (not pressed), but of course when someone presses them, they won't act like system buttons (i.e. animate up and "balloon" out.
I'm currently using a fantastic add-on keyboard, my fork of KOKeyboard (which uses the buttons above). This is such a cool addition. While the buttons look like iPad buttons, each one has 5 keys in it. By dragging to a corner you select one of the four, and tapping in the middle gives you that key. This might be overkill for your app, but it really helped me with mine. It looks like this:
(the Key / Value is in the under laying view.) The center control lets you move the cursor - its like a joy stick - and can be used to both move and select text. Amazing class, I wish I'd invented it!
Also, for any solution, you want to use a UIToolbar as the view holding the keys, for the reason that it supports blur of the view it overlays, just like the keyboard does. You can use the UIToolbar with no bar button items in it (if you want), and just add subviews. This is a "trick" I learned here, as there is no other way to get blur!
David's KOKeyboard (er…, the one he used - see David's comment below) looks nice. I suspect that he is using the official Apple mechanism:
inputAccessoryView
Typically, you'd set that value on a UITextView, but it can be any class that allows itself to become the first responder.
The provided view will be placed above the default apple keyboard.
It is correct that there is no official mechanism (and it is suggested against) to modify any system provided keyboard. You can add to it, as above. You can also entirely replace it for with your own mechanism. Apply will forgo the keyboard setting on your view and use a custom input mechanism if you set
inputView
set it to any view - Apple will still manage its appearance and dismissal as it does the custom keyboards.
Edit: Of course, iOS 8.x added significant access to keyboards. (not mentioned here)
I'm in the process of developing an iPad-only survey-app using MonoTouch. With monotouch.dialog (mt.d) I found that building these interfaces can come quickly, which is awesome.
However... I also found that mt.d only does about 80% of what I want. Makes me wonder: should I invest in extending mt.d to my needs or should I choose something differently over mt.d?
Some of my requirements:
Radiogroups without transitions: I like the options to be
presented right away (there's more than enough space on the iPad
screen)
A rating UI control, such as
http://www.cocoacontrols.com/platforms/ios/controls/dyrateview
Mixed radiogroups: like 3 predefined elements and a fourth which
allows for manually added content
What are your thoughts on this? Can this be done easily (I'm a trained programmer, but quite new to both C# and iOS development)? Do you guys know of any online repositories of custom UI components with C#/MonoTouch bindings?
Thanks a lot!
This is of course a subjective opinion, but my take on it is that if you believe you can do your UI in UITableView (which MonoTouch.Dialog is based on), then you should go for MonoTouch.Dialog. If UITableView will not fit your needs, you should look for a different approach. MonoTouch.Dialog is quite flexible, and open-source, so if you need anything to be different you can just use the source code and modify it at will.
Ok,
I'm very confused about something... being new to development on iOS I'm often pushed towards the storyboard/graphical design (specially to make file owner, segue, etc type of connections). HOWEVER; every time there's something besides a basic (dare I say primitive) design, I have to do things via code... problem is that just because you can do something via code doesn't make it right according to Apple. so you have to know all the rules to have you app approved. Even some of the examples from Apple (UISPLITVIEW with multiple view controllers -> MultipleDetailViews) do not have story boards just XIB... is that normal???
So question is: why have graphical design if you have to move towards coded solutions anyway. just to say that you have an easy to program interface?
can anyone help me understand that??
cheers!!
Three things (at least!) are going on here:
Storyboards are relatively new and a lot of examples existed before storyboards were introduced.
People are always dreaming up things that are more complex than a very high-level approach can handle. (Even with .xib files, which are more flexible than storyboards, people write custom code to get around limitations.)
For examples, code is linear and a bit easier to follow than the description of a bunch of clicks and drags.
So, first of all, a storyboard is nothing more than a conglomerate of .xib files. When you use storyboards, Xcode handles unloading all the nibs for you. At its core, your app still uses these nib files.
Additionally, your app won't get rejected if you use code to set a property instead of setting it in Interface Builder, or vice versa. I don't know that I would say Apple's stance is just because you can do something in code doesn't make it right. I would argue that they urge developers to set as many properties via IB because less code that you write means less bugs that you introduce. If I have a view in a nib, and I check its "hidden" property in IB, that's no different than me saying view.hidden = YES in code. Apple doesn't prefer one over the other. But using IB relieves me from having to know that the property to hide a view is "hidden" and that it accepts a BOOL as an argument. If in iOS6 they decide to make it shouldHideSelf, using IB's hidden property will be automatically updated, where as I would have to manually update my programmatic setting of the hidden property.
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.