I'm new to Typhoon. I'm reading documentation to inject dependencies into my storyboard's view controllers. I have basic understand of how the framework does the DI on classes, but storyboards seems complicated. I have read both storyboards and PList integration documentation but I'm kind of confused.
This may sound silly and obvious. If my storyboard filename is Main.storyboard, in my plist I'd add key UILaunchStoryboardName with value Main.storyboard?
What would be the value for key UIMainStoryboardFile?
Do dependencies get injected automatically or how do I specify which dependencies get injected into each of my storyboard's view controllers?
I was unable to find an example or tutorial that uses storyboard (and since most of them are in objc and I'm working with Swift, it's kinda hard to follow up every step, so I apologize in advance if these questions are silly
To answer questions one and two, if you create a project from Xcode specifying to use storyboards, then those values will already be completed in your plist. If you have a legacy project, this is a nice way to see what those values should be.
As for question 3, if you 'annotate' your storyboard view controllers with auto-injection macros, then dependencies are indeed injected automatically. For non-storyboard view controllers then to have dependencies injected, an instance should be obtained from Typhoon, just like in the Quick Start.
Note that you can inject the assembly itself into a view controller, in order to load an injected object graph 'on demand'.
Related
What is the best way to handle the storyboard with multiple developer while using SVN. I'm facing issue while commit with other developers storyboard.
For a team to work on the same app it's recommended that every developer creates a separate storyboard file for the feature / module he working on that way no conflicts would happen , only drawBack i think is that instead of easily using self.storyboard , you have to create the storyboard object corresponding to the name of the storyboard you created but it can be handled with a simple extension
I would personally prefer taking multiple storyboards in such a situation. Use storyboard references as much as you can. This will not only help your developers to independently work with their storyboards, but it would also separate multiple functionality or to be specific, modules, from each other.
I have a Swift project which contains a lot of screens (got from xibs and storyboard) with many core functionalities.
Now two different projects based on these core functionalities are needed. The requirements are these projects must have different headers, cells, colors, assets, etc.
Which strategy would you follow to get different interfaces based on target/project, from a single core framework?
static config:
maybe pull all project related variable, and put it in a plist file, working like archiving and unarchiving. when framework loaded, get boot info from that file.
or abstract all these info into a static class? works almost the same way.
some way dynamic config:
delegate pattern: every project who want to use your framework, must
implement one object with pre-designed protocol, use the object to bootstrap framework, your framework should get the project layer based question answers like header file, assets, etc.
sorry for my English, hope this helps.
;)
I have a VIPER module (SubjectList) in which I want to have a more generic HeaderModule, with a SubjectListCollectionModule and a BlockModule. At what point would I logically add the HeaderModule?
I could include the modules in the SubjectListViewModel, but I could also render them in the SubjectListView, instantiate them via Interface Builder, use xibs. What is recommended?
I recently made a sample project which is built using the VIPER architecture with the help of the codegen tool called Generamba.
Here is the project:
https://github.com/dimklo/ViperSample
In this project you can find the module called News. This module has two submodules named NewsTable and NewsFilter. These submodules are presented from the News module router in methods presentNewsFilterModule and presentNewsListModule.
The submodule creation code there is not very easy to follow but maybe it will help you somehow.
Use of xib is a good option, but I suggest you go with Interface Builder. That'll be a more well-to-do thing with VIPER.
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
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.