twitterfacebookgoogle pluslinkedinrss feedemail

quarta-feira, 28 de outubro de 2015

Nome do StoryBoard IOS - XCODE 7

Em uma implementação de um @protocol do Facebook, queria redirecionar para um novo ViewController.
Contudo, teria que recriar o StoryBoard para realizar esta atividade.
Depois de fazer login no facebook, executa método loginButton. Implementei o método para recriar o SB e enviar para outro ViewController.
Veja o código abaixo:
 //Implementacoes do Protocol do botão do Facebook.  
 -(void)loginButton:(FBSDKLoginButton *)loginButton didCompleteWithResult:(FBSDKLoginManagerLoginResult *)result error:(NSError *)error{  
   NSLog(@"Logado");  
   UIStoryboard *sb = [UIStoryboard storyboardWithName:@"Main.storyboard" bundle:nil];  
   UIViewController *vc = [sb instantiateViewControllerWithIdentifier:@"SegundoLoginVC"];  
   vc.modalTransitionStyle = UIModalTransitionStyleFlipHorizontal;  
   [self presentViewController:vc animated:YES completion:NULL];  
   //[self performSegueWithIdentifier:@"segundoLoginFB" sender:self];  
 }  

Ocorria o seguinte erro, onde não sabia o nome id do meu StoryBoard.
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Could not find a storyboard named 'Main.storyboard' in bundle NSBundle 
Para saber o nome do StoryBoard, vemos no arquivo .plist.





sexta-feira, 23 de outubro de 2015

Git - GitHub - Controle de Versão - Desfazendo e Refazendo

Este é o quinto artigo sobre o Git.
Para ler o primeiro artigo, com comandos essenciais. Clique aqui.
Para ler o segundo artigo, com comandos para servidores remotos. Clique aqui.
Para ler o terceiro artigo, com comandos para fazer Tags/Releases. Clique aqui.
Para ler o quarto artigo, com comandos para Branchs. Clique Aqui.

Estudando sobre como voltar versões de arquivos e commits, senti dificuldade em diferenciar os comandos checkout, reset e revert.
A diferença entre esses comandos são interessantes, vamos começar com exemplos práticos, para identificar a diferença entre eles e saber quando usar.
O Git tem três componentes principais:
1 - Diretório de Trabalho
2 - Snapshot
3 - Histórico de Commits
Lembre-se destes componentes para saber a diferença do que estamos fazendo.

Checkout.
O comando checkout já é conhecido para entrar em branch, contudo podemos utilizar ele para verificar revisões antigas do nosso sistema.
Imagina que queira verificar como era o seu sistema na versão v.2.0, simular algumas funções nesta versão antiga.
O comando checkout altera o seu diretório de trabalho com a versão informada, por isso, antes de realizar o comando é necessário fazer commit das alterações que você realizou.
Eu vi na Internet algumas pessoas usando o checkout de uma forma de desfazer os commits realizados, o checkout não deve ser usado desta forma, somente para verificar versões antigas, uma forma de consulta.
Vou verificar a versão do meu sistema de exemplo na versão v.2.0.
Primeiramente criei um branch, não economizem na criação de branch é rápido e utiliza poucos recursos. Como o git trabalha com apontamentos, criar um branch é bem economico e te ajuda muito no trabalho.
Depois verifiquei as tags que criei e utilizei o comando git checkout v.2.0, com este comando nosso diretório de trabalho já foi substituído para a versão 2.0 e podemos fazer as verificações necessárias.
Verifique os comandos abaixo.
$ git branch testeCheckout  
$ git checkout testeCheckout  
 Switched to branch 'testeCheckout'  
 MacMiniRomero:TesteStoryBoard douglasromero$ git branch  
  Teste_2  
  master  
 * testeCheckout  
$ git tag  
 v.1.0  
 v.2.0  
 v.3.0  
$ git checkout v.2.0  
 Note: checking out 'v.2.0'.  
 You are in 'detached HEAD' state. You can look around, make experimental  
 changes and commit them, and you can discard any commits you make in this  
 state without impacting any branches by performing another checkout.  
 If you want to create a new branch to retain commits you create, you may  
 do so (now or later) by using -b with the checkout command again. Example:  
  git checkout -b <new-branch-name>  
 HEAD is now at 2128d14... Segunda Parte do Tutorial  
O git somente faz um apontamento para a versão 2.0. Os snapshots e o histórico de commits continuam existindo.
No exemplo abaixo, mandei exibir os commits da versão 2.0 e depois fiz um checkout em um versão mais recente, 3.0, depois executei o git log para exibir os commits, verificamos que tudo isso continua existindo no branch, histórico de commits e shapshot
$ git log --oneline  
 2128d14 Segunda Parte do Tutorial  
 7eda703 Initial Commit  
$ git checkout v.3.0  
 Previous HEAD position was 2128d14... Segunda Parte do Tutorial  
 HEAD is now at 02215fd... Inserindo arquivo de ignore.#  
$ git log --oneline  
 02215fd Inserindo arquivo de ignore.#  
 d28226b Update TesteStoryBoardTests.m  
 81c3aa1 Merge branch 'master' of https://github.com/dsromerobr/TesteStoryBoard  
 55f8e2a Deletando arquivos de configuração de usuário. Ok.  
 aa3945a Commit com alterações do exemplo de GIT. Inclusão de uma property na primeira tela.  
 afb0c3e Create README.md  
 2128d14 Segunda Parte do Tutorial  
 7eda703 Initial Commit  

O checkout também aceita passar um arquivo, caso queremos restaurar somente o histórico de um arquivo.
$ cat arquivo.txt   
 primeiro commit.  
 segundo commit.  
 terceiro commit.  
 quarto commit.  
$ git log --oneline  
 9d1e52e quarto commit  
 44bd001 terceiro commit  
 ce62788 segundo commit  
 7cc5847 arquivo de teste 1  
 02215fd Inserindo arquivo de ignore.#  
 d28226b Update TesteStoryBoardTests.m  
 81c3aa1 Merge branch 'master' of https://github.com/dsromerobr/TesteStoryBoard  
 55f8e2a Deletando arquivos de configuração de usuário. Ok.  
 aa3945a Commit com alterações do exemplo de GIT. Inclusão de uma property na primeira tela.  
 afb0c3e Create README.md  
 2128d14 Segunda Parte do Tutorial  
 7eda703 Initial Commit  
$ git checkout ce62788 arquivo.txt   
$ cat arquivo.txt   
 primeiro commit.  
 segundo commit.  

Lembrando que o checkout mexe somente com o diretório de trabalho. Se executarmos o git status, mostrará que tem um arquivo modificado para entrar em staged.
 $ git status  
 On branch testeCheckOutArquivo  
 Changes to be committed:  
  (use "git reset HEAD <file>..." to unstage)  
      modified:  arquivo.txt  

Reset.
O comando reset é um modo de voltar o snapshot para um ponto específico.
Imagina que você fez 3 commits e queira voltar para um ponto específico, assim removendo os commits, este comando consegue fazer isso.
O reset é o comando mais complicado e deve ser usado com cautela.
Este comando tem 3 flags.
--soft -> O diretório de trabalho e o snapshot não são alterados.
--mixed -> O snapshot é alterado mas o diretório de trabalho não altera. Default.
--hard -> Altera tudo para o ponto específico.

Vamos utilizar o parâmetro --soft, onde foram feitos diversos commits com somente o arquivo.txt, gostaria de realizar somente um commit dele. Executando o comando reset com o parâmetro --soft, gostaria de fazer somente 1 commit. Escolhi o commit de hash 7cc5847, assim o snapshot e o diretório de trabalho serão mantidos e farei somente um commit.
$ git log --oneline  
 9d1e52e quarto commit  
 44bd001 terceiro commit  
 ce62788 segundo commit  
 7cc5847 arquivo de teste 1  
 02215fd Inserindo arquivo de ignore.#  
 d28226b Update TesteStoryBoardTests.m  
 81c3aa1 Merge branch 'master' of https://github.com/dsromerobr/TesteStoryBoard  
 55f8e2a Deletando arquivos de configuração de usuário. Ok.  
 aa3945a Commit com alterações do exemplo de GIT. Inclusão de uma property na primeira tela.  
 afb0c3e Create README.md  
 2128d14 Segunda Parte do Tutorial  
 7eda703 Initial Commit  
$ git branch  
  master  
  testeCheckOutArquivo  
 * testeReset  
$ git reset --soft 7cc5847  
$ git log --oneline  
 7cc5847 arquivo de teste 1  
 02215fd Inserindo arquivo de ignore.#  
 d28226b Update TesteStoryBoardTests.m  
 81c3aa1 Merge branch 'master' of https://github.com/dsromerobr/TesteStoryBoard  
 55f8e2a Deletando arquivos de configuração de usuário. Ok.  
 aa3945a Commit com alterações do exemplo de GIT. Inclusão de uma property na primeira tela.  
 afb0c3e Create README.md  
 2128d14 Segunda Parte do Tutorial  
 7eda703 Initial Commit  
$ git status  
 On branch testeReset  
 Changes to be committed:  
  (use "git reset HEAD <file>..." to unstage)  
      modified:  arquivo.txt  

O git reset aceita um arquivo como parâmetro, diferente do checkout, que trás a versão antiga do arquivo para o snapshot atual, o reset manda a versão do arquivo atual para um determinado snapshot.
Veja o exemplo abaixo:
$ git reset Head~1 arquivo.txt   
 Unstaged changes after reset:  
 M     arquivo.txt  
 MacMiniRomero:TesteStoryBoard douglasromero$ cat arquivo.txt   
 primeiro commit.  
 segundo commit.  
 terceiro commit.  
 quarto commit.  
 quinto commit.  
 sexto commit.  
$ git log --oneline  
 cff27cc nova version  
 a22627f Commit de teste !!!  
 6584065 Merge branch 'teste2' into testeCheckOutArquivo Teste de Mergeeeeee  
 611c47d teste de commit do branch  
 9d1e52e quarto commit  
 44bd001 terceiro commit  
 ce62788 segundo commit  
 7cc5847 arquivo de teste 1  
 02215fd Inserindo arquivo de ignore.#  
 d28226b Update TesteStoryBoardTests.m  
 81c3aa1 Merge branch 'master' of https://github.com/dsromerobr/TesteStoryBoard  
 55f8e2a Deletando arquivos de configuração de usuário. Ok.  
 aa3945a Commit com alterações do exemplo de GIT. Inclusão de uma property na primeira tela.  
 afb0c3e Create README.md  
 2128d14 Segunda Parte do Tutorial  
 7eda703 Initial Commit  
$ git checkout a22627f  
 M     arquivo.txt  
 Note: checking out 'a22627f'.  
 You are in 'detached HEAD' state. You can look around, make experimental  
 changes and commit them, and you can discard any commits you make in this  
 state without impacting any branches by performing another checkout.  
 If you want to create a new branch to retain commits you create, you may  
 do so (now or later) by using -b with the checkout command again. Example:  
  git checkout -b <new-branch-name>  
 HEAD is now at a22627f... Commit de teste !!!  
$ cat arquivo.txt  
 primeiro commit.  
 segundo commit.  
 terceiro commit.  
 quarto commit.  
 quinto commit.  
 sexto commit.  

Revert.
Este é o comando seguro para desfazer coisas, os outros comandos são interessantes para branchs privados, contudo em branchs públicos, como o GitHub, utilizar o revert é a melhor opção para evitar problemas.
Execute o comando abaixo:
 $ git revert 2128d14  
Ele irá fazer um merge e poderá ocorrer conflitos.
Assim, tem os parâmetros para dar sequencia em caso de conflitos.
git revert --continue
git revert --abort
git revert --quit


Git - GitHub - Controle de Versão - Branchs

Este é o quarto artigo sobre o Git.
Para ler o primeiro artigo, com comandos essenciais. Clique aqui.
Para ler o segundo artigo, com comandos para servidores remotos. Clique aqui.
Para ler o terceiro artigo, com comandos para fazer Tags/Releases. Clique aqui.

Branch ou Ramificações é um conceito muito interessante no Git.
Nos sistemas CVS comuns no mercado, fazer um Branch é um processo trabalhoso e demorado, mas no Git este processo é bem rápido e fácil.
Somente é feito um apontamento para um snapshot do master, com isso, não é necessário copiar todos os arquivos como nos outros sistemas de controle de versão.

Criando um Branch.
Para criar um novo Branch, utilizamos o comando abaixo.
 $ git branch Teste  
 $ git branch  
  Teste  
 * master  
Depois digitamos o comando git branch, onde exibe todos branchs. Repare que o *, na frente do master, exibe qual branch estamos. Atualmente estamos trabalhando no Master. No branch que estamos trabalhando é chamado de Head.
Agora vamos mudar para o Branch que criamos, através do comando checkout.
$ git checkout Teste  
 Switched to branch 'Teste'  
$ git branch  
 * Teste  
  master  
Agora identificamos que alteramos para o branch Teste. Repare no * na frente do Branch Teste.
Alterei um arquivo no branch Teste e o mesmo arquivo no Master, para simular um conflito.
Sempre que for alterar de branch, verifique se fez commit das suas alterações.
 $ git commit -a -m "Testando Branch #1"  
Depois fazer o checkout para o master.
 $ git checkout master  
 Switched to branch 'master'  
 Your branch is ahead of 'origin/master' by 1 commit.  
  (use "git push" to publish your local commits)  
Agora usamos o comando git merge, para fazer o merge dos arquivos. No caso, irá ocorrer um conflito, conforme abaixo.
 $ git merge Teste  
 Auto-merging TesteStoryBoard/Base.lproj/Main.storyboard  
 CONFLICT (content): Merge conflict in TesteStoryBoard/Base.lproj/Main.storyboard  
 Automatic merge failed; fix conflicts and then commit the result.  
 MacMiniRomero:TesteStoryBoard douglasromero$ git status  
 On branch master  
 Your branch is ahead of 'origin/master' by 1 commit.  
  (use "git push" to publish your local commits)  
 You have unmerged paths.  
  (fix conflicts and run "git commit")  
 Unmerged paths:  
  (use "git add <file>..." to mark resolution)  
      both modified:  TesteStoryBoard/Base.lproj/Main.storyboard  
 no changes added to commit (use "git add" and/or "git commit -a")  
Resolvendo Conflitos.
Utilizamos a ferramenta mergetool. Na versão que estou utilizando, no MAC OSX, defini para utilizar a ferramenta externa opendiff, que veem com o mac.
 $ git mergetool --tool=opendiff   
Abrirá uma tela com os arquivos para você realizar o merge manual.
Depois de resolver os conflitos, conseguirá realizar o commit.

Deletando um Branch.
Para deletar um branch, utilizamos o comando branch com o parâmetro -D.
$ git branch -D teste  
 Deleted branch teste (was 4c9d7fd).  

Listagem de Branch.
Para ver o último commit em cada branch, interessante para saber os status de cada um.
 $ git branch -v  
  NorthWind 4c9d7fd Revert "Segunda Parte do Tutorial"  
  SouthWind 4c9d7fd Revert "Segunda Parte do Tutorial"  
 * master  4c9d7fd [ahead 1] Revert "Segunda Parte do Tutorial"  
Listar somente os branchs que sofreram merge.
 $ git branch --merged  
  NorthWind  
 * master  
Somente os branchs que não sofreram merge.
 $ git branch --no-merged  
  SouthWind  

Branch Remotos.
Quando fazemos o clone de um branch, cria automaticamente o server remoto como sendo origin.
Para referenciar branchs remotos, utilizamos: remote/branch
Veja o exemplo abaixo de um checkout em um server remoto.
$ git status origin/master  
 On branch master  
 Your branch is ahead of 'origin/master' by 2 commits.  
  (use "git push" to publish your local commits)  
 nothing to commit, working directory clean  
$ git checkout origin/master  
 Note: checking out 'origin/master'.  
 You are in 'detached HEAD' state. You can look around, make experimental  
 changes and commit them, and you can discard any commits you make in this  
 state without impacting any branches by performing another checkout.  
 If you want to create a new branch to retain commits you create, you may  
 do so (now or later) by using -b with the checkout command again. Example:  
  git checkout -b <new-branch-name>  
 HEAD is now at 02215fd... Inserindo arquivo de ignore.#  
$ git log --oneline  
 02215fd Inserindo arquivo de ignore.#  
 d28226b Update TesteStoryBoardTests.m  
 81c3aa1 Merge branch 'master' of https://github.com/dsromerobr/TesteStoryBoard  
 55f8e2a Deletando arquivos de configuração de usuário. Ok.  
 aa3945a Commit com alterações do exemplo de GIT. Inclusão de uma property na primeira tela.  
 afb0c3e Create README.md  
 2128d14 Segunda Parte do Tutorial  
 7eda703 Initial Commit  
$ git branch  
 * (HEAD detached at origin/master)  
  NorthWind  
  SouthWind  
  master  

Para sincronizar o seu branch com o remoto, utilizamos o seguinte comando:
 $ git fetch origin  

Criando Servidor Remoto.
Também é possível adicionar outro servidor remoto e fazer a referencia para acessar ele, para adicionar outro servidor remoto:
 $ git remote add testeremote https://github.com/dsromerobr/TesteStoryBoard.git  

Verificar os servidores remotos.
 $ git remote -v  
 origin     https://github.com/dsromerobr/TesteStoryBoard.git (fetch)  
 origin     https://github.com/dsromerobr/TesteStoryBoard.git (push)  
 testeremote     https://github.com/dsromerobr/TesteStoryBoard.git (fetch)  
 testeremote     https://github.com/dsromerobr/TesteStoryBoard.git (push)  

Enviando dados (Pushing).
Para enviar dados para o servidor remoto, utilizamos o comando Push.
Vamos criar um branch remoto SouthWind, também podemos criar o Branch com outro nome, alterando para SouthWind:NOVONOME.
 $ git push origin SouthWind:SouthWind  
 Counting objects: 23, done.  
 Delta compression using up to 8 threads.  
 Compressing objects: 100% (18/18), done.  
 Writing objects: 100% (23/23), 3.98 KiB | 0 bytes/s, done.  
 Total 23 (delta 6), reused 0 (delta 0)  
 To https://github.com/dsromerobr/TesteStoryBoard.git  
  * [new branch]   SouthWind -> SouthWind  

Para fazer push para o branch.
 $ git push origin SouthWind  
 Everything up-to-date  

Pegando um novo Branch remoto.
Caso você tenha que trabalhar em um branch, para fazer checkout e criar este branch remoto, utilizamos o comando checkout.
 $ git checkout -b SouthWind origin/SouthWind  
 Branch SouthWind set up to track remote branch SouthWind from origin.  
 Switched to a new branch 'SouthWind'  
 $ git branch  
  NorthWind  
 * SouthWind  
  master  

Leia o quinto artigo, desfazendo e refazendo.

terça-feira, 20 de outubro de 2015

Git - GitHub - Controle de Versão - TAGS

Esta é a terceira parte do artigo sobre Git.
Para ler o primeiro artigo, com comandos essenciais. Clique aqui.
Para ler o segundo artigo, com comandos para servidores remotos. Clique aqui.

Um recurso interessante é criar TAGs, para marcar pontos de release do seu sistema/aplicativo.

Listando Tags.
O comando abaixo exibe as Tags cadastradas no repositório.
  $ git tag   
  v.3.0   

Executando o comando show, podemos ver os detalhes sobre a tag, como a anotação, quem fez a tag, etc.
 $ git show v.3.0  
 tag v.3.0  
 Tagger: Douglas Romero <romero@dsromero.com.br>  
 Date:  Tue Oct 20 10:20:38 2015 -0200  
 Teste de Tags  
 commit 02215fdcd470b0c55bc8a1cb94cc56897e9bc892  
 Author: Douglas Romero <romero@dsromero.com.br>  
 Date:  Tue Oct 20 08:53:43 2015 -0200  
   Inserindo arquivo de ignore.#  
 diff --git a/.gitignore b/.gitignore  
 new file mode 100644  
 index 0000000..07cb108  
 --- /dev/null  
 +++ b/.gitignore  
 @@ -0,0 +1,2 @@  
 +TesteStoryBoard.xcodeproj/xcuserdata/  
 +TesteStoryBoard.xcodeproj/project.xcworkspace/xcuserdata/  
 diff --git a/TesteStoryBoard/Base.lproj/Main.storyboard b/TesteStoryBoard/Base.lproj/Main.storyboard  
 index 5482739..73b6efb 100755  
 --- a/TesteStoryBoard/Base.lproj/Main.storyboard  
 +++ b/TesteStoryBoard/Base.lproj/Main.storyboard  
 @@ -80,7 +80,7 @@  
              <autoresizingMask key="autoresizingMask" widthSizable="YES" heightSizable="YES"/>  
              <subviews>  
                <label opaque="NO" userInteractionEnabled="NO" contentMode="left" horizontalHuggingPriority="251" verticalHuggingPriority="251" fixedFrame="YES" restorationIdentifier="sbSegundoLabel" text="Segunda Tela " textAlignment="natural" lineBreakMode="tailTruncation" baselineAdjustment="alignBaselines" adjustsFontSizeToFit="NO" translatesAutoresizingMaskIntoConstraints="NO" id="GKn-eI-peT">  
 -                <rect key="frame" x="29" y="101" width="108" height="21"/>  
 +                <rect key="frame" x="29" y="101" width="541" height="21"/>  
                  <fontDescription key="fontDescription" type="system" pointSize="17"/>  
                  <color key="textColor" red="0.0" green="0.0" blue="0.0" alpha="1" colorSpace="calibratedRGB"/>  
                  <nil key="highlightedColor"/>  

Criando Tags.
Utilizando o comando abaixo, criamos uma Tag anotada, utilizando o parametro -a, passando o nome da versão e o -m e em seguida a mensagem para a tag anotada.
Também pode-se criar tag sem esta anotação, chamada de Tag leve.
 $ git tag -a v.3.0 -m "Teste de Tags"  

Criando Tags de commits anteriores.
Vamos ver o log de commits de nossa aplicação.
 $ git log --oneline  
 02215fd Inserindo arquivo de ignore.#  
 d28226b Update TesteStoryBoardTests.m  
 81c3aa1 Merge branch 'master' of https://github.com/dsromerobr/TesteStoryBoard  
 55f8e2a Deletando arquivos de configuração de usuário. Ok.  
 aa3945a Commit com alterações do exemplo de GIT. Inclusão de uma property na primeira tela.  
 afb0c3e Create README.md  
 2128d14 Segunda Parte do Tutorial  
 7eda703 Initial Commit  

Queremos criar como sendo o primeiro commit a versão v.1.0, para isso pegamos o código de verificação do commit e fazemos o comando abaixo.
 $ git tag -a v.1.0 -m "Primeira versão do tutorial de trabalhando com StoryBoard" 7eda703   

A tag está criado para o nosso Initial Commit.
 $ git show v.1.0  
 tag v.1.0  
 Tagger: Douglas Romero <romero@dsromero.com.br>  
 Date:  Tue Oct 20 10:47:54 2015 -0200  
 Primeira versão do tutorial de trabalhando com StoryBoard  
 commit 7eda7033bcc848f39fc73f643a0b6babe153af3e  
 Author: Douglas Romero <douglasromero@macminiromero.local>  
 Date:  Mon Oct 5 17:25:22 2015 -0300  
   Initial Commit  

Compartilhando as Tags para o servidor remoto.
Por padrão, utilizando o comando git push, não manda as tags para o servidor remoto.
Utilizamos o comando git push, passando o servidor e o nome da tag, assim as tags serão transferidas para o servidor.
$ git push origin v.1.0  
 Counting objects: 1, done.  
 Writing objects: 100% (1/1), 202 bytes | 0 bytes/s, done.  
 Total 1 (delta 0), reused 0 (delta 0)  
 To https://github.com/dsromerobr/TesteStoryBoard.git  
  * [new tag]     v.1.0 -> v.1.0  
$ git push origin --tags  
 Counting objects: 2, done.  
 Delta compression using up to 8 threads.  
 Compressing objects: 100% (2/2), done.  
 Writing objects: 100% (2/2), 322 bytes | 0 bytes/s, done.  
 Total 2 (delta 0), reused 0 (delta 0)  
 To https://github.com/dsromerobr/TesteStoryBoard.git  
  * [new tag]     v.2.0 -> v.2.0  
  * [new tag]     v.3.0 -> v.3.0  

O segundo comando, passando o parametro --tags, manda todas as tags para o servidor remoto.
É isso Pessoal... agora sabemos como trabalhar com Tags. : )

Leia o terceiro artigo, trabalhando com branchs.

Git - GitHub - Controle de Versão - Servidores Remotos

Esta é a segunda parte do artigo sobre Git, caso não tenha lido a primeira parte, com os comandos essenciais, veja no seguinte link.

Nós temos o nosso Git local e agora vamos ver como trabalhar com o servidor remoto, neste exemplo vou utilizar o GitHub. Você poderá ter o servidor remoto na sua empresa ou em qualquer outro local.

Listando servidores remotos.
Caso tenha feito um git clone de algum servidor remoto, terá os servidores remotos configurados.
Executando o comando abaixo, temos o seguinte retorno.
 $ git remote -v  
 origin     https://github.com/dsromerobr/TesteStoryBoard.git (fetch)  
 origin     https://github.com/dsromerobr/TesteStoryBoard.git (push)  
Por padrão, o git chama o servidor remoto de origin.

Pull - Pegando novos dados do Servidor.
Este comando irá pegar todas as atualizações do servidor remoto e tentar fazer o merge automático, caso alguém tenha enviado uma nova alteração para o servidor remoto.
 $ git pull origin

Push - Enviando dados para o Servidor.
Enviando para o servidor remoto as alterações, executar o seguinte comando.
 $ git push origin master  

Para ajudar a lembrar... : )


Inspecionando um Servidor Remoto.
Este comando retorna informações do servidor remoto, como qual servidor ele realiza o git push e git pull automático, sem definir servidor. Também branchs monitoradoros, etc.

$ git remote show origin  
 * remote origin  
  Fetch URL: https://github.com/dsromerobr/TesteStoryBoard.git  
  Push URL: https://github.com/dsromerobr/TesteStoryBoard.git  
  HEAD branch: master  
  Remote branch:  
   master tracked  
  Local branch configured for 'git pull':  
   master merges with remote master  
  Local ref configured for 'git push':  
   master pushes to master (up to date)  

Estes são os comandos básicos para trabalhar com servidores remotos git.
Agora leia o terceiro artigo sobre Git, trabalhando com TAGs.

segunda-feira, 19 de outubro de 2015

Git - GitHub - Controle de Versão - Primeiros Passos

Git é um controle de versão open source, desenvolvido pelo mestre Linus Torvalds.
Caso não tenha idéia do que é um controle de versão, recomendo começar do básico pela wikipedia. Clique aqui.
Este meu post será voltado em primeiros passos na linha de comando com o Git utilizando o serviço do GitHub.

Verificando o client instalado na sua máquina.
Abrindo o terminal da sua máquina, neste tutorial usarei um MAC OSX.
Digite o comando abaixo para verificar a versão do Git instalado em sua máquina.
 $ git --version  

O resultado será parecido com o print abaixo, caso tenha o git instalado em sua máquina.

Sempre é bom atualizar com a versão recente do Git.
Entrei no site do Git e verifiquei a última versão, como o retorno indica que a versão instalada é a de 2.3.8 e a atual é a de 2.5.3, abaixei o pacote da nova versão e realizei a instalação.
Caso não tenha o Git, entre no site para realizar o download ou atualizar a versão.
Site para download do Git: http://git-scm.com/downloads
Depois do Git corretamente instalado, vamos realizar algumas configurações.

Configuração de Identidade do Usuário.
Estas configurações são para quando realizamos o commit dos arquivos e mostrar o nome do usuário e e-mail corretamente nas informações do commit.
 $ git config --global user.name "SEU NOME"  
 $ git config --global user.email "SEU EMAIL"  

Depois destas configurações de identidades estarem feitas, podemos verificar as configurações utilizando o seguinte comando:
 $ git config --list  


Iniciando um repositório.

Utilizando o Clone de um repositório remoto, no caso no GitHub.
Com o comando abaixo, iremos pegar o repositório remoto no GitHub e criaremos ele na sua máquina.
 $ git clone https://github.com/dsromerobr/TesteStoryBoard.git  
 Cloning into 'TesteStoryBoard'...  
 remote: Counting objects: 55, done.  
 remote: Compressing objects: 100% (26/26), done.  
 remote: Total 55 (delta 5), reused 0 (delta 0), pack-reused 25  
 Unpacking objects: 100% (55/55), done.  
 Checking connectivity... done.  
 $   

Mostrando alterações.
Caso você altere um arquivo, podemos ver os status dos arquivos com o seguinte comando:
 $ git status  
 On branch master  
 Your branch is up-to-date with 'origin/master'.  
 Changes not staged for commit:  
  (use "git add <file>..." to update what will be committed)  
  (use "git checkout -- <file>..." to discard changes in working directory)  
      modified:  TesteStoryBoard/Base.lproj/Main.storyboard  
      modified:  TesteStoryBoard/ViewController.m  
 Untracked files:  
  (use "git add <file>..." to include in what will be committed)  
      TesteStoryBoard.xcodeproj/project.xcworkspace/xcuserdata/  
 no changes added to commit (use "git add" and/or "git commit -a")  

Status dos Arquivos.
Os arquivos podem estar em um desses dois status inicialmente.
untracked: arquivo não monitorado pelo git, deve ter sido criado ou movido recentemente para a pasta.
tracked: arquivo monitorado pelo git.

Sendo um arquivo tracked:
unmodified: Arquivo que não foi modificado.
modified: Arquivo que foi modificado.
staged: Arquivo que foi selecionado.

Este ciclo de Status dos arquivos é extremamente importante ter ele em mente.




A imagem acima demonstra exatamente este ciclo de vida.

Verificando o retorno do comando git status, identificamos os arquivos que foram modificados, saindo do status unmodified para modified.
  Changes not staged for commit:   
  (use "git add <file>..." to update what will be committed)   
  (use "git checkout -- <file>..." to discard changes in working directory)   
    modified: TesteStoryBoard/Base.lproj/Main.storyboard   
    modified: TesteStoryBoard/ViewController.m   

Adicionado Arquivos.
Agora vamos adicionar esses arquivos para Staged.
Adicionei somente o arquivo TesteStoryBoard/Base.lproj/Main.storyboard, utilizando o git add, o comando add serve para sempre alterar os alterar os status dos arquivos.
Executamos o git add e depois o git status para verificar o status. Agora temos arquivos em três status, o adicionado recentemente como staged o ViewController.m como modified e o arquivo xcuserdata como untracked.
$ git add TesteStoryBoard/Base.lproj/Main.storyboard   
$ git status  
 On branch master  
 Your branch is up-to-date with 'origin/master'.  
 Changes to be committed:  
  (use "git reset HEAD <file>..." to unstage)  
      modified:  TesteStoryBoard/Base.lproj/Main.storyboard  
 Changes not staged for commit:  
  (use "git add <file>..." to update what will be committed)  
  (use "git checkout -- <file>..." to discard changes in working directory)  
      modified:  TesteStoryBoard/ViewController.m  
 Untracked files:  
  (use "git add <file>..." to include in what will be committed)  
      TesteStoryBoard.xcodeproj/project.xcworkspace/xcuserdata/  

Para adicionar todos os arquivos, podemos executar o seguinte comando:
 $ git add .   

Depois de executar o comando, vejamos o resultados utilizando o git status.
 $ git status  
 On branch master  
 Your branch is up-to-date with 'origin/master'.  
 Changes to be committed:  
  (use "git reset HEAD <file>..." to unstage)  
      new file:  TesteStoryBoard.xcodeproj/project.xcworkspace/xcuserdata/douglasromero.xcuserdatad/UserInterfaceState.xcuserstate  
      modified:  TesteStoryBoard/Base.lproj/Main.storyboard  
      modified:  TesteStoryBoard/ViewController.m  

Agora todas as modificações estão prontas para serem consolidadas.

Removendo Arquivos.
Para remover um arquivo, temos o comando git rm.
No exemplo, não queremos adicionar o arquivo da pasta xcuserdata.
Utilizando o comando rm, deleta o arquivo fisicamente.
No caso, não queremos que o arquivo seja monitorado, para isso, utilizamos o parametro --cached.
$ git rm --cached TesteStoryBoard.xcodeproj/project.xcworkspace/xcuserdata/douglasromero.xcuserdatad/UserInterfaceState.xcuserstate   
 rm 'TesteStoryBoard.xcodeproj/project.xcworkspace/xcuserdata/douglasromero.xcuserdatad/UserInterfaceState.xcuserstate'  
 MacMiniRomero:TesteStoryBoard douglasromero$ git status  
 On branch master  
 Your branch is up-to-date with 'origin/master'.  
 Changes to be committed:  
  (use "git reset HEAD <file>..." to unstage)  
      modified:  TesteStoryBoard/Base.lproj/Main.storyboard  
      modified:  TesteStoryBoard/ViewController.m  
 Untracked files:  
  (use "git add <file>..." to include in what will be committed)  
      TesteStoryBoard.xcodeproj/project.xcworkspace/xcuserdata/  

Commit dos Arquivos.
Executando o comando git commit, irá abrir o vim com o texto para o commit, depois de editado, o commit será realizado.
 $ git commit  
 [master aa3945a] Commit com alterações do exemplo de GIT. Inclusão de uma property na primeira tela.  
  2 files changed, 4 insertions(+)  

Também tem a opção de realizar o commit com a mensagem já especificada, sem ter que abrir o vim.
 $ git commit -m "MENSAGEM DO COMMIT"  

Ignorando Arquivos.
Podemos criar um arquivo na raiz do projeto, .gitignore, este arquivo especifica os arquivos que não vão ser monitorados, com isso, evitamos de versionar arquivos que não interessam, como arquivos de logs ou de configurações pessoais, como no caso o arquivo de configuração pessoal do xcode, por exemplo os arquivos na pasta xcuserdata.
Exemplo do arquivo .gitignore, interessante para um projeto em IOS.
 $ cat .gitignore  
 TesteStoryBoard.xcodeproj/xcuserdata/  
 TesteStoryBoard.xcodeproj/project.xcworkspace/xcuserdata/  

Listando os Commits Realizados.

Agora uma série de comandos para listar os commits realizados.
 $ git log --pretty=oneline  
 ecf769af853777e7009623fe002879ea4ed517e1 Deletando arquivos de configuração de usuário.  
 aa3945abbb203307eac1b333c331fba6540e8f2d Commit com alterações do exemplo de GIT. Inclusão de uma property na primeira tela.  
 2128d14bb86584fe370bb6bce91893595777567f Segunda Parte do Tutorial  
 7eda7033bcc848f39fc73f643a0b6babe153af3e Initial Commit  

O git log, com o -p, mostra o diff entre os últimos commits.
O parâmetro -2, lista os últimos 2 commits, podendo alterar conforme a sua necessidade.
 $ git log -p -2  

O retorno será parecido com o abaixo:


Uma ferramenta interessante para ver os commits é a ferramenta gitk, que já vem instalada com o git.
Para isso, digite no terminal no repositório: gitk
 $ gitk  
Abrirá uma tela como a baixo, que tem diversas opções de visualizações.


Refazendo último commit.
Caso tenha esquecido de adicionar algum arquivo ou queira alterar a descrição do seu último commit, podemos utilizar o parâmetro --amend, caso não tenha alterado nada nos arquivos e somente queira alterar a descrição do commit, abrirá o vi e altere a descrição. Caso queria adicionar um novo arquivo, execute o git add e depois o git commit --amend.
 $ git commit --amend  

Agora foram explicados os comandos básicos no Git.
Acompanhe a segunda parte do artigo, trabalhando com servidores remotos.

Deixo um link de um excelente livro sobre GIT:
http://git-scm.com/book/pt-br/v1/Primeiros-passos


sexta-feira, 16 de outubro de 2015

Iniciando com Storyboard no IOS - Segunda Parte

Vamos para a segunda parte dos meus estudos sobre Storyboard.
Caso não tenha lido a primeira parte, clique aqui para ler.

Na segunda View, vamos criar uma classe personalizada para este controller. Assim vamos poder fazer algumas ações nesta View.

Criando ViewController para a View do StoryBoard:
Para isso, clicar na pasta raiz do seu projeto e criar um novo arquivo de Cocoa Touch Class. Criei com o nome de SegundoViewController.


Agora vamos relacionar a nossa classe ao ViewController.
Clicar no segundo ViewController e no lado esquerdo, abrir as opções do Identity Inspector (canto direito da imagem) e alterar a opção de CustomClass para a classe criado acima. Conforme figura abaixo.



Agora vamos deixar o label do segundo viewController acessível para a aplicação, vamos criar o IBOutlet para ele.
Selecione o label no Storyboard e com o Control apertado, arraste até para o fonte do arquivo H SegundoViewController.
Também criamos uma property NSString.
Ficando como o código fonte abaixo:

 //  
 // SegundoViewController.h  
 // TesteStoryBoard  
 //  
 // Created by Douglas Romero on 14/10/15.  
 // Copyright © 2015 Douglas Romero. All rights reserved.  
 //  
 #import <UIKit/UIKit.h>  
 @interface SegundoViewController : UIViewController  
 @property (weak, nonatomic) IBOutlet UILabel *segundoLabel;  
 @property (weak, nonatomic) NSString *txtSegundoLabel;  
 @end  


Agora no arquivo M do SegundoViewController, vamos definir que o objeto de tela label tem o valor da propriedade NSString, implementar o viewDidLoad conforme o código abaixo:

 //  
 // SegundoViewController.m  
 // TesteStoryBoard  
 //  
 // Created by Douglas Romero on 14/10/15.  
 // Copyright © 2015 Douglas Romero. All rights reserved.  
 //  
 #import "SegundoViewController.h"  
 @interface SegundoViewController ()  
 @end  
 @implementation SegundoViewController  
 - (void)viewDidLoad {  
   [super viewDidLoad];  
   _segundoLabel.text = _txtSegundoLabel;  
   // Do any additional setup after loading the view.  
 }  
 - (void)didReceiveMemoryWarning {  
   [super didReceiveMemoryWarning];  
   // Dispose of any resources that can be recreated.  
 }  
 /*  
 #pragma mark - Navigation  
 // In a storyboard-based application, you will often want to do a little preparation before navigation  
 - (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender {  
   // Get the new view controller using [segue destinationViewController].  
   // Pass the selected object to the new view controller.  
 }  
 */  
 @end  

No ViewController da primeira tela, vamos importar o SegundoViewController.
Realizar o import no ViewController.h.

 //  
 // ViewController.h  
 // TesteStoryBoard  
 //  
 // Created by Douglas Romero on 05/10/15.  
 // Copyright © 2015 Douglas Romero. All rights reserved.  
 //  
 #import <UIKit/UIKit.h>  
 #import "SegundoViewController.h"  
 @interface ViewController : UIViewController  
 @end  

No M do ViewController, vamos implementar o método prepareForSegue, que irá notificar o segundo view controller.
Na implementação do método, iremos criar uma instancia do SegundoViewController e iremos definir o valor da propriedade txtSegundoLabel.
Conforme no código abaixo:

 //  
 // ViewController.m  
 // TesteStoryBoard  
 //  
 // Created by Douglas Romero on 05/10/15.  
 // Copyright © 2015 Douglas Romero. All rights reserved.  
 //  
 #import "ViewController.h"  
 @interface ViewController ()  
 @end  
 @implementation ViewController  
 - (void)viewDidLoad {  
   [super viewDidLoad];  
   // Do any additional setup after loading the view, typically from a nib.  
 }  
 - (void)didReceiveMemoryWarning {  
   [super didReceiveMemoryWarning];  
   // Dispose of any resources that can be recreated.  
 }  
 -(void) prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender{  
   SegundoViewController *destino = [segue destinationViewController];  
   destino.txtSegundoLabel = @"Chegou da Primeira Tela";  
 }  
 @end  

Agora é só executar a aplicação e verificar o resultado.
Acabamos a segunda parte deste tutorial de trabalhando com StoryBoard.


segunda-feira, 5 de outubro de 2015

Iniciando com Storyboard no IOS


Uma funcionalidade interessante que facilita a vida do desenvolvedor de IOS para fazer interface do usuário é o StoryBoard.
Foi implementado no XCode 4.2 e SDK 5.0.
O Storyboard, termo conhecido para quem faz filmes e quadrinhos inventado pela Walt Disney, agora utilizado na engenharia de software. Utilizamos diversos gráficos e desenhos para desenhar um fluxo, ajudando no desenvolvimento de fluxo de telas. Para saber mais sobre o StoryBoard, vale uma visita a famosa wikipedia.
Antes desta nova implementação, os desenvolvedores de IOS tinham que utilizar arquivos xib, que gerava um arquivo xml do InterfaceBuilder para cada tela. Agora temos somente um arquivo para diversas telas.
Utilizando o StoryBoard, temos uma visão conceitual de todas as telas da app e a interligação entre as mesmas. A transição entre as telas, conhecidas como "segues",  são criadas através de um simples clique entre as telas.
O único problema que eu vejo na utilização de StoryBoard é em desenvolvimento com vários programadores, fico imaginando como deve ser bacana fazer um merge com o StoryBoard. O código gerado deve ser bem legível para um simples humano. Em alguns casos e telas, talvez seja necessário utilizar o xib, caso tenham muitos desenvolvedores na aplicação.

Vamos em um exemplo básico de utilização do StoryBoard.

Após criar um projeto de testes, vemos que temos um arquivo "Main.storyboard", este é o arquivo que ao clicar em cima, vemos que abre o Interface Builder.
Na imagem abaixo, vemos o arquivo Main.storyboard e temos somente um view controller.
Percebemos também que tem a primeira "flecha", mostrando o início do fluxo e no canto direito, a opção de "Is Initial View Controller" está selecionada.



Neste view controller inicial, vamos criar um label e um botão. Não vou ensinar comandos básicos neste artigo, como criar objetos, etc. Depois de criar os objetos na tela principal, procurar o objeto View Controller e arrastar o objeto ao lado de nosso view controller principal.
Ficando igual na imagem abaixo:


Reparem no canto direito da imagem, onde abaixo tem os objetos disponíveis e colocamos o view controller no storyboard. Acima, alterei o nome do view controller para principal na opção: View Controller -> Title, isso ajuda na organização, alterar também o title do novo controller para "segundo". Na caixa da esquerda, vemos a alteração do nome do view controller para "Principal".
Adicionei um terceiro view controller para este nosso exemplo e defini o Title dele como "Terceiro".
Apertando command - ou +, alteramos o zoom de nosso StoryBoard.
Ficando conforme abaixo:
Agora vamos adicionar um label e um botão na segunda tela e um label na terceira tela.
Para criar um segues, fica apertado o botão "control" clica no botão e arrasta até a tela. No interface builder, você verá que criou uma flecha para a terceira tela.
Após soltar, mostrará uma lista com algumas opções de segues. Selecione a opção Push.
Ficará igual a tela abaixo:



Perceba que alinhamos as telas e os segues foram criados.
Agora vamos executar a aplicação para ver se está funcionando.
Executando a aplicação, ao clicar no botão, irá ocorrer um erro de execução e retornará um erro parecido como abaixo:
 2015-10-05 19:26:54.389 TesteStoryBoard[248:28916] *** Terminating app due to uncaught exception 'NSGenericException', reason: 'Push segues can only be used when the source controller is managed by an instance of UINavigationController.'  
 *** First throw call stack:  
 (0x23e2068b 0x351dae17 0x285f52f9 0x285919b5 0x285917e3 0x28591a55 0x27f1a795 0x27f1a725 0x27f0354b 0x27f1a085 0x27f19cff 0x27f12e57 0x27ee47e5 0x27ee2fdf 0x23de3c3f 0x23de382d 0x23de1b9b 0x23d35249 0x23d35035 0x2ce18ad1 0x27f4a899 0x1185d 0x35926873)  
 libc++abi.dylib: terminating with uncaught exception of type NSException  
 (lldb)   

Este erro ocorreu porque não tem um Navigation Controller.
Para inserir um Navigation Controller, vamos no Menu "Editor", escolhemos a Opção "Embed In" e selecionamos a opção "Navigation Controller".
Você irá reparar que aparecerá um novo componente na apresentação do storyboard, o Navigation Controller.

Build na aplicação e testar a mesma.
Agora ela funcionará perfeitamente.
Fizemos uma navegação simples entre telas e o melhor, sem programar uma linha.
O Interface Builder funciona muito bem para fazer telas. Sendo este a grande facilidade em programar em IOS.
Gostaria que no Android tivéssemos recurso parecido.
Para quem quiser fazer download do código fonte, segue o link do github:
https://github.com/dsromerobr/TesteStoryBoard

Se quiser ver mais recursos do StoryBoard, acompanhe o segundo tutorial:
http://blog.dsromero.com.br/2015/10/iniciando-com-storyboard-no-ios-segunda.html



segunda-feira, 28 de setembro de 2015

Integração do Facebook com SDK do Facebook no IOS 9 e XCODE 7.


Queria integrar o login do Facebook em minha aplicação, com isso tive alguns problemas que vou relatar. Não vou descrever todo o processo, que o quickstart dá uma boa idéia de como fazer a integração com o sdk do facebook. Vou relatar alguns problemas que eu tive.


Primeiro passo:
Entrar no site de developer do Facebook:https://developers.facebook.com/quickstarts/
- Escolher IOS e Cadastrar a sua aplicação.

Fazer o download do SDK.
Como estou desenvolvendo para o IOS 9, fiz o download do SDK para IOS 9, que atualmente está na versão beta.


Adicionar o SDK ao Projeto:



No Xcode 7, entrar na raiz do projeto, clicar no botão direito, selecionar "-> Add Files".
No quickstart do Facebook, pedem para não selecionar a opção "Copy into destination group folder". Contudo, na versão 7 do Xcode não tem esta opção, tem uma nova opção que é necessário selecionar para evitar erros de importação no Xcode 7, selecionar a opção "Copy Items if Needed".



Selecionar os seguintes pacotes para importação para o seu projeto:
FBSDKCoreKit.Framework, FBSDKLoginKit.Framework, FBSDKShareKit.Framework
Criar fbauth2 no plist
Este processo não vi no quickstart e gerava erro, que não achava o fbauth2.
Abrir o plist e incluir o campo LSApplicationQueriesSchemes, type Array e incluir a propriedade fbauth2, NSString. Conforme a figura abaixo:


Adicionar usuário de testes
Para testarmos a aplicação, seguindo o quickstart, devemos incluir um usuários de testes.
Entrar na página de developer do facebook do facebook, entrar em My Apps e depois selecionar Roles.
Incluir um usuário de testes, já que sua app não estará publicada ainda.




Vou criando outros Posts com problemas e duvidas que vou resolvendo.
Espero ter ajudado.


sexta-feira, 25 de setembro de 2015

XCODE 7 - Deploy direto no Iphone sem licença de Desenvolvedor.


O desenvolvimento de aplicativos para IOS tem algumas particularidades, que deixam a parte de testes complicada.

No Android, conseguimos criar uma máquina virtual, onde conseguimos emular completamente um aparelho com este sistema operacional.
No IOS, temos uma simulação do aparelho. Esta simulação, representa uma grande dificuldade. Não conseguimos testar a aplicação, pois a simulação utiliza recursos do computador, não conseguimos testar se a nossa aplicação irá ficar lenta em um determinado dispositivo. Dificuldades em testar recursos de camera, bluetooth, integração com outras apps, etc.
Não vou explicar aqui sobre a diferença entre Simulação e Emulação, pesquisando no Google irá achar diversos artigos explicando esta diferença.

Na versão 7 do Xcode, diferente das outras versões, onde tinhamos que comprar uma licença de desenvolvedor, com o valor simbólico de $99 anuais, para poder fazer um deploy direto da app para o iphone, agora na versão 7, podemos fazer isso sem a licença de desenvolvedor.

No início fiquei espantado como sai caro desenvolver para IOS. Temos que ter um MAC e pelo menos um Iphone e Ipad para testarmos a aplicação. Para quem está começando, um investimento pesado. Com isso, limitando os desenvolvedores que querem entrar neste mundo de IOS.

Eu tenho um Iphone 4s aposentado aqui em casa, pensei que nunca mais iria ligar ele, mas o mesmo está servindo perfeitamente para os meus testes. O mesmo está atualizado com o IOS9.1 e depois de "zerar" o sistema operacional, está funcionando perfeitamente.

Para utilizar ele em seu desenvolvimento e testes, primeiro temos que plugar o mesmo com o cabo USB no seu MAC.


Depois de plugado no computador, o ITunes irá reconhecer o Iphone.
Abrir o Xcode e escolher Product/Destination e selecionar o seu Iphone.
Na primeira vez, irá pedir para você logar com a sua conta do Apple.


Mande o Build e o Xcode irá compilar a aplicação no seu aplicativo.
Na primeira vez, será necessário liberar a sua aplicação para poder ser executada no IOS.
Irá aparecer um erro que o software não é confiável.
Para liberar a aplicação, segue o seguinte caminho: ajustes/geral/perfil.
Selecionar para confiar no desenvolvedor/aplicação.


 Pronto, agora você irá conseguir testar a aplicação direto em seu celular.

 

Sobre o Blog

Neste blog irei compartilhar as minhas experiências e observações. Os temas serão variados, mas com ênfase em tecnologia. Inscreva-se nos nossos canais para receber atualizações.