The app I'm working has images embedded in the bundle; they may be JPG or PNG. Trying to find a path those resources can be done in one of three possible ways, as far as I see right now:
1) NSString *imgPath = [NSString stringWithFormat:@"%@/%@", [[NSBundle mainBundle] bundlePath], nameOfImage];
#1 is what I ended up using, since that's exactly where the images are located and I don't have to be concerned about the type of the image.
2) NSString *docPath = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory,NSUserDomainMask,YES) objectAtIndex:0]; // And add as part of a formatted string, like in item 1.
#2 was a side path I took, forgetting that you have to add the references as part of a folder structure (which I'm not completely clear on at this time)
3) NSString *jpgPath = [[NSBundle mainBundle] pathForResource:nameOfImage ofType:@"jpg"];
#3 was the way I was recently taught, but the it always bothered me that there was an "ofType" message. How can you rest assured that the image type will ALWAYS be of that type. I'd have to do a bit of extra work (pulling from a plist, or database, or parsing the image name) to ensure I had the proper resource type. And since images are, very generally speaking, interchangeable (at least as far as my content developers are concerned!), I feel this is a case where it pays to be more flexible, so #3 just doesn't work for me (in this situation).
Showing posts with label obj-c. Show all posts
Showing posts with label obj-c. Show all posts
Monday, November 9, 2009
Thursday, October 8, 2009
Unrecognized Selector Error
In case you get this:
Remember to synthesize the property in question (in this case 'Delegate', which would require a 'setDelegate' selector if I were to hand-code the property). I like Objective-C overall so far, but there are a few quirks that bug me. The property + synthesize issue is one of them. You don't have to call @synthesize if you make the getter/setters yourself, but failure to do either thing should generate an error, not a warning like it does during compilation. I totally missed it.
2009-10-08 17:26:29.125 MyApp[5487:20b] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[HowToPlayViewController setDelegate:]: unrecognized selector sent to instance 0xd3dae0'
Remember to synthesize the property in question (in this case 'Delegate', which would require a 'setDelegate' selector if I were to hand-code the property). I like Objective-C overall so far, but there are a few quirks that bug me. The property + synthesize issue is one of them. You don't have to call @synthesize if you make the getter/setters yourself, but failure to do either thing should generate an error, not a warning like it does during compilation. I totally missed it.
Wednesday, September 30, 2009
Basics of Xcode
My buddy already knows the Mac well enough to move around and has installed Xcode before. I'm not going into the install process; the instructions are clear enough. After the install, you can launch Xcode from Developer:Applications:Xcode.app.
On first launch, you'll see the Xcode News; I usually uncheck the display again box. You can restore it from under the Help menu. Close it for now.
Click File->New Project. You get something like this:
Lots of options to choose from. In the selection column on the left, you can pick from iPhone OS and Mac OS X options, as Xcode is used to develop software for both platforms. We're interested in the iPhone OS section for now. Under "Library" you can produce a static library, which is basically a collection of code that you can create to re-use across multiple application and share with your friends and family. That's a topic for another day.
Under "Application," there are a variety of choices. They are all ways to quickly generate a foundation of pre-written code for specific needs. You could choose any one of them and by adding and removing the write code, create another one from the list. There is nothing special about any of the project templates other than the fact they generate extra code for you that you might have needed to write anyway.
That said, choose the "Window-based Application," click on "Choose...," name the project something like 'MyCoolApp' and save it. This should pop up:
There's a lot to look at. Here's the high level things we're concerned with:
Groups & Files is where the source code, resources, libraries and lots of other things live. You'll be spending much of your time in the Classes group. You add, move, and remove groups as you desire in order to best organize the project. A well organized project is a happy project.
The contents of whatever is highlighted here will show up in the upper, right side, dual-colored pane. Any files that you highlight will show up in the lower right side editor pane, including pictures and plists, but not the likes of xib/nib files.
It's useful to go backwards up the Groups & Files list, starting with Frameworks.
By default, the Frameworks group contains the basics: UIKit, Foundation and CoreGraphics. These libraries give you the basic tools to start writing sophisticated code. You'll end up using at least one thing out of each of them 99% of the time, so Xcode puts them there automatically.
Under Resources, you get a the MyCoolApp-Info.plist (or just Info.plist in some cases) and the MainWindow.xib. The plist is the property list for the application and is used to set, as would be expected, various properties concerning your application, including the name that is to be displayed on the iPhone (otherwise, your app would be named the same as your project, i.e. "MyCoolApp").
The xib file (called a 'nib' file, despite the spelling; Mac OS X uses nibs while iPhone uses xibs. Coding for the Mac has been around longer and the name has stuck, since nibs and xibs essentially do the same thing) contains "freeze-dried code." Without going into too much detail, it part of the system (which launches the Interface Builder app) where you can easily layout your user interface without having to write code. However, you will need to write code to actually get your nifty new layout to do anything when the user taps on the screen.
The Other Sources group never gets touched. You can look at the two files in it, but don't touch them. I may mention somethings about 'main.m' in a later post.
And lastly, the Classes group is where you will do the main bulk of your work (unless you create another group that you'd prefer to work in). Under the Window-base Application template, there are two files, MyCoolAppDelegate.h and MyCoolAppDelgate.m.
The .h file is a header file; it is in essence a public view into the code. If someone is interested in how your code works (as located in the .m file), they would look at the .h file (because the .m file is typically not available for viewing). The .m file is the source code itself and where all the work happens. You will have multiple .h and .m files in any app that is of reasonable complexity.
That's it for now. More coming soon, hopefully.
On first launch, you'll see the Xcode News; I usually uncheck the display again box. You can restore it from under the Help menu. Close it for now.
Click File->New Project. You get something like this:
Lots of options to choose from. In the selection column on the left, you can pick from iPhone OS and Mac OS X options, as Xcode is used to develop software for both platforms. We're interested in the iPhone OS section for now. Under "Library" you can produce a static library, which is basically a collection of code that you can create to re-use across multiple application and share with your friends and family. That's a topic for another day.
Under "Application," there are a variety of choices. They are all ways to quickly generate a foundation of pre-written code for specific needs. You could choose any one of them and by adding and removing the write code, create another one from the list. There is nothing special about any of the project templates other than the fact they generate extra code for you that you might have needed to write anyway.
That said, choose the "Window-based Application," click on "Choose...," name the project something like 'MyCoolApp' and save it. This should pop up:
There's a lot to look at. Here's the high level things we're concerned with:
Groups & Files is where the source code, resources, libraries and lots of other things live. You'll be spending much of your time in the Classes group. You add, move, and remove groups as you desire in order to best organize the project. A well organized project is a happy project.
The contents of whatever is highlighted here will show up in the upper, right side, dual-colored pane. Any files that you highlight will show up in the lower right side editor pane, including pictures and plists, but not the likes of xib/nib files.
It's useful to go backwards up the Groups & Files list, starting with Frameworks.
By default, the Frameworks group contains the basics: UIKit, Foundation and CoreGraphics. These libraries give you the basic tools to start writing sophisticated code. You'll end up using at least one thing out of each of them 99% of the time, so Xcode puts them there automatically.
Under Resources, you get a the MyCoolApp-Info.plist (or just Info.plist in some cases) and the MainWindow.xib. The plist is the property list for the application and is used to set, as would be expected, various properties concerning your application, including the name that is to be displayed on the iPhone (otherwise, your app would be named the same as your project, i.e. "MyCoolApp").
The xib file (called a 'nib' file, despite the spelling; Mac OS X uses nibs while iPhone uses xibs. Coding for the Mac has been around longer and the name has stuck, since nibs and xibs essentially do the same thing) contains "freeze-dried code." Without going into too much detail, it part of the system (which launches the Interface Builder app) where you can easily layout your user interface without having to write code. However, you will need to write code to actually get your nifty new layout to do anything when the user taps on the screen.
The Other Sources group never gets touched. You can look at the two files in it, but don't touch them. I may mention somethings about 'main.m' in a later post.
And lastly, the Classes group is where you will do the main bulk of your work (unless you create another group that you'd prefer to work in). Under the Window-base Application template, there are two files, MyCoolAppDelegate.h and MyCoolAppDelgate.m.
The .h file is a header file; it is in essence a public view into the code. If someone is interested in how your code works (as located in the .m file), they would look at the .h file (because the .m file is typically not available for viewing). The .m file is the source code itself and where all the work happens. You will have multiple .h and .m files in any app that is of reasonable complexity.
That's it for now. More coming soon, hopefully.
Starting from Scratch
A co-worker of mine is interested in learning Objective-C. He has literally no coding experience at all, so I'm going to try and help him along. As you can imagine, I'm starting with the absolute basics. He is computer savvy, so that makes it a bit easier since I can often hand wave application level topics (like what a 'Group' is in Xcode and how to add files to it for example).
I think that Objective-C is a actually a fairly reasonable first language to start with (compared to C/C++/Java). Xcode and Interface Builder hide a lot of the nitty-gritty away from the user, so the ramp up time to get something fun and meaningful going is fairly short. You still have to take time to understand the concept of pointers and memory management which I think is a good thing. I always have been very conscientious my stack and heap issues and I think it has made me a better programmer. Luckily, memory management is very well defined (here), and the basic concepts are quick to grasp.
My plan is to get him up and running with the basics of computer science and present to him some best practices early on so that if he takes to it like a fish to water, he is got a solid foundation.
I think that Objective-C is a actually a fairly reasonable first language to start with (compared to C/C++/Java). Xcode and Interface Builder hide a lot of the nitty-gritty away from the user, so the ramp up time to get something fun and meaningful going is fairly short. You still have to take time to understand the concept of pointers and memory management which I think is a good thing. I always have been very conscientious my stack and heap issues and I think it has made me a better programmer. Luckily, memory management is very well defined (here), and the basic concepts are quick to grasp.
My plan is to get him up and running with the basics of computer science and present to him some best practices early on so that if he takes to it like a fish to water, he is got a solid foundation.
Thursday, December 11, 2008
Objective C Doc
Found this link at another blog (fullof.bs; no seriously, that's the domain): http://ktd.club.fr/programmation/fichiers/cpp-objc-en.pdf. So far, it's been a good read. Thought I'd post it since I've been away from the blog for a bit. Work and life has taken away my time to program for the iPod. Hope to get back to it soon. The more I read of Obj-C, the more I like it.
Sunday, November 16, 2008
Finally Displayed an Image
I'm not liking the Cookbook very much. It seems to try to be a combination of advanced-user-cookbook and beginner-tutorial and does neither very well. The author seems to take a huge number of short cuts, seeming to assume you went through the whole beta SDK process along with her. I didn't. I'm new to the game.
Anyway, since it wasn't really helping me, I decided to just try and draw a single picture on the simulator. What a pain, but then I had a similar problem with C#. UIImage:drawAtPoint doesn't actually draw at a point, for example, until you add it to a UIImageView. I was trying to draw the image raw, but that wouldn't happen. I suspect it's doable, but there's too much linkage with the .xib file that gets created in a basic project. Anyway, after much wailing and gnashing of teeth, I finally got it. Here it is, without the proper memory handling (because handling that's still new to me as well):
UIImage *myImage = [UIImage imageNamed:(@"Olga-Kurylenko-1.jpg")];
UIImageView *myImageView = [[UIImageView alloc] initWithImage:myImage];
[myImage drawAtPoint:(CGPointMake(50.0,50.0))];
[self.view addSubview:myImageView];
So there you are. I need to free up the "myImageView" variable and come to grips on who the heck frees the "myImage" variable. Oh, this goes into the "viewDidLoad:" method, by the way. The logic is that viewDidLoad: gets called and when the super viewDidLoad gets called, then the image view will also get displayed.
Anyway, since it wasn't really helping me, I decided to just try and draw a single picture on the simulator. What a pain, but then I had a similar problem with C#. UIImage:drawAtPoint doesn't actually draw at a point, for example, until you add it to a UIImageView. I was trying to draw the image raw, but that wouldn't happen. I suspect it's doable, but there's too much linkage with the .xib file that gets created in a basic project. Anyway, after much wailing and gnashing of teeth, I finally got it. Here it is, without the proper memory handling (because handling that's still new to me as well):
UIImage *myImage = [UIImage imageNamed:(@"Olga-Kurylenko-1.jpg")];
UIImageView *myImageView = [[UIImageView alloc] initWithImage:myImage];
[myImage drawAtPoint:(CGPointMake(50.0,50.0))];
[self.view addSubview:myImageView];
So there you are. I need to free up the "myImageView" variable and come to grips on who the heck frees the "myImage" variable. Oh, this goes into the "viewDidLoad:" method, by the way. The logic is that viewDidLoad: gets called and when the super viewDidLoad gets called, then the image view will also get displayed.
New iPhone/Obj C books
Bought two books on Friday:
The Cocoa Programming book starts out really well. I think it'll help dramatically in my understanding some of the more overwhelming aspects of learning this new programming language. I'll probably review both books later, after I've used them a bit more.
- The iPhone Developer's Cookbook: Building Applications with the iPhone SDK
- Cocoa Programming for the Mac OS (3rd Edition)
The Cocoa Programming book starts out really well. I think it'll help dramatically in my understanding some of the more overwhelming aspects of learning this new programming language. I'll probably review both books later, after I've used them a bit more.
Friday, November 14, 2008
False Starts in Slideshow Development
I tried to write my first program tonight, from scratch (well, actually using a template from the New Project window). Didn't even really get started, because I got too caught up in how I should start. I have a simple design document, but I'm still not familiar enough with Apple's API set and terminology to determine what I should use for the various parts of my applet.
For instance, just to start, should I use UIWindow or IBOutlet UIWindow? What's the difference? (I read about it, but need to digest what they're talking about). For the images, should I use UIImage or UIImageView? The code samples use UIImageView, but UIImage seems more precise to me.
On the topic of views... what should I start with after I figure out my UIWindow dilemma? UIView or UIViewController. The sample apps seem to mix them up and I can't quite tell the superficial differences between the actions they offer. I'm definitely going to have to compare the sample code to the APIs in more detail and see what methods they are using (or not using).
The applet I'm trying to design is a simple "slideshow" type app. I want to be able to load in a list of pictures from the file system and then use the touch-flick action to move from one to the next and back (in a circular fashion). I heard a reference to a controller (or view?) that might be suited to such an activity in on of the early getting started videos. I might have to go back and look at that.
As far as resource handling is concerned, I want to be able to arbitrarily name my resources and associate that name with the actual external name. The few pieces of sample code I've looked at have just directly used the file name in question. I want to be able to easily change the files behind the scenes without changing the code (or lamely re-naming the files to match what's in the code). So I'll also have to look into how the resources are managed.
Lots to do! Maybe a book will help.
For instance, just to start, should I use UIWindow or IBOutlet UIWindow? What's the difference? (I read about it, but need to digest what they're talking about). For the images, should I use UIImage or UIImageView? The code samples use UIImageView, but UIImage seems more precise to me.
On the topic of views... what should I start with after I figure out my UIWindow dilemma? UIView or UIViewController. The sample apps seem to mix them up and I can't quite tell the superficial differences between the actions they offer. I'm definitely going to have to compare the sample code to the APIs in more detail and see what methods they are using (or not using).
The applet I'm trying to design is a simple "slideshow" type app. I want to be able to load in a list of pictures from the file system and then use the touch-flick action to move from one to the next and back (in a circular fashion). I heard a reference to a controller (or view?) that might be suited to such an activity in on of the early getting started videos. I might have to go back and look at that.
As far as resource handling is concerned, I want to be able to arbitrarily name my resources and associate that name with the actual external name. The few pieces of sample code I've looked at have just directly used the file name in question. I want to be able to easily change the files behind the scenes without changing the code (or lamely re-naming the files to match what's in the code). So I'll also have to look into how the resources are managed.
Lots to do! Maybe a book will help.
Subscribe to:
Posts (Atom)