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.
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.
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 9 years ago.
Improve this question
Is it better to build separate views for the different screen sizes for the height of the iPhone. Or is it better to creat a #define IS_IPHONE5 and adjust the view's code based on the hight of the phone? Any other ideas would be appreciated.
Have you thought about using Auto Layout? It's the Apple-recommended way to do this.
You can find some posts online bashing Auto Layout. You shouldn't be discouraged by them, because from what I've seen they can mostly be divided into 2 groups:
incorrect understanding of Auto Layout by the authors,
poor Auto Layout implementation in Interface Builder in Xcode 4 (it's gotten a lot better in Xcode 5).
Using Auto layout is great option. Other then this you should create different views and use them depending on device and screen.
Creating different views for the different device screen resolutions is not a good idea. You should try to avoid constants when it comes to screen dimensions. If Apple decided to bring out a 6" phablet tomorrow with a different resolution you'd have to update your app and create an entirely new view for that resolution.
If you no longer have to support iOS5 then you should definitely go for auto layout. Take a look at this Ray Wenderlich tutorial to better understand auto layout:
http://www.raywenderlich.com/20881/beginning-auto-layout-part-1-of-2
If you still need to support iOS5 then go with auto-resizing masks (the above tutorial also explains auto-resizing in short), it has its limits but you can correct this in viewDidLayoutSubviews in UIViewControllers and layoutSubviews in UIViews.
For every developer arrives the day to improve the user interface experience because apps are evalutated mainly from the ui carefulness.
So, i've took a look around the websites and I found some psd where to start to desing my apps.
My question is: How to transform a psd prototype to a well-working app?
I don't unserstand how a mockup can help a developer to build a ui...
Can someone make me some clear the situation?
Well, I'd be careful to make a distinction between the graphics an app uses and the actual User Interface. Certainly the graphics are part of the UI, but the UI is soooo much more than that. Depending on how it is done, photoshop mock ups can be simple graphics you can use for your interface to complexes 'scenes' describing how the app functions. In the latter case, the mock-up can be useful for UI design, in the former case it just gives you pretty images to use (which can certainly be useful).
But to more directly answer your question, most people take 'slices' (individual pieces) of the photoshop image and export them as .png images (or .jpg). If the .psd file doesn't already have the images 'sliced', look up 'photoshop image slicing' on Google. You can then import them into Xcode and use them as background images for the controls you want to use. Especially since iOS 5.0, images can be used for a lot of controls. Also, you'll probably want to make sure you make the image resizable with proper UIEdgeInsets. This will allow the image to resize without pixilation by setting an area that can be tiled within the image.
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 8 years ago.
Improve this question
Mac app development is rumored to be very similar to iOS app development, but of course there are big differences.
When we put all the facts about hardware and screen constraints aside, what are the biggest obstacles an experiences iOS app developer must overcome to start with Mac app development?
Some of the awful things I've heard:
Myth 1: On the Mac, the coordinate system is different. 0 is at the bottom left. Feels like driving on the wrong side of the street.
Myth 2: NSView is not really like UIView. UIView always has a CALayer. NSView doesn't.
Myth 3: Table Views on the Mac are far more complex and harder to use than UITableView on iOS.
Can someone debunk them, or add a few others? Where are the painful differences in the APIs?
1 and 2 are absolutely true. 3 is debatable - some things about NSTableViews are nicer, such as how you can use any object (e.g. a string, image, number) as a cell value.
Whilst we're on the subject of cells though, that's another pain - many NSViews have cell properties that do the real work, so the view hierarchy is mirrored by a cell hierarchy that makes everything more complex. Text fields are really confusing because of this.
Also, NSLabels/NSButtons can hardly do anything compared with UILabels/UIButtons - no font setting, no colour setting, no customisation at all - they're basically useless.
And if you do use Core Animation, it's poorly integrated with views. So for example you can transform an NSView in 3D if it's backed by a CALayer, just like in UIKit, but if you try to click on it, the mouse co-ordinates aren't mapped by the same transform as the view appearance, so if you transform a control it basically becomes un-clickable unless you click where it was originally positioned on screen before you transformed it.
Basically the whole of the Mac OS SDK feels like it was an early alpha version of the iOS SDK that hasn't been properly tested and where some of the stupid, overcomplicated ideas (cells) that didn't make it into production haven't been taken out yet.
</rant>
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).