In the previous steps we’ve registered and connected the Auth0 service to the our Postgrest service. In this last and final post we’ll test it using an iOS app. Configuring and creating an iOS app is out of the scope of this tutorial, but nevertheless it’s quite easy to do using the official guide. To make things easier, I’ve created an iOS project where you can add your Auth0 client ID and domain name, and get started.| Home on Sam Khawasé
Postgrest performs authentication and authorization using JWTs.1. JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. We can use a SQL funtion to generate a JWT based on username/password. However many users prefer to use the social logins instead of creating one more account. Authentication brokers like Auth0 provide an easy way to incorporate social logins like Facebook, Goo...| Home on Sam Khawasé
In the previous section we’ve created the database service and bootstraped it with our entities and user roles. Now it’s time to configure the PostgREST service and tie it up with the DB. We’ll start by modifying the docker-compose.yml file and adding the following config under the server section: version: '3' services: db: # PostgreSQL database config server: image: postgrest/postgrest ports: - "3000:3000" links: - db:db environment: PGRST_DB_URI: postgres://authenticator:password@db:5...| Home on Sam Khawasé
Configuring PostgreSQL, and defining the SQL entities There are several ways to install PostgreSQL database, however the easiest way is through docker[^1]. We’ll use a docker-compose file to configure all the aspects of this project. The Docker-compose file will eventually have 3 sections, each representing: PostgreSQL database PostgREST service Swagger OpenAPI service The base docker-compose file looks like this: version: '3' services: db: # PostgreSQL database config server: # PostgREST s...| Home on Sam Khawasé
In Codd, we trust In the field of Computer Science and Engineering, few things come close to the durability and ubiquity of SQL. As web or mobile developers, there’s usually a RESTful API backend that serves JSON responses over HTTP. More often than not, there’s a SQL DB used in these REST API services. However if we look closely, we find that the business logic is in Java/Kotlin/Python layer, whereas the DB is usually just a data store.| Home on Sam Khawasé
With the completion of the modular ViewModel, we can now proceed to put the final piece of the puzzle, the ViewController. In order to do that let’s start with the Single View App project we created in the first post. Here are the things we need to do: Rename the ViewController to AmenityViewController. Add a MapKit Mapview to the Main.storyboard and change it to take all available space. Create an IBOutlet connecting the AmenityViewController to the Storyboard.| Home on Sam Khawasé
In the previous posts, we’ve created the Model, Location, and Networking components, and we’ll use them to design our ViewModel. The ViewModel will need a method to get the current location, and another one to get amenities. Here’s how we can define the protocol for the ViewModel. protocol MapViewModelConfirming { func getCurrentLocation() -> (Double, Double) func getAmenities(in range: Int, type: AmenityType, completion: @escaping CompletionBlock) } We’ll also need a protocol to whic...| Home on Sam Khawasé
In the post about defining our Data class, we took a look at the Overpass Turbo API. We’ll now create a simple networking layer to interact with the API. We’ll use the NSURLSession to keep things simple. The networking layer in our case has 3 parts: API Resource: We will send the Overpass turbo XML query, and the required headers. Response: We receive the JSON output from OSM after the successful completion of network operation.| Home on Sam Khawasé
CoreLocation APIs provide the Location updates in iOS. We need to define a protocol around the CoreLocation features to make it easy to mock, and inject as dependency. Let’s name the protocol as LocationProvidable, which that provides location updates to the ViewModel using the platform API. protocol LocationProvidable { var listener: LocationObservable? { get set } func setListener(listener: LocationObservable) func startLocationUpdates() func getCurrentLocation() -> (Double, Double) } The...| Home on Sam Khawasé
The model defines the way to encapsulate the data we need to show on the View. We'll use OpenStreetMaps API to get the list of amenities in the range. Before we do that, we need to take a quick detour to learn more about Overpass Turbo, our data provider. Overpass Turbo Overpass turbo is a web-based data filtering tool for OpenStreetMap. With overpass turbo we can run Overpass API queries and analyse the resulting OSM data interactively on a map.| Home on Sam Khawasé
Model-View-Controller (MVC)1 is the defacto Apple prescribed approach to create iOS apps. After developing apps for a while, the shortcomings of MVC become obvious, earning them the nickname Massive View Controllers among the developer community. Some of the problems with MVC are: Poor testability: ViewControllers end up doing so many things and it makes testing cumbersome. No well defined way to put networking code in canonical MVC, so ViewControllers end up doing that part.| Home on Sam Khawasé
I design products, fine-tune strategies, build teams, and create rock solid software.| Sam Khawasé
I design products, fine-tune strategies, build teams, and create rock solid software.| Sam Khawasé