Mobits - Blog

Google comprará AdMob

2009-11-09T18:43:00Z

A AdMob, uma das maiores plataformas de anúncios móveis anunciou hoje para seus clientes e parceiros que assinou um acordo definitivo onde será adquirida pela Google por US$ 750 milhões.

A AdMob é conhecida pelos usuários de iPhone, pois diversos aplicativos, como o nosso Cine Mobits, utilizam a sua plataforma de propaganda para viabilizar sua gratuidade. Ela também disponibiliza propagandas para outras plataformas, como o Android.

A Google já havia anunciado a sua entrada no mercado de anúncios para dispositivos móveis, portando o Google Ads para o iPhone e o Android. Mas, como sabemos, a Google nunca entra para ser mais um no mercado, ela quer sempre ser a maior. A compra da AdMob certamente a consolidará como a maior player desse mercado.

Nós que utilizamos a plataforma da AdMob acreditamos que haverá melhorias com a maior oferta de anúncios do Google, podendo levar anúncios aos nossos aplicativos que sejam mais adaptados ao conteúdo do mesmo.

Leia também:

Como retirar o joystick do Cine Mobits do seu Nokia

2009-11-05T20:19:00Z

Olá pessoal,

com o lançamento da última versão do Cine Mobits Java, muitos usuários de celulares Nokia touch têm perguntado o porquê de aparecer um joystick quando iniciado o Cine Mobits. Então eis a resposta!

Nos novos celulares Nokia touch (como Nokia 5800, N97), a configuração para que apareça o joystick em aplicativos é padrão. Porém, há uma forma de alterar para que não apareça mais. Só deixar claro que isso é uma configuração por aplicativo, pois uns podem precisar do joystick, enquanto outros não, como no caso do Cine Mobits.

Então segue como alterar a configuração:
Menu -> Settings -> Application mgr -> Installed apps -> CineMobits - > Options -> Suite settings -> On-screen keyboard

Só atentem que para celulares em que a língua é em português, o passo-a-passo é o mesmo, porém traduzido para português!

Pronto! Agora você verá que quando iniciado o Cine Mobits não terá mais o joystick aparecendo.

Aproveitem o Cine Mobits :)

SETI 2009: Semana de Tecnologia e Inovação na UFRJ

2009-10-21T12:55:00Z

Evento adiado para Novembro! Não perca!

A EJCM está organizando a SETI, Semana de Tecnologia e Inovação, que vai trazer palestras de representantes de empresas como Google, Microsoft, Yahoo, Globo.com, entre outros. As palestras serão distribuidas em dois dias, 26 e 27 de Outubro UPDATE: 17 e 18 de Novembro e as inscrições são gratuitas.

Se você estiver no Rio nos dias do evento e conseguir aquela folga no trabalho, não perca a oportunidade de assistir às palestras, que vão abordar, entre outros assuntos, Desenvolvimento Ágil, Projetos inovadores e casos de sucesso.

Mobits desenvolve mais um aplicativo para a Módulo

2009-10-20T16:27:00Z

A Mobits acaba de desenvolver mais um aplicativo para iPhone: Módulo Workflow Manager. Ele também faz parte do pacote Módulo Risk Manager.

A partir da coleta de informações que ocorre no Risk Manager e o conhecimento dos riscos que permeiam a organização que está sendo avaliada, o passo seguinte é o tratamento destes riscos, que ocorre por meio do Workflow Manager. Esse tratamento é possível através da criação de eventos e o acompanhamento dos mesmos.

No Workflow Manager web, os eventos detêm vários atributos, porém somente os pré-requisitos são cadastrados no iPhone para facilitar a entrada de dados, pois sabemos que digitar é algo custoso em dispositivos móveis. Como no Módulo Risk Manager para iPhone, no Módulo Workflow Manager há a adição de fotos, áudio e localização GPS para cada evento.

Espero em breve escrever mais um post sobre o Módulo Workflow Manager para iPhone, contando onde este aplicativo está sendo utilizado. Aguardem!

Leia também:

Venda de conteúdo dentro de Apps Gratuitas

2009-10-15T22:06:00Z

Até que enfim!

A Apple decidiu liberar o chamado In App Purchase para aplicações gratuitas. Inicialmente, a venda de conteúdo extra era permitida somente em aplicações pagas, mas agora, com esta decisão da Apple, poderemos esperar o fim das aplicações lite e o começo das tão solicitadas aplicações demo (1, 2).

Agora, o desenvolvedor pode criar uma aplicação completa, mas restringir o acesso a determinadas funcionalidades e distribuí-la de modo gratuito na App Store. Se o cliente quiser adquirir as funcionalidades, poderá, de dentro da própria aplicação, comprá-las e ativá-las.

Isto também abre portas para novos modelos de negócio. Uma app gratuita é, normalmente, dezenas de vezes mais baixadas que qualquer app paga e o desenvolvedor poderá explorar isso para lançar aplicações completas gratuitas atingindo um número de clientes maior, mas ao mesmo tempo disponibilizar sua loja interna para vender conteúdo, créditos, fases, armas, equipamentos e muito mais.

Arrisco-me a dizer que esse mecanismo poderia ser mais uma arma contra a pirataria. Se cada desenvolvedor elaborar a sua maneira de destravar funcionalidades, crackear apps irá requerer mais trabalho do que é preciso hoje.

Podemos esperar boas novidades depois desta notícia. Pelo menos a Mobits já está planejando os modos de explorar esta oportunidade ;)

Dica: como obter o número do iPhone através de um aplicativo

2009-10-08T16:32:00Z

Pois é.. a primeira vista pode parecer estranho, mas desde o firmware 2.1 existe uma brecha no iPhone SDK que possibilita que o número do telefone seja obtido por um aplicativo. Fiquei sabendo quando li esse post no MacMagazine que diz que desenvolvedores mal intencionados estavam enviando telefones dos seus usuários para depois incomodá-los com ligações de marketing.

Não satisfeito, resolvi procurar na internet e achei o código para obter o número do telefone:

id number = [[NSUserDefaults standardUserDefaults] objectForKey:@”SBFormattedPhoneNumber”];

NSLog(@”user phone number is %@”, number);

Testando no iPhone 3G com firmware 3.1 e chip da operadora Claro, obtive o número do meu telefone com o seguinte formato: 5555-5555, sem o código do país e o DDD. Contudo, vi em algumas referências como esta, que quando esse método é usado em iPhones com chips americanos, ele retorna um número assim 1 (555) 555-5555... ainda vou testar em outras operadoras.

De qualquer forma, fica a dica. Não sei se ela servirá para alguma coisa útil, mas a primeira ideia que eu tive foi mandar para um servidor o número dos celulares das pessoas que pirateiam aplicativos, heheheh. Usando métodos anti-cracking como esse, seria possível identificar esses usuários e depois poder ligar dizendo: "Olá, eu sou o desenvolvedor do aplicativo que você pirateou, tudo bom?". Que acham da ideia?

Leia também:

Flash no iPhone?

2009-10-07T00:55:00Z

A resposta é não, pelo menos não o Flash Player. A Apple ainda se nega a permitir que a Adobe construa um player para seu navegador. Como a Adobe não poderia simplesmente aceitar esse obstáculo, afinal o Flash está largamente presente nos jogos online de hoje, ela está desenvolvendo uma outra alternativa.

Recentemente, foi divulgado no Adobe Labs que com o Flash Professional CS5 será possível compilar sua aplicação em ActionScript 3 para o iPhone OS. Assim, o desenvolvedor poderá disponibilizar seu aplicativo na própria App Store!

Imagino que terá bastante limitações, porque desenvolver algo dessa forma não dá pra usufruir completamente dos recursos existentes na linguagem nativa. Mas não posso negar que isso representa uma enorme facilidade para aqueles que já trabalham com Flash, pois assim poderão criar também para o iPhone/iPod Touch - que é um mercado em pleno crescimento. Além disso, penso em uma outra questão. Para desenvolver uma aplicação para iPhone só é possível com um Mac. Será que com a nova aposta da Adobe será possível desenvolver usando o Windows?

Para quem se animou, a Adobe promete lançar a versão beta do Flash Professional CS5 no final deste ano. Para quem quer ver um exemplo na prática, a Adobe mostrou alguns jogos já disponíveis na loja da Apple.

Até a próxima, pessoal!

update: Hoje enquanto fazia o post para o blog, perguntei para a @adobeflash se daria para desenvolver com o Flash para iPhone usando o Windows. O gerente de marketing de produto do Flash Adobe Professional, Jonathan Wall (@jwall), me respondeu que sim! Ou seja, vamos aguardar o fim do ano para conferir! ;)

Mais uma promoção do Mobits Button Soccer. Somente hoje!

2009-10-02T19:27:00Z

Dois motivos para comemorar: 1 ano da Mobits e a vitória da campanha Rio 2016. Todo mundo sai ganhando!

Não perca! Como o Rio de Janeiro foi a cidade escolhida para sediar os Jogos Olímpicos de 2016, para comemorar, a Mobits decidiu fazer uma promoção do jogo. Corra, MBS por $0,99.

A promoção ficará no ar somente hoje, então não dê bobeira!

Aproveito para avisar que já estamos devenvolvendo a próxima versão do jogo a partir das sugestões de todos os usuários. As mudanças previstas para entrar são:

Inteligencia Artificial
Escolha de times

Fiquem ligados no nosso twitter (@futeboldebotao) para saber mais detalhes.

Mobits completa um ano de vida!

2009-10-02T17:30:00Z

Parabéns!

Se hoje, dia 2 de outubro, a cidade do Rio de Janeiro comemora a eleição para sede das Olimpíadas de 2016, a Mobits está duplamente em festa: ontem comemoramos o nosso primeiro aniversário.

Como balanço, dois produtos, quatro grandes projetos, e o esforço de seguir à risca a nossa missão: ouvir nossos clientes para alcançar a satisfação daqueles que usam os nossos produtos.

É isso aí, pessoal, que mais e mais anos da Mobits venham! Parabéns para nós todos!

Leia também:

Programando para Windows Mobile usando MVC e Delegates - Parte 2

2009-09-24T17:40:00Z

Continuando o post sobre a utilização de MVC em um projeto para Windows Mobile no Visual Studio 2008, falaremos agora como lançar mão dos eventos para poder completar o padrão.

De acordo com algumas literaturas, a implementação do padrão MVC especifica que o modelo notifique a view em caso de alterações, de forma que os dados exibidos na view sejam atualizados.

Para fazer essa notificação, vamos ampliar um pouco mais o conceito de delegates, passado no primeiro post, e utilizar também eventos.

Na verdade, para os mais atentos, o conceito de evento já foi utilizado no post anterior, quando eu criei o seguinte método na view para adicionar um delegate:

public void AddSalvarClick(ViewEventsDelegate metodo) {
    BtnSalvar.Click += new EventHandler(metodo);
}

Estávamos na verdade dizendo que o evento Click do botão BtnSalvar iria acionar o método passado por ele por parâmetro. Assim, fica mais fácil entender o funcionamento de um evento:

Os eventos são os "gatilhos" para os delegates: quando um evento é chamado, os métodos adicionados a ele são chamados;
Os eventos não aceitam qualquer tipo de delegate: ao declarar um evento, você deve especificar qual o tipo de delegate está associado a ele. De uma forma direta, isso implica dizer que os eventos só aceitam os métodos com a assinatura especificada na declaração do delegate.

Voltemos ao nosso exemplo. Como disse acima, a implementação do padrão em camadas pede a notificação da view em caso de alteração no modelo. Mas aqui é necessário pensar um pouco na forma como essa notificação vai ser feita, principalmente no que diz respeito ao modo como a informação a ser alterada será passada para a view. Em alguns textos, ao notificar a view, o objeto de modelo passa como parâmetro ele mesmo, e a view pega então todos os valores do modelo e preenche. O problema que alguns podem ver aqui é o da acoplagem, pois eu estaria prendendo a classe view a um tipo específico de modelo. Uma solução alternativa seria criar notificações para várias alterações, passando então o valor (geralmente em tipos básicos como strings, inteiros, etc) só do que está sendo alterado.

Não sou puritano, mas acho as duas abordagens válidas. A vantagem da segunda - além da baixa acoplagem - é reduzir para métodos pequenos a alteração do conteúdo. Tenho certo medo de métodos do tipo AlteraTudo(object modelo), por ter séria tendência a se tornar um método frankenstein, difícil de dar manutenção.

Vamos ao código! Em um exemplo fictício, onde tenho um sistema de venda de livros, um modelo óbvio seria um Livro. Vou criar nesse exemplo um evento que trata a notificação da alteração do preço do livro. Quando o preço for alterado, ele notifica a todos aqueles que "assinaram" o evento.

  namespace PostMVC {
      //declarando o delegate
      public delegate void PriceChangeDelegate(float price);

      class Book {

          //criando o evento
          private event PriceChangeDelegate OnPriceChange;

          //metodo que adiciona delegates ao evento do preco
          public void AddPriceChangeDelegate(PriceChangeDelegate priceDelegate) {
              OnPriceChange += priceDelegate;
          }

          //o atributo preco
          private float _price;

          // Get e Set do campo preço. Perceba que no set eu chamo o 
          //evento que sera executado por causa da alteracao feita
          public float Price {
              get { return _price; }
              set {
                  _price = value;
                  if (OnPriceChange != null)
                      OnPriceChange(value);
              }
          }
      }
  }

Percebam a validação feita antes de executar o evento:

  if (OnPriceChange != null)
        OnPriceChange(value);

Um evento é nulo se nenhum delegate está associado a ele. Agora, na view, o código fica bem simples: basta adicionar um método que tenha a assinatura do delegate especificada, que faça essa alteração:

  public void AlteraPrecoNaTela(float preco) {
        //codigo que escreve na tela
  }

E no construtor também fica bem tranquila a implementação:

  class BookController {
        private Book model;
        private BookPriceForm view;

        //construtor
        BookController() {
              model = new Book();
              view = new BookPriceForm();

              model.AddPriceChangeDelegate(view.AlteraPrecoNaTela);
        }
  }

Com isso, o único que fica acoplado é o controller, que é quem realmente tem que ter os modelos e as vistas.

Dessa forma, você evita colocar o código todo no formulário, você traz a sua lógica de negócio para o controlador, seu código fica mais simples, mais fácil dar manutenção, e todos ficam felizes! :)

Leia também:

Performance do SQLite Persistent Object

2009-09-18T14:46:00Z

Da última vez que comparei as soluções ORM para iPhone, cheguei a conclusão de que o Sqlite Persistent Object - SPO era o mais indicado para o projeto que estávamos desenvolvendo. Agora, com o projeto concluído, observamos que a performance não estava adequada às necessidades do cliente e começamos a buscar soluções.

Minha primeira idéia foi aproveitar a chegada do iPhone OS 3.0 e migrar do SPO para Core Data imaginando que, por ser uma solução desenvolvida especificamente para a plataforma, seria bem mais eficiente. Contudo, após estudo da API, vi que a mudança seria um pouco mais complicada, pois ela usa um paradigma diferente da anterior e eu teria que mexer muito além das classes de modelo, possivelmente mexendo em todas as outras classes, controladores principalmente. Embora tenha coberto as classes de modelo com testes unitários, achei que seria arriscado demais fazer a mudança estando tão próximo da entrada do sistema em produção. Decidi deixar essa idéia na gaveta e parti para tentar melhorar o que já estava implementado e em funcionamento.

Avaliando o tempo de cada atividade

Não faz sentido buscar melhorias na performance se você não tiver como saber se as modificações estão realmente influenciando no tempo de cada atividade. Para avaliar isso, existem algumas ferramentas disponíveis no Mac OS, como o Instruments e o Shark. Utilizando a segunda, consegui ter uma idéia clara de quais métodos estavam consumindo mais tempo da CPU através da análise de Time Profile.

Mas para medir o tempo de uma atividade completa - que atravessa vários métodos, threads, callbacks - eu desenvolvi uma classe simples, porém eficaz, para calcular esses tempos. Uma classe que batizei de Benchmark e que pode ser usada da seguinte maneira:

- baixarLista {
    [Benchmark start:@"baixarLista"];
    ....
}

- exibirLista {
    .....
    [Benchmark finish:@"baixarLista"];
}

A saída seria algo parecido com:

2009-09-17 13:52:49.729 MyAPP[876:20b] BENCHMARK: baixarLista started
2009-09-17 13:52:56.507 MyAPP[876:6b07] BENCHMARK: baixarLista: 6.777050s

As vantagens desta abordagem são:

o código é pouco invasivo, pois você pode dar o import do Benchmark no .pch e usar em todas as classes;
permite o uso de labels para identificar o benchmark, o que permite realizar vários benchmarks ao mesmo tempo sem se confundir;
por utilizar somente métodos estáticos, permite que um benchmark comece num método de uma classe e termine no de outra classe sem que seja necessário o compartilhamento de dados entre as classes.

O código completo da classe você confere aqui.

Identificando os gargalos

Depois de levantar o tempo gasto e os métodos mais custosos durante a execução de cada atividade, pude me concentrar em encontrar os pontos considerados gargalos e que eu poderia fazer alguma mudança.

Datas

O SPO armazena os campos de data como strings no banco e todas as operações de recuperação ou gravação passam por métodos de conversão definidos em NSDate-SQLitePersistence.m. Analisando a saída do Shark, observei que estas conversões estavam tomando muito tempo de processamento e, para minha surpresa, a maior parte do tempo não era gasta com a conversão em si, mas com a instanciação da classe NSDateFormatter. Para solucionar o problema, bastou declarar o formatador como estático e instanciá-lo somente uma vez, criando uma espécie de cache. Esta modificação já surtiu um grande efeito, pois a atividade que estava sendo trabalhada envolvia, de uma só vez, o download, gravação e exibição de uma lista de entidades que possuíam 3 campos de data cada uma.

Lista dinâmica de propriedades

Dentre vários métodos do SPO, são feitas chamadas ao método propertiesWithEncodedTypes das entidades para obter um dicionário com todas suas propriedades e seus respectivos tipos. Esse método é relativamente custoso, pois esse dicionário é montado toda vez que o método é solicitado e, a cada busca por uma lista de entidades, podem ser feitas dezenas - ou centenas - de chamadas a este método.

Mais uma vez, a solução foi simples: cache. Depois da primeira chamada do método, o dicionário fica gravado numa variável estática que é consultada nas chamadas subsequentes. Resultado: mais um salto na performance.

Strings

As propriedades das entidades em Objective C são declaradas em camelCase, enquanto as respectivas colunas do banco seguem uma notação_com_underscores e para fazer essa conversão, o SPO define dois métodos em NSString-SQLiteColumnName.m. Como nos casos anteriores, esses métodos são muito solicitados durante as atividades, mas eu consegui fazer uma estatística que mostrava em em mais de 80% dos casos a conversão era desnecessária, pois a propriedade tinha a mesma notação tanto no código quanto na base. A mudança neste caso foi simplesmente verificar antes se o nome já estava no formato certo e retorná-lo imediatamente. Outro salto na performance.

Conclusão

Com as mudanças acima e utilizando a classe de benchmark, conseguir registrar melhoras de mais de 60% em diversas atividades do aplicativo. Registrei quedas, por exemplo, de 11 para 4 segundos, outras de 9 para 3.

Fiquei muito satisfeito com o resultado, principalmente por não ter que encarar uma mudança profunda no mecanismo de armazenamento do aplicativo tão próximo da entrada em produção.

Se você também utiliza o SQLite Persistent Objects na sua app, pode baixar o patch aqui.

Acessando a lista de contatos do iPhone dentro da sua app

2009-09-16T21:56:00Z

Olá pessoal!

Depois que descobri que não mais poderia enviar SMS dentro da minha app, tive que mudar a funcionalidade que estava implementando para deixar de ser envio de SMS para ser de email. Mas eu não queria que este envio de email fosse feito fora da minha aplicação por meio do Mail App. Então decidi criar um formulário de email com a mesma facilidade de poder acessar a lista de contatos do iPhone e escoher o email de um contato já cadastrado.

Pesquisando, achei a referência no iPhone Dev Center de como acessar a lista. Mas como sou legal, segue um exemplo.

Primeiro, adicione um botão à sua view e crie um método para este botão no controller. Neste método, a tela de contatos será chamada e exibida:

- (IBAction)clickAdicionaEmail:(id)sender {
ABPeoplePickerNavigationController *picker = [[ABPeoplePickerNavigationController alloc] init]; 
picker.peoplePickerDelegate = self;
[self presentModalViewController:picker animated:YES]; 
[picker release];   
}

A seguir, o delegate da classe ABPeoplePickerNavigationController deve ser implementado, conforme vemos abaixo:

- (void)peoplePickerNavigationControllerDidCancel:(ABPeoplePickerNavigationController *)peoplePicker { 
[self dismissModalViewControllerAnimated:YES]; 
}

O método acima é chamado quando a ação de exibir a lista de contatos é cancelada. No nosso exemplo, simplesmente a tela é fechada.

- (BOOL)peoplePickerNavigationController:(ABPeoplePickerNavigationController *)peoplePicker shouldContinueAfterSelectingPerson:(ABRecordRef)person {
return YES; 
}

Este segundo é chamado após um contato da lista é selecionado. Acima, este método retorna YES porque quero selecionar uma informação do contato e não o próprio, ou seja, se fosse necessário somente o nome do contato, era só pegar esta informação e retornar NO no método.

- (BOOL)peoplePickerNavigationController:(ABPeoplePickerNavigationController *)peoplePicker shouldContinueAfterSelectingPerson:(ABRecordRef)person property:(ABPropertyID)property identifier:(ABMultiValueIdentifier)identifier {
if (property == kABPersonEmailProperty) {
    CFTypeRef emails = ABRecordCopyValue(person, property);
    CFIndex indiceEmail = ABMultiValueGetIndexForIdentifier(emails, identifier);

    self.emailContato.text = (NSString *)ABMultiValueCopyValueAtIndex(emails, indiceEmail);
    [self dismissModalViewControllerAnimated:YES];
}

return NO;
}

Já o último é quando desejo selecionar um informação do contato, como, por exemplo, o email. No nosso caso, email é uma propriedade multivalorada, ou seja, o contato pode ter mais de um, por isso, precisamos saber exatamente qual queremos. No exemplo, qualquer email selecionado do contato é válido.

Pronto! É assim que conseguimos selecionar email dos nossos contatos do iPhone na nossa app.

Até a próxima :)

Leia também:

Mobits no Diário do Comércio

2009-09-08T21:41:00Z

Confira a matéria sobre a Mobits no Diário do Comércio!

A Mobits acabou de ganhar destaque na matéria do Diário do Comércio. Para conferir acesse: http://www.dcomercio.com.br/Materia.aspx?id=26483&canal=53

Ficamos muito felizes em ver nosso trabalho mais uma vez exposto na mídia!

Promoção do Mobits Button Soccer. Somente hoje!

2009-09-05T12:00:00Z

Promoção especial no dia de Brasil x Argentina! 50% de desconto! Aproveite e indique aos amigos!

Não perca! Por causa do clássico internacional Brasil x Argentina - que são os times disponíveis no MBS - a Mobits decidiu fazer uma promoção do jogo liberando-o por 50% de desconto.

A promoção ficará no ar somente hoje, então não dê bobeira!

Aproveito para avisar que já estamos devenvolvendo a próxima versão do jogo a partir das sugestões de todos os usuários. As mudanças previstas para entrar são:

Inteligencia Artificial
Escolha de times

A previsão é que esta versão esteja disponível dentro de um mês. Então fiquem ligados no nosso twitter (@futeboldebotao) para saber mais detalhes.

Envio de SMS: Java ME x iPhone OS

2009-09-01T22:25:00Z

Olá pessoal,

estou aqui para contar para vocês a minha última saga com o desenvolvimento de aplicativos em Java ME e iPhone OS. Dessa vez parecia ser uma funcionalidade boba, mas que me rendeu algumas horinhas e trabalho jogado fora. :(

A funcionalidade era envio de SMS. Primeiro desenvolvi em Java ME. Não foi difícil pesquisar e encontrar o algoritmo que fizesse isso. O mais chato foi ter a certeza de que este algoritmo realmente funcionava para os mais diversos celulares.

Para que vocês não tenham o mesmo tabalho que tive, segue o algoritmo de envio de email em Java ME:

try {
        MessageConnection connection = (MessageConnection)Connector.open("sms://99999999");

        TextMessage sms = (TextMessage)connection.newMessage(MessageConnection.TEXT_MESSAGE);
        sms.setPayloadText("Olá");

        connection.send(sms);
        connection.close();
    } 
    catch (SecurityException e) {
        e.printStackTrace();
    } 
    catch (IOException e) {
        e.printStackTrace();
    } 
    catch (Exception e) {
        e.printStackTrace();
    }

Terminado o desenvolvimento em Java ME, fui em busca do algoritmo que fizesse o mesmo em iPhone. Porém, como para mim era certo de que acharia a solução, fiz logo um formulário de envio de SMS. Mas não estava certa. Depois de inúmeras pesquisas, inclusive em fóruns da própria Apple, a única coisa que descobri foi que os aplicativos para iPhone que desejam enviar SMS, só farão isso fora do mesmo, ou seja, a única coisa que fazemos é chamar o aplicativo de mensagens que o iPhone possui. E para piorar, nem a mensagem pode ser preenchida pelo nosso aplicativo, somente o número. Então, percebi que de nada adiantou meu esforço para fazer o formulário de envio de SMS. Dessa vez a Apple me decepcionou. :(

Segue abaixo, como chamar o aplicativo de mensagens do iPhone:

NSString *stringURL = @"sms:99999999";
NSURL *url = [NSURL URLWithString:stringURL];
[[UIApplication sharedApplication] openURL:url];

Ah, e não se esqueçam que depois de enviada sua mensagem SMS, o seu aplicativo não volta, ou seja, o usuário precisa novamente acessá-lo.

É, dessa vez os créditos estão todos com o Java ME! Espero sinceramente que a Apple libere o envio de SMS de dentro de aplicativos desenvolvidos por nós.

Valeu :)