Comments for The Flying Jalapeño Lives

Comment on iPhone code snippet: Phone number formatter by Omar

Omar — Sun, 24 Jan 2010 00:41:02 +0000

This works like a champ.

So to complete the help for someone who is newbie:

Where you see:
[localText fullRange]
i.e the use of “fullRange”,
Just replace that with:
NSMakeRange(0,[cname length])
Assuming cname is delcared like this below:
NSMutableString *cname = [NSMutableString stringWithString:str];

Hope that additional info make save you an additional 1 minute

Comment on iPhone OS 4 and Backgound Tasks or “Why We Don’t Have a Calendar API” by Jimbob

Jimbob — Thu, 21 Jan 2010 15:16:04 +0000

Apps running in the background don’t cause battery problems if they’re in suspended animation, just waiting to be woken by a timer. They’ll cause memory problems, though, since the iPhone doesn’t have paging (yet).

Local push notifications would be very good for a bunch of apps that implement some sort of calendar function. I can imagine both local and network push notifications to be used to wake up apps and let them execute code, but that would likely be abused with all kinds of polling anti-patterns, negating any improvements to battery life.

The solution depends on what you want to do. If you want faster app switching, the best solution is to implement paging and suspend running apps to disk. If you want background activity (such as location tracking or music scrobbling) apps should be allowed to spawn small background daemons with severely limited memory and no GUI.

Comment on iPhone OS 4 and Backgound Tasks or “Why We Don’t Have a Calendar API” by Nathan de Vries

Nathan de Vries — Thu, 21 Jan 2010 05:26:03 +0000

Overloading the user-facing calendar as a system-level scheduler seems unlikely given that launchd does exactly what you’re trying to do. Something along the lines of SMJobBless() in the ServiceManagement framework is more likely to be exposed.

Comment on iPhone OS 4 and Backgound Tasks or “Why We Don’t Have a Calendar API” by Corey

Corey — Wed, 20 Jan 2010 15:34:48 +0000

@Jimbob My guess is probably off here, at least technology wise. I don’t think that Apple would allow multiple apps to run as background processes. That would be a huge battery drain. Thats it woud be nice to have the Calendar App (or some other process) handle all “local push notifications”. Which is similar to how the Push Notifications work now, minus the ability to execute code.

@mare I actually doubt they would allow executing of arbitrary code as well. But if they wanted a simple solution that gives developers more flexibility without sacrificing (too much) battery life, they do have the pieces in place. There is some chatter about “Calendar Syncing”, I have to assume that the Calendar API is coming in the next major OS release.

Comment on iPhone OS 4 and Backgound Tasks or “Why We Don’t Have a Calendar API” by mare

mare — Wed, 20 Jan 2010 14:53:42 +0000

I agree this would be cool. But I’m sure if Apple will enable such functionality it will be a bit more limited. I think they’ll never allow you to send some code to be executed by another process. If your code crashes (because it is just wrong/malformed or because of a fringe case that didn’t show up in debug/review) it’ll crash an Apple process. Apple doesn’t like that, even though that process will be re-spawned.

But they might very well at some point in the future (soon?!) provide a limited API where you can show a message at a certain time/date.

Comment on iPhone OS 4 and Backgound Tasks or “Why We Don’t Have a Calendar API” by Jimbob

Jimbob — Wed, 20 Jan 2010 10:31:50 +0000

Two things: Blocks can’t be passed to another address space and don’t survive termination of the process. If the process is kept alive, NSTimer can be used for this, anyway. No reason to mess with exposed calendar entries.

Comment on My Greatest iPhone Development Resource by The Flying Jalapeno Lives » Development Links: Redux

The Flying Jalapeno Lives » Development Links: Redux — Mon, 28 Dec 2009 10:14:34 +0000

[...] This is an update to my previous post [...]

Comment on My Greatest iPhone Development Resource by 2009-12-24 学习记录

2009-12-24 学习记录 — Thu, 24 Dec 2009 04:24:02 +0000

[...] http://boredzo.org/opensourcelinks/byauthor.html My Greatest iPhone Development Resource [...]

Comment on Open Source iPhone: Resources by harry

harry — Sun, 06 Dec 2009 02:39:00 +0000

This lookss kewllll

Comment on Obscure iPhone: viewDidLoad and loadNibNamed by Corey

Corey — Wed, 18 Nov 2009 16:39:50 +0000

Interesting.

As far as I know, loadNibNamed does not create the view controller, the view controller is already instantiated. The view controller being the top level object of the nib is simply a proxy (file’s owner).
It simply unarchives the nib, places those objects in memory, and connects the outlets.

You can of course instantiate a second view controller within a nib, if it is not the top level object. I wonder if this is the way you are accomplishing this?

In that case, I would fully expect viewDidLoad to be called.

In my case, I am loading the nib within the init method of top level view controller. This may in fact be the cause of the problem.

Comment on Obscure iPhone: viewDidLoad and loadNibNamed by Noel@snappytouch.com

Noel@snappytouch.com — Wed, 18 Nov 2009 14:51:32 +0000

I load nibs like that all the time, and viewDidLoad will get called… whenever the view is loaded. What’s happening is that loadNibNamed just creates the view controller, but the main view won’t be loaded until you access it.

So for example, calling loadNibNamed followed by adding its view to some hierarchy will cause the view to be loaded and viewDidLoad to be called.

But yes, you have to watch out for that because otherwise it’s possible to do operations on the view controller before the viewDidLoad function is called and can lead to unexpected results (I’ve had my share of bugs because of that early on).

Comment on Make it easier! – Dterm by Florian

Florian — Thu, 24 Sep 2009 14:11:10 +0000

Wow, never heard about that tool. I love it