Applications
WWDC 2008
2008-04-08
White Tree: 1/640s f/8.0 ISO200 70mm, -0.3ev, Canon 30D, Canon 70-200L IS f2.8
Since I'm now developing a real Mac application (known as PP for now), I've taken the plunge and signed up for WWDC. It will be my first year and it will be busy.
I'm in the SF Bay area, but far enough away that commuting to the show in San Francisco makes no sense; so I'll have to find accommodation for that week. Does anyone know of a good (and not oppressively expensive) hotel in the Moscone area?
I'm coding this app in my spare time, progress is slow. I'm learning a great deal about how the frameworks are put together and how they should be used. Typically I get something wrong when I add a feature and then figure out what the right way is as I work through the issues that uncovers. Invariably I end up with less code, and find my code shifting to more sensible places. At that point I know I'm done and can move on.
I'm tackling the application in a simple way. I know that the main purpose of the app needs a whole lot of supporting functionality, so I'm writing that support first. Once all those pieces are in place I will start on the main event. This has the advantage that by the time I get there I will have had a lot of time to think about how I want to do it. And by the magic of object-oriented design, much of that should be independent of other decisions, such as how I store documents on disk and how the windows and views work.
|
Cocoa: How To Sync Views With A Color Preference Slider
2008-03-27
Much of my spare time is being used up very gradually writing a new photography-oriented application which I have code-named PP. This being my first sizable Mac app I also spend a lot of time reading, figuring out, rewriting code, and debugging as I encounter each challenge and work through it. While I am not going to blog the entire thing as I did with Random Wok, I am going to contribute pieces of what I have learned along the way.
PP has a thumbnail browser, as any photography-oriented app has, and I want to be able to control its background color. Just like Aperture I have a slider in my prefs panel that changes the gray level of the background and need to have that stored in the user's preferences. Since PP is a document-based app (I can have many document windows open at the same time), changing the browser background has to affect all the open documents and should do so in real time so the user can see the result.
Here is my prefs panel. Not much there yet:
The slider is set up to deliver a number between 0.0 and 1.0 and continuously return its state. The prefs panel XIB file also has an NSUserDefaultsController. The file's owner is a custom window controller:
I use three separate mechanisms for keeping everything in sync: actions, bindings, and notifications. Here is all of it together in one diagram:
The slider, NSUserDefaultsController and preferences file are joined together with bindings. I bind the slider's value to NSUserDefaultsController:
so that the controller is notified of all changes to the slider value. The NSUserDefaultsController keeps the prefs file on disk in sync. That is 100% of what is needed to handle the slider and the prefs. To set up the initial preferences I create the defaults in my application object:
To keep the browser background color in sync with the slider I have to be able to tell the browser's view controller that the value has changed so that it can get it from the NSUserDefaultsController object. This is a two-stage process: the slider tells its window controller via its action and the window controller tells the browser view controller through a notification:
To update the browser views, each instance of the browser view controller listens for notifications that indicate the color has changed and sends the appropriate message to its view:
The above two methods are called at appropriate times by the browser's window controller. The color is updated like this as the notification is received:
Finally, to set up the initial color the browser view controller implements this code:
That's it. Having set all of this up I can use the same mechanisms for handling other preferences and parameters that affect the browser or other views. I'm understanding the value of following the MVC pattern: it gives everything a place -- if you can figure out where that should be.
PP has a thumbnail browser, as any photography-oriented app has, and I want to be able to control its background color. Just like Aperture I have a slider in my prefs panel that changes the gray level of the background and need to have that stored in the user's preferences. Since PP is a document-based app (I can have many document windows open at the same time), changing the browser background has to affect all the open documents and should do so in real time so the user can see the result.
Here is my prefs panel. Not much there yet:
The slider is set up to deliver a number between 0.0 and 1.0 and continuously return its state. The prefs panel XIB file also has an NSUserDefaultsController. The file's owner is a custom window controller:
I use three separate mechanisms for keeping everything in sync: actions, bindings, and notifications. Here is all of it together in one diagram:
The slider, NSUserDefaultsController and preferences file are joined together with bindings. I bind the slider's value to NSUserDefaultsController:
so that the controller is notified of all changes to the slider value. The NSUserDefaultsController keeps the prefs file on disk in sync. That is 100% of what is needed to handle the slider and the prefs. To set up the initial preferences I create the defaults in my application object:
To keep the browser background color in sync with the slider I have to be able to tell the browser's view controller that the value has changed so that it can get it from the NSUserDefaultsController object. This is a two-stage process: the slider tells its window controller via its action and the window controller tells the browser view controller through a notification:
To update the browser views, each instance of the browser view controller listens for notifications that indicate the color has changed and sends the appropriate message to its view:
The above two methods are called at appropriate times by the browser's window controller. The color is updated like this as the notification is received:
Finally, to set up the initial color the browser view controller implements this code:
That's it. Having set all of this up I can use the same mechanisms for handling other preferences and parameters that affect the browser or other views. I'm understanding the value of following the MVC pattern: it gives everything a place -- if you can figure out where that should be.
The Shape Of iPhone Applications
2008-02-04
With the iPhone SDK coming soon, I'm looking forward to a new kind of application, one that installs in two or more places and uses the mobility of the iPhone to extend the Macs that we currently have on our desks in a new way.
Many iPhone apps will offer this:
The app installs on the phone and that is it. It runs on the iPhone and doesn't talk to anything. Think of games, utilities, and the like. Of course the iPhone has internet access, so we'll also see apps that do this:
Safari already does it, so it's no big deal. Weather, stocks, and other simple gather-the-data-and-display-it apps will be numerous. There will be others that have a server end and an iPhone end:
The Google map application does this. Note that Google/Apple writes the code for both ends of the connection; if you don't have both, nothing happens. There is no browser in use here, and not necessarily any standard protocol. But most software developers don't have a huge server infrastructure like Google. And there are all sorts of scaling and billing problems with this kind of application if you are a small shop. So what do you make?
What I'm thinking of is an application that looks like this:
This is one application from one vendor that comes in two parts: one part that is installed on the iPhone and one part installed on the Mac. There are no scaling problems since for each customer only a few iPhones connect to a few Macs. The customer owns both ends. Billing is also not an issue, since it's not the Mac that is a precious resource here. This kind of app extends what I have on my Mac to my iPhone. Quicken could do this (but I bet it never will). Back up software could do this to tell me what had happened and get my response.
Another type of application could look like this:
The iPhone accesses data on the internet and the home Mac to get its job done. The Mac supplies personal information, maybe passwords, home address, account information, and the internet servers supply the other data needed. The idea here is that the Mac has the personal knowledge and the internet servers have the world knowledge. The two are combined to do things that could not be done in any other way.
Probably a better way of doing the same thing given the much larger storage and bandwidth of the home Mac is this:
Apple is already doing this with iTunes, but nobody else is. The iPhone can now use all the accounts that the Mac can, so there is no extra work. Privacy and billing are handled by the same mechanisms that the desktop uses.
Let's say you were running Delicious Library on your home Mac. With an app from Delicious Monster running on the iPhone you could access your media library in real time. With that, you could use your iPhone to lend things out, look up books you found on your travels to see if you already had them or needed just that one to complete a set. You could add voice annotations to books that you have at home. You could browse your home media collection and compare what you paid with those in front of you at the thrift store. Or compare what you see with what is currently selling on eBay and be sure you don't already have it. And a zillion other applications that create value by extending the personal desktop computer to the mobile hand.
Many iPhone apps will offer this:
The app installs on the phone and that is it. It runs on the iPhone and doesn't talk to anything. Think of games, utilities, and the like. Of course the iPhone has internet access, so we'll also see apps that do this:
Safari already does it, so it's no big deal. Weather, stocks, and other simple gather-the-data-and-display-it apps will be numerous. There will be others that have a server end and an iPhone end:
The Google map application does this. Note that Google/Apple writes the code for both ends of the connection; if you don't have both, nothing happens. There is no browser in use here, and not necessarily any standard protocol. But most software developers don't have a huge server infrastructure like Google. And there are all sorts of scaling and billing problems with this kind of application if you are a small shop. So what do you make?
What I'm thinking of is an application that looks like this:
This is one application from one vendor that comes in two parts: one part that is installed on the iPhone and one part installed on the Mac. There are no scaling problems since for each customer only a few iPhones connect to a few Macs. The customer owns both ends. Billing is also not an issue, since it's not the Mac that is a precious resource here. This kind of app extends what I have on my Mac to my iPhone. Quicken could do this (but I bet it never will). Back up software could do this to tell me what had happened and get my response.
Another type of application could look like this:
The iPhone accesses data on the internet and the home Mac to get its job done. The Mac supplies personal information, maybe passwords, home address, account information, and the internet servers supply the other data needed. The idea here is that the Mac has the personal knowledge and the internet servers have the world knowledge. The two are combined to do things that could not be done in any other way.
Probably a better way of doing the same thing given the much larger storage and bandwidth of the home Mac is this:
Apple is already doing this with iTunes, but nobody else is. The iPhone can now use all the accounts that the Mac can, so there is no extra work. Privacy and billing are handled by the same mechanisms that the desktop uses.
Let's say you were running Delicious Library on your home Mac. With an app from Delicious Monster running on the iPhone you could access your media library in real time. With that, you could use your iPhone to lend things out, look up books you found on your travels to see if you already had them or needed just that one to complete a set. You could add voice annotations to books that you have at home. You could browse your home media collection and compare what you paid with those in front of you at the thrift store. Or compare what you see with what is currently selling on eBay and be sure you don't already have it. And a zillion other applications that create value by extending the personal desktop computer to the mobile hand.
Cocoa Cheerleaders
2007-12-02
Cocoa Cheerleaders is brought to you by the team at PyrusMalus. It's a large collection of links to blogs, articles, books, code, and other information about Cocoa.
My interest piqued by the name, I discovered that PyrusMalus is the Latin name for the Domestic Apple tree. And there is a mystery application in the works looking for alpha testers called Atlantic.
A Quick Look At Photon 1.0
2007-11-05
Photon is a RAW workflow utility designed to do one thing well: let me view and sort my images quickly before I import the good ones into a more heavyweight tool like Aperture or Lightroom.
As soon as I put my card into a reader, Photon starts reading and converting RAW files, putting thumbnails into the area on the left. I can start working with images right away: no need to wait for the download to finish. Photon maxed out both my CPUs as it downloaded at about 7MB per second from my USB card reader.
Across the top are stacks: general purpose bins for images. The currently selected stack populates the thumbnail pane, so clicking on a different stack shows me a different set of images. Each card initially goes into its own stack.
To process my images I scroll through the thumbnails with the left and right arrow keys and restack the images using whatever criteria make sense for me. Each stack has a single-key short-cut, called a hotkey (the numbers 1 and 2 in the screen shot above). I can reassign these to any keys I like. 7, 8, 9, X might relate to ratings. I could add a stack called T for trash and another called P for print. If I were shooting a wedding I could assign hotkeys for different locations or people. There is no need to drag and drop images, just pressing the hotkey moves the image to the stack assigned to that key and shows the next image in the viewer. I can process 1000 images with only 1000 key presses this way.
Zooming is simplicity itself: I click on the image and it zooms to 100% with the click point at the center:
I let go, and it returns to a scaled view. To make zooming persistent I can move the switch bottom right.
Once I have my images sorted, I am ready to export the images to disk. Since many of my images have no value and were either moved to a junk stack or skipped over, I only save some of the stacks. I can save the original RAW, or opt to have Photon convert to JPG, TIFF, or a number of other formats. Once done, I am ready to import my surviving images into Aperture or another application or process them further, maybe adding GPS data or keywords.
I found this 1.0 release of Photo to be stable and fast. There are a few rough edges to the interface and a need for refinement in some areas. Photon is short on features -- but that's good. It does what it claims to do well, and there is plenty of functionality that can be added later once customers start telling Green Volcano what they would like to see. The demo version does everything except save stacks.
As soon as I put my card into a reader, Photon starts reading and converting RAW files, putting thumbnails into the area on the left. I can start working with images right away: no need to wait for the download to finish. Photon maxed out both my CPUs as it downloaded at about 7MB per second from my USB card reader.
Across the top are stacks: general purpose bins for images. The currently selected stack populates the thumbnail pane, so clicking on a different stack shows me a different set of images. Each card initially goes into its own stack.
To process my images I scroll through the thumbnails with the left and right arrow keys and restack the images using whatever criteria make sense for me. Each stack has a single-key short-cut, called a hotkey (the numbers 1 and 2 in the screen shot above). I can reassign these to any keys I like. 7, 8, 9, X might relate to ratings. I could add a stack called T for trash and another called P for print. If I were shooting a wedding I could assign hotkeys for different locations or people. There is no need to drag and drop images, just pressing the hotkey moves the image to the stack assigned to that key and shows the next image in the viewer. I can process 1000 images with only 1000 key presses this way.
Zooming is simplicity itself: I click on the image and it zooms to 100% with the click point at the center:
I let go, and it returns to a scaled view. To make zooming persistent I can move the switch bottom right.
Once I have my images sorted, I am ready to export the images to disk. Since many of my images have no value and were either moved to a junk stack or skipped over, I only save some of the stacks. I can save the original RAW, or opt to have Photon convert to JPG, TIFF, or a number of other formats. Once done, I am ready to import my surviving images into Aperture or another application or process them further, maybe adding GPS data or keywords.
I found this 1.0 release of Photo to be stable and fast. There are a few rough edges to the interface and a need for refinement in some areas. Photon is short on features -- but that's good. It does what it claims to do well, and there is plenty of functionality that can be added later once customers start telling Green Volcano what they would like to see. The demo version does everything except save stacks.
Displaperture: Nothing To Do With Aperture
2007-10-31
Displaperture rounds the corners of the desktop. Leopard no longer does this, and some people want that feature back.
More Than Just Leopard: New Applications Are Coming
2007-10-22
With all the excitement about Mac OS X 10.5 Leopard in the air, it is easy to forget why we have computers in the first place: applications.
Once Leopard finally gets into the hands of mere mortals on October 26th, the application marketing dam will break. Finally all the developers who spent an extra four months polishing and tuning their recent creations will be free of Apple's NDA shackles and be showing off the fruits of their toil. It should be very interesting, and I believe will cement my belief that Leopard demonstrates OS X nearing a mature state. There will be many apps that are Leopard only. Why? Because Leopard apps can be written so much faster than was possible on Tiger. Certainly anything I write from here on out will be for Leopard.
Scott Stevenson has a sneak peek at Delicious Library, but for a few more days, we cannot see any more.
Once Leopard finally gets into the hands of mere mortals on October 26th, the application marketing dam will break. Finally all the developers who spent an extra four months polishing and tuning their recent creations will be free of Apple's NDA shackles and be showing off the fruits of their toil. It should be very interesting, and I believe will cement my belief that Leopard demonstrates OS X nearing a mature state. There will be many apps that are Leopard only. Why? Because Leopard apps can be written so much faster than was possible on Tiger. Certainly anything I write from here on out will be for Leopard.
Scott Stevenson has a sneak peek at Delicious Library, but for a few more days, we cannot see any more.
The Bagelturf site welcomes Donations of any size