Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
Is there a tool for documenting the many Xcode bindings, outlet and IBAction bindings, key value bindings, etc? I have looked at the threads on Doxygen and HeaderDoc, but these document program files, to describe classes etc, but don't seem to cover the huge number of 'hidden' linkages that Xcode drag-and-drop enables?
A specific example, I can use the XIB editor to create an IBAction for every control on my window, to methods in one or more class/instances, defined in one or more files - I want ONE list of all of these, showing the control type and name, the source file, class and method - or a graphical representation would be even better. Then a similar list for the key value path links to arrayControllers etc.
I AM new, so if I have missed something obvious, please tell me.
Thanks.
No, there's no tool for documenting .xib files unless you consider the file itself as part of your documentation. (You did say "self documenting" after all.) .xibs are stored as XML, though, so if you really want to extract the data, it's there to be had.
The actions you create in IB appear in your source code. You could add comments there describing the object that sends the action, but that would largely miss the point of using a .xib (and actions) in the first place, which is to decouple the UI elements from the controller.
If the point of the documentation is to make your project easier for other developers to understand, you might want to get some more experience with Objective-C before you go to a lot of trouble creating a .xib documenting tool. Given a .xib and the relevant header files, any competent Obj-C programmer should be able to tell easily which controls are connected to which actions, or to debug problems in that area. People have been working with .xib and .nib files for 20+ years -- the lack of a separate documentation tool may be a good indication that such a thing may not be as useful as it seems at first.
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 7 years ago.
Improve this question
I am currently developing an iOS app that can be used by different clients keeping pretty much the same interface for all of them. I would like to make this interface somehow “customisable” without having to change the storyboard for every client but I am not sure how to do so.
I thought that maybe I could have some sort of XML file that would contain the value of the UI elements, modify it and have the app read the value of the UI elements from it at compile time so the final app would contain the desired messages, images, etc.
To make the changes easier I also thought of some kind of “wizard” that would show the UI elements that can be changed, allow me to edit and write them to the xml file and after all that, compile the app from the command line (running a script from inside the wizard).
Is my idea viable? If so, how can I accomplish it or what tool are out there that might help me?
Is there another option that would help me accomplish this “customisable” interface?
Note: this is my first iOS app and is still being developed, I searched for related topics and info but found nothing useful so I am not sure if I am asking even possible to do for iOS or if it is out there under another "name".
Edit: by customisable I mean being able to change the text of the messages, the labels, the banner, the clients img logo, color of some elements and that kind of things.
Edit 2 what I would like is to develop a "wizard" that will modify an xml file and maybe replace some images in my app before it is compiled (that is my current idea). After that I would compile it and all the customisation would be done and the app would be ready for the client.
I would suggest that you look at targets http://www.itexico.com/blog/bid/99497/iOS-Mobile-Development-Using-Xcode-Targets-to-Reuse-the-Code
You could generate your XML file for each "Target", but only include the correct one for each target. Then when the app is compiled it should include all the relevant information. If you are producing multiple apps, you also need to consider that the app bundle Id would need to be different for each. Again Targets handles this
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
I'm just about to delve into the world of app development (I'm usually a game developer) in iOS, and I've read the debates of using Storyboards Vs doing it programmatically, and I get for simple apps Storyboards is the way to go, but what about for Apps that access a server? and need to do lots of things dynamically? it seems most Apps these days would be like that, if that's the case are Storyboards a good idea in that situation?
You have to remember that Storyboards are not an alternative to code. They are a tool that can be used along with coded view, nibs, etc...
The real skill comes in using all of these in such a way that takes least effort and gives most maintainability, readability and reliability.
Many of my apps combine several storyboards and a lot of nibs.
Having said that. Nothing that can be done in a storyboard should be anywhere near any cloud code.
The classes that access the cloud should not change whether you are coding views using nibs or using storyboards.
The article that was linked in the other answer is very odd indeed. To dismiss storyboards as things that are only used for prototyping is just plain wrong.
A well structured app (or part of an app) that access some network stuff should be modelled something like...
[Networking stuff]----[View Controller Stuff]----[View Stuff]
It doesn't matter whether the view controller is created in a storyboard, nib or in code. The networking stuff is unchanged.
Also, the article mentions "custom views" as something that you can't do with Storyboards. Again, that's just wrong. My latest app Emojicate was written using a combination of Storyboards (the project has 2 storyboards), nibs (for custom cells etc...) and a couple of coded views (the emoji message view is coded).
It sounds like the guy writing that hasn't really looked into the various tools in any amount of detail.
Please take a look at the this article. I think it's summarised really nice and briefly the pros and cons:
http://andrewrauh.com/2013/09/01/storyboardsnibs-vs-doing-everything-with-code-in-ios/
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
Lots of iOS development tutorials are full of "just copy this and your button will work" or "this code does this, just copy it and change some variables". I'm trying to learn everything from scratch so it makes the best possible sense. Turns out I can't find any information about Xcode compiling and linking process. And also, I would like to understand how the macros like IBAction are translated exactly. I've found something here, but it does not explain entirely. I want to see the code when its fully assembled with its headers and so...
Is there a way to program for Xcode just with code? I mean, to insert and link all objects with code, no visual processes used.
Does anyone know a good book about this?
Here are some answers to your questions!
Anything that you can do in InterfaceBuilder you can do in code, yep. Configuring view objects is a bit repetitive and ends up being a lot of code for something easy (once you know what options you have) which is why the IB tool is there.
The IBAction flag is actually only used by the IDE to provide assistance in generating the xib so when the file is unarchived, the properties it sets will line up. It's not foolproof as you can make a property, set the outlet, then delete the property and your app will crash!
You can see the output of pre-processor macros by selecting Product -> Perform Action -> Compile/Analyze/Preprocess/Assemble. These are all handy tools to see what Xcode is building under the hood.
Compiling and linking is not too important for iOS development since Xcode is the only tool you use to build your application (with the exception of xcodebuild command) and it handles that all for you. If you do want to dig in deeper, I don't know of a good reference but googling LLVM (the toolset to compile/debug/link/etc) would be a good starting place.
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
The question is about structuring in iOS
So I receive a message from a company where I passed a test and they say:
"First of all I want to highlight that they said (developers who took my test) that they really liked how clean your code was. One thing where you could improve is the structuring of classes which wasn't ideal."
I asked about what actually I did wrong or what should I improve. I am not sure that this is the stack question, but maybe some one can point me or suggest some thing how for example you structure you code.
I am asking because clean and structure and what about I care every time, but right now I hear that is not ideal.
So usually I write code with the count of lines no more then 250 - 300. I care about pragma marks that separate code into lifecycle blocks, i care about spaces and etc.
So my code is separated also into "folders" where I store appropriate logic elements like:
View Controllers
Views
Constants
Models
Helpers
XIBs (if any)
Storyboards (if any)
Each of these folders have subfolders that is not a group as well but real folder on hard drive and each folder contain some classes which named with appropriate name the class does.
I understand there are no rights or examples how to structures project, because it depend on the tasks and developers or company style. But if I receive some message like above, so then maybe can someone suggest something where I can read about or what I miss maybe.
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 have an iOS app that uses a few viewcontrollers with lots of elements. I built the viewcontrollers in the interface builder (in a storyboard). For some key elements (loginbutton, important text, etc..) I created an IBOutlet to be able to use these elements in my code (adjust text/graphics mostly).
For some others where I just needed a quick fix (for example an activity indicator that I show and hide programmatically), I chose to not create an IBOutlet, but instead give them a tag number and access them by the viewWithTag:(NSInteger) method.
This seemed to work for me (it's only my second iOS project so it might be completely wrong to do this). But now that the viewcontrollers get more complex I find it hard to remember which numbers I already used for tags. Is there any way to keep track of this other than by going trough all the elements and checking their tag?
Maybe it's all wrong to use tags this way, in that case that's fine too. I could look them all up once and just create IBOutlets for all the cases where I use a tag now.
I would try to avoid using view tags as much as possible.
There are always other (and almost always better) ways to do exactly the same thing by using properties and data models instead of tags.
Here is an article that I found with some nice examples of why they're not a good idea to use... http://doing-it-wrong.mikeweller.com/2012/08/youre-doing-it-wrong-4-uiview.html
If you need to access a UI element then create an IBOutlet for it in the interface of the class that needs it.
Alternatively, if there are several elements that are the same then you can create and IBOutletCollection which is just an array that contains all the elements linked to it.
EDIT
For anyone stumbling across this now. This is an article from a former Apple engineer explaining why using tags is not only a code smell and bad practice but also a performance issue.
https://www.fadel.io/blog/posts/ios-performance-tips-you-probably-didnt-know/