Eylül, 2017 tarihine ait yayınlar gösteriliyor

@SerializedName and @Expose annotations

The  @SerializedName  annotation is needed for Gson to map the JSON keys with our fields. In keeping with Java's camelCase naming convention for class member properties, it is not recommended to use underscores to separate words in a variable.  @SerializedName  helps translate between the two. @SerializedName ( "quota_remaining" ) @Expose private Integer quotaRemaining; In the example above, we are telling Gson that our JSON key  quota_remaining  should be mapped to the Java field  quotaRemaining .  If both of these values were the same, i.e. if our JSON key was  quotaRemaining  just like the Java field, then there would be no need for the  @SerializedName  annotation on the field because Gson would map them automatically. The  @Expose  annotation indicates that this member should be exposed for JSON serialization or deserialization. 

GIT - graph and oneline parameters

  git log --graph --oneline  * 3884eab Add color * 3e42136 now using requestAnimationFrame * 4035769 frame interval was set wrong after game was paused * 25ede83 a couple missing ends with the ipad version * df03538 I can't spell 'screen' apparently :) * b0678b1 Revert controls * f19cb1b Fix typo in space * 75928a9 Use space for movement and enter for shooting * ac83b72 mostly finished ipad version * 7ca4826 trying to get div touch controls to work * 3cb406e first pass at ipad controls * fe7993e now capturing down key so people don't accidently scroll the page * 343935f added license * 80f3bc7 increased canvas size * 7dc3de0 made the framerate counter dumb but more accurate * f077ea3 added pointInPolygon method for moz * 5cb7bed added reverseTransform method * a53b00a trying to get ff collision detection working * 1e47136 matrix really only needs to be a 2x3 * 186453f small changes * c0b670e you get 200 Quatloos for shooting a big flying saucer *

Git - Commit Message Style Guide

Commit Messages Message Structure A commit messages consists of three distinct parts separated by a blank line: the title, an optional body and an optional footer. The layout looks like this: type: subject body footer The title consists of the type of the message and subject. The Type The type is contained within the title and can be one of these types: feat:  a new feature fix:  a bug fix docs:  changes to documentation style:  formatting, missing semi colons, etc; no code change refactor:  refactoring production code test:  adding tests, refactoring test; no production code change chore:  updating build tasks, package manager configs, etc; no production code change The Subject Subjects should be no greater than 50 characters, should begin with a capital letter and do not end with a period. Use an imperative tone to describe what a commit does, rather than what it did. For example, use  change ; not changed or changes. The Body Not all commits are co

GIT - Checkout

Behavior of  git checkout Checking out an earlier commit will change the state of at least one file. This is sometimes true . Git doesn't allow you to save a new commit if no files have been updated, so you might think this is always true. However, it's possible to do the following: Save a commit (call this commit 1). Update some files and save another commit (call this commit 2). Change all the files back to their state during commit 1, then save again (call this commit 3). This sometimes happens if commit 2 contained a bug, and it's important to fix the bug quickly. The easiest thing to do might be to remove all the changes introduced by commit 2 to fix the bug, then figure out how to safely reintroduce the changes later. At this point, commit 3 is the latest commit, so if you checkout commit 1, none of the files will be changed. Checking out an earlier commit will change the state of more than one file. Checking out an earlier commit will change the sta

GIT - Clone

Behavior of  git clone If someone else gives you the location of their directory or repository, you can copy or clone it to your own computer. This is true for both copying a directory and cloning a repository. As you saw in the previous lesson, if you have a URL to a repository, you can copy it to your computer using  git clone . For copying a directory, you weren't expected to know this, but it is possible to copy a directory from one computer to another using the command  scp , which stands for "secure copy". The name was chosen because the  scp  command lets you securely copy a directory from one computer to another. The history of changes to the directory or repository is copied. This is true for cloning a repository, but not for copying a directory. The main reason to use  git clone  rather than copying the directory is because  git clone  will also copy the commit history of the repository. However, copying can be done on any directory, whereas  git clon

GIT - Command Review

Git Command review 1-Compare two commits, printing each line that is present in one commit but not the other. git diff will do this. It takes two arguments - the two commit ids to compare. 2-Make a copy of an entire Git repository, including the history, onto your own computer. git clone will do this. It takes one argument - the url of the repository to copy. 3-Temporarily reset all files in a directory to their state at the time of a specific commit. git checkout will do this. It takes one argument - the commit ID to restore. 4-Show the commits made in this repository, starting with the most recent. git log will do this. It doesn't take any arguments.