inaka

Latest blog entries

/
Erlang and Elixir Factory Lite B.A.

A brief introduction about what was the Erlang Factory Conference in Buenos Aires for some Inaka team members

Jul 07 2017 : Euen Lopez

/
The Art of Writing a Blogpost

The Art of Writing a Blogpost

Apr 11 2017 : Matias Vera

/
SpellingCI: No more spelling mistakes in your markdown flies!

Feb 14 2017 : Felipe Ripoll

/
Fast reverse geocoding with offline-geocoder

Do you need a blazing fast reverse geocoder? Enter offline-geocoder!

Jan 18 2017 : Roberto Romero

/
Using Jayme to connect to the new MongooseIM REST services

MongooseIM has RESTful services!! Here I show how you can use them in an iOS application.

Dec 13 2016 : Sergio Abraham

/
20 Questions, or Maybe a Few More

20 Questions, or Maybe a Few More

Nov 16 2016 : Stephanie Goldner

/
The Power of Meeting People

Because conferences and meetups are not just about the technical stuff.

Nov 01 2016 : Pablo Villar

/
Finding the right partner for your app build

Sharing some light on how it is to partner with us.

Oct 27 2016 : Inaka

/
Just Play my Sound

How to easily play a sound in Android

Oct 25 2016 : Giaquinta Emiliano

/
Opening our Guidelines to the World

We're publishing our work guidelines for the world to see.

Oct 13 2016 : Brujo Benavides

/
Using NIFs: the easy way

Using niffy to simplify working with NIFs on Erlang

Oct 05 2016 : Hernan Rivas Acosta

/
Function Naming In Swift 3

How to write clear function signatures, yet expressive, while following Swift 3 API design guidelines.

Sep 16 2016 : Pablo Villar

/
Jenkins automated tests for Rails

How to automatically trigger rails tests with a Jenkins job

Sep 14 2016 : Demian Sciessere

/
Erlang REST Server Stack

A description of our usual stack for building REST servers in Erlang

Sep 06 2016 : Brujo Benavides

/
Replacing JSON when talking to Erlang

Using Erlang's External Term Format

Aug 17 2016 : Hernan Rivas Acosta

/
Gadget + Lewis = Android Lint CI

Integrating our Android linter with Github's pull requests

Aug 04 2016 : Fernando Ramirez and Euen Lopez

/
Passwordless login with phoenix

Introducing how to implement passwordless login with phoenix framework

Jul 27 2016 : Thiago Borges

/
Beam Olympics

Our newest game to test your Beam Skills

Jul 14 2016 : Brujo Benavides

/
Otec

Three Open Source Projects, one App

Jun 28 2016 : Andrés Gerace

/
CredoCI

Running credo checks for elixir code on your github pull requests

Jun 16 2016 : Alejandro Mataloni

/
See all Inaka's blog posts >>

/
Using Jayme to connect to the new MongooseIM REST services

Sergio Abraham wrote this on December 13, 2016 under ios, mangosta, mongooseim .

If you open the web page of MongooseIM at Erlang Solutions’ readthedoc.io, you can find a new and interesting feature for client developers: a REST-API. It's specially useful for those of you who are not familiar with XMPP since it allows you to send and receive messages just using REST APIs.

At Inaka, we thought that its a great idea and then I’ve created a target for the MongooseIM example application (we call it Mangosta/iOS) just to play with it.

In fact, since we already have a useful REST library for Swift, I wanted to see how good it would be for consuming MongooseIM's API. Turns out, they fit together quite nicely.

For those of you who are not familiar with it, the REST library we are using is Jayme, which uses Swift’s futures to deal the asynchronous operations and their results. It is also fully customizable and very flexible.

A key feature to provide this flexibility in Jayme is that you can configure a protocol containing repository function signatures for your CRUD operations for each storage unit you need, the way you want. See it for instance, here: CRUDRepository

For example, when you want to send a message you need to create an entity, in this case lets call it a 'Message':

import Foundation

struct Message: Identifiable {
    let id: String
    let to: String
    let from: String
    let body: String
    let timestamp: CLong
}

extension Message: DictionaryInitializable,
    DictionaryRepresentable {

    init(dictionary: [String: AnyObject]) throws {
        guard let
        id = dictionary["id"] as? String,
        to = dictionary["to"] as? String,
        body = dictionary["body"] as? String,
        from = dictionary["from"] as? String,
        timestamp = dictionary["timestamp"] as? CLong
        else { throw JaymeError.ParsingError }
        self.id = id
        self.to = to
        self.from = from
        self.body = body
        self.timestamp = timestamp
    }

    var dictionaryValue: [String: AnyObject] {
        return [
        "to": self.to,
        "body": self.body
        ]
    }
}

Of course you can create your own initializer, since most of the time the requests have mandatory and facultative properties, and then you can adapt it to your needs.

After that, the next step is to create your CRUD with the operations you want that entity to support:

class MessageRepository: CRUDRepository {

typealias EntityType = Message
// here you establish your server session.
let backend = NSURLSessionBackend.MongooseREST()

let name = "messages"

func sendMessage(entity: EntityType)
-> Future<Void, JaymeError> {
    let path = self.name
    return self.backend.futureForPath(path, method: .POST, parameters: entity.dictionaryValue)
    .map { _ in return }
}

// As an example, other CRUD functions are possible here:
func getNMessages(limit: NSNumber?,
    before: NSNumber?) -> Future<[EntityType],
    JaymeError> {
        let path = self.name
        var parameters: [String : AnyObject] = [:]
        if let limit = limit {
            parameters["limit"] = limit
        }
        if let before = before {
            parameters["before"] = before
        }
        return self.backend.futureForPath(path,
            method: .GET, parameters: parameters)
            .andThen {
                DataParser().dictionariesFromData($0.0)
            }
            .andThen {
                EntityParser().entitiesFromDictionaries($0)
            }
        }

func getNMessagesWithUser(withJID: String,
limit: NSNumber?, before: NSNumber?)
-> Future<[EntityType], JaymeError> {
    let path = self.name + "/" + withJID
    var parameters: [String : AnyObject]? = nil
    if let limit = limit {
        parameters!["limit"] = limit.integerValue
    }
    if let before = before {
        parameters!["before"] = before.longValue
    }
    return self.backend.futureForPath(path,
        method: .GET, parameters: parameters)
        .andThen {
            DataParser().dictionariesFromData($0.0)
        }
        .andThen {
            EntityParser().entitiesFromDictionaries($0)
        }
    }
}

Finally sending a message is a piece of cake. This is how you do it in your ChatViewController:

let toJID = myfriend@erlang-solutions.com

let message = Message(id: NSUUID().UUIDString,
    to: toJID, from: "", body: thisMessageBody,
    timestamp: NSNotFound)

self.sendMessage(message)

func sendMessage(theMessage: Message) {
    MessageRepository().sendMessage(message).start() {
        result in
        switch result {
            case .Success( _ ):
            // Manage your local archive and UI
            // method to show this message in the
            // chat flow.

            break
            case .Failure(let error):
            print("Error: \(error)")
            break
        }
    }
}

One characteristic that is super cool in this library is the fact that it represents quite well the response you get from the server. For instance, you can get your requested data (including pagination) or you get a special ErrorType, called JaymeError, which contains all the information you need in case your request failed for some reason, or if the response could not be parsed.

Further reading

I would recommend you to look into class NSURLSessionBackend and read function futureForPath(path: String, method: HTTPMethodName, parameters: [String: AnyObject]? = nil) -> Future<(NSData?, PageInfo?), JaymeError> and see the magic of this beauty.

Code on!

S.e.A!