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
i am looking for the best and correct approach when dealing with user interface design from a UIStoryBoard. as you guessed correct the problem is with the different aspect ratio between the iPhone 5 to all of the older iPhones. some people using 2 different UIStoryBoard in the app and loading the correct one when the app launched, this will work. but when i will want to make a change now i have to deal with 2 files. the other approach is AutoLayout.
so what do you think is the most efficient \ time convenient when dealing with user interface inside a StoryBoard.
Using two storyboards isn't very DRY and so will result in duplicated effort and files that get out of sync. Additionally, it isn't capable of quickly handling any new screen dimensions that Apple could release.
It is better to use AutoLayout or the older AutoResize. Apple has been pushing AutoLayout increasingly and has improved it with XC5 and iOS 7. Keep your UI, and your code, DRY and embrace the clear path that Apple has laid out to handle this.
Related
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 1 year ago.
Improve this question
So, I have been been looking a lot into this topic and the internet seems to be rather vague and divided. I have found that a lot of people handle different screen sizes and aspect ratios by using certain scripts to scale and anchor game objects.
Some people say that you should have assets of different sizes, and enable/disable them based on the screen size. While this method (to me) seems more efficient, it feels like this is suggested less than the other method.
So I would like to ask what the best method is. (Or if there is such a thing as the "best")
The best way is by using a Canvas Scaler and making good use of the anchor-point of the UI elements in your scene and using Layout Groups, this way they will fit nicely into almost all of the aspect ratios.
A few videos covering these topics:
Jimmy Vegas
Unity 3D With Scott
Cat Trap Studios
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
In nearly every tutorial for beginner SpriteKit game making I've seen, people delete the GameScene.sks with no real explination.
The reason why building simple non-game apps is so beginner friendly is because of the Storyboard.
Ray uses the GameScene here:
http://www.raywenderlich.com/84341/create-breakout-game-sprite-kit-swift
Is there any reason why NOT to use this tool? Writing out EVERYTHING in code is a little more daunting when you have this tool sitting right here that seems to simplify it a bit.. but I'd rather avoid it if it's better to do so.
Thanks in advance.
It's all personal preference really. I think the reason why people delete it though (at least in my opinion) is due to the following reasons:
You have to specify an initial scene size in the file. Whereas if you create the scene programmatically you can set the size to the view size.
The editor is very limiting. Xcode 7 however greatly expands the editor to include much more such as custom classes.
There were some pretty big bugs/crashes in the initial release of Xcode 6.
When learning Sprite Kit it's good to know how to programmatically do things instead of doing it visually. This is because games often have dynamic gameplay so you will certainly have to do things programmatically (especially when you consider the limitations of the Xcode 6 editor).
Some people (including myself) may use their own custom editor for designing levels etc. Whereas interface builder is standard because it has become very powerful over the years and works perfectly with UIKit.
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
I wish to make an iOS application that includes a document library, log/journal, forums, possible randomized quotes ?and coaching tools?, and have built applications of that size in other contexts but this is my first iOS application.
Right now I'm working through http://www.raywenderlich.com/1797/how-to-create-a-simple-iphone-app-tutorial-part-1 , and I'd welcome comments on other tutorials, but I wanted to ask: does it work to work out the logical gears of an application before developing the graphic design? I would like to have somewhere between a Dirtylicious and Nature look, but my natural bent (no pun intended) is to get most the gears working and then defer most of the design work until after the gears. I expect they should not be completely separated, and there are cases where you apply the design and then realized that what the gears are doing only looked good on paper, but I wanted to do a sanity check on whether it makes to look up tutorials appropriate to a document library, a log/journal, forums, etc. and get them to work together first, and then skin it.
TIA,
It is recommended that you follow the MVC pattern, which strives for separation between layers.
http://developer.apple.com/library/ios/#documentation/general/conceptual/devpedia-cocoacore/MVC.html
Xcode helps you implementing that pattern.
I think you should try to put in "paper" everything you want to do, before doing any actual coding, check how many views you are gonna have, what you need, the flow between views, try to diagram everything, that will save you a lot of pain later. You don't have to be so specific about the GUI at this stage, you only need to know what kind of visuals you need in the views, (buttons, labels, etc...)
And yes, I think you're safe doing the Model first.
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
I maintain an app for my business and am pretty much self-taught on code. I understand all of the structural code, and everything is perfectly usable. My problems is with the overall boringness of the looks. Everything is stock iOS from buttons to backgrounds to pinstripes on the list view. Does anyone have any guides or tutorials they used to take a stock iOS app's look to something like the Piictu app? (I'm not looking for something that impressive but in between that and stock iOS; and I'm open to a full app re-start.)
Almost all of controls can be customized with the view properties. and also there are lots of fully customized controls published with its source code.
With iOS5 there is a lot more scope now for customisation of UIKit elements. However, where this is not custom enough for your design then you would need to write your own controls rather than only using Apple'. There are a few good ADC videos on this.
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 6 years ago.
Improve this question
Is there any way to port an existing iPhone app to a Mac OS X app?
It's a very broad question and, as such, is very difficult to answer.
Generally the answer would have to be no.
For an app, if you strictly followed the MVC model, you'd be able to keep the model but would need to rewrite both the view and the controller. For a game it depends on how low-level it is. If you used a framework that it also available on the Mac then a lot may port automatically but you'll still need to reconsider the controls, screen size, etc. Either way it's non-trivial.
It's been a while but looks like its now possible to port some iOS app over to the Mac. Obviously they will look as if they are running under the iOS Simulator, without the faux iPhone screen bezel.
The framework that makes this possible is UMEKit, a re-implementation of UIKit on the Mac on top of Cocoa.
I really doubt, iOS programming is view oriented with only one windows, MacOs instead is windows-oriented. Even if the APIs are really similar, the iOS framework is totally a new thing, recently projected (cfr. UITable).
A lot of the basic UI elements that iOS apps rely on (such as table views and navigation stacks) are not present on the MacOS. So at the very least you will need to rethink and rewrite a lot of your UI, though a lot of the underlying application logic code can be reused.