Improved code style, comments, bumped compileSdkVersion etc.

[mrmaffen]

Hey there,

I'm loving this project and so I thought I'd put some work in and go through the lint warnings and fix some stuff. I have fixed and improved some comments. I've also removed some redundant scope modifiers and bumped up the gradle build tools version, buildToolsVersion, compileSdkVersion and targetSdkVersion. I've also removed local.properties and added it to .gitignore since it's essentially useless for people forking your repo since well ... there's only local properties in there.

No code logic has been changed in this PR.

I have compiled and tested jdeferred in my Android App project.

---

This change is 

[saturnism]

hiya - this looks nice and doesn't change the behavior. however, the checkstyle stuff is failing.
we also kept Android SDK version at 19 due to its usages. https://developer.android.com/about/dashboards/index.html

@aalmiray wdyt?

[aalmiray]

Have to check if this change works with our CI build

[aalmiray]

Reviewed 43 of 43 files at r1.
Review status: all files reviewed at latest revision, 6 unresolved discussions, some commit checks failed.

---

subprojects/jdeferred-android/jdeferred-android.gradle, line 48 at r1 (raw file):

    defaultConfig {
         minSdkVersion 15
         targetSdkVersion 26

as @saturnism mentioned the project needs to have a lower number for compatibility's sake

---

subprojects/jdeferred-android/src/main/AndroidManifest.xml, line 24 at r1 (raw file):

    <uses-sdk
        android:minSdkVersion="8"
        android:targetSdkVersion="19" />

see comment about compatibility

---

subprojects/jdeferred-android/src/main/java/org/jdeferred/android/AndroidDeferredManager.java, line 89 at r1 (raw file):

				|| (task.getStartPolicy() == StartPolicy.DEFAULT && isAutoSubmit())) {
			
			if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {

@saturnism do we still need this check?

---

subprojects/jdeferred-core/src/main/java/org/jdeferred/DeferredManager.java, line 26 at r1 (raw file):

import org.jdeferred.multiple.MultipleOutcomes;
import org.jdeferred.multiple.MultipleResults;
import org.jdeferred.multiple.OneOutcome;

why were these import statements added?

---

subprojects/jdeferred-core/src/main/java/org/jdeferred/DonePipe.java, line 30 at r1 (raw file):

 */
public interface DonePipe<D, D_OUT, F_OUT, P_OUT> {

please remove this empty line :-)

---

subprojects/jdeferred-core/src/main/java/org/jdeferred/Promise.java, line 160 at r1 (raw file):

	 * @param doneFilter if null, use {@link org.jdeferred.impl.FilteredPromise.NoOpDoneFilter}
	 * @param failFilter if null, use {@link org.jdeferred.impl.FilteredPromise.NoOpFailFilter}
	 * @param progressFilter if null, use {@link org.jdeferred.impl.FilteredPromise.NoOpProgressFilter}

@saturnism I think these Noop classes should be part of the public API, that is, move them out from org.jdeferred.impl.

---

Comments from Reviewable

[aalmiray]

@mrmaffen thank you for taking the time to make these improvements 😄

[saturnism]

Should we slate this for 2.0? I.e., a lot of the code changed here will be pretty difficult to merge into the 2.x branch.

@mrmaffen ptal #115

That being said, since multiple contributors will be submitting to this branch, would it be possible to get smaller piece-meal changes at a time? :) would really appreciate it!

[aalmiray]

+1 on moving the updates to the 2.x branch

[mrmaffen]

As for the targetSdkVersion ... I think the best way to maintain compatibility is to always target the latest API level and test it thoroughly. I am using my own compiled version with the targetSdkVersion set to 26 and haven't run into any issues so far. The minSdkVersion was kind of ambigous before my changes. The AndroidManifest declared it to be 8, while your gradle build file was set to 15. I think your gradle build file takes precedent in this case.

The official Android docs state something similar wrt the targetSdkVersion (https://developer.android.com/guide/topics/manifest/uses-sdk-element.html):

To maintain your application along with each Android release, you should increase the value of this attribute to match the latest API level, then thoroughly test your application on the corresponding platform version.