Ruby Motion just came out, and the screencast doesn't seem to say anything about whether or not you can use Interface Builder to build your interfaces and integrate them in your RubyMotion project. Is such a thing possible? Or do I really have code everything by hand, not to mention maintain to different pieces of code for iPhone/iPad?
My rep isn't high enough to create a rubymotion tag, so please help out if appropriate.
I'd just like to point out that RubyMotion 1.3 now support automatic compilation of .xib files that you put into the resources folder. So now the workflow becomes :
Create your .xib file using XCode (no need to create a project, just use File|New...|File) and save it into the resources folder. As there is no support for outlets yet, be careful to set the tag property for each control you want to use in your code (you'll find in the property sheet of each component under the "View" header).
RubyMotion will take care of compiling your .xib file into a .nib file, so enjoy :)
In your UIViewController derived class, load the nib using loadNibNamed:owner:options:, as shown below.
In viewDidLoad, fetch your various components using viewWithTag: and add events handlers using addTarget:action:forControlEvents:,as show below.
As a bonus, next time you want to edit your xib, just do open resources/MyView.xib, it will only launch the good parts of XCode.
class CalculatorViewController < UIViewController
def loadView
views = NSBundle.mainBundle.loadNibNamed "Keyboard", owner:self, options:nil
self.view = views[0]
end
def viewDidLoad
button = view.viewWithTag 1
button.addTarget self, action:'buttonTapped:', forControlEvents:UIControlEventTouchUpInside
end
def buttonTapped(button)
# ...
end
end
Yes you can use Interface Builder in RubyMotion.
.xib files that are located in the resources directory are automatically compiled into .nib files and available to your project.
There is even a way to support outlets if you are so inclined :
https://github.com/yury/ib#readme
http://ianp.org/2012/05/07/rubymotion-and-interface-builder/
But if you really want to use IB then you could still probably use it to lay out your UI and just call
NSBundle.mainBundle.loadNibNamed(MY_NIB_NAME, owner:self, options:nil)
or similar. I don't think that RubyMotion does any name mangling so you can use your ruby classes in IB by explicitly setting them.
You can probably build the interface in IB and call the command-line tools to compile the XIB to a NIB.
However, you aren't going to be able to connect outlets or assign actions because IB can't parse the Ruby source files for the IBOutlet and IBAction tokens. Normally, the NIB loading code makes those connections for you after loading your NIB. You'll have to do that yourself, in code.
Of the two glaring weaknesses in RubyMotion, to me this is the worst. (The other is that lack of code completion will make writing to the Cocoa APIs really tedious.)
Cappuccino had the same problem. They developed a tool called XcodeCapp: https://github.com/cappuccino/cappuccino/tree/master/Tools/XcodeCapp
It creates "dummy" Obj-C files that you can connect your outlets and actions to in IB, automatically parses them in the background and enables you to use IB to layout your Cappuccino UIs.
It should be possible to take a similar approach with RubyMotion (if you really want to use IB).
Johannes
There is someone who has made that:
Here is a tutorial video: https://www.youtube.com/watch?v=cOapNvehbg4
And this is the website https://github.com/yury/ib
Extra-Tipp: To find wrappers for rubymotion check this source
http://rubymotion-wrappers.com/
Hope this helps
Related
I tried to turn a xib project which is downloaded from iOS Developer Library of Apple, into a pure code one for further use, but it didn't work.
I wonder what should I pay attention to when I do this kind of conversion, and I wonder it will help me improve my skill of iOS developing.
Converting the Xib file into pure code part is not a very big task, you just need to be carefully replace the items created via Interface builder by your code part. You can follow this sequence while converting such projects :-
1) Display the elements made via IB with your code.
2) Make sure the delegates and datasources to be connected via code if they were connected via IB.
3) Check for the IBActions, if any to be replaced.
4) Lastly, if you are not using ARC or the Project that is being converted not using ARC then the dealloc part or viewDidUnload method, where we generally make the objects nil and release.
Hope it helps you :)
There are some tool available. For example, http://kosmaczewski.net/projects/nib2objc/
I notice that normal practice is to declare IBAction methods in the header file. I have also noticed that it is not necessary to do so for Interface Builder to recognise the IBAction methods and allow me to link them to controls. So what is the purpose of declaring the IBAction method in the header file?
There is no good reason, unless you have a good reason to expose them to others -or- if you need to open the nibs in Interface Builder.app.
Some people may do it for historical reasons, or out of habit. Prior to Xcode 4, there was a separate app to edit nibs (Interface Builder). Interface Builder was not backed by a compiler in the way you know it in Xc4; It just used a basic objc parser to interpret headers. Over time, it learned to communicate with Xcode. In earlier days, you had to drag and drop headers to sync them ;)
It seems that people may ask: is this view built from a nib. Is it true that a nib is the compiled form, and xib is in XML form, and we don't use nib any more but only use xib? So nowadays, it just means "is it built from a xib"?
I disagree completely with #Nate's answer. IOS has in fact always had nib files, they've just been hidden. You see, when the compiler flattens a XIB file so that it can be retrieved by the application, it actually "converts" it to a .nib file! If you don't believe me, try this:
NSLog(#"%#", [[NSBundle mainBundle]pathForResource:#"myxib" ofType:#"xib"]);
It returns NULL, because it doesn't exist! Now try this:
NSLog(#"%#", [[NSBundle mainBundle]pathForResource:#"myxib" ofType:#"nib"]);
Pretty cool, huh?
So in a twisted way, it is correct to say that a XIB is really a nib.
iOS development has never actually used .nib files. It's always been .xibs. NIB was originally an acronym for NeXT Interface Builder. iPhone development originally used a tool called Interface Builder to create user interfaces, saved in .xib format. Interface Builder has recently been (sort of) merged into XCode 4, so you can build your .xib files there.
Yes, the .xib format is a human-readable XML format, which makes it a little easier to use with version control systems (diffing, etc.) than .nibs.
For legacy purposes, I suppose, the two formats are pronounced the same ... "nib". Probably also because words that start with "x" are difficult to pronounce :)
I am just about to start a universal iOS application. I want to make this application using interface builder only.
Can some one suggect how can I arrange the two nib files? Whenever I create a class only one xib file is created, but I want two xib files, one for iPhone and the other for iPad application as this a universal application.
Also can you suggest which approach would be better i.e. making UI for this universal application through interface or using coding.
Just add another xib file to the project. You can start by making a copy of the first version you make, or with a blank xib.
To ensure correct xib is loaded at runtime you have a few options. I prefer to overload nibName on UIViewController, but you can also just call initWithNibName:, passing the correct nib name.
If you overload nibName, it might be something like this:
- (NSString*) nibName
{
return UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPhone ? #"myphonenib" : #"mypadnib";
}
Personally given a choice, I prefer using xib, as the purpose of them is to "hide" GUI code making "function" code uncluttered..also "WYSIWYG" UI design kicks it for speed of development.
As for adding XIB...do As TomSwift suggest, just add them later
or as I did, do them on bulk later...i.e.
develop iphone bits first
Make copy of project
Convert copy to iPad
Rename Appdelegate & xib with your naming standard e.g *iPad suffix
Retrofit copied into your universal original.
(Note making sure you get all references changes and correct can be tidious & backup everything :)
Good luck.
Good people of StackOverflow,
I am in the early stages of building a non-document-based Cocoa application. What I'm aiming for is a window layout similar to iTunes, with a left, middle, and right pane. The Xcode template for such an application includes a file called MainMenu.xib containing both the main menu, and the main application window, with supporting logic contained in the MyApp_AppDelegate class.
I can already foresee that continuing down this route will eventually lead to a very large and disorganized app delegate class. Therefore, my spidey sense tells me to break out the logic for the main window into its own NSWindowController subclass (and accompanying XIB file). Furthermore, would I be correct to split out each pane into its own NSViewController subclass? This would seem to better separate my concerns, at the expense of more files and some extra code to wire everything together.
The closest advice I've been able to find is in Apple's Interface Builder User Guide but it does not answer the question directly. However, I guess my question is not about nib files in particular, but about high-level application organization.