To separate action methods out of the app delegate, I moved them into modules in the relevant controllers and included the modules in AppDelegate.
However at first, I tried to define the actions for each controller in a hash and use define_method to dynamically create the methods. That gave me the error method '<action>:' created by attr_reader/writer or define_method cannot be called from Objective-C. Please manually define the method instead (using the 'def' keyword).
Compared to define_method, including modules not very efficient with RubyMotion. For this situation performance is not as important, but is there another way to create methods on-the-fly that can be called from Objective-C?
From what I can understand from your explanation of your problem, you're handling actions in your app delegate. It's important to handle this kind of stuff from your controllers or to put the actions in your views, then setup a delegate for your view.
When it comes to RM though, you will have to work around not being able to do things like this.
I can't think of a time where this would be the only way to do what you're trying. Using Napalm's suggestion is one way.
If you were creating lots of events for dynamic content or server provided content, you can just use a method that uses those values instead of defining a method's definition off them (as define_method is usually providing a very similar method for all the dynamic methods it defines). Just try using normal `
There will be lots of alternative solutions available to you.
Related
I am having a very difficult time finding the answer to this. I want to create a custom class (this I know how to do) and have it get instantiated--one instance--that is globally accessible from within my application. I am looking to centralize and abstract some code and use this globally-available object as an interface. I can't believe how weird this is to figure out.
I need to have models, etc., available from within this object.
Help is appreciated.
I am running Rails 3.2.8.
Any model that you put in app/models will be autoloaded by Rails, so you can stick a custom model there.
The class will be available throughout your app, so whether you can just use class methods or not is up to you. If you want it to be a singleton, see this helpful article.
Lastly, if you need the model to instantiate in some specific way, just put it in an initializer. Any file in config/initializers will be run once as the app boots up.
You probably want a Singleton...
http://www.ruby-doc.org/stdlib-1.9.3/libdoc/singleton/rdoc/Singleton.html
However, that will only be available to that apps process. If you run multiple app servers (ie. multiple thin instances or Passenger) each will have it's own instance.
If you need something truly global you'll have to look into other options.
I am developing a Game Project and wish to use the Object Composition pattern to give me a great deal of flexibility. I currently override message forwarding methods in order that the Composite can invoke the methods of its Components.
The only downside to this is that -forwardingTargetForSelector: only works when there is to be only one target. If I have a Composite with two Components that have the same selector, then I will have to resort to using the (much slower) -forwardInvocation method and perform the NSInvocation on both the targets.
From reading a few books on advanced Objective-C and Runtime reference, it seems that I may be able to forward messages by dynamically creating an implementation that will invoke the IMP in the child Component Classes. I would use the Runtime method class_addmethod to do this.
My question is, does anyone know if Apple considers this to be private API and thus against App Store Rules? Has anyone used class_addmethod in Apps that have passed review?
It is common knowledge that method swizzling is not allowed in the store, but this is not exactly the same thing. One typical example was swizzling the -drawRect: on UINavigationBar, before the Appearance API was available. This would be adding methods to my own object rather than messing with Apple's own API.
Thanks for Reading!
Lawrence
From what I've read as long as you're not swizzling Apple provided classes to alter functionality, you should be fine. The Objective-C runtime isn't a private API, so if this is all happening on your own code then you should be fine to do this.
I'm working on an exiting iOS app (called Mazin in the App store, if anyone is interested) and I'm trying to rework the code to avoid using the Application Delegate or a singleton for sharing information/methods. In particular I have the following to share across certain views and controllers:
CoreData objects like NSManagedObjectConttext and related custom methods for interacting with the data
State properties used in several places like currentMazeType, gameMode, and soundIsMuted along with a few widely used utility methods particular to the game
Views and methods used to display information used commonly throughout the app (e.g., an ActivityIndicator and methods to show/hide it on a given view)
In general, several views and ViewControllers need access to various subsets of this information and I need a mechanism to share the information and methods "globally" across these objects. Some of this sharing is for convenience (e.g., every time I want to display a basic activity indicator, I just call a common "startActivityIndicator" method) but some are required (e.g., changing gameMode changes it "globally" and several views/controllers need to access the common mode info).
What sort of patterns would work best for this requirement? I have my own solution in mind, and I'll post it below for your consideration/comments.
Thanks!
Solution I am considering:
I plan to create a few "utility" classes (e.g. GameDataUtil, AppStateUtil, GadgetsUtil) that each encapsulate a proper subset of the "global" information and/or methods. Each View or ViewController that needs to access the common info/methods in a utility will have an appropriate property of that given type (e.g., a view that can make a sound needs access to the AppStateUtil so it can determine if sounds are currently muted).
The ApplicationDelegate will be the only class that generates single instances of the "utility" classes and will pass those instances to the appropriate objects that get loaded from its Nib (in applicationDidFinishLaunching). Those views/controllers will have to pass all necessary information to any of their members that they may load programmatically (which could get hairy--class A may need a GagetsUtil in order to pass it to an instance of class B even though class A never uses the utility directly).
This is sort of like injecting dependencies from the application delegate down (since I don't have the utility of an Dependency Injection Container).
Now, I have thought about creating an uber-utility (e.g., ConfigUtil) that would hold one property for each of the other utilities. The AppDelegate would create a single instance of the uber-utility (setting it up with instances of the other utilities it creates). The AppDelegate would pass the uber-utility instance to anyone who needs access to any of the basic utilities. Each basic utility would still encapsulate a sub-set of the common data/methods, but by putting one of each into an uber-utility and passing it around, I don't have to keep up with which utility is needed by which class (not only for its own use but also to pass to any of its member objects).
NSNotification would be a step away from that model, and is typically easy to implement.
If many things know of and refer to mutable global data right now... it will take time to undo that.
Update
I remembered that I had written a more detailed response to a similar scenario here at SO.
This is a question about best-practices.
I have an application that uses a standard iOS tab controller.
One of the things that I'd like to do is split the XIB up into separate files. I can achieve this by specifying the 'child' XIB in the 'NIB Name' section for each tab controller. So far, so good.
In this application, I have an object that is used by virtually all of the UIViewControllers (e.g: provides web service calls). Let's call it MyServices.
In the single XIB solution, I can drag an object onto the Objects list, set the type to be 'MyServices'. I can declare in each ViewController an IBOutlet of type MyServices*, and wire the two together. This works nicely.
However, if I move my view out to a separate XIB, any controllers further down the stack that need access to the MyServices object are out of luck, because the object no longer exists within that XIB to perform wiring with.
What I'd expected to be able to do is to declare an 'external object', and wire to that instead. But I can't see how I 'pass' the MyServices Object in the 'parent' XIB as the 'external' object in the child XIB.
Is this just not supported in IB? What is the best alternative?
I could not specify the XIB name in the controller, and perhaps programatically create it at runtime (presumably with some kind of loadFromNib code declaring a dictionary to provide the external object). This does mean that the controller that does this has to be aware of MyServices, even if it doesn't use it directly.
Alternatively, I could have a 'dataProvider' in each UIViewController, so instead of setting the MyServices directly as an IBOutlet, it could do do [dataProvider getServices]. Again, will have to be wired to something that can do that - which limits where XIBs can be broken up. And it feels a bit needlessly verbose..
What's the best practice here?
It looks like with using External Object, you take the object instantiation back into your own hands and you also have to instantiate the NIBs manually. At least that's what I gathered from the answer to How to use a common target object to handle actions/outlets of multiple views?
Can I use Interface Builder to inject dependencies across multiple nibs? asks very similar question to yours, also without a real solution.
In How do I set up a proxy object in the main application NIB? the author also gives up on the idea of using Interface Builder as a dependency injection tool.
So I would guess that we, the Java immigrants, are banging our heads against invisible walls here. The metaphors we use to shape the code in our heads (and the code qualities we've come to value and associate with quality), do not apply to Objective-C, as is. That might be because we are not familiar with Obj-C idioms. Or it might be, that we are dealing with different evolutionary stages of language and community development (for example see the staggering immaturity of TDD practice in Obj-C). I, personally, have not seen much best practices described in Obj-C world in the 9 months that I am seriously dealing with it.
I am looking to write a plugin controller in Cocoa that loads bundles, and exposes a specific set of methods for the plugins to call.
My question is this: is it possible to know (any) info about the object that called a method in the controller. When an instantiated plugin calls a method in my plugin controller, I would like to know which of the plugin instances called the method, without having to rely on the plugin sending a pointer to itself as a parameter (I could always validate the pointer they send, but I want to keep the API methods as simple as possible).
There may be no perfect solution (and there are simple workarounds), but it's always good to learn some new tricks if possible (or the reasons why it's impossible).
Thanks in advance.
It's not possible without walking the stack, and possibly not even then. There's not even a guarantee that a given message was sent from within a method — and even if it was, it may not be the method that you think of as being the "caller." For example, assuming your plugins have access to Cocoa, your controller methods could be called by an NSTimer.
In general, this is not practical. The normal way to accomplish this is to have objects pass themselves around. If you're trying to do this for security reasons, you'll want a much more robust solution anyway, because Cocoa's object model was not designed with that in mind. It's way too easy for objects to lie about who and what they are.
Well, you could throw an exception, catch it and examine its stacktrace.
Assuming that Objective-C supports exceptions, of course.
Sending a reference to the calling object is how this is usually done. As an alternative, you could have your host code provide a proxy object for plugins to talk to. As each plugin is loaded, create a new proxy object for each to talk to.