I'm very new to objective-c and cocoa(started today), I have experience with java and this just seems like a different world. I'm building an app with scene kit and OSRSerialPort(Have looked at the example code and don't understand how the controller is connected to the view). The goal of this is to take accelerometer data from a micro controller and making a visual representation of it with scene kit. I've tried to implement my controller in the same way as the example project in OSRSerialPort's github. Mine just doesn't seem to work. I'm just confused on why my project would don't receive input from the port but the example one receives it just fine when I feel as I've implemented it the correct way. I've attached the xCode project here.
Would love any help on this.
I'm building an app with scene kit and OSRSerialPort(Have looked at
the example code and don't understand how the controller is connected
to the view)
With Xcode, you can connect a Controller to a View without writing any code. When you use Xcode's Interface Builder(IB), almost non-readable xml data is inserted automatically into the .xib file for a window, which is the code that actually connects the two objects.
Then when your application starts, the .xib file is parsed, and the objects listed in the .xib file are created and the connections listed in the .xib file are setup.
I would guess that the connections you can't find are in the window's .xib file.
In fact, ORSSerialPort's README.md says this:
This application demonstrates that it is possible to setup and use a
serial port with ORSSerialPort without writing a lot of "glue" code.
Nearly all of the UI is implemented using Cocoa bindings.
without writing a lot of "glue" code means that instead of writing code the developers did a lot of dragging between objects in IB. And Cocoa bindings is a term of art, but you'll see that you have to understand other things first.
After figuring out how to download the project and open it locally in Xcode, I was able to look at MainMenu.xib in IB. Below is a screen shot of what MainMenu.xib looks like in IB, and on the right hand side there is a partial list of the connections for ORSSerialPortDemoController:
Those connections were established without writing any code.
I'm very new to objective-c and cocoa(started today)
Well, then put your current project aside, and learn the basics of how to use Xcode in Hello World style apps, then work your way up. As you progress in your learning, you will know when you are ready to go back to your current project.
Related
I am following a personal learning path for macOS development, learning the basics of C and Objective-C before moving on to Swift (which I already know a bit, but felt the need to learn where all that came from). I am aware there are better, more modern and functional APIs, so please do not suggest learning that or SwiftUI. The point of this question is knowing what is not working in my example.
I closely followed this tutorial, whose source code can be downloaded from here. My code is available here, instead.
The first thing I noticed while following the tutorial is that Xcode (v 13.3.1 on macOS
12.3.1) doesn't add a Collection View Item and a View to the xib's workbench when dragging out a Collection View from the Object Library to the main window. I worked around it by manually adding a Collection View Item and a Custom View to design the UI as the tutorial showed. I triple-checked and connected all outlets as instructed then pressed Cmd-R to build and run. The app crashed, bringing me to main.m at the return NSApplicationMain(argc, argv); line with the following error:
I understand part of this error, but do not know how to "register one item nib or class", while dataSource is not covered in this tutorial.
Comparing with the source code I noticed that an extra outlet was added from the Collection View, connecting its itemPrototype to the CollectionViewItem. I did just that and, this time, Xcode refused to build throwing this error:
Do you know how to make this work? I would also appreciate any and every explanation on the first error.
Thank you for your patience and help.
NSOutlineView changed quite a bit in macOS 10.11 and isn't compatible with the tutorial. NSOutlineView can be used in legacy mode by choosing layout Content Array (Legacy) in IB.
I'm fairly new to Objective-C and cocoa programming, so I don't really understand the concept of App Delegates.
When we create a cocoa application, do we store our code (Methods, actions, outlets) in the App Delegate files or do we create a new file that will act as a controller and code from there. Right now, I put all of my code in those two files, but from what I read, your goal is to try to make your App Delegate files as slim as possible.
My question is: What's the usage of the app delegate files?
Talking about applicationDidFinishLaunching::
It's just your application entry point. Normally you only create the window and your first ViewController, or your Tabbar - your main starting interface class - here.
All the other delegate methods of the NSApplicationDelegate have other functions of course. Most of them are the point, where you react on the state of the app. Opened / Closed / Backgrounded / Reopened etc.
But you should probably have a look at the programming tutorials in the iPhone documentation. There is a lot of information on how to structure your objc projects. E.g. look here: Start Developing iOS Apps Today
Or if your looking for OSX Apps, look here:
1) Your First Mac App
2) Mac App Programming Guide
There is also a bunch of Sample code.
The App Delegate is a handler location to handle events that occur on the application. Things like open and close. It also hangs around the whole time the application is executing and you can grab the singleton instance at any point by doing [[NSApplication sharedApplication] delegate].
This comes in handy for handing objects between controllers and serving as a router for events. You can also store some data on the delegate if you need to modify/have access to it in different parts of the code.
This all works well for simple applications, but as things become more complex, you need to have some division of responsibilities. The AppDelegate should really only be responsible for actions that occur on the application itself, not on another view or a controller. Putting all/most of your code in the AppDeligate is certainly bad practice and will lead to horrible code as things get more complex and need to be maintained.
I'm stuck on this step of developing an XCode application: https://developer.apple.com/library/mac/#documentation/General/Conceptual/Mac101/Articles/07_WhereNext.html
What I'm confused about is the role of the AppDelegate class that's created by default when creating a project initially in XCode 4. If I implement a custom controller, let's use the example link above and call it TrackController. Do I make that controller the app delegate? It seems any tutorial I read isn't very clear on this.
So, in AppDelegate, do I create a new instance of the controller class here? And if so, do I then hook up the outlet here? Or do I change the File's Owner to be the controller class? If that's the case, then how's that done in XCode 4?
Not a very well defined question I know, but I'm sure someone knows what I'm talking about.
EDIT
The following screenshot shows what I mean. The blue box is now "Track Controller". I've shown the AppDelegate class in this case though to make it clear. What do I use, AppDelegate.m, or TrackController.m? How should it be done?
EDIT 2
Going back to this, I've uploaded the code to GitHub here as I still haven't figured out how to hook everything up.
To re-explain, I need to figure out how AppDelegate and TrackController all relate and communicate with one another. The concepts are generally new to me and I've read the Apple documentation but they haven't really helped me. I've even had in-depth discussions with experts and I still fail to see how it should work.
My model is Track, then I have TrackController and of course AppDelegate. AppDelegate is instantiating TrackController and I was hoping that it'd be able to open up its window.
What am I doing wrong? Hopefully an expert can help me!
What it's describing is that the application delegate should focus on handling the delegate calls sent to the app.
You actually create a new class to act as the primary controller of the app, and then you add code to call it when the app is finished loading. From there on out, that app is (supposedly) your primary control point (except, of course, when it 'hands off' to another class).
I'm more familiar with how the process works on iOS than Macs, which have to worry about windows, but for an iOS app you'd add code to call your starting view controller from inside ApplicationDidFinishLaunching:WithOptions:. From there, the view controller takes off, and the easiest way to view the entire process is that you start at the view controller (that's how most tutorials handle it, in fact, letting XCode handle the fact that the app delegate creates that view controller).
I'm trying to figure how to look at or manipulate the code behind views I've created in tutorial applications I've copied.
I understand that you are supposed to "control" the views using a view controller. The part that's confusing me is that when I follow the tutorials, I'm clicking on my view objects, setting the delegate, but I don't see where that is acutally happening in the code. Are you able to see the code that makes up a view or is that totally hidden from you?
You mean when you are dragging views around visually when you open a nib?
The objects you create and the connections you make are saved to an XML file. When Xcode builds your application, these are then converted to a more efficient binary file format.
When your application runs, the binary file is read, and the objects described within are instantiated. Where connections are made, the nib loading part of the platform uses Key-Value Coding to set the outlets and properties on related objects, most often the nib owner.
You can see the XML representation of your views by right-clicking on the nib in the project navigator panel on the left-hand side, then selecting Open As | Source Code.
You need to go through Apple's "Your First iOS App" guide, and read it, do it, and reread it until just that basic tutorial sinks in.
If you use Interface Builder to create a view (it will create that view in a nib file), you will connect that with a view controller that will consist of an interface file and an implementation file. Within these files you will place code by which you will reference those components in the view, and you will also code methods that will give you behaviors and operations that can be triggered or can manipulate components and data of that (or other) views.
You just need to really digest Apple's documentation better. They have wonderful guides to help you.
I'm writing a Cocoa application where I have an auto generated app delegate:(MyAppDelegate.h/MyAppDelegate.m)
So I am not sure of the best way to structure the class files for this Cocoa application. I understand MVC thoroughly (on the iPhone) but I'm having a block as to try organising the source properly in a Cocoa app.
I need to spawn two separate fullscreen OpenGL views. The problem is that I could simply create classes for "OpenGLView" then instantiate and call all this code into the app delegate, but it seems messy and it's aparently not the place to do it.
How would I best achieve the code structure?
Instantiate your application delegate in the MainMenu.xib file and hook it up. When I've done Cocoa fullscreen stuff, I've instantiated the views in the -applicationDidFinishLaunching method of the application delegate. It *is* messy, because for fullscreen views it doesn't really make sense to use interface builder. This is the same way that other folks do fullscreen apps in Cocoa.