AngularJS: Service vs provider vs factory

Question: What are the differences between a Service, Provider and Factory in AngularJS?
Comment: I found that all the Angular terms were intimidating for beginners. We started off with this cheatsheet that was a little easier for our programmers to understand while learning Angular http://demisx.github.io/angularjs/2014/09/14/angular-what-goes-where.html. Hope this helps your team too.
Comment: In my opinion, the best way to understand the difference is using Angular's own documentation: https://docs.angularjs.org/guide/providers it is extremely well explained and uses a peculiar example to help you understand it.
Comment: @Blaise Thank you! Per my comment in the post, I left it out intentionally, since 99% of use cases from my experience can be successfully handled via `service.factory`.  Didn't want to complicate this subject further.
Comment: I find this discussion also very useful http://stackoverflow.com/questions/18939709/angularjs-when-to-use-service-instead-of-factory
Comment: [**Here are some good answers**](http://stackoverflow.com/questions/11324202/creating-common-controller-functions/40037549#40037549) about how `services`, `factories` and `providers` works.
Comment: It seems to me the confusion around this topic arises because this is one place where AngularJS is over-engineered and poorly documented. As @demisx mentioned, there seems to be no compelling use case where you would use a service over a factory, and they're both syntactic sugar on top of provider (which, unlike the others, can be configured in the 'module.config' before the singleton is instantiated).
Answer: From the AngularJS mailing list I got an amazing thread that explains service vs factory vs provider and their injection usage. Compiling the answers:
Services
Syntax: module.service( 'serviceName', function );
Result: When declaring serviceName as an injectable argument you will be provided with an instance of the function. In other words new FunctionYouPassedToService().
Factories
Syntax: module.factory( 'factoryName', function );
Result: When declaring factoryName as an injectable argument you will be provided with the value that is returned by invoking the function reference passed to module.factory.
Providers
Syntax: module.provider( 'providerName', function );
Result: When declaring providerName as an injectable argument you will be provided with (new ProviderFunction()).$get(). The constructor function is instantiated before the $get method is called - ProviderFunction is  the function reference passed to module.provider.
Providers have the advantage that they can be configured during the module configuration phase.
See here for the provided code.
Here's a great further explanation by Misko:
provide.value('a', 123);

function Controller(a) {
  expect(a).toEqual(123);
}

In this case the injector simply returns the value as is. But what if you want to compute the value? Then use a factory
provide.factory('b', function(a) {
  return a*2;
});

function Controller(b) {
  expect(b).toEqual(246);
}

So factory is a function which is responsible for creating the value. Notice that the factory function can ask for other dependencies.
But what if you want to be more OO and have a class called Greeter?
function Greeter(a) {
  this.greet = function() {
    return 'Hello ' + a;
  }
}

Then to instantiate you would have to write
provide.factory('greeter', function(a) {
  return new Greeter(a);
});

Then we could ask for 'greeter' in controller like this
function Controller(greeter) {
  expect(greeter instanceof Greeter).toBe(true);
  expect(greeter.greet()).toEqual('Hello 123');
}

But that is way too wordy. A shorter way to write this would be provider.service('greeter', Greeter);
But what if we wanted to configure the Greeter class before the injection? Then we could write
provide.provider('greeter2', function() {
  var salutation = 'Hello';
  this.setSalutation = function(s) {
    salutation = s;
  }

  function Greeter(a) {
    this.greet = function() {
      return salutation + ' ' + a;
    }
  }

  this.$get = function(a) {
    return new Greeter(a);
  };
});

Then we can do this:
angular.module('abc', []).config(function(greeter2Provider) {
  greeter2Provider.setSalutation('Halo');
});

function Controller(greeter2) {
  expect(greeter2.greet()).toEqual('Halo 123');
}

As a side note, service, factory, and value are all derived from provider.
provider.service = function(name, Class) {
  provider.provide(name, function() {
    this.$get = function($injector) {
      return $injector.instantiate(Class);
    };
  });
}

provider.factory = function(name, factory) {
  provider.provide(name, function() {
    this.$get = function($injector) {
      return $injector.invoke(factory);
    };
  });
}

provider.value = function(name, value) {
  provider.factory(name, function() {
    return value;
  });
};

Comment: See also http://stackoverflow.com/a/13763886/215945 which discusses the differences between service and factory.
Comment: This example could be incredible if it used a clear practical example.  I get lost trying to figure out what the point of things like `toEqual` and `greeter.Greet` is.  Why not use something slightly more real and relatable?
Comment: Although a service is called by creating an instance of the function. It is actually created only once per injector which makes it like singleton.http://docs.angularjs.org/guide/dev_guide.services.creating_services
Comment: Using the function expect() is a poor choice to explain something. Use real world code next time.
Comment: In edit 611 I added usage of angular constants and values. To demonstrate the differences of the the other's already shown. http://jsbin.com/ohamub/611/edit
Comment: The statement about module.service that you will get `new FunctionYouPassedToService()` is not always true. If FunctionYouPassedToService() return an object or function, it will be returned as the injectable service, just like module.factory.
Comment: See also http://docs.angularjs.org/guide/providers there is a good overview on the official Angular site.
Comment: @AdamZerner, I find the diagram misleading in section for providers. This code won't even compile in Angular, because a provider must define `$get`
Comment: It took me some time to figure out that for the provider, two objects get created, one 'greeter2Provider' and 'greeter2'. First being the provider itself which is by appending 'Provider' to the name supplied and 'greeter2' being the return value of $get, same as the name supplied. Why is this syntax followed only for provider? Why not automatically add Service or Factory suffixes as well? just to make this consistent.
Comment: @KylePennell Sounds like you might want to look into the concept of a "Factory" in OOP context. If you are familiar, the uses are obvious, but in a nut-shell, Factories create and provide things (objects) and Services do things to objects you provide. Factories are functions that return objects. Services are functions you call [and pass objects to]. Hope that helps.
Comment: Wait... `provider.provide` and `provide.provider`? This is so confusing.. Could there be a better name for the modules, like `myModule`? And what is that `provider` variable in the end? Also a module or? Please, could someone edit this so that all the *custom* variable, function and instance names used are unique by purpose?
Answer: JS Fiddle Demo
" Hello world " example with factory / service / provider:

var myApp = angular.module('myApp', []);

//service style, probably the simplest one
myApp.service('helloWorldFromService', function() {
    this.sayHello = function() {
        return "Hello, World!";
    };
});

//factory style, more involved but more sophisticated
myApp.factory('helloWorldFromFactory', function() {
    return {
        sayHello: function() {
            return "Hello, World!";
        }
    };
});

//provider style, full blown, configurable version
myApp.provider('helloWorld', function() {

    this.name = 'Default';

    this.$get = function() {
        var name = this.name;
        return {
            sayHello: function() {
                return "Hello, " + name + "!";
            }
        }
    };

    this.setName = function(name) {
        this.name = name;
    };
});

//hey, we can configure a provider!
myApp.config(function(helloWorldProvider){
    helloWorldProvider.setName('World');
});

function MyCtrl($scope, helloWorld, helloWorldFromFactory, helloWorldFromService) {

    $scope.hellos = [
        helloWorld.sayHello(),
        helloWorldFromFactory.sayHello(),
        helloWorldFromService.sayHello()];
}

    {{hellos}}

Comment: @Nate: `this` doesn't change context, actually, because what's being called is `new Provider()`.$get(), where `Provider` is the function being passed to `app.provider`. That is to say that `$get()` is being called as a method on the constructed `Provider`, so `this` will refer to `Provider` as the example suggests.
Comment: Is the reason why @Antoine gets the "Unknown provide: helloWorldProvider" error because in your .config code, you use 'helloWorldProvider', but when you define the provider in myApp.provider('helloWorld', function()), you use 'helloWorld'?
In other words, in your config code, how does angular know you are referring to the helloWorld provider? Thanks
Comment: Why do I get `Unknown provider: helloWorldProvider <- helloWorld` when running this locally? Commenting it out, same error for the other 2 examples. Is there some hidden provider configuration ? (Angular 1.0.8)
-- Found: http://stackoverflow.com/questions/12339272/angular-js-unknown-provider
Comment: Doesn't `this` change context in the `$get` function? - you no longer refer to the instantiated provider in that function.
Comment: @Brandon Ohh ok that's kindof neat then. Confusing at first glance - thanks for the clarification!
Comment: Can you please explain $get use in provider ?
Answer: TL;DR
1) When you're using a Factory you create an object, add properties to it, then return that same object. When you pass this factory into your controller, those properties on the object will now be available in that controller through your factory.
app.controller('myFactoryCtrl', function($scope, myFactory){
  $scope.artist = myFactory.getArtist();
});

app.factory('myFactory', function(){
  var _artist = 'Shakira';
  var service = {};

  service.getArtist = function(){
    return _artist;
  }

  return service;
});

2) When you're using Service, AngularJS instantiates it behind the scenes with the 'new' keyword. Because of that, you'll add properties to 'this' and the service will return 'this'. When you pass the service into your controller, those properties on 'this' will now be available on that controller through your service.
app.controller('myServiceCtrl', function($scope, myService){
  $scope.artist = myService.getArtist();
});

app.service('myService', function(){
  var _artist = 'Nelly';
  this.getArtist = function(){
    return _artist;
  }
});

3) Providers are the only service you can pass into your .config() function. Use a provider when you want to provide module-wide configuration for your service object before making it available.
app.controller('myProvider', function($scope, myProvider){
  $scope.artist = myProvider.getArtist();
  $scope.data.thingFromConfig = myProvider.thingOnConfig;
});

app.provider('myProvider', function(){
 //Only the next two lines are available in the app.config()
 this._artist = '';
 this.thingFromConfig = '';
  this.$get = function(){
    var that = this;
    return {
      getArtist: function(){
        return that._artist;
      },
      thingOnConfig: that.thingFromConfig
    }
  }
});

app.config(function(myProviderProvider){
  myProviderProvider.thingFromConfig = 'This was set in config';
});

Non TL;DR
1) Factory
Factories are the most popular way to create and configure a service. There's really not much more than what the TL;DR said. You just create an object, add properties to it, then return that same object. Then when you pass the factory into your controller, those properties on the object will now be available in that controller through your factory. A more extensive example is below.
app.factory('myFactory', function(){
  var service = {};
  return service;
});

Now whatever properties we attach to 'service' will be available to us when we pass 'myFactory' into our controller.
Now let's add some 'private' variables to our callback function. These won't be directly accessible from the controller, but we will eventually set up some getter/setter methods on 'service' to be able to alter these 'private' variables when needed.
app.factory('myFactory', function($http, $q){
  var service = {};
  var baseUrl = 'https://itunes.apple.com/search?term=';
  var _artist = '';
  var _finalUrl = '';

  var makeUrl = function(){
   _artist = _artist.split(' ').join('+');
    _finalUrl = baseUrl + _artist + '&callback=JSON_CALLBACK';
    return _finalUrl
  }

  return service;
});

Here you'll notice we're not attaching those variables/function to 'service'. We're simply creating them in order to either use or modify them later.

baseUrl is the base URL that the iTunes API requires
_artist is the artist we wish to lookup
_finalUrl is the final and fully built URL to which we'll make the call to iTunes
makeUrl is a function that will create and return our iTunes friendly URL.

Now that our helper/private variables and function are in place, let's add some properties to the 'service' object. Whatever we put on 'service' can be directly used inside whichever controller we pass 'myFactory' into.
We are going to create setArtist and getArtist methods that simply return or set the artist. We are also going to create a method that will call the iTunes API with our created URL. This method is going to return a promise that will fulfill once the data has come back from the iTunes API. If you haven't had much experience using promises in AngularJS, I highly recommend doing a deep dive on them.
Below setArtist accepts an artist and allows you to set the artist. getArtist returns the artist. callItunes first calls makeUrl() in order to build the URL we'll use with our $http request. Then it sets up a promise object, makes an $http request with our final url, then because $http returns a promise, we are able to call .success or .error after our request. We then resolve our promise with the iTunes data, or we reject it with a message saying 'There was an error'.
app.factory('myFactory', function($http, $q){
  var service = {};
  var baseUrl = 'https://itunes.apple.com/search?term=';
  var _artist = '';
  var _finalUrl = '';

  var makeUrl = function(){
    _artist = _artist.split(' ').join('+');
    _finalUrl = baseUrl + _artist + '&callback=JSON_CALLBACK'
    return _finalUrl;
  }

  service.setArtist = function(artist){
    _artist = artist;
  }

  service.getArtist = function(){
    return _artist;
  }

  service.callItunes = function(){
    makeUrl();
    var deferred = $q.defer();
    $http({
      method: 'JSONP',
      url: _finalUrl
    }).success(function(data){
      deferred.resolve(data);
    }).error(function(){
      deferred.reject('There was an error')
    })
    return deferred.promise;
  }

  return service;
});

Now our factory is complete. We are now able to inject 'myFactory' into any controller and we'll then be able to call our methods that we attached to our service object (setArtist, getArtist, and callItunes).
app.controller('myFactoryCtrl', function($scope, myFactory){
  $scope.data = {};
  $scope.updateArtist = function(){
    myFactory.setArtist($scope.data.artist);
  };

  $scope.submitArtist = function(){
    myFactory.callItunes()
      .then(function(data){
        $scope.data.artistData = data;
      }, function(data){
        alert(data);
      })
  }
});

In the controller above we're injecting in the 'myFactory' service. We then set properties on our $scope object with data from 'myFactory'. The only tricky code above is if you've never dealt with promises before. Because callItunes is returning a promise, we are able to use the .then() method and only set $scope.data.artistData once our promise is fulfilled with the iTunes data. You'll notice our controller is very 'thin' (This is a good coding practise). All of our logic and persistent data is located in our service, not in our controller.

2) Service
Perhaps the biggest thing to know when dealing with creating a Service is that that it's instantiated with the 'new' keyword. For you JavaScript gurus this should give you a big hint into the nature of the code. For those of  you with a limited background in JavaScript or for those who aren't too familiar with what the 'new' keyword actually does, let's review some JavaScript fundamentals that will eventually help us in understanding the nature of a Service.
To really see the changes that occur when you invoke a function with the 'new' keyword, let's create a function and invoke it with the 'new' keyword, then let's show what the interpreter does when it sees the 'new' keyword. The end results will both be the same.
First let's create our Constructor.
var Person = function(name, age){
  this.name = name;
  this.age = age;
}

This is a typical JavaScript constructor function. Now whenever we invoke the Person function using the 'new' keyword, 'this' will be bound to the newly created object.
Now let's add a method onto our Person's prototype so it will be available on every instance of our Person 'class'.
Person.prototype.sayName = function(){
  alert('My name is ' + this.name);
}

Now, because we put the sayName function on the prototype, every instance of Person will be able to call the sayName function in order alert that instance's name.
Now that we have our Person constructor function and our sayName function on its prototype, let's actually create an instance of Person then call the sayName function.
var tyler = new Person('Tyler', 23);
tyler.sayName(); //alerts 'My name is Tyler'

So all together the code for creating a Person constructor, adding a function to it's prototype, creating a Person instance, and then calling the function on its prototype looks like this.
var Person = function(name, age){
  this.name = name;
  this.age = age;
}
Person.prototype.sayName = function(){
  alert('My name is ' + this.name);
}
var tyler = new Person('Tyler', 23);
tyler.sayName(); //alerts 'My name is Tyler'

Now let's look at what actually is happening when you use the 'new' keyword in JavaScript. First thing you should notice is that after using 'new' in our example, we're able to call a method (sayName) on 'tyler' just as if it were an object - that's because it is.
So first, we know that our Person constructor is returning an object, whether we can see that in the code or not. Second, we know that because our sayName function is located on the prototype and not directly on the Person instance, the object that the Person function is returning must be delegating to its prototype on failed lookups. In more simple terms, when we call tyler.sayName() the interpreter says "OK, I'm going to look on the 'tyler' object we just created, locate the sayName function, then call it. Wait a minute, I don't see it here - all I see is name and age, let me check the prototype. Yup, looks like it's on the prototype, let me call it.".
Below is code for how you can think about what the 'new' keyword is actually doing in JavaScript. It's basically a code example of the above paragraph. I've put the 'interpreter view' or the way the interpreter sees the code inside of notes.
var Person = function(name, age){
  //The below line creates an object(obj) that will delegate to the person's prototype on failed lookups.
  //var obj = Object.create(Person.prototype);

  //The line directly below this sets 'this' to the newly created object
  //this = obj;

  this.name = name;
  this.age = age;

  //return this;
}

Now having this knowledge of what the 'new' keyword really does in JavaScript, creating a Service in AngularJS should be easier to understand.
The biggest thing to understand when creating a Service is knowing that Services are instantiated with the 'new' keyword. Combining that knowledge with our examples above, you should now recognize that you'll be attaching your properties and methods directly to 'this' which will then be returned from the Service itself. Let's take a look at this in action.
Unlike what we originally did with the Factory example, we don't need to create an object then return that object because, like mentioned many times before, we used the 'new' keyword so the interpreter will create that object, have it delegate to it's prototype, then return it for us without us having to do the work.
First things first, let's create our 'private' and helper function. This should look very familiar since we did the exact same thing with our factory. I won't explain what each line does here because I did that in the factory example, if you're confused, re-read the factory example.
app.service('myService', function($http, $q){
  var baseUrl = 'https://itunes.apple.com/search?term=';
  var _artist = '';
  var _finalUrl = '';

  var makeUrl = function(){
    _artist = _artist.split(' ').join('+');
    _finalUrl = baseUrl + _artist + '&callback=JSON_CALLBACK'
    return _finalUrl;
  }
});

Now, we'll attach all of our methods that will be available in our controller to 'this'.
app.service('myService', function($http, $q){
  var baseUrl = 'https://itunes.apple.com/search?term=';
  var _artist = '';
  var _finalUrl = '';

  var makeUrl = function(){
    _artist = _artist.split(' ').join('+');
    _finalUrl = baseUrl + _artist + '&callback=JSON_CALLBACK'
    return _finalUrl;
  }

  this.setArtist = function(artist){
    _artist = artist;
  }

  this.getArtist = function(){
    return _artist;
  }

  this.callItunes = function(){
    makeUrl();
    var deferred = $q.defer();
    $http({
      method: 'JSONP',
      url: _finalUrl
    }).success(function(data){
      deferred.resolve(data);
    }).error(function(){
      deferred.reject('There was an error')
    })
    return deferred.promise;
  }

});

Now just like in our factory, setArtist, getArtist, and callItunes will be available in whichever controller we pass myService into. Here's the myService controller (which is almost exactly the same as our factory controller).
app.controller('myServiceCtrl', function($scope, myService){
  $scope.data = {};
  $scope.updateArtist = function(){
    myService.setArtist($scope.data.artist);
  };

  $scope.submitArtist = function(){
    myService.callItunes()
      .then(function(data){
        $scope.data.artistData = data;
      }, function(data){
        alert(data);
      })
  }
});

Like I mentioned before, once you really understand what 'new' does, Services are almost identical to factories in AngularJS.

3) Provider
The biggest thing to remember about Providers is that they're the only service that you can pass into the app.config portion of your application. This is of huge importance if you're needing to alter some portion of your service object before it's available everywhere else in your application. Although very similar to Services/Factories, there are a few differences which we'll discuss.
First we set up our Provider in a similar way we did with our Service and Factory. The variables below are our 'private' and helper function.
app.provider('myProvider', function(){
   var baseUrl = 'https://itunes.apple.com/search?term=';
  var _artist = '';
  var _finalUrl = '';

  //Going to set this property on the config function below.
  this.thingFromConfig = '';

  var makeUrl = function(){
    _artist = _artist.split(' ').join('+');
    _finalUrl = baseUrl + _artist + '&callback=JSON_CALLBACK'
    return _finalUrl;
  }
}

*Again if any portion of the above code is confusing, check out the Factory section where I explain what it all does it greater details.
You can think of Providers as having three sections. The first section is the 'private' variables/functions that will be modified/set later (shown above). The second section is the variables/functions that will be available in your app.config function and are therefore available to alter before they're available anywhere else (also shown above). It's important to note that those variables need to be attached to the 'this' keyword. In our example, only 'thingFromConfig' will be available to alter in the app.config. The third section (shown below) is all the variables/functions that will be available in your controller when you pass in the 'myProvider' service into that specific controller.
When creating a service with Provider, the only properties/methods that will be available in your controller are those properties/methods which are returned from the $get() function. The code below puts $get on 'this' (which we know will eventually be returned from that function). Now, that $get function returns all the methods/properties we want to be available in the controller. Here's a code example.
this.$get = function($http, $q){
    return {
      callItunes: function(){
        makeUrl();
        var deferred = $q.defer();
        $http({
          method: 'JSONP',
          url: _finalUrl
        }).success(function(data){
          deferred.resolve(data);
        }).error(function(){
          deferred.reject('There was an error')
        })
        return deferred.promise;
      },
      setArtist: function(artist){
        _artist = artist;
      },
      getArtist: function(){
        return _artist;
      },
      thingOnConfig: this.thingFromConfig
    }
  }

Now the full Provider code looks like this
app.provider('myProvider', function(){
  var baseUrl = 'https://itunes.apple.com/search?term=';
  var _artist = '';
  var _finalUrl = '';

  //Going to set this property on the config function below
  this.thingFromConfig = '';

  var makeUrl = function(){
    _artist = _artist.split(' ').join('+');
    _finalUrl = baseUrl + _artist + '&callback=JSON_CALLBACK'
    return _finalUrl;
  }

  this.$get = function($http, $q){
    return {
      callItunes: function(){
        makeUrl();
        var deferred = $q.defer();
        $http({
          method: 'JSONP',
          url: _finalUrl
        }).success(function(data){
          deferred.resolve(data);
        }).error(function(){
          deferred.reject('There was an error')
        })
        return deferred.promise;
      },
      setArtist: function(artist){
        _artist = artist;
      },
      getArtist: function(){
        return _artist;
      },
      thingOnConfig: this.thingFromConfig
    }
  }
});

Now just like in our factory and Service, setArtist, getArtist, and callItunes will be available in whichever controller we pass myProvider into. Here's the myProvider controller (which is almost exactly the same as our factory/Service controller).
app.controller('myProviderCtrl', function($scope, myProvider){
  $scope.data = {};
  $scope.updateArtist = function(){
    myProvider.setArtist($scope.data.artist);
  };

  $scope.submitArtist = function(){
    myProvider.callItunes()
      .then(function(data){
        $scope.data.artistData = data;
      }, function(data){
        alert(data);
      })
  }

  $scope.data.thingFromConfig = myProvider.thingOnConfig;
});

As mentioned before, the whole point of creating a service with Provider is to be able to alter some variables through the app.config function before the final object is passed to the rest of the application. Let's see an example of that.
app.config(function(myProviderProvider){
  //Providers are the only service you can pass into app.config
  myProviderProvider.thingFromConfig = 'This sentence was set in app.config. Providers are the only service that can be passed into config. Check out the code to see how it works';
});

Now you can see how 'thingFromConfig' is as empty string in our provider, but when that shows up in the DOM, it will be 'This sentence was set…'.
Comment: The only part that is missing in this excellent write-up is the relative advantages of using the service over an factory; which is clearly explained in the the accepted answer by Lior
Comment: FWIW(maybe not much), here is a blogger that takes issue  with Angular, and doesn't like providerProvider  http://codeofrob.com/entries/you-have-ruined-javascript.html
Comment: Awesome post, but I'm still a tiny bit confused: $scope is a service right? You say the controller itself should be thin and shouldn't own many variables or methods. But when I add a method to $scope such as in $scope.myFunction() = function(){...} within the controller, that's different right? I just don't really understand why I wouldn't attach a method definition or variable to $scope (in my controller) vs making the method part of a custom service or factory. Please let me know. Thanks
Comment: What is this?

app.service('myFactory', function () {
  var service = {};
  return service;
});   (it is the syntax I always use)
Comment: Followed from your blog. Greatly explained, thank you. There's a minor typo in your Provider example, the last piece of code: `getArtist = function () {
        return _artist;
      },`, shouldn't that be a colon? (On your blog, someone has fixed that here already.
Answer: All Services are singletons; they get instantiated once per app. They can be of any type, whether it be a primitive, object literal, function, or even an instance of a custom type.
The value, factory, service, constant, and provider methods are all providers. They teach the Injector how to instantiate the Services.

The most verbose, but also the most comprehensive one is a Provider
  recipe. The remaining four recipe types — Value, Factory, Service and
  Constant — are just syntactic sugar on top of a provider recipe.

The Value Recipe is the simplest case, where you instantiate the Service yourself and provide the instantiated value to the injector.
The Factory recipe gives the Injector a factory function that it calls when it needs to instantiate the service. When called, the factory function creates and returns the service instance. The dependencies of the Service are injected as the functions' arguments. So using this recipe adds the following abilities:

Ability to use other services (have dependencies)
Service initialization
Delayed/lazy initialization

The Service recipe is almost the same as the Factory recipe, but here the Injector invokes a constructor with the new operator instead of a factory function.
The Provider recipe is usually overkill. It adds one more layer of indirection by allowing you to configure the creation of the factory.

You should use the Provider recipe only when you want to expose an API
  for application-wide configuration that must be made before the
  application starts. This is usually interesting only for reusable
  services whose behavior might need to vary slightly between
  applications.
The Constant recipe is just like the Value recipe except it allows you to define services that are available in the config phase. Sooner than services created using the Value recipe. Unlike Values, they cannot be decorated using decorator.

  See the provider documentation.
Comment: @joshperry As a newbie, I've googled the difference between service and factory for a while. I do agree this is the best answer ever! I'd understand service as a service class (e.g. encoder/decoder class), which might have some private properties. And factory provides a set of stateless helper methods.
Comment: Yaa examples in other answers above fail to very clearly explain the core difference b/w services and providers which is what is injected at the time when these recipes are instantiated.
Comment: So service and factory are essentially the same?  Using one of the other provides nothing other than alternative syntax?
Comment: @Matt, yes, service is a concise way when you already have your own function which you want to expose as a service. From docs:

myApp.factory('unicornLauncher', ["apiToken", function(apiToken) {
  return new UnicornLauncher(apiToken);
}]);

vs:

myApp.service('unicornLauncher', ["apiToken", UnicornLauncher]);
Answer: Understanding AngularJS Factory, Service and Provider
All of these are used to share reusable singleton objects. It helps to share reusable code across your app/various components/modules.

From Docs Service/Factory:

Lazily instantiated – Angular only instantiates a service/factory when an application component depends on it.
Singletons – Each component
dependent on a service gets a reference to the single instance
generated by the service factory.

Factory
A factory is function where you can manipulate/add logic before creating an object, then the newly created object gets returned.
app.factory('MyFactory', function() {
    var serviceObj = {};
    //creating an object with methods/functions or variables
    serviceObj.myFunction = function() {
        //TO DO:
    };
    //return that object
    return serviceObj;
});

Usage
It can be just a collection of functions like a class. Hence, it can be instantiated in different controllers when you are injecting it inside your controller/factory/directive functions. It is instantiated only once per app.
Service
Simply while looking at the services think about the array prototype. A service is a function which instantiates a new object using the 'new' keyword. You can add properties and functions to a service object by using the this keyword. Unlike a factory, it doesn't return anything (it returns an object which contains methods/properties).
app.service('MyService', function() {
    //directly binding events to this context
    this.myServiceFunction = function() {
        //TO DO:
    };
});

Usage
Use it when you need to share a single object throughout the application. For example, authenticated user details, share-able methods/data, Utility functions etc.
Provider
A provider is used to create a configurable service object. You can configure the service setting from config function. It returns a value by using the $get() function. The $get function gets executed on the run phase in angular.
app.provider('configurableService', function() {
    var name = '';
    //this method can be be available at configuration time inside app.config.
    this.setName = function(newName) {
        name = newName;
    };
    this.$get = function() {
        var getName = function() {
             return name;
        };
        return {
            getName: getName //exposed object to where it gets injected.
        };
    };
});

Usage
When you need to provide module-wise configuration for your service object before making it available, eg. suppose you want to set your API URL on basis of your Environment like dev, stage or prod

NOTE
Only provider will be available in config phase of angular, while
service & factory are not.

Hope this has cleared up your understanding about Factory, Service and Provider.
Comment: What would I do if I wanted to have a service with a particular interface, but have two different implementations, and inject each into a controller but tied to different states using ui-router? e.g. make remote calls in one state, but write to local storage instead in another.

The provider docs say to use `only when you want to expose an API for application-wide configuration that must be made before the application starts. This is usually interesting only for reusable services whose behavior might need to vary slightly between applications`, so doesn't sound possible, right?
Answer: For me, the revelation came when I realized that they all work the same way: by running something once, storing the value they get, and then cough up that same stored value when referenced through dependency injection.
Say we have:
app.factory('a', fn);
app.service('b', fn);
app.provider('c', fn);

The difference between the three is that:

a's stored value comes from running fn.
b's stored value comes from newing fn.
c's stored value comes from first getting an instance by newing fn, and then running a $get method of the instance.

Which means there's something like a cache object inside AngularJS, whose value of each injection is only assigned once, when they've been injected the first time, and where:
cache.a = fn()
cache.b = new fn()
cache.c = (new fn()).$get()

This is why we use this in services, and define a this.$get in providers.
Comment: I also like this answer most. The point of all of them is to provide access to an object whenever needed through DI.
Normally you're doing fine with `factory`s.
The only reason `service`s exist are languages like CoffeeScript, TypeScript, ES6 etc. so you can use their class syntax.
You need `provider`s only if your module is used in several applications with different settings by using `app.config()`.
If your service is a pure singleton or is able to create instances of something only depends on your implementation.
Answer: Service vs provider vs factory:
I am trying to keep it simple. It's all about basic JavaScript concept.
First of all, let's talk about services in AngularJS!
What is Service:
In AngularJS, Service is nothing but a singleton JavaScript object which can store some useful methods or properties. This singleton object is created per ngApp(Angular app) basis and it is shared among all the controllers within current app. When Angularjs instantiate a service object, it register this service object with a unique service name. So each time when we need service instance, Angular search the registry for this service name, and it returns the reference to service object. Such that we can invoke method, access properties etc on the service object.
You may have question whether you can also put properties, methods on scope object of controllers! So why you need service object? Answers is: services are shared among multiple controller scope. If you put some properties/methods in a controller's scope object , it will be available to current scope only. But when you define methods, properties on service object, it will be available globally and can be accessed in any  controller's scope by injecting that service.
So if there are three controller scope, let it be controllerA, controllerB and controllerC, all will share same service instance.

How to create a service?
AngularJS provide different methods to register a service. Here we will concentrate on three methods factory(..),service(..),provider(..);
Use this link for code reference
Factory function:
We can define a factory function as below.
factory('serviceName',function fnFactory(){ return serviceInstance;})

AngularJS provides 'factory('serviceName', fnFactory)' method which takes two parameter, serviceName and a JavaScript function. Angular creates service instance by invoking the function fnFactory() such as below.
var serviceInstace = fnFactory();

The passed function can define a object and return that object. AngularJS simply stores this object reference to a variable which is passed as first argument. Anything which is returned from fnFactory will be bound to serviceInstance . Instead of returning object , we can also return function, values etc, Whatever we will return , will be available to service instance.
Example:
var app= angular.module('myApp', []);
//creating service using factory method
app.factory('factoryPattern',function(){
  var data={
    'firstName':'Tom',
    'lastName':' Cruise',
    greet: function(){
      console.log('hello!' + this.firstName + this.lastName);
    }
  };

  //Now all the properties and methods of data object will be available in our service object
  return data;
});

Service Function:
service('serviceName',function fnServiceConstructor(){})

It's the another way, we can register a service. The only difference is the way AngularJS tries to instantiate the service object. This time angular uses 'new' keyword and call the constructor function something like below.
var serviceInstance = new fnServiceConstructor();

In the constructor function we can use 'this' keyword for adding properties/methods to the service object.
example:
//Creating a service using the service method
var app= angular.module('myApp', []);
app.service('servicePattern',function(){
  this.firstName ='James';
  this.lastName =' Bond';
  this.greet = function(){
    console.log('My Name is '+ this.firstName + this.lastName);
  };
});

Provider function:
Provider() function is the another way for creating services. Let we are interested to create a service which just display some greeting message to the user. But we also want to provide a functionality such that user can set their own greeting message. In technical terms we want to create configurable services. How can we do this ? There must be a way, so that app could pass their custom greeting messages and Angularjs would make it available to factory/constructor function which create our services instance.
In such a case provider() function do the job. using provider() function we can create configurable services.
We can create configurable services using provider syntax as given below.
/*step1:define a service */
app.provider('service',function serviceProviderConstructor(){});

/*step2:configure the service */
app.config(function configureService(serviceProvider){});

How does provider syntax internally work?
1.Provider object is created using constructor function we defined in our provider function.
var serviceProvider = new serviceProviderConstructor();

2.The function we passed in app.config(), get executed. This is called config phase, and here we have a chance to customize our service.
configureService(serviceProvider);

3.Finally service instance is created by calling $get method of serviceProvider.
serviceInstance = serviceProvider.$get()

Sample code for creating service using provide syntax:
var app= angular.module('myApp', []);
app.provider('providerPattern',function providerConstructor(){
  //this function works as constructor function for provider
  this.firstName = 'Arnold ';
  this.lastName = ' Schwarzenegger' ;
  this.greetMessage = ' Welcome, This is default Greeting Message' ;
  //adding some method which we can call in app.config() function
  this.setGreetMsg = function(msg){
    if(msg){
      this.greetMessage =  msg ;
    }
  };

  //We can also add a method which can change firstName and lastName
  this.$get = function(){
    var firstName = this.firstName;
    var lastName = this.lastName ;
    var greetMessage = this.greetMessage;
    var data={
       greet: function(){
         console.log('hello, ' + firstName + lastName+'! '+ greetMessage);
       }
    };
    return data ;
  };
});

app.config(
  function(providerPatternProvider){
    providerPatternProvider.setGreetMsg(' How do you do ?');
  }
);

Working Demo
Summary:

Factory use a factory function which return a service instance.
serviceInstance = fnFactory();
Service use a constructor function and Angular invoke this constructor function using 'new' keyword for creating the service instance.
serviceInstance = new fnServiceConstructor();
Provider defines a providerConstructor function, this providerConstructor function defines a factory function $get . Angular calls $get() to create the service object. Provider syntax has an added advantage of configuring the service object before it get instantiated.
serviceInstance = $get();
Answer: As pointed out by several people here correctly a factory, provider, service, and even value and constant are versions of the same thing. You can dissect the more general provider into all of them. Like so:

Here's the article this image is from:
http://www.simplygoodcode.com/2015/11/the-difference-between-service-provider-and-factory-in-angularjs/
Answer: Factory
You give AngularJS a function, AngularJS will cache and inject the return value when the factory is requested.
Example:
app.factory('factory', function() {
    var name = '';
    // Return value **is** the object that will be injected
    return {
        name: name;
    }
})

Usage:
app.controller('ctrl', function($scope, factory) {
     $scope.name = factory.name;
});

Service
You give AngularJS a function, AngularJS will call new to instantiate it. It is the instance that AngularJS creates that will be cached and injected when the service is requested. Since new was used to instantiate the service, the keyword this is valid and refers to the instance.
Example:
app.service('service', function() {
     var name = '';
     this.setName = function(newName) {
         name = newName;
     }
     this.getName = function() {
         return name;
     }
});

Usage:
app.controller('ctrl', function($scope, service) {
   $scope.name = service.getName();
});

Provider
You give AngularJS a function, and AngularJS will call its $get function. It is the return value from the $get function that will be cached and injected when the service is requested.
Providers allow you to configure the provider before AngularJS calls the $get method to get the injectible.
Example:
app.provider('provider', function() {
     var name = '';
     this.setName = function(newName) {
          name = newName;
     }
     this.$get = function() {
         return {
            name: name
         }
     }
})

Usage (as an injectable in a controller)
app.controller('ctrl', function($scope, provider) {
    $scope.name = provider.name;
});

Usage (configuring the provider before $get is called to create the injectable)
app.config(function(providerProvider) {
    providerProvider.setName('John');
});

Answer: I noticed something interesting when playing around with providers.
Visibility of injectables is different for providers than it is for services and factories. If you declare an AngularJS "constant" (for example, myApp.constant('a', 'Robert');), you can inject it into services, factories, and providers.
But if you declare an AngularJS "value" (for example., myApp.value('b', {name: 'Jones'});), you can inject it into services and factories, but NOT into the provider-creating function. You can, however, inject it into the $get function that you define for your provider. This is mentioned in the AngularJS documentation, but it's easy to miss. You can find it on the %provide page in the sections on the value and constant methods.
http://jsfiddle.net/R2Frv/1/

from Service: {{servGreet}}

from Provider: {{provGreet}}

Answer: This is very confusing part for newbie and I have tried to clarify it in easy words
AngularJS Service: is used for sharing utility functions with the service reference in the controller. Service is singleton in nature so for one service only one instance is created in the browser and the same reference is used throughout the page.
In the service, we create function names as property with this object.
AngularJS Factory: the purpose of Factory is also same as Service however in this case we create a new object and add functions as properties of this object and at the end we return this object.
AngularJS Provider: the purpose of this is again same however Provider gives the output of it's $get function.
Defining and using Service, Factory and Provider are explained at http://www.dotnetfunda.com/articles/show/3156/difference-between-angularjs-service-factory-and-provider
Comment: Factory and providers are also singleton object ? Any scanrio where factories are recommended over services ?
Answer: For me the best and the simplest way of understanding the difference is:
var service, factory;
service = factory = function(injection) {}

How AngularJS instantiates particular components (simplified):
// service
var angularService = new service(injection);

// factory
var angularFactory = factory(injection);

So, for the service, what becomes the AngularJS component is the object instance of the class which is represented by service declaration function. For the factory, it is the result returned from the factory declaration function. The factory may behave the same as the service:
var factoryAsService = function(injection) {
  return new function(injection) {
    // Service content
  }
}

The simplest way of thinking is the following one:

Service is an singleton object instance. Use services if you want to provide a singleton object for your code.
Factory is a class. Use factories if you want to provide custom classes for your code (can't be done with services because they are already instantiated).

The factory 'class' example is provided in the comments around, as well as provider difference.
Comment: how can a service be a singleton if it gets instantiated every time it is used? i can get my head around that...
Comment: Service is only once instantiated during dependency resolving, and then when you ask for service from injector, you're getting always the same instance. It can be easily check here: http://jsfiddle.net/l0co/sovtu55t/1/, please run it with console. The console shows that service is instantiated only once.
Comment: oh i see. i was expecting to be able to literally `new MyService()` or something :)
Answer: My clarification on this matter:
Basically all of the mentioned types (service, factory, provider, etc.) are just creating and configuring global variables (that are of course global to the entire application), just as old fashioned global variables were.
While global variables are not recommended, the real usage of these global variables is to provide dependency injection, by passing the variable to the relevant controller.
There are many levels of complications in creating the values for the "global variables":

Constant
This defines an actual constant that should not be modified during the entire application, just like constants in other languages are (something that JavaScript lacks).
Value
This is a modifiable value or object, and it serves as some global variable, that can even be injected when creating other services or factories (see further on these). However, it must be a "literal value", which means that one has to write out the actual value, and cannot use any computation or programming logic (in other words 39 or myText or {prop: "value"} are OK, but 2 +2 is not).
Factory
A more general value, that is possible to be computed right away. It works by passing a function to AngularJS with the logic needed to compute the value and AngularJS executes it, and it saves the return value in the named variable.
Note that it is possible to return a object (in which case it will function similar to a service) or a function (that will be saved in the variable as a callback function).
Service
A service is a more stripped-down version of factory which is valid only when the value is an object, and it allows for writing any logic directly in the function (as if it would be a constructor), as well as declaring and accessing the object properties using the this keyword.
Provider
Unlike a service which is a simplified version of factory, a provider is a more complex, but more flexible way of initializing the "global" variables, with the biggest flexibility being the option to set values from the app.config.
It works like using a combination of service and provider, by passing to provider a function that has properties declared using the this keyword, which can be used from the app.config.
Then it needs to have a separate $.get function which is executed by AngularJS after setting the above properties via the app.config file , and this $.get function behaves just as the factory above, in that its return value is used to initialize the "global" variables.
Answer: My understanding is very simple below.
Factory:
  You simply create an object inside of the factory and return it.
Service:
You just have a standard function that uses this keyword to define a function.
Provider:
There is a $get object that you define and it can be used to get the object that returns data.
Comment: Didn't you mixed up the Factory and Service ? Services creates where factory returns.
Comment: When you declaring service name as an injectable argument you will be provided with an instance of the function. In other words new FunctionYouPassedToService(). This object instance becomes the service object that AngularJS registers and injects later to other services / controllers if required.
//factory
When you declaring factoryname as an injectable argument you will be provided with the value that is returned by invoking the function reference passed to module.factory.
Comment: Okay, so… in angular the factory is a [singleton](http://en.wikipedia.org/wiki/Singleton_pattern) where the "service" is a actually a [factory](http://en.wikipedia.org/wiki/Factory_method_pattern) (in common design patterns terms)
Answer: Summary from Angular docs:

There are five recipe types that define how to create objects: Value,
Factory, Service, Provider and Constant.
Factory and Service are the most commonly used recipes. The only difference between them is that the Service recipe works better for objects of a custom type, while the Factory can produce JavaScript primitives and functions.
The Provider recipe is the core recipe type and all the other ones are just syntactic sugar on it.
Provider is the most complex recipe type. You don't need it unless you are building a reusable piece of code that needs global configuration.

Best answers from SO:
https://stackoverflow.com/a/26924234/165673  (<-- GOOD)
https://stackoverflow.com/a/27263882/165673
https://stackoverflow.com/a/16566144/165673
Answer: All the good answers already. I would like to add few more points on Service and Factory. Along with the difference between service/factory. And  one can also have questions like:

Should I use service or factory? What's the difference?
Is they do same or have same behaviour?

Lets start with the difference between Service and factory:

Both are Singletons: Whenever Angular find these as a dependency first time,it create a single instance of service/factory. Once the instance is created, same instance is used forever.
Can be used to model an object with behavior: They can both have methods, internal state variables, and so on. Though the way you write that code will differ.

Services:
A service is a constructor function, and Angular will instantiate it by calling new yourServiceName(). This means a couple of things.

Functions and instance variables will be properties of this.
You don't need to return a value. When Angular calls new yourServiceName(), it'll receive the this object with all the properties you put on it.

Sample Example:
angular.service('MyService', function() {
  this.aServiceVariable = "Ved Prakash"
  this.aServiceMethod = function() {
    return //code
  };
});

When Angular injects this MyService service into a controller that
  depends on it, that controller will get a MyService that it can call
  functions on, e.g. MyService.aServiceMethod ().

Be careful with this:
Since the constructed service is an object, the methods inside it can refer to this when they're called:
angular.service('ScoreKeeper', function($http) {
  this.score = 0;

  this.getScore = function() {
    return this.score;
  };

  this.setScore = function(newScore) {
    this.score = newScore;
  };

  this.addOne = function() {
    this.score++;
  };
});

You might be tempted to call ScoreKeeper.setScore in a promise chain, for instance if you initialized the score by grabbing it from the server: $http.get('/score').then(ScoreKeeper.setScore). The trouble with this is that ScoreKeeper.setScore will be called with this bound to null and you'll get errors. The better way would be $http.get('/score').then(ScoreKeeper.setScore.bind(ScoreKeeper)).
Whether you choose to use this in your service methods or not, be careful how you call them.
Returning a Value from a Service:
Due to how JavaScript constructors work, if you return a complex value (i.e., an Object) from a constructor function, the caller will get that Object instead of the this instance.
This means that you can basically copy-paste the factory example from below, replace factory with service, and it'll work:
angular.service('MyService', function($http) {
  var api = {};

  api.aServiceMethod= function() {
    return $http.get('/users');
  };
  return api;
});

So when Angular constructs your service with new MyService(), it'll get that api object instead of the MyService instance.
This is the behavior for any complex values (objects, functions) but not for primitive types.
Factories:
A factory is a plain old function that returns a value. The return value is what gets injected into things that depend on the factory. A typical factory pattern in Angular is to return an object with functions as properties, like this:
angular.factory('MyFactory', function($http) {
  var api = {};

  api.aFactoryMethod= function() {
    return $http.get('/users');
  };

  return api;
});

The injected value for a factory dependency is the factory's return
  value, and it doesn't have to be an object. It could be a function

Answers for above 1 and 2 questions:

For the most part, just stick with using factories for everything.
  Their behavior is easier to understand. There's no choice to make
  about whether to return a value or not, and furthermore, no bugs to be
  introduced if you do the wrong thing.
I still refer to them as "services" when I'm talking about injecting
  them as dependencies, though.
Service/Factory behavior is very similar, and some people will say
  that either one is fine. That's somewhat true, but I find it easier to
  follow the advice of John Papa's style guide and just stick with
  factories.**
Answer: An additional clarification is that factories can create functions/primitives, while services cannot. Check out this jsFiddle based on Epokk's: http://jsfiddle.net/skeller88/PxdSP/1351/.
The factory returns a function that can be invoked:
myApp.factory('helloWorldFromFactory', function() {
  return function() {
    return "Hello, World!";
  };
});

The factory can also return an object with a method that can be invoked:
myApp.factory('helloWorldFromFactory', function() {
  return {
    sayHello: function() {
      return "Hello, World!";
    }
  };
});

The service returns an object with a method that can be invoked:
myApp.service('helloWorldFromService', function() {
  this.sayHello = function() {
     return "Hello, World!";
  };
});

For more details, see a post I wrote on the difference: http://www.shanemkeller.com/tldr-services-vs-factories-in-angular/
Answer: There are good answers already, but I just want to share this one.
First of all: Provider is the way/recipe to create a service (singleton object) that suppose to be injected by $injector (how AngulaJS goes about IoC pattern).
And Value, Factory, Service and Constant (4 ways) - the syntactic sugar over Provider way/recepie.
There is Service vs Factory part has been covered:
https://www.youtube.com/watch?v=BLzNCkPn3ao
Service is all about new keyword actually which as we know does 4 things:

creates brand new object
links it to its prototype object
connects context to this
and returns this

And Factory is all about Factory Pattern - contains functions that return Objects like that Service.

ability to use other services (have dependencies)
service initialization
delayed/lazy initialization

And this simple/short video: covers also Provider: https://www.youtube.com/watch?v=HvTZbQ_hUZY (there you see can see how they go from factory to provider)
Provider recipe is used mostly in the app config, before the app has fully started/initialized.
Answer: After reading all these post It created more confuse for me.. But still all is worthfull information.. finally I found following table which will give information with simple comparision

The injector uses recipes to create two types of objects: services
and special purpose objects
There are five recipe types that define how to create objects: Value,
Factory, Service, Provider and Constant.
Factory and Service are the most commonly used recipes. The only difference between them is that the Service recipe works better for objects of a custom type, while the Factory can produce JavaScript primitives and functions.
The Provider recipe is the core recipe type and all the other ones are just syntactic sugar on it.
Provider is the most complex recipe type. You don't need it unless you are building a reusable piece of code that needs global configuration.
All special purpose objects except for the Controller are defined via Factory recipes.

And for beginner understand:- This may not correct use case but in high level this is what usecase for these three.

If you want to use in angular module config function should created as provider

angular.module('myApp').config(function($testProvider){
$testProvider.someFunction();
})

Ajax call or third party integrations needs to be service.
For Data manipulations create it as factory

For basic scenarios factory&Service behaves same.
Answer: Using as reference this page and the documentation (which seems to have greatly improved since the last time I looked), I put together the following real(-ish) world demo which uses 4 of the 5 flavours of provider; Value, Constant, Factory and full blown Provider.
HTML:

{{main.title}}*

{{main.strapline}}

Earn {{main.earn}} per click

You've earned {{main.earned}} by clicking!

    <button ng-click="main.handleClick()">Click me to earn</button>
    * Not actual money

app
var app = angular.module('angularProviders', []);

// A CONSTANT is not going to change
app.constant('range', 100);

// A VALUE could change, but probably / typically doesn't
app.value('title', 'Earn money by clicking');
app.value('strapline', 'Adventures in ng Providers');

// A simple FACTORY allows us to compute a value @ runtime.
// Furthermore, it can have other dependencies injected into it such
// as our range constant.
app.factory('random', function randomFactory(range) {
    // Get a random number within the range defined in our CONSTANT
    return Math.random() * range;
});

// A PROVIDER, must return a custom type which implements the functionality
// provided by our service (see what I did there?).
// Here we define the constructor for the custom type the PROVIDER below will
// instantiate and return.
var Money = function(locale) {

    // Depending on locale string set during config phase, we'll
    // use different symbols and positioning for any values we
    // need to display as currency
    this.settings = {
        uk: {
            front: true,
            currency: '£',
            thousand: ',',
            decimal: '.'
        },
        eu: {
            front: false,
            currency: '€',
            thousand: '.',
            decimal: ','
        }
    };

    this.locale = locale;
};

// Return a monetary value with currency symbol and placement, and decimal
// and thousand delimiters according to the locale set in the config phase.
Money.prototype.convertValue = function(value) {

    var settings = this.settings[this.locale],
        decimalIndex, converted;

    converted = this.addThousandSeparator(value.toFixed(2), settings.thousand);

    decimalIndex = converted.length - 3;

    converted = converted.substr(0, decimalIndex) +
        settings.decimal +
        converted.substr(decimalIndex + 1);

    converted = settings.front ?
            settings.currency + converted :
            converted + settings.currency;

    return converted;
};

// Add supplied thousand separator to supplied value
Money.prototype.addThousandSeparator = function(value, symbol) {
   return value.toString().replace(/\B(?=(\d{3})+(?!\d))/g, symbol);
};

// PROVIDER is the core recipe type - VALUE, CONSTANT, SERVICE & FACTORY
// are all effectively syntactic sugar built on top of the PROVIDER construct
// One of the advantages of the PROVIDER is that we can configure it before the
// application starts (see config below).
app.provider('money', function MoneyProvider() {

    var locale;

    // Function called by the config to set up the provider
    this.setLocale = function(value) {
        locale = value;
    };

    // All providers need to implement a $get method which returns
    // an instance of the custom class which constitutes the service
    this.$get = function moneyFactory() {
        return new Money(locale);
    };
});

// We can configure a PROVIDER on application initialisation.
app.config(['moneyProvider', function(moneyProvider) {
    moneyProvider.setLocale('uk');
    //moneyProvider.setLocale('eu');
}]);

// The ubiquitous controller
app.controller('mainCtrl', function($scope, title, strapline, random, money) {

    // Plain old VALUE(s)
    this.title = title;
    this.strapline = strapline;

    this.count = 0;

    // Compute values using our money provider
    this.earn = money.convertValue(random); // random is computed @ runtime
    this.earned = money.convertValue(0);

    this.handleClick = function() {
        this.count ++;
        this.earned = money.convertValue(random * this.count);
    };
});

Working demo.
Answer: Here is some broilerplate code I've come up with as a code-template for object factory in AngularjS.  I've used a Car/CarFactory as an example to illustrate.  Makes for simple implementation code in the controller.

Here is a simpler example.  I'm using a few third party libraries that expect a "Position" object exposing latitude and longitude, but via different object properties.  I didn't want to hack the vendor code, so I adjusted the "Position" objects I was passing around.
    angular.module('app')
.factory('PositionFactory', function() {

    /**
     * BroilerPlate Object Instance Factory Definition / Example
     */
    this.Position = function() {

        // initialize instance properties
        // (multiple properties to satisfy multiple external interface contracts)
        angular.extend(this, {
            lat         : null,
            lon         : null,
            latitude    : null,
            longitude   : null,
            coords: {
                latitude: null,
                longitude: null
            }
        });

        this.setLatitude = function(latitude) {
            this.latitude           = latitude;
            this.lat                = latitude;
            this.coords.latitude    = latitude;
            return this;
        };
        this.setLongitude = function(longitude) {
            this.longitude          = longitude;
            this.lon                = longitude;
            this.coords.longitude   = longitude;
            return this;
        };

    }; // end class definition

    // instance factory method / constructor
    this.Position.prototype.instance = function(params) {
        return new
            this.constructor()
                    .setLatitude(params.latitude)
                    .setLongitude(params.longitude)
        ;
    };

    return new this.Position();

}) // end Factory Definition

.controller('testCtrl', function($scope, PositionFactory) {
    $scope.position1 = PositionFactory.instance({latitude: 39, longitude: 42.3123});
    $scope.position2 = PositionFactory.instance({latitude: 39, longitude: 42.3333});
}) // end controller

;
Answer: This answer address the topic/question
how Factory, Service and Constant — are just syntactic sugar on top of a provider recipe?
OR
how factory ,servic and providers are simailar internally
basically what happens is
When you make a factory() it sets you function provided in second argument to provider's $get and return it(provider(name, {$get:factoryFn })), all you get is provider but there is no property/method other than $get of that provider(means you can't configure this)
Source code of factory
function factory(name, factoryFn, enforce) {
    return provider(name, {
      $get: enforce !== false ? enforceReturnValue(name, factoryFn) : factoryFn
    });
};

When making a service() it return you providing a factory() with a function that injects the constructor (return the instance of the constructor you provided in your service) and returns it
Source code of service
function service(name, constructor) {
    return factory(name, ['$injector', function($injector) {
      return $injector.instantiate(constructor);
    }]);
};

So basically in both cases you eventually get a providers $get set to your function you provided , but you can give anything extra than $get as you can originally provide in provider() for config block
Answer: I know a lot of excellent answer but I have to share my experience of using
1. service for most cases of default
2. factory used to create the service that specific instance
// factory.js ////////////////////////////
(function() {
'use strict';
angular
    .module('myApp.services')
    .factory('xFactory', xFactoryImp);
xFactoryImp.$inject = ['$http'];

function xFactoryImp($http) {
    var fac = function (params) {
        this._params = params; // used for query params
    };

    fac.prototype.nextPage = function () {
        var url = "/_prc";

        $http.get(url, {params: this._params}).success(function(data){ ...
    }
    return fac;
}
})();

// service.js //////////////////////////
(function() {
'use strict';
angular
    .module('myApp.services')
    .service('xService', xServiceImp);
xServiceImp.$inject = ['$http'];

function xServiceImp($http) {
    this._params = {'model': 'account','mode': 'list'};

    this.nextPage = function () {
        var url = "/_prc";

        $http.get(url, {params: this._params}).success(function(data){ ...
    }
}
})();

and using:
controller: ['xFactory', 'xService', function(xFactory, xService){

        // books = new instance of xFactory for query 'book' model
        var books = new xFactory({'model': 'book', 'mode': 'list'});

        // accounts = new instance of xFactory for query 'accounts' model
        var accounts = new xFactory({'model': 'account', 'mode': 'list'});

        // accounts2 = accounts variable
        var accounts2 = xService;
...

Answer: Little late to the party.  But I thought this is more helpful for who would like to learn (or have clarity) on developing Angular JS Custom Services using factory, service and provider methodologies.
I came across this video which explains clearly about factory, service and provider methodologies for developing AngularJS Custom Services:
https://www.youtube.com/watch?v=oUXku28ex-M
Source Code: http://www.techcbt.com/Post/353/Angular-JS-basics/how-to-develop-angularjs-custom-service
Code posted here is copied straight from the above source, to benefit readers.
The code for "factory" based custom service is as follows (which goes with both sync and async versions along with calling http service):

var app = angular.module("app", []);
app.controller('emp', ['$scope', 'calcFactory',
  function($scope, calcFactory) {
    $scope.a = 10;
    $scope.b = 20;

    $scope.doSum = function() {
      //$scope.sum = calcFactory.getSum($scope.a, $scope.b); //synchronous
      calcFactory.getSum($scope.a, $scope.b, function(r) { //aynchronous
        $scope.sum = r;
      });
    };

  }
]);

app.factory('calcFactory', ['$http', '$log',
  function($http, $log) {
    $log.log("instantiating calcFactory..");
    var oCalcService = {};

    //oCalcService.getSum = function(a,b){
    // return parseInt(a) + parseInt(b);
    //};

    //oCalcService.getSum = function(a, b, cb){
    // var s = parseInt(a) + parseInt(b);
    // cb(s);
    //};

    oCalcService.getSum = function(a, b, cb) { //using http service

      $http({
        url: 'http://localhost:4467/Sum?a=' + a + '&b=' + b,
        method: 'GET'
      }).then(function(resp) {
        $log.log(resp.data);
        cb(resp.data);
      }, function(resp) {
        $log.error("ERROR occurred");
      });
    };

    return oCalcService;
  }
]);

The code for "service" methodology for Custom Services (this is pretty similar to 'factory', but different from syntax point of view):

var app = angular.module("app", []);
app.controller('emp', ['$scope', 'calcService', function($scope, calcService){
 $scope.a = 10;
 $scope.b = 20;

 $scope.doSum = function(){
  //$scope.sum = calcService.getSum($scope.a, $scope.b);

  calcService.getSum($scope.a, $scope.b, function(r){
   $scope.sum = r;
  });
 };

}]);

app.service('calcService', ['$http', '$log', function($http, $log){
 $log.log("instantiating calcService..");

 //this.getSum = function(a,b){
 // return parseInt(a) + parseInt(b);
 //};

 //this.getSum = function(a, b, cb){
 // var s = parseInt(a) + parseInt(b);
 // cb(s);
 //};

 this.getSum = function(a, b, cb){
  $http({
   url: 'http://localhost:4467/Sum?a=' + a + '&b=' + b,
   method: 'GET'
  }).then(function(resp){
   $log.log(resp.data);
   cb(resp.data);
  },function(resp){
   $log.error("ERROR occurred");
  });
 };

}]);

The code for "provider" methodology for Custom Services (this is necessary, if you would like to develop service which could be configured):

var app = angular.module("app", []);
app.controller('emp', ['$scope', 'calcService', function($scope, calcService){
 $scope.a = 10;
 $scope.b = 20;

 $scope.doSum = function(){
  //$scope.sum = calcService.getSum($scope.a, $scope.b);

  calcService.getSum($scope.a, $scope.b, function(r){
   $scope.sum = r;
  });
 };

}]);

app.provider('calcService', function(){

 var baseUrl = '';

 this.config = function(url){
  baseUrl = url;
 };

 this.$get = ['$log', '$http', function($log, $http){
  $log.log("instantiating calcService...")
  var oCalcService = {};

  //oCalcService.getSum = function(a,b){
  // return parseInt(a) + parseInt(b);
  //};

  //oCalcService.getSum = function(a, b, cb){
  // var s = parseInt(a) + parseInt(b);
  // cb(s);
  //};

  oCalcService.getSum = function(a, b, cb){

   $http({
    url: baseUrl + '/Sum?a=' + a + '&b=' + b,
    method: 'GET'
   }).then(function(resp){
    $log.log(resp.data);
    cb(resp.data);
   },function(resp){
    $log.error("ERROR occurred");
   });
  };

  return oCalcService;
 }];

});

app.config(['calcServiceProvider', function(calcServiceProvider){
 calcServiceProvider.config("http://localhost:4467");
}]);

Finally the UI which works with any of the above services:

 <title></title>

   Value of a is {{a}},
   but you can change
   <input type=text ng-model="a" />

   Value of b is {{b}},
   but you can change
   <input type=text ng-model="b" />

  Sum = {{sum}}

  <button ng-click="doSum()">Calculate</button>

Answer: Just to clarify things, from the AngularJS source, you can see a service just calls the factory function which in turn calls the provider function:
function factory(name, factoryFn) {
    return provider(name, { $get: factoryFn });
}

function service(name, constructor) {
    return factory(name, ['$injector', function($injector) {
      return $injector.instantiate(constructor);
    }]);
}

Answer: Let's discuss the three ways of handling business logic in AngularJS in a simple way: (Inspired by Yaakov's Coursera AngularJS course)
SERVICE:
Syntax:
app.js
 var app = angular.module('ServiceExample',[]);
 var serviceExampleController =
              app.controller('ServiceExampleController', ServiceExampleController);
 var serviceExample = app.service('NameOfTheService', NameOfTheService);

 ServiceExampleController.$inject = ['NameOfTheService'] //protects from minification of js files

function ServiceExampleController(NameOfTheService){
     serviceExampleController = this;
     serviceExampleController.data = NameOfTheService.getSomeData();
 }

function NameOfTheService(){
     nameOfTheService = this;
     nameOfTheService.data = "Some Data";
     nameOfTheService.getSomeData = function(){
           return nameOfTheService.data;
     }
}

index.html

   {{serviceExample.data}}

Features of Service:

Lazily Instantiated: If it is not injected it won't be instantiated ever. So to use it will have to inject it to a module.
Singleton: If injected to multiple modules, all will have access to only one particular instance. That is why very convenient to share data across different controllers.

FACTORY
First let's have a look at the syntax:
app.js:
var app = angular.module('FactoryExample',[]);
var factoryController = app.controller('FactoryController', FactoryController);
var factoryExampleOne = app.factory('NameOfTheFactoryOne', NameOfTheFactoryOne);
var factoryExampleTwo = app.factory('NameOfTheFactoryTwo', NameOfTheFactoryTwo);

//first implementation where it returns a function
function NameOfTheFactoryOne(){
   var factory = function(){
      return new SomeService();
    }
   return factory;
}

//second implementation where an object literal would be returned
function NameOfTheFactoryTwo(){
   var factory = {
      getSomeService : function(){
          return new SomeService();
       }
    };
   return factory;
}

Now using the above two in the controller:
 var factoryOne = NameOfTheFactoryOne() //since it returns a function
 factoryOne.someMethod();

 var factoryTwo = NameOfTheFactoryTwo.getSomeService(); //accessing the object
 factoryTwo.someMethod();

Features of Factory:

Follows the factory design pattern. The factory is a central place that produces new objects or functions.
Not only produces singleton, but customizable services.
The .service() method is a factory that always produces the same type of service, which is a singleton, and without any easy way to configure it's behavior. That .service() method is usually used as a shortcut for something that doesn't require any configuration whatsoever.

PROVIDER
Let's again have a look at the Syntax first:
angular.module('ProviderModule', [])
.controller('ProviderModuleController', ProviderModuleController)
.provider('ServiceProvider', ServiceProvider)
.config(Config); //optional

Config.$inject = ['ServiceProvider'];
function Config(ServiceProvider) {
  ServiceProvider.defaults.maxItems = 10; //some default value
}

ProviderModuleController.$inject = ['ServiceProvider'];
function ProviderModuleController(ServiceProvider) {
  //some methods
}

function ServiceProvider() {
  var provider = this;

  provider.defaults = {
    maxItems: 10
  };

  provider.$get = function () {
    var someList = new someListService(provider.defaults.maxItems);

    return someList;
  };
}

}

Features of Provider:

Provider is the most flexible method of creating services in Angular.
Not only we can create a factory that's dynamically configurable, but at the time of using the factory, with the provider method, we could custom configure the factory just once at the bootstrapping of our entire application.
The factory can then be used throughout the application with custom settings. In other words, we can configure this factory before the application starts. In fact in the angular documentation it is mentioned that the provider method is what actually gets executed behind the scenes when we configure our services with either .service or .factory methods.
The $get is a function that is directly attached to the provider instance. That function is a factory function. In other words, it's just like the one that we use to provide to the .factory method. In that function, we create our own service. This $get property, that's a function, is what makes the provider a provider. AngularJS expects the provider to have a $get property whose value is a function that Angular will treat as a factory function. But what makes this whole provider setup very special, is the fact that we can provide some config object inside the service provider, and that usually comes with defaults that we can later overwrite in the step, where we can configure the entire application.
Answer: Essentially, Provider, Factory, and Service are all Services. A Factory is a special case of a Service when all you need is a $get() function, allowing you to write it with less code.
The major differences among Services, Factories, and Providers are their complexities. Services are the simplest form, Factories are a little more robust, and Providers are configurable at runtime.
Here is a summary of when to use each:
Factory: The value you are providing needs to be calculated based on other data.
Service: You are returning an object with methods.
Provider: You want to be able to configure, during the config phase, the object that is going to be created before it's created. Use the Provider mostly in the app config, before the app has fully initialized.
Comment: erm. Value, Factory, Service and Constant — are just syntactic sugar on top of a provider recipe. [Angularjs docs - providers](https://docs.angularjs.org/guide/providers)
Comment: yes i agree , now with angular 4 we don't have this headache  any more
Answer: Factory: The factory you actually create an object inside of the factory and return it.
service: The service you just have a standard function that uses the this keyword to define function.
provider: The provider there's a $get you define and it can be used to get the object that returns the data.
Answer: 1.Services are singleton objects that are created when necessary and are never cleaned up until the end of the application life-cycle (when the browser is closed). Controllers are destroyed and cleaned up when they are no longer needed.
2.The easiest way to create a service is by using the factory() method.
The factory() method allows us to define a service by returning an object that contains service functions and service data. The service definition function is where we place our injectable services, such as $http and $q.
Ex:
angular.module('myApp.services')
.factory('User', function($http) { // injectables go here
var backendUrl = "http://localhost:3000"; var service = {
    // our factory definition
user: {},
setName: function(newName) {
      service.user['name'] = newName;
    },
setEmail: function(newEmail) { service.user['email'] = newEmail;
},
save: function() {
return $http.post(backendUrl + '/users', { user: service.user
}); }
};
return service; });

Using the factory() in our app
It's easy to use the factory in our application as we can simply inject it where we need it at run-time.
angular.module('myApp')
.controller('MainController', function($scope, User) {
  $scope.saveUser = User.save;
});

The service() method, on the other hand allows us to create a service by defining a constructor function. We can use a prototypical object to define our service, instead of a raw javascript object.
Similar to the factory() method, we'll also set the injectables in the function definition.
The lowest level way to create a service is by using the provide() method. This is the only way to create a service that we can configure using the .config() function.
Unlike the previous to methods, we'll set the injectables in a defined this.$get() function definition.
Answer: Syntactic Sugar is the difference. Only provider is needed. Or in other words only provider is the real angular, all other ones are derived(to reduce code). There is a simple version as well, called Value()  which returns just the value, no calculation or function. Even Value is derived from provider!
So why such complications, why can't we just use provider and forget everything else? It is supposed to help us write code easily and communicate better. And toungue-in-cheek reply would be, the more complex it gets the better selling a framework will be.

A provider that can return value = Value
A provider that can just
instantiate and return = Factory (+ Value)
A provider that can
instantiate + do something = Service (+ Factory, + Value)
A provider
= must contain a property called $get (+Factory, + Service, + Value)

Angular injection gives us the first hint in reaching this conclusion.
"$injector is used to retrieve object instances as defined by provider" not service, not factory but provider.
And a better answer would be this:
"An Angular service is created by a service factory. These service factories are functions which, in turn, are created by a service provider. The service providers are constructor functions. When instantiated they must contain a property called $get, which holds the service factory function."
So master provider and injector and all will fall in place :) . And it gets interesting in Typescript when $get can be implemented in a provider by inheriting from IServiceProvider.


BGE Facing Plane

Question: I'm creating a game in Blender. The enemies in the FPS are sprites on a flat plane. The only problem I have is making the flat plane to where it's constantly facing the player camera similar to Doom, because the enemies aren't in 3D. Is there a way to make the flat plane mesh constantly face the player camera using the Logic, or is there any Python coding involved?
Answer: If you enable Billboard in Materials Tab under Game Settings > Face Orientation, the planes local x-axis will always face the camera while the z-axis remains as it is (= the object rotates only on its z-axis).
https://docs.blender.org/manual/en/dev/game_engine/materials.html#face-orientation
Comment: Good one red @Momel .  My version hasn't got that.  Would have been handy!
Comment: Correction - I did find it, thanks to your post. :)
Answer: This is not a very good answer but it should get you there.  I've dug out the logic bricks of a game I made a long time ago when learning the BGE.  The pic pretty much says it all...

To bring the enemy sprites' logic up, select them in the 3D window.
The "Near" sensor detects when the player gets within the distance range you type in and sets off 3 actuators.  The one you're looking for is "Steering".  That will make the enemy face the player or whatever you nominate.  I see I'd set him to an almost zero velocity. (coward that I am)
The other two are broadcasting messages which other "Sensors" can pick up and act upon or ignore.
I imagine you'd need your enemy sprites to pick up a broadcast "message" and "Steer" them towards the camera or player.  Same with anything else that has to do the same.
Good luck with your game.  It was a lot of fun as I recall.

BGE Facing Plane


Negative temperature and Absolute hot

Question: This video explains that heat at negative temperatures flows from the negative object to the normal object. If the temperature of the normal object is absolute hot, what happens with the heat? The heat can't be transferred to the absolute hot object, and it apparently does not flow in the other direction, so what happens to it?
Comment: Possible duplicates: http://physics.stackexchange.com/q/1775/2451, http://physics.stackexchange.com/q/21851/2451 and links therein.
Comment: Neither of those address absolute hot (planck temperature.)
Comment: It's not clear that absolute hot actually exists.  It seems likely that at some energy level a particle could shed energy through pair production.
Answer: "Absolute Hot" is a cute phrase, but meaningful only in a limited context, where the concept of negative temperature applies.  That is, there's a finite number of energy levels in a finite energy range, and whatever particles/quanta/excitations we're studying stay in that context.   For example we may be interested in spins of nuclei in a crystal, and how they are affected by magnetic fields.
If a system is at "absolute hot" and you add a bit more energy, the system will be excited in some way making use of energy levels outside (not necessarily above, but probably) the finite range, breaking some contraints (or assumptions) about the system under study.   For the nuclear spins example, maybe some atoms become dislodged from the lattics, or the electrons take up the energy in all the marvelous ways described in condensed matter physics.  Electrons have no upper limit - they can always escape from the crystal with arbitrarily great escape velocities.
In other words: something will break, changing the system from what it was during discussion of negative temperatures, to something more general. Energy will find a way in, if you force it.
At best, added quanta of energy, such as photons or phonons, will bounce off (a pure white object) or pass through (transparency).

Negative temperature and Absolute hot


Difference in meaning of Zeicher / Zecher

Question: In this question it discusses the background of saying both Zeicher & Zecher in Devarim 25:19, however I was wondering what is the difference in translation between Zeicher & Zecher?
Comment: Why assume there is a difference?
Answer: The standard understanding is that it means "memory of" either way, just a question of how it's vowelized. (You'll find both vowelizations in different texts of Psalm 145, known to most of us as the daily "Ashrei", on the line "zecher rav tuvcha...").
But just for fun, the Gemara, (b. bathra 21a), records a discussion wherein Joab thought the commandment only applied to the male Amalekites. The standard reading of that Gemara is he read "zachar" (male); but it's been suggested that "zecher" could be misinterpreted as a possessive form of "zachar" (just as "eshen hakivshan" means "smoke of the kiln", "eshen" is the possessive form of "ashan.")
Comment: As a wise man once told me, it's either zecher or zeicher but its zichur not zachar.
Comment: See here for discussion about that http://www.balashon.com/2007/03/zecher-and-zachar.html
Answer: There are multiple kinds of Segolites (penultimately stressed two syllable words marked with Segol/Tzere-family vowels). Some are Segol-Segol (6-dots) and move to Tzere-Segol (5-dots) when in construct form (Neder -> Neider : Vow -> Vow-of), while some start with 5 dots and remain that way in construct from (Seifer -> Seifer : Book -> Book-of), while others start with 6 dots and remain that way in construct from (Beged -> Beged : Clothing -> Clothing of). These types develop a Chirik when they get a suffix (Nidro = his vow; Sifro = his book; Bigdo = his clothing).
While there was a small amount of discussion in medieval times which category זכר is, it turns out it's of the second type. So there is no word Zekher (6 dots) and it hence has no meaning. (Someone saying Zekher is likely just mispronouncing Zeikher.) Zeikher (5 dots) can mean either "remembrance" or "remembrance of" depending on context (in your case it's the latter).
Of historical note: there was a time when printers were printing Zekher (6 dots) in various places in Tanakh and/or the Siddur, rarely in conformance to any of the three categories above. Some homiletic explanations were offered for these discrepancies (eg. the first Lubavitcher Rebbe wrote that the 6 dot version represent love and kindness, while the 5 dot version represents fear; alternatively, R Yosef Steiner (Afikei Mayim 1:85) said the 5 dot version represents exile (Tzere like Tzar) and the 6 dot version represents redemption (Segol like Segulah)), but these suggestions aren't based in and don't reflect the traditional grammar.
R Meshullam Roth (Besoret Eliyahu 5) in explaining a passage in the Talmud (BB 21b) suggests that Zekher (6 dots) can be the construct form of Zakhar (male), like how 'Eshen (Exodus 19:18) is the construct form of 'Ashan (smoke). He relies on his read of Ibn Ezra there who claims 'Eshen is essentially an exception which happens occasionally where words borrow other forms' constructions. There are a lot of problems with this. No one ever suggested this as an explanation of that passage before. There is no reason to think Zakhar has exceptions if we've never seen one before. More importantly, 'Eshen is probably not the construct form of 'Ashan, but rather of 'Ashein (cf. Exodus 20:15, Isaiah 7:4), like Yerekh is the construct form of Yareikh (Genesis 32:33), Ketef/Kateif, Geder/Gadeir, etc. Rashbam (Exodus 19:18) notes this and says 'Ashein means "smoky/smokiness[/smog?]" (פומיאה בלע"ז fumes; while we might not appreciate it, furnaces back then were really smoky). There is no evidence of a word Zakheir (male-y (?)) nor would such a word, even in construct state, fit in the context of that passage in the Talmud. Rather, as above, Zekher is not a word.
Answer: Rabbi Soloveitchik was reported to repeat these words in Ashrei as well. This practice is recorded in this online siddur, along with the meaning of each word.

The Rav would repeat the verse, but with the first word read "זֵכֶר",
  instead of "זֶכֶר", much as we do for the same word when reading
  Parashas Zachor. One means "that which reminds you" and the other
  means "a memory". It is unclear which means which, and although the
  Vilna Gaon taught specific meanings for each reading, his students'
  writings conflict as to what his opinion was as well. Notably, Rav
  Chaim Vilozhiner quoted the Gaon as saying that "זֶכֶר" is the one that
  means "a memory", which is the meaning intended here – "They will give
  expression to their memory of Your goodness".
Comment: This explanation fits right in with the third paragraph of my answer: it dates from a time when many were unsure of the proper text, and it isn't based in and doesn't reflect the traditional grammar.
Comment: If you could source this teaching directly to the Gra that would be an improvement.
Comment: Frankly I'm not entirely sure what the difference is between "a memory" and "that which reminds you". Is one like "in my brain there are memories of Simchas Torah as a child" and the other like "Sunkist candies are a reminder to me of Simchas Torah as a child"?
Comment: "Sunkist candies are a reminder to me of Simchas Torah as a child" I think so.


Does usual city pollution have effects on relative humidity?

Question: I've noticed that in a rural area with low pollution the relative humidity is constantly lower than the humidity in a high polluted city. Is there any correlation between pollution and humidity?
Comment: The problem is that I don't have statistical data, so is based on personal observations, that's why I'm asking. Every morning we have a 90-100% relative humidity here (in the city) and decreases to 60-80% later in the day. At my house from a rural area, the relative humidity is constantly lower and sometimes, like past few days, the relative humidity is 65-80% in the morning and decreases to 45% later in the day. Right now for example at 7:30Am, in Bucharest the temperature is 2C and relative humidity 93%. At the country house  (90 km away), the temperature is 0C and 45% relative humidity.
Comment: @GeorgeI.: The country house you mention in your comment, what direction is it from Bucharest and what is its height above sea level? If it is west or at a higher elevation I can understand why there would be lower humidity there than in Bucharest. Also, are there significant areas of forests or large bodies of water near Bucharest? What is the landscape like at both locations and what are the predominant types of vegetation at both locations?
Comment: Welcome to http://earthscience.stackexchange.com/! Could you provide some data examples you have seen?
Comment: @Fred: Both locations are on the same longitude. There is no water or forest near the country house, but in the city there are waters. In suburbs there are forests nearby.
Comment: Too many variables and insufficient observational data involved. Voting to close as 'unclear what you're asking'.
Answer: By way of reference, "humidity depends on water vaporization and condensation, which, in turn, mainly depends on temperature".
From the information you have supplied in your comments. There are waters in Bucharest and forests in the suburbs, but no waters or forests where the country house is located.
From your information, Bucharest has a number of sources of atmospheric water vapour, the river that flows through it (evaporation of water) and the forests in the suburbs (transpiration of water). Additionally, motor vehicle exhausts will increase the humidity as water vapour is one of the products of the combustion of hydrocarbons.
The warmer the air, the greater its capacity to hold moisture. Cities tend to be warmer than rural areas due to the heat island effect, which is the result of modifying land surfaces and the generation of waste heat.
Humidity in the rural location will arise from evaporation of water in the soil and transpiration from crops or grasses. Such transpiration will produce less water vapour than forests. Additionally, the rural location will have significantly fewer cars producing water vapour in their exhausts. Consequently, the rural location will be less humid than the city.
The reason why Bucharest is more humid that the rural location has more to do with the greater availability and vaporization of water in Bucharest and the temperature of Bucharest than the amount of pollution in Bucharest.
Comment: Just perfect. Knowing the two locations, I can say that your answer match the actual situation.
Comment: You didn't emphasize in the writeup, but warmer air = greater capacity... = LOWER relative humidity (at night when the heat island is greatest).  Now, if you've got more moisture sources, then yes, it could lead to higher absolute humidity as well.  But if we're talking about how humid it feels, not sure urban heat island contributions are going to make it feel moister or drier
Answer: Relative humidity, while a nice way to gauge how air might feel (comfort), is a poor measure for comparison between different times during the day.  Of note you observe:

Every morning we have a 90-100% relative humidity here (in the city) and decreases to 60-80% later in the day.

This is merely an effect of the diurnal temperature change.  Relative humidity is the ratio of the actual amount of water vapor in the air compared to the amount of water vapor needed to saturate the air.  The water vapor needed to saturate the air is a function of temperature.  Warm air needs more water vapor to be saturated than cold air.
If you have air with a constant mass of water vapor and vary the temperature between cold (e.g. 7 AM) and warm (e.g. the afternoon) you will have the same pattern of relative humidity you have observed -- very high in the morning and decreasing during the day.  This is a normal pattern and absent of any effects moistening or drying the air you will observe this daily pattern of relative humidity in many places.

Right now for example at 7:30Am, in Bucharest the temperature is 2C and relative humidity 93%. At the country house (90 km away), the temperature is 0C and 45% relative humidity.

Air at 2 C and 93% RH has a vapor pressure around 6.5 hPa and
air at 0 C and 45% RH has a vapor pressure around 2.8 hPa.  This means the air in Bucuresti has a little more than twice the water content of the air from your rural location.  The other answer by Fred gives some good reasons how this can arise.
A few other reasons can be the large scale wind motions and where your rural location happens to be.  Bucuresti can often be in westerly winds where some moistening occurs from flow over the Danube and further moistening within Bucuresti from rivers and lakes.  As Fred noted, urban areas tend to be warmer than rural areas so there is more capacity to hold water vapor (before saturation is reached).
You don't mention where your rural home is, but if it happens to be to the north or north west (e.g. Ploiesti, Pitesti, Buzau) then you have orographic effects from the Carpathian mountains that can dry out the air.  If flow is up and over the mountains then the air is cooled as it flows upslope (on the Transylvanian side) where it becomes cloudy and can precipitate.  This reduces the amount of water vapor in the air and as it flows downslope and warms it remains dryer.  I could give a more specific large scale flow explanation given the location of the rural house.