Bom, voltando a nossa Categoria, ela implementa um método :appendToFile:usingEncoding na class NSString que é bastante útil, apesar de simples. Como o nome diz, ele irá adicionar a string em questão em um arquivo texto.

Veja o código aqui.

Atualização: o Jeff LaMarche tem um post mais atualizado, onde ele implementa o método na classe NSData. Convenhamos, realmente mais “genérico”.

O problema é que (ainda, espero!) não existe nenhuma classe/biblioteca no Cocoa que nos permita utilizar expressões regulares em toda sua plenitude. A classe NSPredicate faz alguma coisa, mas é ainda limitada. O jeito então é utilizarmos bibliotecas de terceiros.

Uma boa biblioteca para aplicações para o iPhone é a RegexKitLite. Ela possui um footprint baixo (16KB a 20KB), o que a torna ótima para um dispositivo móvel com restrições de recursos. Um problema com esta implementação é que ela linka com uma biblioteca que a Apple ainda não liberou uma interface pública oficial (libicucore.dylib), como apontado em sua própria documentação. Existe uma chance que isto venha a acontecer no futuro, como mostra esta mensagem na lista de mensagens da Apple para o Xcode. Outra vantagem desde projeto é que ele possui uma excelente documentação, que pode inclusive ser incluída no Help do Xcode.

Existem outras alternativas:

• AGRegEx – Faz parte do AGKit, uma biblioteca para Cocoa com outras funcionalidades (sockets, processos)
• ObjPCRE
• MOKit
• OFRegularExpression

Veja também o excelente artigo “8 Regular Expressions You Should Know” para alguns usos muito úteis de expressões regulares.

Bom, mas dizem por aí que todo bom programador tem como “virtude” ser preguiçoso. Virtude porque a preguiça o obriga a encontrar maneiras mais fáceis de fazer as coisas chatas e/ou repetitivas. Vamos então ver como criar Views para suas apps de uma maneira bem mais fácil.

Ao tutorial:

Abra o Xcode e crie um novo projeto usando o template View Based Application. Dê um nome bem criativo ao seu projeto como, por exemplo, Teste.

O Xcode irá criar um projeto bem simples, com uma View (TestViewController.xib) e seu respectivo Controller (TesteViewController.m e TesteViewController.h). A view que criaremos no Interface Builder será, na verdade, uma subview da que foi criada automaticamente pelo Xcode. Tudo bem simples, só para passar o conceito.

Vamos declarar nossa subview dentro do controller criado automaticamente pelo Xcode. Abra o arquivo TesteViewController.h e acrescente a declaração:

@interface TesteViewController : UIViewController {
    UIView *subView;
}

@property (nonatomic, retain) IBOutlet UIView *subView;

Depois faça o synthesize da propriedade no TesteViewController.m:

#import "TesteViewController.h"

@implementation TesteViewController

@synthesize subView;

Agora vamos criar nossa view no Interface Builder e fazer as conexões necessárias para nosso controller “enxergá-la”. Selecione Resources na painel esquerdo e adicione um novo arquivo.

Escolha “User Interface” nas opções à esquerda e selecione o template View XIB.

Novamente, escolha um nome criativo para nossa view: SubView. Ao retornar ao Xcode, de um duplo clique no arquivo SubView.xib criado, para abri-lo no IB.

O Xcode criou para nós uma  subview do tamanho da tela inteira. Mas nós queremos ela menor, para inserí-la na view principal. Normalmente é assim que você irá fazer nas suas aplicações, é claro. A subview será um dos componentes do layout da view principal, junto com outros elementos e/ou controles.

Tem um “macete” para fazer com que o IB nos deixe alterar o tamanho da nossa view para o valor desejado. Na janela Attributes Inspector (abra com Cmd-1) selecione None para Status Bar.

Com isso os campos que permitem alterar o tamanho da nossa view são habilitados. Vá para a janela Size Inspector (Cmd-3) e mude o H: (height – altura) para 40). Deixe o campo W: (width – comprimento) em 320.

Bom, vamos fazer alguma firula na nossa subview para que possamos enxergá-la quando for adicionada à sua view “pai” (caso contrário ambas estariam com a mesma cor default e não seria possível fazer a distinção entre elas). Acrescente um label à view e mude a cor de fundo. Por exemplo:

Agora um dos passos mais importantes: temos que dizer quem será o controller que irá responder por esta view e conectá-la à propriedade correta deste controller. É isto que nos permitirá manipulá-la no nosso código.

Selecione “File’s Owner” na janela com os componentes da nossa SubView.xib:

Na janela Identity Inspector (Cmd-4) e escolha a classe do nosso controller (TesteViewController) no campo Class.

Com isto dizemos à SubView que o controller dela será o já criado TesteViewController. Agora falta informar qual das propriedades deste controller refere-se ao componente UIView. Clique com o botão direito no File’s Owner da janela SubView.xib e conecte a propriedade subView ao componente View, como mostrado na figura abaixo:

Pronto! Layout (maravilhoso…) criado e conexões feitas. Terminamos no IB. Volte ao Xcode e vamos acrescentar o código que mostra nossa view.

Abra o arquivo TestViewController.m e procure pelo método viewDidLoad e acrescente o código abaixo:

- (void)viewDidLoad {
    [super viewDidLoad];

    [[NSBundle mainBundle] loadNibNamed:@"SubView" owner:self options:nil];
    self.subView.frame = CGRectMake(0.0, 50.0, 320.0, 40.0);
    [self.view addSubview:self.subView];
}

Na linha 4 estamos lendo do bundle da nossa app o arquivo NIB que contém nossa view. Depois, na linha 5, setamos a posição da nossa view dentro da view pai. Por fim, adicionamos a SubView na view pai. Voilá!

O “segredo” das coisas funcionarem, e o Xcode saber que nossa “SubView.xib” corresponde à propriedade subView do nosso controller, está na conexão feita lá em cima, no IB. Lembre-se sempre disso, pois é muito comum os desenvolvedores esquecerem este passo e depois ficarem malucos tentando entender porque sua aplicação não funciona corretamente.

Rode o programa e o resultado será algo assim:

É isto! Bem simples, como deveria ser mesmo. Quando for pensar no layout das suas aplicações, tenha em mente como esta técnica pode facilitar seu trabalho. Criar as views no IB é sempre mais fácil do que fazê-lo “na mão”.

Claro que existem considerações: alguns layouts podem ser um pouco mais complicados e não serem possíveis de serem feitos no IB. Outro fator a ser levado em conta é que a leitura de um arquivo de resource do “disco” é uma tarefa que demanda mais do hardware do iPhone do que construí-la no código (além do recurso gastar mais espaço). Para muitas aplicações isto, claro, não fará diferença. Avalie caso a caso.

Eu nunca entendi essa preferência, para ser sincero. Em se tratando de uma excelente ferramenta como o IB, o caso fica ainda mais grave. Antes de ter contato com ele, já havia utilizado quase tudo que existe disponível por aí (Delphi, VB, Visual Studio, Eclipse, Netbeans…), então posso falar sem medo: o Interface Builder é realmente excelente. Não deixa a desejar em nada e, a despeito de algumas idiossincrasias típicas do mundo Apple, não tem como não ficar fã.

Mas para quem prefere o estilo “mão na massa” para criar suas interfaces visuais, o Matt Campbell fez um post onde ele ensina como criar um ViewController através de código. Na verdade é algo bem simples de ser feito (tirando o trabalho de ficar criando todos os controles no código), mas achei interessante divulgar a dica porque acaba sendo útil para entender um pouco mais o under the hoods no Cocoa Touch. Em especial como e onde o Application Delegate cria a View inicial e essa View cria os controles que irão compor a interface com o usuário.

Resumo rápido:

1. No AppDelegate:applicationDidFinishLaunching você cria sua View e a adiciona à window (objeto já existente na AppDelegate – você usou os templates do Xcode, certo?).
2. No ViewController: loadView você cria seus controles visuais e os adiciona à view.

E não esqueça de contribuir com suas macros no projetinho que abri no Github.

Faço isso com todo o prazer! Já conheço o trabalho do Vinicius (e, por tabela, da galera da ImproveIt) desde 2007 2006, quando comecei a me envolver mais fortemente com metodologias ágeis. Nessa época era impossível não cair no site da ImproveIt em qualquer busca pelo assunto. Era uma referência excelente, com MUITO material de qualidade, além do blog e do podcast comandados pelo Vinicius.

Tive oportunidade também de assistir uma palestra dele no 1°. Minas on Rails, na qual ele, como de costume, brilhou. É um cara super didático nas suas explicações e consegue, com metáforas muito bem colocadas, traduzir de maneira clara as suas idéias, tanto nas palestras quanto no blog, artigos, etc.

Enfim, aprendi e aprendo muito com esse cara e agora espero conseguir retribuir de alguma forma, ajudando na divulgação do trabalho. Trabalho que, por sinal, é muito bom. Sugiro que conheçam o Be on the Net e também o modelo de negócios que está por trás da iniciativa, principalmente se você é um empreendedor da rede.

Pra quem achar que é só propaganda, fica a dica para acompanhar o blog da ImproveIt e também o Vinicius no Twitter. Sempre tem conteúdo muito bom vindo dele!

Mas é claro que o que é bom pode ficar melhor ainda. Você pode criar suas próprias macros para facilitar ainda mais sua vida. Está cansado de digitar:

@property (nonatomic, retain) NSTipoQualquer minhaPropriedade

nas suas interfaces?

Então é só criar uma macro que irá inserir o texto acima quando você digitar “@prop”, por exemplo. E colocando “placeholders” nos lugares certos (em NSTipoQualquer e minhaPropriedade), para facilitar a navegação e substituições necessárias.

O Xcode já vem com uma série de macros pré-definidas. Elas ficam no diretório /Developer/Applications/Xcode.app/Contents/PlugIns/TextMacros.xctxtmacro/Contents/Resources/. Macros criadas pelo usuário devem ser colocadas no diretório ~/Library/Application Support/Developer/Shared/Xcode/Specifications.

Para criar a macro @property acima, siga os passos:

1. Crie o arquivo ObjectiveC.xctxtmacro no diretório ~/Library/Application Support/Developer/Shared/Xcode/Specifications. Você provavelmente vai precisar criar este diretório, pois ele não é criado na instalação do Xcode.
2. Insira o código abaixo no seu arquivo ObjectiveC.xctxtmacro:

   /**
       Objective C text macro specifications
     by Marcelo Baltar
   */
   
   (
     {
       Identifier = objc.msb.property;
       BasedOn = objc;
       IsMenuItem = NO;
       Name = "@property definition";
       TextString = "@property (nonatomic, retain) <#datatype#> <#property#>";
       CompletionPrefix = "@prop";
       IncludeContexts = ( "xcode.lang.objc.interface" );
     },
   )
   

3. Reinicie o Xcode (sim, essa é a parte chata: toda edição nos arquivos das macros só será reconhecida após você reiniciar o Xcode).

Vamos dar uma olhada no arquivo para entendê-lo. As propriedades que definem uma macro devem estar entre colchetes. Se você criar várias macros em um mesmo arquivo (o que você provavelmente irá fazer), não se esqueça de separar cada definição com uma vírgula.

As propriedades que utilizamos para definir nossa macro foram:

Identifier: identificador único da macro. Pode ser qualquer string, desde que única entre suas macros. Mas, claro, tente colocar algo que faça sentido. No exemplo, utilizei obj para identificar uma macro para Objective-C (seguindo uma convenção da Apple), msb são as minhas iniciais e property é um nome que escolhi identificando o comando sobre o qual a macro será aplicada.

BasedOn: Define o “pai” dessa macro. Quaisquer propriedades não setadas na definição da sua macro serão herdadas do “pai” que você definir aqui. No nosso exemplo, estamos herdando da definição de objc.

IsMenuItem: Determina se a macro irá aparecer no menu Edit → Insert Text Macro.

Name: Nome da macro, que irá aparecer no menu Edit → Insert Text Macro, se  a propriedade IsMenuItem estiver setada (YES).

TextString: A string que efetivamente será inserida no seu código. Note que você pode configurar alguns placeholders, utilizando a sintaxe <#nome_do_placeholder#>. Lembrando que placeholders são aquelas posições na string inserida pelo code completion pelas quais você pode navegar com uma combinação de teclas (^/ por default).

CompletionPrefix: Essa é a macro que será substituída pelo conteúdo definido pela propriedade TextString.

IncludeContexts/ExcludeContexts: Essa propriedade serve para você definir um escopo onde sua macro funcionará. Ela não é obrigatória, mas é útil se você quiser utilizar, por exemplo, macros iguais com comportamentos diferentes, dependendo de onde ela for inserida, ou simplesmente para evitar situações onde a macro não se aplica. No nosso exemplo, o code completion só irá substituir @prop quando estiver definido dentro de uma @interface, o que faz todo o sentido.’

Algumas observações

Tenha muito cuidado com a sintaxe do arquivo, porque qualquer erro impedirá que o Xcode faça o parsing adequadamente e a mensagem de erro dele não será nem um pouco amigável. Isso se ele der alguma mensagem de erro. Ele pode simplesmente ignorar todo seu arquivo, ou uma parte dele, tornando bastante difícil a identificação do erro. Em especial, lembre-se sempre de fazer o correto escape das aspas, usando a barra invertida. Por exemplo:

TextString = "NSString *meuBlog = @\"Still Coding\"";


Você pode usar o mesmo valor do CompletionPrefix para diversas macros. Basta usar o atalho de teclado Next Completion para alternar entre as definições.

Os valores permitidos para as propriedades IncludeContext e ExcludeContext são:

"xcode.lang.objc.block"
"xcode.lang.objc.bracketexpr"
"xcode.lang.objc.parenexpr"
"xcode.lang.objc.interface"
"xcode.lang.objc.implementation",
"xcode.lang.objc.protocol.declaration",
"xcode.lang.objc.protocol",
"xcode.lang.objc.function.declaration",
"xcode.lang.objc.function.definition",
"xcode.lang.objc.typedef",
"xcode.lang.objc.initializer"


Criei um projetinho no github para ir colocando algumas macros que eu for definindo ao longo da vida. Fique à vontade para fazer um fork e contribuir com suas macros!

Disclaimer: As idéias para este post foram retiradas deste excelente artigo. Não deixe de visitá-lo para informações adicionais.

Em tempo: confira também esse post para saber mais sobre o autocompletion do Xcode.

Como você deve saber, a categoria Jogos não existe na AppStore nacional. E a maneira que alguns desenvolvedores encontram para “burlar” essa limitação é colocar o jogo na categoria “Entreterimento”.

O porém é que, nas AppStores não brasileiras, o ideal é que seja utilizada realmente a categoria Jogos, pois isso dá uma visibilidade muito maior ao trabalho.

Mas deixo o resto da história para o Blog do iPhone contar…

São vários controles utilizados na própria aplicação para o Facebook, bastante interessantes:

• Photo Viewer - Funcionalidade similar ao álbum de fotos do iPhone, com um grande diferencial: as fotos não precisam estar no aparelho, podem ser puxadas da rede/internet.
• Message composer – Para criar mensagens de e-mail de dentro da sua aplicação.

• Web image views – Para mostrar imagens a partir de uma url.
• Internet-aware table view controllers - Cria tabelas a partir de dados buscados na Internet. Suporte até para fazer reload se você balançar o iPhone.
• Better text fields - UITextView que aumenta de tamanho a medida que você digita e o TTPickerTextField, um campo de entrada de texto com sugestão.
• HTTP disk cache – funciona com o NSURLRequest, para fazer um request http, mas adicionando um cache.
• URL-based Navigation – faz a navegação da sua aplicação funcionar como se fosse páginas da Internet. Cada controller registra uma URL que, ao ser visitada, mostra a view associada ao controller.

O código está disponível no github, juntamente com uma aplicação de exemplo.

Thank you, Joe!