When resetting the Loader, we must free all the resources and wait for next startLoading call to start working again.

Would fix https://github.com/stanfy/enroscar/issues/60

• Update Gradle plugin and Robolectric tests
  • Reflection-based tests didn't survive
  • ImageRequestTest.shouldCacheImages() does not pass for some strange reason
• Remove strict ui-net dependency
• Enable Docker-Travis integration http://docs.travis-ci.com/user/workers/container-based-infrastructure/

/cc @lampapos

Take a look at AsyncUserActivity.

Generally:

class Operations { // may be even an activity or fragment
  @Load Async<List<OrderItem>> orderItems() {
    return implementation;
  }
  @Send Async<OrderSubmissionResult> submitOrder() {
    return implementation;
  }
}

void onCreate() {
  // ...
  // generated class
  OperationsOperator operator = OperationsOperator.build()
      .operations(new Operations())
      .withinActivity(this)
      .get();

  operator.when().orderItemsIsFinished()
      .doOnResult((List<OrderItem> items) -> { /* Display them. */ })
      .doOnError((Throwable e) -> { /* whatever */ })

  .alsoWhen().submitOrderIsFinished()
    .doOnResult({ /* Remove that annoying progress bar. */ });

  submitButton.setOnClickListener({ operator.submitOrder(); });

  operator.orderItems();
}

CrucialGUIOperationManager has no direct reference to the ImagesManager now - ImagesManagerCrucialGUIOperationListener located in assist module, just registers itself as regular listener and implements the behavior removed from ui module

By using DefaultBeansManager you always have to pray Lord that nobody had called BeansManager.get(ctx) before you.

Whole configuration thing is fully static and not depends on context so let's allow users to call BeansManager manually.

Javadoc, sources and plain Jar is packaged from default variant. AFAIK, Android Studio can't resolve sources for AAR dependencies, but can decompile classes.

ImageManager simply eats all helpful error messages so you have no clue why your image hadn't load.

Real life example which gives you nothing:

enroscar.ImagesManager﹕ Process url content://com.example/brandpack/restaurant_logo/snoac_st
enroscar.ImagesManager﹕ Not in mem content://com.example/brandpack/restaurant_logo/snoac_st
enroscar.ImagesManager﹕ Set loading for content://com.example/brandpack/restaurant_logo/snoac_st!160x160
enroscar.ImagesManager﹕ Key content://com.example/brandpack/restaurant_logo/snoac_st!160x160
enroscar.ImagesManager﹕ Current loaders count: 1

Parallel builds. This project contains multiple modules. Parallel builds can improve the build speed by executing tasks in parallel. We can enable this feature by setting org.gradle.parallel=true.

Configuration on demand. Configuration on demand tells Gradle to configure modules that only are relevant to the requested tasks instead of configuring all of them. We can enable this feature by setting org.gradle.configureondemand=true.

gradle caching. Shared caches can reduce the number of tasks you need to execute by reusing outputs already generated elsewhere. This can significantly decrease build times. We can enable this feature by setting org.gradle.caching=true.

Gradle daemon. The Daemon is a long-lived process that help to avoid the cost of JVM startup for every build. Since Gradle 3.0, Gradle daemon is enabled by default. For an older version, you should enable it by setting org.gradle.daemon=true.

===================== If there are any inappropriate modifications in this PR, please give me a reply and I will change them.