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.
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());
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.
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.
This question already has answers here:
When to use Storyboard and when to use XIBs
(9 answers)
Closed 9 years ago.
I am new to iOS development (No apps created yet), but I ask for advice from my friend that has really high rated apps on the market. He said not to use storyboards.
As much as I want to take his advice, they seem really helpful.
Is this something that can cause problems for my app in the future?
Is there any reason I may want to not use storyboards?
Coming from an Android background, I don't see why I should use them.
I tend to avoid storyboards for anything apart from perhaps a quick prototype. If you know you have a very simple app which isn't going to get complicated, and you're the only developer, storyboards might be ok.
Here are a few blog posts that detail some of the pain points when using storyboards:
http://toxicsoftware.com/uistoryboard-issues.html
http://blog.waynehartman.com/archive/2012/01/07/uistoryboard-on-ios-5-the-good-the-bad-and-the.aspx
Both of the above are a bit dated, but I believe the pertinent points still hold true.
Note that in theory you need to use a storyboard(s) to get static tables, which can be useful. To get this benefit, you could put only the static tables in storyboard files (note: you can have multiple storyboard files in an app) and use xibs or just code for the rest of the UI.
I'd recommend against using either storyboards or Interface Builder.
You'll learn Objective-C faster if you spend more time using it. Switching between IB and code, you'll have two things to learn. The context switching will still slow you down later on.
Nibs and storyboards are big XML files that don't play well with source control; if you're working on one at the same time as someone else, you will get merge conflicts.
You can't see everything that's going on at once in IB, so it's hard to track down things like layout problems.
You can't search or replace in IB the way you can in code
Nibs and storyboards put your view logic in your controllers. Whether that's a problem for you depends on how much of an MVC purist you are.
If you want to port your apps to/from Android, IB will make it much harder.
This all comes from experience. I started out running a small software team developing iOS apps using IB (storyboard wasn't out yet) and within a year it had caused so many problems that I'd had to forbid its use. Our productivity went way up when we stopped using it.
I think it's not important to use it or not,the most important is how your application is?(quality, beautiful, fast...).
StoryBoard is great for beginner to shorten design time and understand.
But when to become professional developer, you will love to draw your interface by coding because typing more faster than graphic.
I don't think this question is really answerable. There are pros and cons of any technical decision and this one is no different.
Pros:
Visual, so you get a much better idea of what your app will look like more quickly
Less code
Autolayout can be easier
It's not all-or-nothing. You can build the "base" in Storyboards and finish it off in code
Cons:
A big hairball of an XML file makes merge conflicts pretty nasty
Less flexibility than code (no inheritance, etc.)
If you have lots of screens in your app, using a single storyboard can get pretty difficult unless you have a vast screen!
It depends only on you. If you developing your application alone, storyboards are very useful. If you work in a team, it's better yo use .xibs because there is less problems with merging them with svn in comparison to storyboards
Very broad question. There are times when storyboards are great and other times when they are a hassle. Depends on the requirements and compatibility needs of your app.
See this answer for a great explanation of when to use storyboards and when to use XIBs:
When to use Storyboard and when to use XIBs
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 3 years ago.
Improve this question
I've been writing iOS apps for a while now and gradually went from doing the UI entirely programmatically to using the Interface Builder intensively. I'm now thinking about using the new Storyboarding feature for some of my new projects, but I don't have enough experience or knowledge with it to calculate the advantages and disadvantages of doing so.
Can anybody give some examples or information about when using Storyboarding payed off and when it was a waste of time?
Advantages of Storyboarding
It's cool - suave way to design interfaces
Use of StoryBoardSegues to identify navigation/modal relationships
If your app supports multiple devices, good way to organize different views (by storyboard file rather than naming, etc)
Nice for prototyping
Prototype UITableViewCell can save time
Disadvantages of Storyboarding
It's a runtime feature, so I believe it is only available in iOS 5
StoryBoardSegues are kind of rigid in my experience and you may make use of prepareForSegue a lot
Like IB, not very friendly with other display engines and toolkits
Makes it hard to share designs for a single view or set of views - you have to send all or nothing
These seem kind of superficial, I guess I haven't given it much thought... At first I was gung-ho about story boards, but now I've reverted to IB or even just programatic view configuration... The more I use them, the less I like them, and the more they feel like a gimmick/waste of time.
Edit
I wrote this answer a few years ago. I have left it the same as before for posterity, although some points are likely no longer relevant (ie the fact that it requires iOS 5+).
After some time, my opinion hasn't changed on storyboards. As others have mentioned, they're okay if you are working solo on an app with few views to manage, but they become a real pain with source control & collaboration. In addition, I prefer one-file-one-object, and storyboards obviously bundle stuff together (as does IB, but to a lesser extent).
If I were writing an app meant to be maintained for any serious length of time, I would go with programmatic view configuration over IB, but definitely IB over storyboards.
Another disadvantage with Storyboarding not mentioned is that merges can be very difficult if not impossible if there are conflicts.
Update: It also occurred to me that it puts logic in two places. If your segue is not doing the right thing it might be because of an error in prepareForSegue or it might be because you named your segue incorrectly. Doing things programmatically is, in the end, not that hard.
At the latest WWDC (2013) Apple Devs strongly recommend using storyboard and built in IB stuff to do most of your code for you instead of writing it by hand because you are much more likely to avoid deprecation and take advantage of feature updates via automated conversions.
The lone disadvantage is the difficulty in allowing git collaboration on storyboards, as there will be conflicts on virtually every commit.
If you are a solo programmer, you should always be using storyboards.
I have a similar background to you - I started with mostly building my iOS UI programmatically since IB was not really user-friendly, but lately decided to use IB more and more, since it is better for designing the UI and works fine for standard-elements.
With the new Xcode I switched to Storyboard, since they provide a full view of the application. It is possible to generate the complete UI (with all views) in a single File, which can be used for prototyping and which I can view my colleagues before writing the first code line. It is far better and easier than designing with photoshop or similar tools.
However if you use a lot of your own UI elements/controls or something using a different "engine" (cocos2d, OpenGL, etc.) it is usually better to generate the UI programmatically, since these "engines" are not really integrated with IB/Storyboards.
I have learn the storyboarding by following the tutorials from the raywenderlich's website and there is a lot of stuff about the storyboard.
Here is the link to site: http://www.raywenderlich.com/5138/beginning-storyboards-in-ios-5-part-1
Advantages of storyboard:
1) Before you start developing app you can see all the screens of the app.
2) You can visually see the relationship between each screen.
3) It can help to reduce the amount of the code specially in case of UITableView you can use prototype cells and static cells to design your TableView in storyboard.
4) In case if you have to work on someone else code you can get the better understanding of the flow of the app by viewing storyboard in short time.
5) You can setup the user interface for iPhone 4 and iPhone 5 by applying the retina form factor from storyboard, without running the app again and again.
6) If you are doing client based work then some clients want to see the prototype of the app before start developing it, here storyboard helps you a lot.
Disadvantages of storyboard:
1) For storyboard you will need a big screen specially in case of iPad.
2) I also experience a difficulty while copying views from other apps to storyboard.
3) I also experience problems in storyboard when multiple developers work on the same project by using git repository.
By reading and understanding the advantages and disadvantages you can judge your self when to use storyboard.
One Word (DON'T)
One of the biggest disadvantages of storyboard aside from the git conflicts that make it impossible for two or more persons to work on it. but also if the project went so big and you have +40 screens , if you insane enough to move anything just one pixel in any view controller you have in the storyboard, you'll have a very huge compilation time, that you can build your app and make it run in more than 5 minutes, and of course don't let me start with archiving to give some one adhoc of the app .
after this painful experience I totally fell back to the oldy goldy great xib files and deleted the storyboard file in a huge fire celeberation .