I like how their email app looks so simple, with the background image with white/greyish vertical lines etc.
Is that image released or is it done programatically?
I remember there was a sample that they released that had some UI components, but I can't find it!
Most of Apple's standard UI comes default with their UIKit controls. For example, grouped table views look exactly like the ones you see in the Settings app, toolbars and navigation bars look exactly like those in Mail, text views behave like those in Notes, you get access to modal views that look and work identically to Mail and Messages, and so on.
When you open or create a nib file in Interface Builder, and drag UIKit elements to your interface, you'll see them just as Apple designed them. You'll get similar results even by creating them programmatically.
The sample code that shows off some UIKit controls is UICatalog.
Related
Since I am using Xcode 11 I am having problems with the Safe Area. My App is an ArKit- App that uses an ARSCNView. after upgrading to Xcode 11 the safe Are doesn't allow me to display it full screen anymore. Actually all the views in all ViewControllers can't be displayed in full screen. I really don't know where to start. Did anyone experience this kind of behavior?
Thanks!
Edit:
I unchecked all the necessary boxes I hope. The behavior I still get is this:
Storyboard Main
Inspector
Live View
There seems to be a view underneath. But I never added one and the inspector doesn't show. This changed with xcode11.
I just found out what happened to my ViewControllers. I am checking for internet connection with a LaunchViewController. The segue from this controller to the next one did not specify "full screen". I still don't know why I have to explicitly tell the segue to do so in Xcode 11. But in the end that solved my problem.
Thank you
The Safe Area is used as a reference for constraints for views and objects that you want the user to be able to interact with. It is used as a guide during the layout of objects on the screen. If you want to take advantage of the entire screen, constrain your views to the superview (basically the main view of the view controller). This is handy for displaying things like backgrounds on the entire view. Take a look at Apple's human interface guidelines for more info:
Apple's Human Interface Guidelines: Adaptivity and Layout
Similar Question:
iPhone X - Safe Area does not achieve full-screen experience?
Say I have an OSX app with some sprites moving around, call them gremlins. When I click on a gremlin, I want to display some sliders that control some attributes of that gremlin, maybe scale, speed, direction, that sort of thing, then click the gremlin again to dismiss the sliders. Then click another gremlin and display the sliders to control that one's attributes. I can easily create some NSSliders and set them up in the code. But I'd much rather create a set of sliders in Interface Builder, and load them on-demand: if I wanted to rearrange them and play with their relative positions, it would be nice to do it using that visual interface, rather than having to fiddle with the code, recompile, run, click on a gremlin, and see how it looks. Plus it just seems like better design in general--but I don't know, I'm new to Apple Land, and haven't done anything professionally in this environment yet.
I've tried googling every variation I can think of on "Swift: programmatically load/connect to controls created in Interface Builder", but haven't found any demonstrations or discussion on how to do this, or even an indication that anyone does it. It's making me worry that this is just not the way things are done in Apple Land. Is this possible? Prohibitively/unnecessarily difficult? Is it what people do? If it is possible, what is it called, ie, what can I google for to find out more about it?
Try having a look for "reusing a view xib".
This seems like a good starting point: Example
Create xib file
Design it in Interface Builder
Create a custom UIView file and create initialisers for the view
Add file as owner of the xib (Interface Builder)
Connect elements from xib to Outlets
Load the xib in the UIView file initialisers
Assign it to new UIViews you create
this is a very noobie question although I have had quite a bit of experience iphone development.
I have a client who wants an app with various screnns, but does not want to use built in iphone navigation, but instead wants to have buttons on the screens. All I can find is a load of 14 year olds giving tutorials on MVC or using different views in the same nib.
Does anybody know what apples suggested way of doing this is as I can imagine it been a mind field.
Many thanks
Maybe you should have followed the MVC tutorials of the 14 year old guys.
Then you would know that you could use the built in iphone navigation controllers (ie UITabBarController, UINavigationController) without their standard view counterparts (ie UITabBar, UINavigationBar).
You could always just draw buttons on the screen in interface builder and use custom images for the normal/highlighted states.
When the button is pressed it's up to you what you'd like to do with the received buttonclick method being invoked... the usual way is with the standard navigation system which can optionally have a navigation bar at the top with (back) button, title, etc... and you push/pop viewcontrollers in a hierarchical way. You can just turn the title (or change for your own style) but it does enforce a hierarchical structure.
If you don't want hierarchical navigation of your screens you can either do this with your own custom navigation controller than handles which viewcontroller is currently visible or you could use a thirdparty component like three60 which allows you to navigate around like a webbrowser does on webpages.
You may also want to take a look at Corona which is more for games but would allow you to do a totally custom interface with all sorts of custom transitions and just needs you to write lua... that said it will limit you on using their engine with this approach as you can't get to the ObjC level.
Finally one last approach is simply to use webview and pick up the clicked links so you design your app via webpages... rather ugly approach but can work well if you're very familiar with HTML.
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.
I'm slowly working through the iPhone Application Programming Guide and although it's been great I was wondering if anybody has seen any resources that match class names/widgets with a visualisation/diagram.
For example when I'm reading about Containers and UITableView's it'd be very helpful if I could see what the widget actually looked like. Thanks.
Once you get started with development, the UICatalog example project can also be very helpful. It shows each type of UI element (buttons, sliders, images, etc...) and you can look at the source to get a feeling for how it is used.
You can see how the controls look like in interface builder. You won't see the exact classname, but it's pretty straightforward. A progress bar is a UIProgressBarView, a button is a UIButton, etc.