Introduction

Last Wednesday, we began going over the git version control system.
Git and GitHub are going to be used this semester to work on the Cinequest app and so I am spending the time now to familiarize people with them, so we can make use of them as the semester progresses.
So far we talked about how create a repository, how to host it using Apache, how to configure your credentials for use in a git repository, how to commit changes, how to branch, how to pull, push, and merge, and how to resolve conflicts.
Today, we begin by saying how to make patches.

Making patches

To make a patch with git you use the command:
```
git format-patch rev1 rev2
```
By default you will get a separate patch file for each commit between the two revisions. As an example of creating a single file patch via concatenation, we could do instead:
```
git format-patch e3e4f2067 --stdout > my.patch
```
Here no rev2 is given so it will be assumed to be HEAD.

To see the effects of a patch on current branch before applying it, you can do things like:

% git apply --stat my.patch
 test1.php |    2 ++
 test2.php |    2 ++
 test1.php |    1 +
 test2.php |    2 --
 4 files changed, 5 insertions(+), 2 deletions(-)

To see if the patch will cause any problem if applied, one can type:
```
git apply --check my.patch
```
Finally, to apply a patch to the current branch, you use
```
git am --signoff <  my.patch
```
Like svn, git repositories can be put on a server and made accessible remotely. This is what (Github does).
This is either done using git daemon, or using WebDAV extension to http. In either case, you can do your "git clone" with a url rather than a filesystem path.
If you've cloned such a repository, and made and commited modifications, and now want to send them back to the remote repository, you use the command "git push" or "git push remote_branch_name local_branch_name".

Git Tags

Unlike svn, where we might have a folder tags which has our different release project, with git we often directly make tagged revision of the master branch.
The production server than does a git checkout of that tag.
To create such a tag you might do,
```
git tag -a tag_name revision -m "message about creating tag"
```
For example, in our myrepos example, we might make some changes and commit and the commit has version number. We could make a v1 tag as follows:
```
git tag -a v1 c3ac05c -m "Made Version 1"
```
"git tag -l" lists what tags one has.
By default, when you do a git push, tags are not sent. To send them, use "git push --tags"
To get remote tags into your local git instance you can do:
```
git fetch --tags
```
In our case, we could cd into myrepos2 and then type this line.
```
cd ../myrepos2
git pull
git fetch --tags
```
To checkout a tag one can do:
```
git checkout tags/[tag_name]
```
In our example, in myrepos2, we could type:
```
git checkout tags/v1
```

Quiz

Which of the following is true?

To associate a Layout with an Android Activity we might call the method setContentView in our Activity's onCreate method.
The public final class R has to be written by hand by the coder of an Android application.
Git revision numbers start at the number 1 and increment by 1 with each commit.

Issue Tracking

Typically, you would post patches you make to some kind of bug/issue tracking tool for review before they are checked-in.
Some popular Bug/Issue tracking tools are: JIRA , Bugzilla , Trac .
Here is a list of other tracker that exist: http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems
GitHub comes with its own lightweight issue tracker for each project and has its own wiki. If you spot a bug or see an issue you would like to solve you just click on the issue link and write up a description of it. People can follow up on your description and if it is eventually solved then close the issue.
For each project GitHub also has a Wiki which can be used to describe things like how to compile the project etc.

GitHub

GitHub is a web-based hosting service for git repositories.
It was launched in 2008 and currently has between 3-4 million users and as of today hosts more than 15.6 million repositories.
It was originally written in Ruby (using Ruby on Rails) and Erlang. Information about its infrastructure can be gleaned by following the Github Blog Engineering Category.
GitHub hosts two kinds of repositories public and private. Here is a link to Details on GitHub plans.
GitHub recommends repositories be less than 1GB and not have many files bigger than 100MB.
Public repositories are free and are viewable by anyone.
Private repositories can be limited in who sees it but cost money.
The Cinequest project is hosted on various public repositories -- one for iPhone, one for Android.
Cloud services like GitHub can be cool -- just be sure to always keep your own copy of the data.

Getting started with GitHub

To use github you should at a minimum configure in git your username and email:

git config --global user.name "YOUR NAME"
git config --global user.email "YOUR EMAIL ADDRESS"

Here is what the git repository for last semester Cinequest iPhone project looked like:
Notice there is a link to git clone this repository on the right hand side.
If you want to start your own repository, when you log in to GitHub on your profile page, you'll see three tabs:
You can select the repositories tab, click new, and follow the directions.

GitHub Work Flows

GitHub itself has pretty good tutorials on how to Create a GitHub Repository and Fork a GitHub Repository.
The basic workflow for working with an existing git repository on GitHub is to go to that repositories page, and
- Click the Fork link.
- Get a local copy of the fork, work on it, either within GitHub's online editors or on your local machine, commit changes. If not already, get those changes push'd back to your local copy.
- Initiate a pull request back to the original repository.
- The owner of the original repository then decides if they want to accept or not the pull request.

GitHub Work Details -- Getting a copy

In details what happening, is clicking fork gives you a copy in your user account space of that repository. For example, the original repository might have been:

https://github.com/ORIGINAL_USERNAME/PROJECT.git

your fork wil be

https://github.com/YOUR_USERNAME/PROJECT.git

To get a copy on your laptop of your fork, you just clone that address:

git clone https://github.com/YOUR_USERNAME/PROJECT.git

To make sure you can stay in sync with the original repository we need to add an upstream source for our close:

git remote add upstream https://github.com/ORIGINAL_USERNAME/PROJECT.git

GitHub Work Details -- Working locally, Synchronization, Pull Requests

After making a local clone we can make changes, commit them, and use
```
git push origin master
```
to send them back to GitHub in our workspace on GitHub.
Periodically, we should synchronize with the upstream source:
```
git fetch upstream
```
then check out our local branch
```
git checkout master
```
and finally merge changes (we might need to resolve conflicts like described earlier)
```
git merge upstream/master
```
To make a request of the original project to get your code incorporated in it involves make a pull request. This is pretty straightforward and can be done in a GUI. Here are GitHub's Pull Request Instructions
Similarly, for the project maintainer to merge in a pull request can also be done via GUI. Here are GitHub's Merge a Pull Request Instructions.

Back to Phone Programming!

Let's get back to coding for the mobile devices.
To start we should look at what we can do with some of the controls each device has to offer, beginning with the iPhone.
If you have updated your XCode since last week, you'll notice it now supports iOS 8.
In particular, this means when you create a new project, on the screen, where you can choose the project name, you can choose which language to code in: either Objective-C or Swift.
Also, iPhone6 and 6 Plus appear in the list of devices for the Simulator.
Apps now have a LaunchScreen.xib file which is a splash screen for when the app is initially launched (as opposed to resumed from running in the background).

Active, Static, and Passive Controls

On the iPhone UI controls come in three types: active (ex, button), static (ex, label), and passive (ex text field).
All iPhone controls are a subclass of UIControl.
Each control can trigger multiple actions depending on how they are touched. For example, a finger swipe might do something different than a tap.
For some passive controls, like a text field we'll want to bring up the iPhone keyboard.
The iPhone Keyboard is implemented as a view filled with a series of button controls.
You never directly interact with the keyboard, but you instead write auxiliary code to control how it behaves.

An Image View and Text Field Example

We're going to build a simple app, with a view consisting of an Image at the top, then a pair of labels and textfields.
First, to create the image we, as we did last day, create and add an image to our Supporting Files folder
Then add an Image View to our View Panel in Interface Builder.
Using the Inspector on the Image View Attributes, we select our image for the Image attribute.
Next we add two Labels and two Text Fields to our view, these can be found in IB's Library under Inputs & Values
For the Text Fields, we edit their Placeholder attribute to hint at what the user should be entering in that text field.
Make sure the Clear When Editing check box beneath this attribute is checked so the hint text vanishes when people start typing.

What it should look like

An example of a iPhone UI with an image and two textfields

This actually looks ugly, because we have our storyboard set up with the width and height both set to Any.

If we want our storyboard more like a older iPhone we can adjust these kind of values to compact and play with Layout.

Text Input Traits

Beneath the Font Attributes group of Text Field Attributes there is a collection of Text Input Traits.
These control how/when the Text Field is selected, auto-capitalization, spell-checking, and how other things are done.
One useful Text Input Trait is the Keyboard trait. We can select this to be Number Pad if we want the keyboard to default to be the numeric keypad.
There is another Text Input Trait with which you can also select the text of the return key to be Done, if you like.
Next we set up the Outlets for each of the Text Fields by switching to assistant view and Ctrl-dragging the TextField to the ViewController.h file.
This is so we can send messages to the Text Fields objects when we do a click. If we do not set up these outlets, part of the code that follows won't work!
If we did Build and Run at this point you would notice that once you had entered a Text Field the keyboard would come up but not go away.

Interface Code for Getting Keyboard To Go Away

//
//  ViewController.h
//  KeyboardTest
//
//  Created by Chris Pollett on 9/22/14.
//  Copyright (c) 2014 Chris Pollett. All rights reserved.
//

#import <UIKit/UIKit.h>

@interface ViewController : UIViewController

@property (weak, nonatomic) IBOutlet UITextField *nameField;
@property (weak, nonatomic) IBOutlet UITextField *numberField;

@end

Modified Controller Code for Getting Keyboard To Go Away

//
//  ViewController.m
//  KeyboardTest
//
//  Created by Chris Pollett on 9/22/14.
//  Copyright (c) 2014 Chris Pollett. All rights reserved.
//

#import "ViewController.h"

@interface ViewController ()

@end

@implementation ViewController


-(IBAction)textFieldDoneEditing:(id)sender
{
    [sender resignFirstResponder];
}

- (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.
}

@end

This tells the Text Field to no longer behave as first responder for the UI input.
To hook this action with the Text Fields, we click on a given text field then open the Connection Inspector. The Event we want to handle is Did End on Exit. So for textfield click and drag it to First Responder and select the action textFieldDoneEditing.

Click Background To Close Keyboard

It is also useful to make it so the user can just click the background to get rid of the keyboard.
To do this, we can add a line:
```
-(IBAction)backgroundClick:(id)sender;
```
to our header file.

Then add to our implementation:

-(IBAction)backgroundClick:(id)sender
{
   [_nameField resignFirstResponder];
   [_numberField resignFirstResponder];
}

Next in Interface Builder we select the view on which everything is drawn and then switch in the right pane to identity inspector. We then change the class from UIView to UIControl so that it can be hooked up with an IBAction. Then we connect Touch Up Inside for this control from to File's Owner and hook it up with backgroundClick
Another way to achieve a similar effect is to put a button that covers the whole screen, then put the other controls on top of this.

Finish Git, GitHub, More iPhone Controls

Outline