Nextbus stops! Served by Google App Engine! Displayed on the iPhone!
Of course:
- The app crashes as soon as you try to do anything after the map loads.
- There are way too many pins. And I don’t want them to be pins anyway. And the stops aren’t likely to change often so I should actually move this operation off the network and onto the iPhone, which might mean reimplementing geohash, which I don’t yet fully understand (but know to be neat!).
- I haven’t written code to query Nextbus for predictions. This will be fairly easy, but exactly how I want to handle caching is an open question.
Still: wheels, motion, etc.
P.S. Objective C suuuuuucks
But it has all the memory safety of C combined with all the blazing speed of Smalltalk! What could go wrong?
Cool… neat to see you working on iPhone stuff.
But: P.S. Objective C suuuuuucks — really?
I’m honestly curious why you think so. I’ll admit I haven’t programmed any other compiled languages except for straight C, but I’ve been doing Cocoa for about five years and really enjoy Objective-C, Cocoa or no.
Cool… neat to see you working on iPhone stuff.
But: P.S. Objective C suuuuuucks — really?
I’m honestly curious why you think so. I’ll admit I haven’t programmed any other compiled languages except for straight C, but I’ve been doing Cocoa for about five years and really enjoy Objective-C, Cocoa or no.
Hmm, sorry about the double comment, but I got an HTTP 500 after submit instead of a redirect.
The double comment’s my fault — I’m not sure where those 500 errors are coming from, but they’re appearing fairly frequently. I really need to move this site to WordPress.
The thing I don’t like about Objective C is mostly just that it’s confusing. Which isn’t the language’s fault, necessarily, although it could certainly be a bit nicer about it. I remember string manipulation in C++ being a total pain in the ass, too, so it’s likely that I’m just cranky about going back to a compiled language — any compiled language.
With that said:
* For beginner stuff, the strongly-typed-but-not-really nature of things just means your app will unexpectedly crash instead of the compiler yelling at you first
* The crash reporting leaves a lot to be desired. Did the iPhone simulator just disappear unexpectedly? Is the debugger just showing some unhelpful bit of assembler? Time to add a bunch more NSLog()s!
* I’ve been pretty unimpressed with the documentation. I’ve gotten to the point I’m at through a combination of Apple’s materials, the O’Reilly SDK book, 4 or 5 hours of the Stanford iTunes U class, and tons of googling. None of them has felt like THE introductory text (the Stanford thing is the best of the lot, but it’s video, and therefore a pretty terrible way to learn programming). Interpreted languages’ communities are just a million times better at this stuff for whatever reason.
* I’ve already learned and completely forgotten how reference counting/autorelease works. I’m positive I’m going to have to completely revamp my app to plug leaks once its basic functionality is complete.
* This isn’t about Objective C per se, but while the SDK seems very well-designed in general, the map stuff has a couple of extremely lame aspects to it. In particular, they really only want you to do point-type annotations. If you want to draw a region or a vector on the map you’re going to need to drop another transparent view on top of it, pass through all the touch events and deal with keeping the scale and position in sync. It’s kind of a nightmare. At least, that’s my understanding of it at this point.
Cool, thanks for the detailed reply.
For beginner stuff, the strongly-typed-but-not-really nature of things just means your app will unexpectedly crash instead of the compiler yelling at you first
Yeah, this can happen more frequently. Recommend getting absolutely zero compiler warnings, or treating warnings as errors, to help with this. But yeah.
The crash reporting leaves a lot to be desired. Did the iPhone simulator just disappear unexpectedly? Is the debugger just showing some unhelpful bit of assembler? Time to add a bunch more NSLog()s!
Crash logs might help with this.
I’ve been pretty unimpressed with the documentation. I’ve gotten to the point I’m at through a combination of Apple’s materials, the O’Reilly SDK book, 4 or 5 hours of the Stanford iTunes U class, and tons of googling. None of them has felt like THE introductory text (the Stanford thing is the best of the lot, but it’s video, and therefore a pretty terrible way to learn programming). Interpreted languages’ communities are just a million times better at this stuff for whatever reason.
Yeah, I hear that. I love the Apple docs now that I know Cocoa, but it’s not what I learned off of. And I think iPhone in particular was hampered by several months of NDA out of the gate.
I’ve already learned and completely forgotten how reference counting/autorelease works. I’m positive I’m going to have to completely revamp my app to plug leaks once its basic functionality is complete.
This is just one of those Cocoa things you have to master. The two basic rules are: 1) if you use a method with alloc, new, or copy in it, you need to release, and 2) if you need a variable around beyond the current scope, you need to retain it, then release it when you’re done in the other place(s).
This isn’t about Objective C per se, but while the SDK seems very well-designed in general, the map stuff has a couple of extremely lame aspects to it. In particular, they really only want you to do point-type annotations. If you want to draw a region or a vector on the map you’re going to need to drop another transparent view on top of it, pass through all the touch events and deal with keeping the scale and position in sync. It’s kind of a nightmare. At least, that’s my understanding of it at this point.
I’ve only done a bit with MapKit, but yeah. It’s a 1.0. You can file a Radar on it, though, for later releases.
Thanks for writing back — this is extremely helpful. Your explanation of the rules for memory management is the best I’ve seen!
There are a couple other subtleties to memory management too, but the same two rules apply. Here’s an example.
Say you have an instance variable that’s a (let’s say mutable) dictionary that holds some certain data through the life of the app.
Say you then make a new object [[NSObject alloc] init] and add it to the dictionary.
If you look closely at the docs for NSMutableDictionary, it tells you that objects get retained when added, so that they are guaranteed to stay around. So if you want the object to disappear when the dictionary is done with it, you would release it right after adding it to the dictionary. You create it (retain count 1), add it (retain count 2), and release it (retain count 1). Dictionary releases it (retain count 0) and thus frees it.
But again, same rules apply — just need to know that some methods retain things when they are needed. For data-type objects, arrays and dictionaries are the main ones to remember.
While the alloc-new-copy rule helps you remember when you need to be responsible for a release. one more way of looking at retain counts is useful (this, by the way, is from the Hillegass book).
Think of retains as leashes & collars around the neck of a dog. Everyone who wants to make sure the dog sticks around puts a leash & collar on it (retain). When you don’t care anymore, you remove the collar (release). When no collars are left, it runs away.
So an array/dictionary retains, then when it’s done, releases.
i love google