I am writing a very basic 3D modelling program. I've used LWJGL to render my objects and JavaFX to provide an user interface in a separate window, new thread.
As I saw JavaFX likes to take control over the application, but in my case this was not an option. I tried to pass my already created scene graph to the JavaFX controller class, but I didn't find a way doing this properly.
It's seems to be impossible to pass anything from outside into the main JavaFX class. The start method loads the layout from an FXML file with reflection magic, but this method is called in the constructor, therefore variables are not initialized. Defining a new constructor with parameters throws an exception (class cannot be initialized).
After struggling many hours, I gave up, I've decided to create a new scene graph in the JavaFX controller and created a getter method to it.
public class Toolbox extends Application implements Runnable {
private ToolboxLogic logic = new ToolboxLogic(); //controller, the scene graph is instantiated
...
public SceneGraph getSceneGraph() {
return logic.sceneGraph; // returns the scene graph
}
}
Not a beautiful solution, but it shall work, I said. But it doesn't.
I tried to load a file in two locations:
with code written in the LWJGL renderer
with buttons, calling a method in the controller
If I load a file from the renderer, my objects show up on the screen, but I cannot navigate with the buttons, only the root node appears in the scene graph.
If I load a file from the user interface, I can navigate on the tree, but it doesn't show up in the renderer.
It seems like here
return logic.sceneGraph;
Java would have done a deep copy instead of returning a pointer, and each part of my program is working with its own version of the scene graph.
What is a problem, and how can I make it work properly?
Thank you!
OK, I got it working by setting the scene graph static. Strange! Now, I'm really curious, why it behaves like this.
Related
I created a very simple new Cocoa application, with a new class and custom controller (or object in interface builder, the plain blue cube). I connected all outlets with interface builder and assigned the custom delegate to the class. The problem is, the code does not get executed (checked by setting breakpoints), the window presents itself, and there are no errors.
The code of the class is really irrelevant, I tried once before with a proper set up and it worked there, I couldn't spot the difference however.
The key here is a separate controller together with class instead of the standard App's Delegate, to integrate the project to a bigger one.
I am not very experienced with OOP so I wanted to share what I am currently doing and ask for some advice about how I should go about a couple of things.
I am currently working on a simple game that uses a 2d grid. Here is a quick overview of my class structure:
'GameBoard'- has an array of the possible cell states for the game, and methods that implement the rules.
'GameView' - has the superclass NSView, and is placed in my window as a custom view. This class is intended to read from the game board and draw the contents of the array by mapping the stares to an enumeration of images in its drawRect: method.
'GameController' - this is an intermediate class intended to initialise the game board and view, and handle the various UI controls. This class has instance variables of the 'GameBoard' and 'GameView' type.
Originally, I was doing nearly everything in the View class, and had it working fine but it started to get hard really to follow, which was my main reason for wanting to spread my code over a new class.
I have created a method in 'GameController' that initialises a new game, with some user defined parameters (removed in the snippet to save space).
-(IBACTION)initialiseGame:(id)sender {
gameBoard = [[GameBoard alloc] init...];
gameView = [[GameView alloc] init...];
}
What I want to do here is pass the game view a pointer to the game board instance so that I can read it's array to draw the current state of the game, something like:
-(void)initWithGameBoard:(GameBoard*)gameBoard;
Is this the right way of going about that, or should I be doing this in a different way?
My next problem with moving to the controller class is that I cannot seem to find out how to do is get a pointer to the instance of GameView that I have placed on the window in IB? Would it be better to not place the view on the window in interface builder, and instead place it on the window programatically in the initialiseGame function? If so how would I go about doing that?
I guess one other question would be, should I just scrap this idea and stick to doing everything in the GameDraw class?
Thank you very much for taking your time to read this, this is probably a very simple question to any experienced object-oriented programmer, but I cannot seem to find the answers specifically anywhere.
There's more than one way to do make this work, but here's how I would do it:
Instantiate the view once in IB. Don't invoke alloc/init yourself.
In your view controller, make an outlet for your view and connect it in Interface Builder. That's how your controller will get access to it. Your view controller will need to be the file owner — probably it already is.
Design the view to be reusable. Give it a -setGameBoard: method for the controller to invoke. Make sure the view can draw something blank when it doesn't have a game board.
Write -initializeGame: like this:
-(IBAction) initialiseGame:(id) sender {
gameBoard = [[GameBoard alloc] init...];
[gameView setGameBoard:gameBoard];
}
Sorry for the stupid post, but I am new to Objective-C programming and Cocoa and have a couple of questions which I can't find the answers to, I'm hoping someone can enlighten me.
Firstly, in XCode, when using the Interface builder, when I want to create a new object I drag the object to my 'assets'. However I can't specify methods or anything without manually creating a new class file. Is there any point using the interface builder's 'object'?
The first app I built to test things with, I put most of the code in the AppDelegate class files. Research has shown me that the AppDelegate's purpose is simply handling application events like launching and closing. Was I wrong in putting the methods in this class? Does it make any difference?
Finally, if I have several class files created, each handling their own functionality with an interface built and linked to the classes, then what do I do with the 'main' file? It seems to me that the 'main' file and 'appdelegate' class files will be for the most case left as-is?
I hope that makes sense. Again i'm sorry for the silly-sounding questions but I can't find any answers.
Thanks in advance everyone!
Firstly, in XCode, when using the Interface builder, when I want to create a new object I drag the object to my 'assets'. However I can't specify methods or anything without manually creating a new class file.
Sure you can. Just set the class of the object using the inspector.
Note that you can only connect nib objects to an outlet or action. You can't specify any random methods, nor should you—the whole point of the IBOutlet, IBOutletCollection, and IBAction keywords is to declare in code that these properties/methods are used by a nib.
Is there any point using the interface builder's 'object'?
Yes, but pretty rarely. Usually you create objects in code and connect outlets to them.
The application's delegate is one object you may want to create in the MainMenu or MainWindow nib, if you build your application that way (the iOS templates have changed away from it for some reason).
The first app I built to test things with, I put most of the code in the AppDelegate class files. Research has shown me that the AppDelegate's purpose is simply handling application events like launching and closing. Was I wrong in putting the methods in this class?
Probably. The application's delegate generally should only handle business relating to the NS/UIApplicationDelegate protocol.
On the flip side, it's OK to make your root view controller the application's delegate, if it makes sense to do so (and the NS/UIApplicationDelegate implementation code is not too voluminous). The question you have to answer—and only you can answer it for your application—is whether you are making your root view controller the application's delegate or the application's delegate the root view controller. If in doubt, keep them separate.
Does it make any difference?
Long-term, yes. It's very easy, especially in the class of the application's delegate, to create a Big Ball of Mud class—one without well-defined and clearly-delineated responsibilities. Take dynamite to such a class as soon as possible.
Finally, if I have several class files created, each handling their own functionality with an interface built and linked to the classes, then what do I do with the 'main' file? It seems to me that the 'main' file and 'appdelegate' class files will be for the most case left as-is?
Yes. They're boiler-plate.
If you haven't written any code in the application's delegate (or have removed everything you had put there into new and better-delineated classes), such that all that's left are empty method bodies or none at all, you can safely remove the application's delegate. You can always create it again later if you change your mind.
Note that if you delete your application delegate class, you should also change the main.m file—or the MainMenu/MainWindow nib, if you have one—to not refer to it. Your application won't build if your UIApplicationMain call (or any other code) refers to a class that doesn't exist, and it will crash if your MainMenu/MainWindow nib (or any other nib) refers to a class that doesn't exist.
There is no shame in your application having a delegate if you need it to, but if you don't, removing it and the class you were using for it eliminates future temptation to stuff code there or use it to store third-order globals.
The point of using objects in interface builder is to connect methods of the object to UI elements.
It partly depends on what your methods are doing, but for the most part the app delegate class is going to be left alone. It isn't an actual requirement (your program will work either way) but it is common practice because it generally creates more maintainable code. The app delegate should just handle the application events ( using other classes to do any complex logic or heavy lifting ).
The 'main' file will most likely not change. I can't think of any reason to do so, but I wouldn't rule it out for some advanced cases.
To be honest I only used the Object thing in IB once, when I wanted a separate object to have some UI bindings.
About the app delegate and main file, yes, you'll leave them as-is most of the time. But if you try to do something besides test apps you'll need to handle open events to, for example, connect to a server, ask the user for a review, increment some launch counter, etc... Those are just examples!
The main file I advise you to left it alone and use the object oriented tools provided. You should have a view controller hierarchy, isolate your views from the data, and use the view controller to comunicate between view and model. Read about MVC if you want more info on how your application should be organized.
I am getting incredibly frustrated with interface builder at the moment, and would appreciate some help before I ragequit it and code everything by hand (which seems to be much, much, much easier).
The basic situation is this: I need to make a model variable accessible to each view controller in my application.
The simplest way I can see to do this is to just create a property on the view controllers that retains the model, and to set that after the controller is initialised.
However, I can't find any of the actual initialisation code for the views shown on the storyboard in my project. There's no reference to any of them at all. Does the interface builder really generate not generate any code reference to its controllers in the app delegate?
For that matter, why is there no reference to any of the top level controller objects (tabview, tableview etc) in code at all?
All I want to know is how to force xcode to actually generate the controller creation code in AppDelegate.m - so that I have access to the created instance of the controller - or, failing that, a way to share the model between these amorphous objects.
Maybe it would be easier to create a singleton class where you can store all your global variables and methods. Example here.
You will need to manually create a subclass of your view controller and then override the methods you want to inject code into. In Interface Builder you can then choose to make your View controllers of this custom type.
I've been trying to learn Core Data, and browsing through questions on Stack Overflow lead me to a recommendation that I try the tutorial on Core Data over at Cocoa Dev Central (Link).
Everything is making sense so far in the tutorial, but when I got to step 16, it wouldn't let me connect the + button to the Posts array controller. I've gone back and double, triple-checked each step along the way and can't see where anything is off, but it still won't let me connect. I'm using the latest versions of Xcode and Interface Builder (just re-downloaded them last week); could this be a version compatibility issue?
Addendum
Seems that the problem was in that I had to change the name by changing the class in the inspector, and that removed the default actions for the array controller. Changing the class back to NSArrayController restores functionality, but now it appears as "Array Controller" wherever it appears, which seems like it'd become problematic with 3 controllers in play once I fix the Authors and Topics controllers.
Got it. Under the inspector, use "Name" to change the name of the object, not "Class". Newbie error.
Based on your comments, you changed the class of the Posts controller from an NSArrayController to a custom class called Posts. Interface builder couldn't find an implementation for this custom class, hence, did not show any actions or outlets available to bind against.
Changing the class back to NSArrayController fixed the problem.
(Interface builder lets you do this as you may want to define your own custom controller. You can add the actions and outlets to the object in IB, then generate the class and add the implementation in XCode. This is quite useful - but can confuse new users of the tool.)