Services

Lets take a closer look at ./app/services/test_service.rb:

Service "hello.world.request", :helloWorld, "hello.world.response"

def helloWorld
	message = params["your_message"]
	{"message"=>message}
end

The Service definition at the top of this file tells the ServiceBroker that the method helloWorld will respond to the message hello.world.request and reply with hello.world.response.

All Appcelerator services need to be in the Services directory, have a filename that ends with _service.rb, and extend Appcelerator::Service.

The Appcelerator service broker scans files matching these criteria on server start and wires your services accordingly. Since this only happens on service start, you must restart every time you create a new service definition. However, if you simple change the code of an existing service, rails, will automatically update the code in development mode.

Just like with Rails controllers, you have full access to your models through ActiveRecord.

Parameters, Returns, and JSON

Appcelerator allows you to access the message payload in the same way you’d access request parameters to a controller, by using the params hash.

Whatever the service method returns becomes the message payload of the response. Appcelerator will automatically serialize basic built-in types (such as arrays and hashes) and ActiveRecord objects. You can return either an object or a hash from the service method. In the former case, the properties of the object will become they keys for the JSON object on the other end.

Rails Controllers

The Appcelerator framework piggy-backs on Rails, which means that all your models, views, and controllers work like usual. Which means that you don’t have to do anything special to use a Rails view dressed-up with Appcelerator, a plain HTML file using Appcelerator, and a plain-old Rails controller in the same project.