A good way to help track down performance issues is through the use of a watchdog timer. They help you by pointing out the places in your code that are taking longer than they should. When the watchdog fires, it can do whatever action is appropriate for your application. I’m sure all iOS developers are aware of the more extreme watchdog timer that has existed since the beginning of iOS which would kill your application if it took too long to shut down. Our watchdog example will be far more benign
. (more…)
In my last two posts, we talked about the basics of GCD and then delved into blocks. Now we’re going to start learning how to replace your old threading code with GCD. For this post, we’ll discuss how to create a simple sequential job queue using dispatch_async and friends. (more…)
Last time I talked about asynchronous behavior via Grand Central Dispatch. One of the core features that makes this all possible is blocks. I thought I’d take a step back this time and just talk about blocks themselves and how they can be used by your code. (more…)
I stated in a past post that threads are evil. I still stand by that statement. Adding threads to an application has historically been fraught with issues. Many stem from people not quite understanding all of the situations can arise, etc. Oh sure, you might know what a deadlock is, but do you know all the circumstances they can occur? How does one safely shut a thread down? Did the owning object go away? It’s not as simple as it seems in most cases.
But what if I could thread until the break of dawn and not have to worry as much about those situations? That’s exactly what Grand Central Dispatch gives you on Mac OS X, and now iOS — access to concurrency without nearly as much pain. (more…)
I ran across this quote from Oliver Reichenstein, and it embodies my thinking completely, though I’ve never been able to put it into such words.
We should use original tools to create iPad apps, not because Steve Jobs said so, but because these tools create products with flesh and bone, that is: an understanding of both the purpose, the potential and the limits of the iPad technology.
I’ve never been a fan of cross-platform frameworks, even though I’ve been involved in four to speak of to date (not always by choice). I like to think I’m pretty good at it at this point, but even the best of us ends up with mediocre platform support or performance because you’re trying to wedge your idea of the universe onto another. And we know from watching Fringe what happens when two universes meet.
A while back I wrote a post called “I hate Xcode”. These days I feel I need to post a revised statement based on my more recent experience with Xcode which can be summed up with: I Love Xcode. I guess this is much akin to Leonard Nimoy writing “I am not Spock” and later writing “I am Spock”. (more…)
In my last Tweetsville Update, I mentioned that there was something that might prevent me from working on Tweetsville going forward, despite the fact I just finished it. Well, that thing has finally materialized so I can finally say that I’m officially back at Apple starting today. It’s been weeks in the making, but it finally materialized late last week.
This time I’m working on iTunes instead of the OS group. Definitely a different type of thing than I’m used to — I’m more a framework/API type of guy — but I think it will be fun nonetheless. Especially since I’ll be working with one of my friends that I used to work with there.
Because it’s Apple, I’m under strict agreement not to have any type of side projects, etc. so it was important to find someone to care for Tweetsville from this point forward. It’s too cool of an application to just let it drop. Especially since I just added Flickr upload support and the ability to quit the app while typing a tweet and have it pick up where you left off next time you run the app this week (both should appear in some future release).
Anyway, that’s the close of this short chapter of my life, and the start of a shiny brand new one!
I’ve recently discovered the simple beauty of [UIColor clearColor] used for a background color. Previously I had been doing stuff like:
self.opaque = NO;
self.backgroundColor = nil;
self.clearsContextBeforeDrawing = YES;
But all I really needed to do was:
self.backgroundColor = [UIColor clearColor];
Same transparency, and I’m guessing (hoping?) that it might be a bit more efficient (unless of course, the innards look for clear color and effectively do what I used to).
Hey, even if it’s not more efficient, it’s certainly simpler to type and it seems to have the same effect!
Sadly, this is one thing I didn’t figure out on my own, but rather spied in some other sources, but I wanted to throw it out there for ‘all uh yous’.
Well, it’s been about two months since I left Yahoo! and I’ve been spending pretty much literally all my time working on an iPhone application. It’s nothing super flashy, mind you, but I feel it is the best app of its kind. I had been really disappointed with all the Twitter apps for the iPhone. Either they were too slow, or scrolling was poor, or it just didn’t work the way I did. So I set out to write the version I’d want to use. I ended up with an application called Tweetsville. I’ve been putting together a small site for it here, so you can check out the features there. I also have set up a Twitter user you can follow if you care.
I had three goals in mind, in this order:
- Totally responsive, with glassy scrolling.
- Embrace the natural aesthetics of the iPhone user experience.
- Use the full power of the Twitter API.
It’s definitely fast and smooth (though admittedly it could be tweaked a bit more), and it looks like a real honest-to-goodness iPhone application. For whatever reason, I thought it would be ideal to do this app using as many standard (or standard-looking) controls as I could. The less custom stuff the better.
But the real beauty is the fact that I cache as much of your Twitter stream as I can get from the API, coupled with the depth of what you can do with this application. You can see your timeline, do direct messaging, see your favorites, history, and replies. You can also see the latest trends and do searches, including advanced searches. It is without a doubt the most powerful Twitter iPhone application I’ve seen to date. Of course, I’ve had my head in the sand for the past 8 weeks!
Will this application change the world? Hell, no. But I think it will definitely make a dent in the Twitter space. And it was fun, which was really my whole main point of writing it. It’s been a long while since coding was fun.
Even with all it does, there is still other things I’d like to do to it to improve the functionality and ease of use beyond what’s there, but there are only so many hours in the day, and I’m burnt out from coding so much. I need a vacation from my vacation!
The real question is: should I even charge for it? I’m currently thinking no, but man, it might really take off, and then I’ll be missing out. If I don’t charge for it, I will likely make the source publicly available. I’ve already got a subversion repository set up and ready for some sources if I do. Or there’s always code.google.com.
I’m hoping this will get submitted very very soon. My last build seems to be pretty stable, and I’m too paranoid to make any real changes now.
Wow, this would be the first thing I’ve ever written and released like this since… Aaron (if anyone remembers that). Again, wow.
As most iPhone developers know, dealing with provisioning files is a bit of a pain. Even more of a pain can be altering your profile and trying to use the altered one.
Well yesterday, after having to do that two or three times, I finally figured out a bit of a clue. I was having trouble making xcode see the profile. Turns out, you need to have the current target configuration set to the config you are modifying in the info panel or else it just won’t show up. Made all the difference in the world.
And of course I always restart xcode after installing any profiles. Install, restart xcode, then ensure your target is set to the right config, then edit the config. Booyah!