Ask HN: What should I build (for OSX)?
12 comments
I started with Core Animation. Now that you know C and some objective-C, you need to learn about Quartz, NSWindows, MVC, AppKit, Foundation, and other parts of Cocoa like Core Data (more on this later).
My first serious project with Cocoa was on a fairly tight timeline (a month for two apps, in fact) and I had only attempted tictactoe in Obj-C years before. What I did was immerse myself in the material and my project.
The project itself was for a museum in NYC, which has 30" touch-screens that let the visitors interact with a visual catalogue of the collection. This was a great introductory project for a few reasons.
First of all we had a great design partner. He built a very simple interface that remained constant through the entire project because he thought it out concretely before implementation. In other words, he considered the data very carefully and determined the fixed way to present it.
The second thing is that in order to import this collection's catalogue into the app, I had to build an XML parser that runs on a background thread while the UI displays a loading screen. That part was a good introduction to building an app and watching what it does in the Console, without getting into the nuances of Core Graphics and drawing, etc.. I recommend you start with something like this so that you don't get overwhelmed. It's extremely important to learn about correct memory management. Once you've got the basics, look into @property also.
From there, I had to learn about how make an application with a special kind of window, work with drawing NSViews and CALayers onto the window, learn about CAAnimation, Core Graphics, etc.
Before I built the app, I worked out my equations for laying the content on the screen and what kind of transformations I'd need to apply. Then I was able to set about building it simply.
At the time I didn't know this, but I can tell you from experience that it's very much worthwhile to look into Core Data. Even if your project is very simple and you require persistent data storage. I personally like to use json-framework and serve my app bundled JSON at initial lunchtime, with net updates after that, then do an import into my Core Data model, but this is really decided by what kind of app you want to build. I used XML for the museum project because we didn't know about json-framework yet. But it turns out that JSON translation into Cocoa objects has been much faster.
From here, you have a few options. You can either continue to develop on the desktop or you can move to iOS without very much difficulty.
If you are going to write mobile apps later and your app will interface with an existing web service, you may be better off using three20 and its http request libraries with JSON support to get data in real time. The Facebook app works like this. Actually three20 is a great option to go with for many apps. It's worth a look too, but make sure you understand UIKit as well as you can before you use three20. You still need to know UIKit to use three20 properly.
In order to determine what project you should build try to observe what kind of problems you have in daily life and what could be built to facilitate them. OS X is a wide topic and you could be talking about a GUI application, a kernel extension, or perhaps a web server. Each of them are projects which could take a month to build.
Hope this helps. Don't hesitate to ask any questions, and remember that Google and the Apple dev forums are great resources.
My first serious project with Cocoa was on a fairly tight timeline (a month for two apps, in fact) and I had only attempted tictactoe in Obj-C years before. What I did was immerse myself in the material and my project.
The project itself was for a museum in NYC, which has 30" touch-screens that let the visitors interact with a visual catalogue of the collection. This was a great introductory project for a few reasons.
First of all we had a great design partner. He built a very simple interface that remained constant through the entire project because he thought it out concretely before implementation. In other words, he considered the data very carefully and determined the fixed way to present it.
The second thing is that in order to import this collection's catalogue into the app, I had to build an XML parser that runs on a background thread while the UI displays a loading screen. That part was a good introduction to building an app and watching what it does in the Console, without getting into the nuances of Core Graphics and drawing, etc.. I recommend you start with something like this so that you don't get overwhelmed. It's extremely important to learn about correct memory management. Once you've got the basics, look into @property also.
From there, I had to learn about how make an application with a special kind of window, work with drawing NSViews and CALayers onto the window, learn about CAAnimation, Core Graphics, etc.
Before I built the app, I worked out my equations for laying the content on the screen and what kind of transformations I'd need to apply. Then I was able to set about building it simply.
At the time I didn't know this, but I can tell you from experience that it's very much worthwhile to look into Core Data. Even if your project is very simple and you require persistent data storage. I personally like to use json-framework and serve my app bundled JSON at initial lunchtime, with net updates after that, then do an import into my Core Data model, but this is really decided by what kind of app you want to build. I used XML for the museum project because we didn't know about json-framework yet. But it turns out that JSON translation into Cocoa objects has been much faster.
From here, you have a few options. You can either continue to develop on the desktop or you can move to iOS without very much difficulty.
If you are going to write mobile apps later and your app will interface with an existing web service, you may be better off using three20 and its http request libraries with JSON support to get data in real time. The Facebook app works like this. Actually three20 is a great option to go with for many apps. It's worth a look too, but make sure you understand UIKit as well as you can before you use three20. You still need to know UIKit to use three20 properly.
In order to determine what project you should build try to observe what kind of problems you have in daily life and what could be built to facilitate them. OS X is a wide topic and you could be talking about a GUI application, a kernel extension, or perhaps a web server. Each of them are projects which could take a month to build.
Hope this helps. Don't hesitate to ask any questions, and remember that Google and the Apple dev forums are great resources.
Actually three20 is a great option to go with for many apps.
This is the only bit of advice in your post that I completely disagree with. Three20 may have some nice UI bits, but it is a very poorly designed framework. I say this having looked at it before and after Facebook made a big redesign of it (breaking backwards compatibility and minimally documenting the changes.)
You can't add one view without adding a dozen other classes. Its not very well documented. It adds a large amount of bloat to the binary and drastically increases compile time.. I can go on, if you like.
This is the only bit of advice in your post that I completely disagree with. Three20 may have some nice UI bits, but it is a very poorly designed framework. I say this having looked at it before and after Facebook made a big redesign of it (breaking backwards compatibility and minimally documenting the changes.)
You can't add one view without adding a dozen other classes. Its not very well documented. It adds a large amount of bloat to the binary and drastically increases compile time.. I can go on, if you like.
We agree on those points, however. It's a big pain in the backside that they don't document their API better. And many of the classes, like TTPhotoViewController and TTScrollView, have some big problems that require modification to overcome.
But besides being a free library, I used three20 in many of my recent apps because I have been working with publishers to build navigation-based apps that require things like image caching and URL navigation. A number of other features of three20 are quite welcome, despite their quirks.
I usually try to do a quick test of the framework before I integrate it into a project and guarantee that it will work, because, you're right, some of them don't behave as advertised. This is even the case with some of Apple's libraries, but I daresay their documentation is better than three20's.
But besides being a free library, I used three20 in many of my recent apps because I have been working with publishers to build navigation-based apps that require things like image caching and URL navigation. A number of other features of three20 are quite welcome, despite their quirks.
I usually try to do a quick test of the framework before I integrate it into a project and guarantee that it will work, because, you're right, some of them don't behave as advertised. This is even the case with some of Apple's libraries, but I daresay their documentation is better than three20's.
I am not a developer, but from what I've seen, many successful projects start with a developer scratching a personal itch. So maybe your first app should be something that would be useful to you personally.
An App to manage all my scanned documents. Interface like iTunes, but each document can be a PDF/TIFF or emailed document I want to save and archive forever - like each month I scan my bills, my current lease, my employment contract, birth certificate, etc etc.
Bonus points if you can encrypt and backup to Amazon S3 or something.
37 Signals do the same, but I would like to save everything locally, not to a webapp. http://37signals.com/svn/posts/585-going-inbox-zero-on-your-...
Bonus points if you can encrypt and backup to Amazon S3 or something.
37 Signals do the same, but I would like to save everything locally, not to a webapp. http://37signals.com/svn/posts/585-going-inbox-zero-on-your-...
A twitter client. No, really. There's only a small handful of native Mac twitter clients, compared to the plethora of iOS clients. And I believe that @ev recently said that Tweetie|Mac isn't going to get updated anytime soon.
Or a small app that only runs in the menubar that will disable or enable bluetooth whenever I hit a key combo. Or when I move into or out of a certain location (Core Location exists on 10.6). Maybe if the person's on a laptop and they disconnect from a power source, turn it off, etc.
Or a small app that only runs in the menubar that will disable or enable bluetooth whenever I hit a key combo. Or when I move into or out of a certain location (Core Location exists on 10.6). Maybe if the person's on a laptop and they disconnect from a power source, turn it off, etc.
For enabling/disabling Bluetooth I call this script
http://hints.macworld.com/article.php?story=2007032818132485...
via Quicksilver.
via Quicksilver.
Have you tried MarcoPolo? It does context based switching of just about everything, and its free. http://www.symonds.id.au/marcopolo/
Yup. However, from MarcoPolo's page:
There are known issues with Snow Leopard:
WiFi evidence source and ToggleWiFi action do not work
Bluetooth may not work, or may cause crashes
There are known issues with Snow Leopard:
WiFi evidence source and ToggleWiFi action do not work
Bluetooth may not work, or may cause crashes
I desperately need an app that watermarks a bulk a amount of images. Let me drag in photos, and then control let me resize the images and control the size of a specified image(s) to be used as a watermark. For example, it should let me apply one image to every corner if I wanted.
ie: http://sphotos.ak.fbcdn.net/hphotos-ak-snc4/hs814.snc4/69481...
ie: http://sphotos.ak.fbcdn.net/hphotos-ak-snc4/hs814.snc4/69481...
I would love a screensaver that works like the Origami slideshow mode on the iPad, only for my desktop machine. I would imagine it'll be an interesting challenge using Core Animation and what not.
Bonus points if it can use photos from iPhoto!
Bonus points if it can use photos from iPhoto!
This is something I would pay for (and I am actually thinking to learn Objective-c just to build it myself because as far as I know, there aren't any good ones around): build an OSX Postgresql GUI client.
Or a client that can be used with a variety of database servers.
I'd love an Android-style notification bar for OS X - one where an incoming IM or whatever rolls the menu bar up, displaying the message briefly, then rolls back down to the standard menu bar.
Do you mean like Growl? (http://growl.info/)
A Pomodoro app might be a good start.
Mindfulness application that would ring a gong at random times, at a user selectable frequency. e.g. seven times in an eight hour span.
An html export Xtension for QuarkXPress that really works.
Gui for grep command.
1. It must be genuinely useful, not just an academic exercise.
2. It must be small enough in scope so that a competent OSX developer could build it in about one month full-time.
3. Bonus points if it's something I can sell.
So what should I build?