I am new to sketch 3. I have a hand on experience with Xcode and iOS development.
My question is wether we can directly use sketch elements in xcode or sketch is only used for prototyping the UI?
For example, If I design Label with a text field in sketch then can I used it as UI Label and UITextField in Xcode?
In my experience as a designer that also develops in Xcode any solutions that claim to go directly from Sketch into Xcode either become vapourware after some time or don't provide a very good solution. I assume it's because Auto Layout is quite complicated and fragile.
It's best to just learn iOS development using Storyboards or possibly SwiftUI for layout. There are some elements that you can get from Sketch into Xcode such as colors, typography and iconography.
Here's a list of apps that can help you with that:
Zeplin: Handoff designs and styleguides with accurate specs, assets, code snippets automatically. https://zeplin.io
InVision: Prepare designs for development. https://www.invisionapp.com/feature/inspect
Avocado: Open designs without design tools. Export images without preparing layers. Click on layers to get code.
https://avocode.com/hand-off-and-inspect
Flawless: A tool to compare the expected design and the real app right inside iOS Simulator (useful for designers who use Xcode or
mobile developers). https://flawlessapp.io
Sketch to Xcode: The fastest way to get colors from Sketch to Xcode. https://sketchtoxcode.com
Disclaimer: I'm the maker of this app.
There is not a way to integrate the sketch elements in xcode, you can use a sketch plug-in you can buy:
https://www.paintcodeapp.com/sketch
I had the same problem, the design was already prepared in the Sketch and wanted to get the code from it easily. My friends and I've working on a solution for converting design into UI codes, last 2 years.
We've developed Monday Hero platform to improve the development phase and actually save time for repetitive code. https://www.mondayhero.io
In Monday Hero, you can upload design and get responsive code with Storyboard, Xib or only code options. You can also select the elements on the design, group them as you wish for your code library and download it easily in like 15 minutes :) It was a dream of me to get the UI code that easily, I hope it can be also useful to you.
Related
I'm using the JUCE framework to make my first few iOS apps, mostly just proofs of concepts for my Github account for job recruiters.
I've got my first app compiled and working on iOS, but I'm having tons of issues with the GUI.
I can't seem to find the right resolutions to fill the screen. I'm testing with an iPhone 7 Plus, and I figured I could just type in the resolution of that screen to the Projucer, but it doesn't work correctly.
Then I realize I'd probably just want one that fills the screen automatically, but dont know which function calls to use or where its located in the Projucer (haven't found it yet).
Also, I'm entirely new to GUI developing as of December, so I'm still learning all of this. I would greatly appreciate keeping it simple. Thank you to anyone who is able to help.
Try this in MainComponent.cpp
Rectangle<int> area = Desktop::getInstance().getDisplays().getMainDisplay().totalArea;
centreWithSize (area.getWidth(), area.getHeight());
My doubt is very simple.
I want to develop one big iOS (iPhone) app of say 30 screens.
One my friend advice me to develop whole UI in coding only and do not use XIB's or storyboard.
I want to ask that, is it feasible for me to develop whole UI in coding instead using XIB and story board?
Will that affect my iOS app processing?
Will that affect my iOS app execution speed or not?
Please suggest me the proper way weather I use XIB and Storyboard of develop UI by Coding only ..... !!!!
Thank you.
Firstly, tell your friend not to give you advices again.(Just kidding! :)) You can develop the whole app programmatically but it's just a pain in the gut. Apple introduced the storyboards to ease the waste of having multiple xib files in your product.
For my personal opinion, use xibs in case of having lots of teammates working with you because of the pain of conflicts. If you're working solo, then storyboards would be the best fit.
Yes, there is no silver bullet that will solve all of your problems, every project is specific and your ability on predicting project requirements will enable you to decide. Here are some pros and cons of both approaches to help in making a decisions:
Storyboards/XIB pros: Very visual, Beginner friendly, Easy autolayout, MVC separation is straightforward on view side
Storyboards/XIB cons: SCM conflict are almost always unresolvable, not all parameters are configurable from IB so you still need to know how to do some stuff in code
Pure Code approach pros: Full control over entire presentation in code, conflicts resolvable easy as it can get
Pure Code approach cons: Might need more experience to master
My judgment would be:
Using storyboards/XIB is better solution for small to medium projects that consist of basic/stock UI elements.
Introducing visually complex solutions and non standard transitions will require that you start writing layout code more and more and stuff becomes easier without XIBs in your way.
From my experience if you are part of the bigger dev team, Storyboards and XIBs are a big NO..
I prefer not using IB at all even for smaller projects as pressing CMD+R after writing bunch of code, and seeing it come alive is very pleasing.. :-)
To answer your question literally: yes, you can make an app without any storyboards or xibs. I think with iPhone 6/6+ you have to have at least one because they check it to see if you support the bigger screens, but that's it.
In fact, my first app in 2013 had almost no Xib UI design. It was iPhone portrait only, I coded with frames and was happy with the precise results I got-- I also think I learned a lot. I think with Auto Layout, especially if you learned Visual Format Language (albeit that's not a easy thing to do) creating a robust interface entirely in code is doable.
That said, not using interface builder is not doing things "the Apple way." And not doing things the Apple way is usually -- not always, but usually -- going to be more difficult. On one level, WWDC videos, guides and sample code all assume you are using IB. Creating every label, subview and view controller in code is going to take several more lines, each, than using xibs or storyboard. You will be swimming against the current.
It's worth noting IB can be immensely frustrating at times. But generally it's worth it, and you learning how to relate it to the code is learning iOS programming. Also about IB , the files it generates are just XML files, it won't have any significant effect on size or performance- I'd be wary of advice from someone who told you that.
An all-code app is doable and would be a challenging way to learn, but this is not advice I would give anyone or second.
I'm learning many features of ios programming, but since I'm a beginner I don't know if it's better to design my appearance programmatically or graphically.
For example, should I make a view in code or should I drag it to my storyboard?
Should I set its size and position programmatically or graphically?
Which one is actually used in projects?
Specially considering the new Auto Layout and Size Classes feature in Xcode6
For auto layout and layout constraints it is best you use graphical tools because it is definitely future proof. You can do the same thing with code but it takes a whole lot of time to do things when compared to the graphical way of doing it. At the end of the day it all comes to the developer's comfort zone and the app's requirements.
A Small Point About Universal Apps:
Universal app building is very comfortable when you choose graphical storyboarding and have separate stuff for iPhone and iPad (also there are bigger screen iPhones and iPads coming). If you choose to do all the UI stuff with code for an universal app you would end up writing a lot of if-else statements, like below
if ([[UIDevice currentDevice] userInterfaceIdiom] == UIUserInterfaceIdiomPhone) {
//Do iPhone stuff.
} else {
//Do iPad stuff.
}
Help from Interface Builder for Autolayouting
The easiest way to add, edit, or remove constraints is to use the
visual layout tools in Interface Builder. Creating a constraint is as
simple as Control-dragging between two views, or to add multiple
constraints at once, you simply use the various pop-up windows.
Quote from -https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/WorkingwithConstraints/WorkingwithConstraints.html
You always have tools to save you even when you have messed up a lot with the constraints.
Some real good stuff,
http://carpeaqua.com/2014/05/09/why-you-should-use-interface-builder-with-auto-layout/
http://www.raywenderlich.com/51992/storyboards-vs-nibs-vs-code-the-great-debate
If you're looking into iOS development as a bit of a hobby then I'd recommend sticking to the graphical tools. These are faster to learn and will let you build your app in a shorter time if you are just beginning.
If you want to work on a large project in a professional environment or in a large team, then a 100% code project is usually desired.
If you pull apart some of the largest apps on the AppStore from huge companies, you'll see they don't use interface builder (IB) files. Take a look at Facebook, Spotify, Dropbox etc etc.
Some reasons include (but not limited to):
Ease of flow: A complicated app UI in interface builder can seem like a blackbox sometimes, whereas code is usually easier to follow
Simpler merging: If you have multiple developers working on the same UI file, merges can be a nightmare and more difficult compared to a source file
Finding problems: If a problem exists in a pure code project then the problem is right there in the code. Locating problems in an IB file can be tough, depending on how buried it is. Also Xcode's 'find' tool doesn't search through IB files
Code runs faster: You probably wont notice the speed but it is an advantage
Some boast the speed of coding using the graphical tools, and it's true that initially it will take you much longer than the code you're not yet familiar with. If you stick with it then you'll be able to write apps just as fast.
I want to have in my app some nice slide navigationmanu just like in SWRevealViewController. My problem is that SWRevealViewController needs iOS 7.0 and ARC and in my project I have iOS 6.0 without ARC. Is there any way to use SWRevealViewController in my app or maybe there is any alternative to it?
You might want to take a look at ViewDeck https://github.com/Inferis/ViewDeck
It is compatible with iOS 6 and non-ARC.
I cannot tell about SWRevealViewController without ARC or iOS7 (thus I cannot directly answer your question), but I would put a lot of weight behind the following :
Over 80% of all iOS devices currently run iOS7 or greater. ARC has been available since iOS5, which is several years ago.
The mobile market is a quickly evolving one. Not upgrading will quickly lead you to a dark path where you'll end up fighting a losing battle. I understand that your project probably has limitations, but converting right now and keeping up with new technologies will save you a lot of trouble (for instance, trying to make a newer component work with your specific setup).
I would add, the same goes for AutoLayout. If you aren't using it already, you should start, NOW. Rumor has it the next iPhones will vary in size, and the legacy way of handling visuals cannot scale correctly (perhaps the whole reason AutoLayout was created is to prepare this change).
So in short, I wouldn't recommend adapting a new component to your old project, but rather updating your old project to make it modern. You'll end up saving a lot of time.
I've currently an App (with a lot of View Controllers, ...) what uses the "discontinued" Facebook three20 Library and any storyboard, xib file.
Now I need to update this App, the Deployment Target will be iOS 7 and I have to build it with XCode 5.
So my questions:
Is using the Storyboard a good Idea? Would you suggest me to recreate all View Controllers in the Interface Builder?
--
Another question: when adding a Label Programmatically using iOS 7 feature
self.edgesForExtendedLayout = UIRectEdgeAll;
how do I set the Frame for this Element? Need I determine if I am in Landscape, Portrait and Add the 20+44 for example manually to the y-Axis to start under the NavBar or are there better ways to solve this problem?
Storyboards are good, and you should absolutely use them in any future app you make. Whether or not you should rebuild a current app to use storyboards is a question of how big the app currently is, how much bigger it might get, how much longer you'll support it, etc.
If the app is already pretty massive and it won't necessarily grow much at all from here, it's probably not worth the effort to convert over to storyboards.
If the app is only a handful of view controllers, but you have big future plans for it, I'd take the time to convert it over to storyboards so that all the future development will go faster/easier.
I don't deny storyboards but I respect the custom view approach. It means I am creating my each & every component programmatically via code, be it a UILabel or a UITableView. Aligning code with ios7 specific requirements can also be handelled & controlled at granular level using custom View approach.
To your questions about setting frames for the element or detecting device orientation can very well be detected & adopted by writing code.
You can search more help as the information is available all around on programming aspects of iOS.