Basically I have a load of classes which are all subviews of UIView.
The app is a (sort of) slideshow application. I want to be able to make lists of potential "routes" that the slides could take in plists.
As such I may have 100s of classes and I don't want to have to include all of them in the potential that I may use one of them once.
So is there a way around this? Can I instantiate a class without including it somehow?
Or am I going to have to include every potential class I'm going to use?
Is there a "global include" like include all... clutching at straws here. :p
Thanks
Tom
Why would you have hundreds of classes? It sounds like you have roughly one custom class, which would represent a slide.
Your comment on the question helps. Consider separating the slide from its content. You could have a single slide class which provides the functionality common to all slides, including the ability to manage one or more content objects. Then you'd create a bunch of different content classes: spreadsheet, animatable graph, checklist, whatever. A slide would look at its data to figure out which content class to instantiate.
If you have a common base class for all your content classes, the slide class only needs to know about the base class. The content base class could act as the manager for all the content classes. You could give it a factory method like -contentForData:(NSData*)data that returns an appropriate content object for the given data. The slide class doesn't need to know about anything more than the content base class then, so this sort of accomplishes your goal of instantiating your content classes without having to include all their headers in your slide class. The content base class would, of course, still have to know about all the content classes.
It gets a little tricky with the base class needing to know about its subclasses but the subclasses being derived from the base class. I think you can get around this by using a forward #class declaration in the content subclasses.
If you're using the class, you must know what set of messages it responds to. Factor out that information into either a common superclass or a protocol, and then you only need to use that.
Can I instantiate a class without including it somehow?
I guess this is not possible because compiler should definitely see class definition in the current scope before using a variable of class type.
IF I understand your question correctly, you want a single place to put your #include directives so that every class in your project has access to them. You can do this in the ProjectName_Prefix.pch file. Any #include or #import statements there will be included in every source code file.
Related
I'm working on a game (in Unity3D) which consists of a dozen menus and no real 2d/3d game world. From a programmer's perspective it is just a bunch of buttons, labels and images.
To not have everything inside of one big menu class, I decided to split the code in parts for every menu. The result is that I've got a dozen classes which themselves have all the references to their gameobjects and e.g. the button methods.
My problem is that almost everything in my project is static by now, because these menus do not get instantiated multiple times and I have to access variables and methods from one menu with the script of another menu.
Thus my question is what the best practice would be for this situation. I've got a couple of ideas, how I could do it, but unfortunately I didn't get to learn what to do in such a situation.
So if you straight up want to suggest something, feel free to do so. :)
My ideas:
1) Make a controller which has static instances of all menus. A button-method in class 'A' could then call Controller.B.x. This does work, but I dislike putting "Controller" everywhere so often, because most classes access methods and variables from other classes so often, that it's just ugly.
2) Make these menus all be singletons. Afaik are singletons "ok" for something like this, but aren't they just shifting the static instance to their own class instead of one controller? When I switched from option 1) to this with one class, basically Controller.A.x became A.instance.x, where "instance" is the static instance of the class inside the class.
3) Keeping everything the way it is, having variables and method being static whenever I need to access them statically from another class, otherwise make them private.
The game is probably not a "bunch of buttons, labels and images".
I suggest to forget about the menus for a second, focus on the model of your game, create classes strictly for that. You don't put things like "how much of a currency does the player have" in any menu, it should exist in a Player class or similar (the model).
Once you can manipulate your model from a single test controller class, and simply log the results in debug console, you're ready to do the same with menus.
After that, you can much easily create user interfaces to read /display (creating labels and images on the fly) and write (hook button events into) the model beneath. These UI classes will probably have so much in common after that.
You can use UnityEvent class for communication between UI and model, they are nicely shown in the Inspector (the same events used in UI Events and Event Triggers).
Fore more general info, Google on some design patterns like MVC, MVP, MVVM, or VIPER.
My recommendation is to strongly consider why you have statics. I understand your reasoning that they are singletons but I don't think that is a good enough reason.
I hope you are using the Unity GUI features properly.
I would just write a base "Menu" component. Then you can add references into the sub classes. For example.
You have a "StartMenu" class derived from "Menu" which is derived from "MonoBehavior". In "StartMenu" you write a method "ShowCharacterCreationMenu()". Then add a button component and hook the method up to that button press. StartMenu will have to have a reference to Character menu. This is the classical OOP approach.
I would do this a little differently though. Unity's strength lies in component based design so I would lean towards that. I would probably create a "Transition" component class that listens for a button press. When that button is pressed it goes to the next menu.
Hope that makes some sense.
I did something a little bit nasty today.
All of our view controllers inherit from two different parent view controllers, let's say XXXViewController and YYYViewController. XXXViewController in turn inherits from TrackedUIViewController, which is a class provided in the Google Analytics SDK so all your view controllers can inherit from it and easily track them.
YYYViewController however, inherits from a different type of view controller. Ah, and it's an open sourced piece of code that I really don't want to change.
What's the problem here? We cannot track any of the YYYViewController children because we can't access the methods provided in TrackedViewController, since they are private.
I don't want to modify the source provided in the Google Analytics SDK. So what did I do? Create a category that exposes those methods, just to avoid the compilation error.
The obvious downside to this is that the GA source code changes it may break, but it will be fairly easy to detect.
I was wondering what other problems I could be facing by doing this, and if you guys can think of a better approach.
Thank you
You can go up in the inheritance chain of YYYViewController, see in turn what class it inherits from. If it's UIViewController, simply change that particular superclass to TrackedUIViewController in the source and you're fine to go.
Example for better understanding: suppose YYYViewController inherits from ZZZViewController, which in turn inherits from UIViewController. Now you can change the superclass of ZZZViewController from UIViewController to TrackedUIViewController - since TrackedUIViewController inherits from UIViewController, no functionality will be lost, but magically your whole YYYViewController class will become trackable.
Hope this helps :-)
You already mentioned the biggest risk of using undocumented APIs: Changes to the API are beyond your control and may break your logic, for example if methods are removed/renamed, or their behavior stops matching your expectations.
From the purely technical point of view, I can see no further problems, since in Objective-C all methods are public. As long as they continue to exist, you may continue to call them.
I would say the root problem is excessive subclassing. Keep view controller hierarchies shallow. Use composition instead of subclassing. If you must subclass ensure that functionality that a class provides can be turned on & off by it's subclasses.
I tried to create a properties view for a graph model in an Eclipse RCP Application. The graph elements are from a non-eclipse library and so don't implement IAdaptable or even IPropertySource.
The Tabbed Properties View, explained here:
http://www.eclipse.org/articles/Article-Tabbed-Properties/tabbed_properties_view.html
seems to be a simple possibility - but only for inputs that implement IAdaptable.
I've thought about implementing my own IPropertySheetPage but the only implementations I found are the built-in PropertySheetPage and TabbedPropertySheetPage which are very complex.
Is there another way to create a properties view for input elements that don't implement IAdaptable? Can I use Tabbed Properties View in a way I don't see yet? Are there any other less complex implementations of IPropertySheetPage, I can look at?
Thank you!
Kristina
Actually, you can write an IAdapterFactory for objects which don't implement IAdaptable and register it in plugin.xml or in your plugin activator. See http://www.eclipsezone.com/eclipse/forums/t61666.html.
Are there any other less complex implementations of IPropertySheetPage, I can look at?
Short answer: No.
But why don't you wrap the non-adaptable object into your own object that implements IAdaptable or IPropertySource or whatever, so that the property-page can work with your wrapper which holds the object you want to make editable through the property-page. And instead of providing this "library" object to global adapter-mechanism, create the wrapper, set the object and provide it to your global selection-service or whatever.
I have an iPhone app that uses a Tab Bar Controller with 3 tabs. Each tab is a separate class. There are several methods that are identical in each class. Instead of having three copies of the same method, I'd like to share the method between the classes. However, I have not figured out how to do this.
Thanks.
This is a classical case of inheritance. Create a base class, and put all things that are common across the classes you are trying to build, into it, both functions and data members. Then, derive your three classes for your tabs from this class (inherit from it, or make it the parent class, lots of overlapping terms here that people generally throw around). Make sure your methods in the parent class are NOT defined as private methods. That would make them inaccessible to your child classes. Hope that helps!
Here you can make a new class and define that method inside that class which you want to share between more than one class.
Now whenever you want to access that method, just import the class and you can use the same method in multiple classes.
Let me know if you need more help.
I have two classes that are already subclasses of a different parent (due to an external library I cannot change this). However I want to share some common code between them, say for example, code that handles an action after a popup dialog etc. How do I do this?
Refactor the shared code into its own class, and include an instance of that class as a field/property within your other two classes.
You can re-factor the appropriate code into a utilities class, and then have the two classes call it. As for the iPhoneSDK, you can probably have the utility method be the delegate method itself.
You could write a category on a common ancestor class. Then both classes could import that Category and call the common code.