From 8c076603b58af795b48348d8976bbaf4bfb08b84 Mon Sep 17 00:00:00 2001 From: Nabil Hachicha Date: Sat, 8 Aug 2015 16:40:52 +0100 Subject: [PATCH] fix typo :) also the there is a broken link to `Promise-Callbacks` article https://github.com/CodeAndMagic/android-deferred-object/blob/2.0/android-deferred-object/wiki/Promise-Callbacks --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index cca1983..58be876 100644 --- a/README.md +++ b/README.md @@ -17,7 +17,7 @@ You can pipe promises so the pieces of asynchronous code gets executed serially A **Promise** is a immutable version of a **DeferredObject**. All DeferredObjects are Promises which is the most generic term and it's preferred. Not all Promises are necessarily a DeferredObject. -On a DeferredObject you have access to the actual **resolve** and **reject** methods which is obviously useful when you want to write your own Deferred. But most library code should return a Promise to prevent users of that library to mess with the internal workings of the library. For example in case of a async HTTP call if would be weird if someone other than the actual piece of code that does the HTTP call fires the resolved callbacks. +On a DeferredObject you have access to the actual **resolve** and **reject** methods which is obviously useful when you want to write your own Deferred. But most library code should return a Promise to prevent users of that library to mess with the internal workings of the library. For example in case of a async HTTP call it would be weird if someone other than the actual piece of code that does the HTTP call fires the resolved callbacks. ## Why/When should I use the Deferred Object / Promise pattern? The DeferredObject/Promise pattern can help you to better organise your code, especially the asynchronous type. It also makes it really easy to merge and pipe the execution of different pieces of asynchronous code, which otherwise would get really messy to code.