Posts Tagged ‘Cocoa’

A little more open source: a personal accounting software

Today I published on GitHub a software I developed for personal accounting I use for a long time. It may help some of you with custom view, table views and probably Core Data, or provide a fundation if you want to build such software. It’s available on GitHub ! Enjoy 😉


Reunionite for iPhone available on the AppStore!

Reunionite iPhone application goal

Check and share with your friends your meeting costs with this free app for your iPhone.

Watch the demonstration videoGet it in the iPhone AppStore.

Retain your IB objects in Cocoa Touch

I previously published 2 articles on the fact that you had to retain your objects instantied from Interface Builder. I finally discovered the scientific explanation within an AdMob source file:

Note that top level objects in nibs other than MainWindow.xib in Cocoa Touch are autoreleased, not retained like in OS X. Be sure to use [self retain] in -awakeFromNib when part of a custom nib (as in this example).

Extract from the AdMob SDK source files for iOS.

Automatically restart an app having started a call?

This post will be quite simple. Its goal is to answer this question : is there a way to automatically restart an app which has initiated a call, once this call ended? This question is pretty related to my own apps (I hope you already know them! if not, just check them in the AppStore! most are free!), since these are phone shortcuts (naturally just a little advertising picture below…).

My iPhone shortcut apps

So I recently checked to determine if I may make my apps a little more better, by allowing the user to have them restarting after the call ended. And the answer is… yes… but… this involves doing something which is not really nice in my case. In fact you can do this through using a WebKit view, and having a phone URL displayed in it. Having the user clicking this URL will bring a confirmation alert, if the user goes on the call takes place, and once it finished the app is restarted (you can Google this to find more details, I will not since I did not use this trick, doesn’t match my user experience goal!).

And that’s all! There is no other way, so if you don’t rely on a click on a link to start a call, do not hope to have your app restarting. iOS is not doing this… anymore (I remember it did in its first versions… it’s a shame it’s not customizable).

Have fun!

Close this Number Keypad I shall not see!

  • Did you ever use an iPhone app with a Number Keypad to edit numbers only fields?
  • Did you ever wonder how you could close the keypad, just like you would do with the standard keyboard and its ‘Done’ button?
  • Are you sure you want to know the answer…?

YOU CAN’T! (at least if the application just used the standard Number Keypad provided within iOS SDK)

So, what choice do you have?

  • Generally, the keypad closure is not really necessary, since the edited field is in its own screen, you just let the user go back (generally through the navigation bar) and the keypad is closed automatically.
  • You may imagine other solutions, too…
  • But the one I’ll give you here offers the following result:
Simulateur iPhone
Uploaded with plasq‘s Skitch!

Now that you’ve seen this, you wan’t to know how to do it, don’t you? So here’s the howto! It’s not my own creation, I followed their tutorial and used the graphic files provided, so you can do so! I just poured a little bit of idea I found on another blog to make it a little more better (to me at least).

So this idea is just to use the powerfulness of Cocoa’s categories (extending classes without subclassing), to add a method to the UIView class enabling me to find the firstResponder from a view and resign it. Calling this method on the app’s main window when I want to close the keypad, it will seek and find the firstResponder, resign it, and thus close the keypad! Easier, isn’t it? And the corresponding is below…


@interface UIView ( RoCHExtensions )
- (UIView *)findAndResignFirstResponder;

@implementation UIView (RoCHExtensions)
- (UIView *)findAndResignFirstResponder {
    if (self.isFirstResponder) {
        [self resignFirstResponder];
		return self;

    for (UIView *subView in self.subviews) {
        UIView *firstResponder = [subView findAndResignFirstResponder];

        if (firstResponder != nil) {
			[firstResponder resignFirstResponder];
			return firstResponder;

    return nil;

Your CoreData app is crashing you don’t know why? Check your properties’ names!

In my case, I was using a property named “description”. Causes the apps to crash without displaying anything to help, so beware of your properties’ names!

Ad’hoc distribution and expired certificate

Once a year, your iPhone Developer Distribution certificate will expire. This will involve the not-so-big-but-nonetheless-boring process to create new private keys, request the certificate, install it in xCode, et caetera.

But once this is done… you’re not finished yet! Remember of this friend of your’s you made a special app for you distributed through Ad’hoc? Its provisionning profile for this app is expired too… Now you’ll have to generate a provisionning profile again, with your brand new Distribution certificate, send it to him, and… huh, no, that’s not finished yet: you have to rebuild your application, since it needs to be signed with your new certificate!

(If you don’t rebuild the app, when trying to install with the new provisionning profile, your friend will get a “invalid signer” alert message.)

Wow! Finished all this? This time you’re done… hopefully.

%d bloggers like this: