Tuesday, June 30, 2015

Use Tuple types to model data

To use sqlite.swift with Swift 2, see the Create a Data Access Layer with SQLite.Swift and Swift 2 post.

A couple of weeks back I wrote a blog post on how to create a data access layer using SQLite.swift.  You can see the post here.  In one of the projects that I am currently working on, I wanted to create the data access layer as I described in that post because I know how well it worked from previous projects.  For this particular project however there are several tables that only have a couple of columns which means I needed to create a number of classes in the data model layer that contained only a few of properties. 

It seemed like a waste to create all those classes which only had a couple of properties so I started wondering if I could use tuples instead of classes to model my data.  I was unsure how modeling data with tuples would work but I decided to give it a try.  I found out that they really worked well. 

In this post I will explain how we could use tuples to model our data and then I will show how I would replace the data model classes from my previous post with tuples.  If you have not read my previous post about creating a data access layer with SQLite.swift, you can read it here.

What are tuple types

A Tuple type groups zero or more values into a single compound type.  Tuples can contain values of different types which allows us to group related data of different types together.  There are many uses for tuples and one of the most common is to use them as a return type from a function when we need to return multiple values.  The Void return type is actually a typealias for a tuple with no values.

Using tuple types to model our data

When I say that I want to model our data what I am referring to is grouping related data together is a single structure.  As an example if I want to create a class name PersonClass to model the information for a person the class may look like this:

class PersonClass {
    var firstName: String
    var lastName: String
    var age: Int
   
    init(firstName: String, lastName: String, age: Int) {
        self.firstName = firstName
        self.lastName = lastName
        self.age = age
    }
}

In this class we define three properties for our person and we also create an initializer that will set these properties.  This is quite a bit of code to simply store data.  If we wanted to create a typealias for a tuple named PersonTuple which models the same data, it would look like this:

typealias PersonTuple = (firstName: String, lastName: String, age: Int)

As we can see it takes a lot less code to create our PersonTuple tuple as compared to the PersonClass class.  Creating an instance of the PersonClass class is very similar to creating a PersonTuple variable.  The following code demonstrates this:

var pClass = PersonClass(firstName: "Jon", lastName: "Hoffman", age: 46)
var pTuple: PersonTuple = (firstName:"Jon", lastName:"Hoffman", age: 46)

We could actually shorten the tuple definition as shown in the following code but I prefer naming the parameters to show what they mean (really personal preference).

var pTuple: PersonTuple = ("Jon", "Hoffman", 46)

We can pass tuple types within our code just like we would pass an instance of a class or structure.  In the following code we show how to write a function that accepts an instance of the PersonClass as the only parameter and a function that accepts a PersonTuple as the only parameter.

func acceptPersonClass(person: PersonClass) {
    println("\(person.firstName) \(person.lastName)")
}
func acceptPersonTuple(person: PersonTuple) {
    println("\(person.firstName) \(person.lastName)")
}

When we replace data modeling classes or structures with tuples our code can become much more compact and in some ways easier to understand however we do lose the ability to add functionality to our data model types.  Some, including myself, would argue that losing the ability to add functions to our data model types is a good thing because if we truly want to separate our data model from our business logic we should not be embedding business logic in our data model classes.

Replacing data modeling classes with tuples

Tuples weren’t meant to be used as replacements for classes or structures however if we create a typealias of a tuple type it can very easily be used to model our data. In the Create a Data Access Layer using SQLite.swift post we had two classes in our data model layer:  Team.swift and Player.swift.  The code for these two classes is shown below:

Team.swift
import Foundation

class Team {
   
    var teamId: Int64?
    var city: String?
    var nickName: String?
    var abbreviation: String?
   
    init(teamId: Int64, city: String, nickName: String, abbreviation: String) {
       
        self.teamId = teamId
        self.city = city
        self.nickName = nickName
        self.abbreviation = abbreviation
    }
}

Player.swift
import Foundation

class Player {
   
    var playerId: Int64?
    var firstName: String?
    var lastName: String?
    var number: Int?
    var teamId: Int64?
    var position: Positions?
   
    init (playerId: Int64, firstName: String, lastName: String, number: Int, teamId: Int64, position: Positions?) {
        self.playerId = playerId
        self.firstName = firstName
        self.lastName = lastName
        self.number = number
        self.teamId = teamId
        self.position = position
    }
}

Now to replace these to classes with tuples, all I really need to do is to create typealiases instead.  For this I crate a DataModel.swift class that contains the following code:

typealias Team = (teamId: Int64?, city: String?, nickName: String?, abbreviation: String?)

typealias Player = (playerId: Int64?, firstName: String?, lastName: String?, number: Int?, teamId: Int64?, position: Positions?)

I then deleted the Team and Player classes and was able to build/run the project as it was before.  We could additionally remove the typealias names from the find() and findAll() methods of the data helper classes.  As an example, the findAll() method from the PlayerDataHelper class looks like this:

static func findAll() -> [T]? {
        var retArray = [T]()
        for item in table {
            retArray.append(Player(playerId: item[playerId], firstName: item[firstName], lastName: item[lastName], number: item[number], teamId: item[teamId], position: Positions(rawValue: item[position])))
        }
        return retArray
    }
We could change this function to this:

static func findAll() -> [T]? {
        var retArray = [T]()
        for item in table {
            retArray.append((playerId: item[playerId], firstName: item[firstName], lastName: item[lastName], number: item[number], teamId: item[teamId], position: Positions(rawValue: item[position])))
        }
        return retArray
    }

However I think the code reads better if we keep the typealias name in the code.

I created a github site which contains the sample project for the “Create a data access layer using SQLite.swift with the changes made in this post.  The repository is located here (https://github.com/hoffmanjon/SQLiteDataAccessLayer).  I would like to know what others think of using tuples to model data.  Please leave comments below.

If you would like to learn more about Swift, you can check out my book on amazon.com or on packtpub.com.


Saturday, June 27, 2015

Mastering Swift

Mastering Swift, the book I wrote on the Swift programming language, is about to be released by Packt Publishing.  The official release date is Tuesday June 30st, 2015.  You can order it from Packt’s site or from Amazon.  

I have always thought that you cannot master a programming language without a good understanding of the basics.  With that philosophy in mind this book starts with the basics of the Swift language before moving into more advance features and concepts.   With this structure, Mastering Swift will appeal to developers that are new to the Swift language because we cover the basics of the language and assume no prior knowledge of Swift.  Mastering Swift will also appeal to the experience developer because over half the books is spent on advance topics and concepts that are design to help the reader master the Swift programming language.

The fist five chapters will introduce the Swift programming language and will give the reader a good understanding of the Swift programming language.  the second half of the book will cover more advance topics such as concurrency, network development, design patterns and memory management including strong reference cycles.

This book takes a very code-centric approach to teaching the Swift programming language.   What this means is every feature and concept discussed in the book is backed by example code that is designed to demonstrate and reinforce the concept covered.  Details on how to download the sample code can be found in the preface of the book.


Below shows what is covered in each chapter:

Chapter 1, Taking our first steps with Swift, introduces the reader to the Swift programming language and will discuss what inspired Apple to create Swift. We will also go over the basic syntax of Swift.   We will also cover how to use Playgrounds to experiment and test Swift code.
Chapter 2, Learning Variables, Constants, Strings, and Operators, explains to the reader about variables and constants in Swift and how to use each of them. There will be brief overviews of the most common variable types with examples on how to use them. We will conclude this chapter by covering the most common operators in the Swift language.
Chapter 3, Using Collections and Cocoa Data Types, introduces Swift's Array and Dictionary collection types with examples on how to use them. We will also show how to use Cocoa and Foundation data types with Swift.
Chapter 4, Learning about Control Flow and Functions, explains how to use Swift's control flow statements. These include looping, conditional, and control transfer statements. The second half of the chapter is all about functions and how to use them.
Chapter 5, Understanding Classes and Structures, explains Swift's classes and structures in detail. We will look at what make them similar and what makes them different. We will also look at access controls and object-oriented design. We will conclude this chapter by looking at memory management in Swift.
Chapter 6, Working with XML and JSON Data, starts off by discussing what XML and JSON data are and their uses. We will then show several examples of how to parse and build XML and JSON data using Apple's frameworks.
Chapter 7, Custom Subscripting, examines what subscripts are and how we can add custom subscripts in our classes, structures, and enumerations.  We will look at the proper way to use subscripts and also when not to use subscripts.
Chapter 8, Using Optional Types and Optional Chaining, looks at what optional types really are, various ways to unwrap them, and optional chaining.  We do introduce the Optional type in earlier chapters but this chapter is designed to give the reader a complete understanding of them.  
Chapter 9, Working with Generics, allows us to write very flexible and reusable code that avoids duplication. In this chapter, we will examine how Swift implements generics. We will also examine the proper ways to use generics and examples of how not to use generics.
Chapter 10, Working with Closures, examines how to define and use closures in our code. We will conclude this chapter with a section on how to avoid strong reference cycles with closures.
Chapter 11, Using Mix and Match, examines how to include Swift code in our Objective-C projects and Objective-C code in our Swift projects.
Chapter 12, Concurrency and Parallelism in Swift, starts off by discussing the difference between concurrency and parallelism.  We then shows how to use both Grand Central Dispatch (GCD) and Operation Queues to add concurrency and parallelism to our applications.
Chapter 13, A Swift Formatting Style Guide, defines a style guide for the Swift language that can be a template for enterprise developers that need to create a style guide.
Chapter 14, Network development with Swift, looks at the Apple API's to connect to remote severs and how to best use them.  We also examine the RSNetworking framework on how to use it in our projects
Chapter 15, Adopting Design Patterns in Swift, looks at what design patterns are and why we should use them.  We also examine how to implement some of the more common design patterns in Swift.  

I would like to thank everyone at Packt Publishing who helped with this book.  Without their help and commitment to this book it would not have turned out so awesome and believe me I really think it turned out awesome.  So if you are new to the Swift programming language or an experience developer that is looking to take their skills to the next level, Mastering Swift may be just the book for you.  Once you have checked out the book, please continue to come back to this blog as I expand and enhance on the material in the book.    




Friday, June 5, 2015

Create a Data Access Layer with SQLite.swift

To use sqlite.swift with Swift 2, see the Create a Data Access Layer with SQLite.Swift and Swift 2 post.

SQLite is an open source, lightweight and cross platform relational database however it does require good knowledge of SQL to use.  For me that is not much of a problem however it is always better if we can avoid embedding SQL statements in our source code.  This is where frameworks like SQLite.swift come in.  SQLite.swift is a type-safe, Swift language layer over SQLite3 that allows us to access an SQLite database in a pure Swift type interface. 
It is important, when designing an application, to design a good data access layer between our application and its backend data storage.  While some may argue that is what Core Data is for, I am just not a big fan of it especially if we are planning on porting our applications to other platforms.  In this blog post, I will show how we can use the SQLite.swift framework to design a good data access layer for our applications written in Swift.
We can download sqlite.swift from it’s githubrepository.  There are good instructions on how to install it either though CocoaPods or manually in our applications here.  Once we have sqlite.swift setup within our application we will be ready to design our data access layer.
In this blog post, we will mainly be discussing how to design the data access layer.  We will back up our design with working example code but the focus of the post will be on the design and the code is there to reinforce that design.

Data Access Layer Introduction


Our data access layer will consist of three layers.  The bottom most, connection, layer will consist of one class named SQLiteDataStore which will contain the connection handle for our SQLite database.  This class will implement the singleton pattern so all access to the database will go though one connection handle.
The next layer will be a data helper layer that will contain one class for each of our tables.  These data helper classes will contain methods to create, insert, delete and query a specific table.  We will want to create a protocol for the data helper classes to ensure that they contain a minimum set of functionality like creating the table.
The final layer is the model layer.  This layer will contain classes that model our database tables and will be used to write or retrieve data from the data store.
In our example, we will have two tables.  These are the Teams and the Players table.  From our description above, we can probably guess that this means we will need two data helper classes (TeamDataHelper and PlayerDataHelper) and two model classes (Team and Player).  The classes required for our data access layer will look like this:



Connection Layer


Now lets look at the code.  We will begin with the SQLiteDataStore class that will contain the connection handle for our database.  The SQLiteDataStore class will contain the following code:

import Foundation
import SQLite

class SQLiteDataStore {
    static let sharedInstance = SQLiteDataStore()
    let BBDB: Database
   
    private init() {
       
        var path = "BaseballDB.sqlite"
       
        if let dirs : [String] = NSSearchPathForDirectoriesInDomains(NSSearchPathDirectory.DocumentDirectory, NSSearchPathDomainMask.AllDomainsMask, true) as? [String] {
            let dir = dirs[0]
            path = dir.stringByAppendingPathComponent("BaseballDB.sqlite");
            println(path)
        }
       
        BBDB = Database(path)
    }
   
    func createTables() {
        TeamDataHelper.createTable()
        PlayerDataHelper.createTable()
       
    }
}

The SQLiteDataStore class implements the singleton pattern so there is only one instance of the class for the lifecycle of our application.  We implement this pattern by creating a private initiator which is accessed from a static constant named sharedInstance.  Inside the initiator, we set the path to the file that will contain our database and then create the BBDB Database instance with that path.
The SQLiteDataStore class contains a second method named createTables.  The createTables method calls the createTable methods from our data helper classes.  This method will let us create all of the tables from a single method.

Model Layer


Now lets look at the model layer.  The classes in the model layer will mirror the tables in the data store so we can use them to read from or write to the data store.  In our example we will have two classes in the model layer, these are the Player and Team classes.  We will look at the Team class first:

class Team {
   
    var teamId: Int64?
    var city: String?
    var nickName: String?
    var abbreviation: String?
   
    init(teamId: Int64, city: String, nickName: String, abbreviation: String) {
        
        self.teamId = teamId
        self.city = city
        self.nickName = nickName
        self.abbreviation = abbreviation
    }
}

The Team class contains four properties and an init method that will set the properties.  The teamId property is designed to be the unique identifier for the table while the rest of the properties are information about the team.
Now lets see the Player class:

class Player {
   
    var playerId: Int64?
    var firstName: String?
    var lastName: String?
    var number: Int?
    var teamId: Int64?
    var position: Positions?
   
    init (playerId: Int64, firstName: String, lastName: String, number: Int, teamId: Int64, position: Positions?) {
        self.playerId = playerId
        self.firstName = firstName
        self.lastName = lastName
        self.number = number
        self.teamId = teamId
        self.position = position
    }
}

The Player class has five properties and an init method that will set the properties.    The playerId property is designed to be the unique identifier for the table while the rest of the properties will be information about the player.  The final property named position is of the type Positions.  The Positions type is an enum that looks like this.

enum Positions: String {
    case Pitcher = "Pitcher"
    case Catcher = "Catcher"
    case FirstBase = "First Base"
    case SecondBase = "Second Base"
    case ThirdBase = "Third Base"
    case Shortstop = "Shortstop"
    case LeftField = "Left Field"
    case CenterField = "Center Field"
    case RightField = "Right field"
    case DesignatedHitter = "Designated Hitter"
}

This enum is used to define the position that a player plays.

Data Helper Layer


Now lets look at the data helper layer.  This layer will be the bridge to our connection layer and will contain one data helper class per table in our database.  We will begin by creating a data helper protocol that will define the set of methods that each data helper class needs to implement.  The DataHelperProtocol protocol looks like this:

protocol DataHelperProtocol {
    typealias T
    static func createTable() -> Void
    static func insert(item: T) -> Int64
    static func delete(item: T) -> Void
    static func findAll() -> [T]?
}

Within this protocol the four methods that we are defining are:    
createTable:  Creates the table
insert:  insets a row into the table
delete:  deletes a row from the table
findAll:  returns all rows in the table

Notice that we only define one method to query our data stores.  We do this because the methods to query each individual table could be different therefore the method(s) needed to query the tables could be different.  We would need to evaluate the query methods needed for each table on a table by table basis.
Now lets look at the TeamDataHelper class that will confirm to the DataHelperProtocol.  This class will be used to read and write information to the Teams table of the SQLite data store.

import Foundation
import SQLite

class TeamDataHelper: DataHelperProtocol {
    static let TABLE_NAME = "Teams"
   
    static let teamId = Expression<Int64>("teamid")
    static let city = Expression<String>("city")
    static let nickName = Expression<String>("nickname")
    static let abbreviation = Expression<String>("abbreviation")
   
    static let table = SQLiteDataStore.sharedInstance.BBDB[TABLE_NAME]
   
    typealias T = Team
   
    static func createTable() {
        let results = SQLiteDataStore.sharedInstance.BBDB.create(table: table, ifNotExists: true) { t in
            t.column(teamId, primaryKey: true)
            t.column(city)
            t.column(nickName)
            t.column(abbreviation)
        }
    }
   
    static func insert(item: T) -> Int64 {
        if (item.city != nil && item.nickName != nil && item.abbreviation != nil) {
            if let results = table.insert(city <- item.city!, nickName <- item.nickName!, abbreviation <- item.abbreviation!).rowid {
                return results
            }
        }
        return -1

    }
   
    static func delete (item: T) -> Void {
        if let id = item.teamId {
            let query = table.filter(teamId == id)
            query.delete()
        }
    }
   
    static func find(id: Int64) -> T? {
        let query = table.filter(teamId == id)
        var results: T?
        if let item = query.first {
            results = Team(teamId: item[teamId], city: item[city], nickName: item[nickName], abbreviation: item[abbreviation])
        }
        return results
    }
   
    static func findAll() -> [T]? {
        var retArray = [T]()
        for item in table {
            retArray.append(Team(teamId: item[teamId], city: item[city], nickName: item[nickName], abbreviation: item[abbreviation]))
        }
        return retArray
    }
}

We start the TeamDataHelper class by setting the TABLE_NAME property.  This property defines the name for the table within our database.  The next four properties (teamId, city, nickname and abbreviation) define the name and type of each row in the table.  We then set the table property which will be used to access the Team table within the SQLite data store.
Finally we implement each of the four methods defined in the DataHelperProtocol protocol plus one extra method which will search the table by its unique identifier.
The PlayerDataHelper class is similar to the TeamDataHelper class except it is used to read and write to the Players table of the SQLite data store.  The PlayerDataHelper class looks like this:

import Foundation
import SQLite

class PlayerDataHelper: DataHelperProtocol {
    static let TABLE_NAME = "Players"
   
    static let playerId = Expression<Int64>("playerid")
    static let firstName = Expression<String>("firstName")
    static let lastName = Expression<String>("lastName")
    static let number = Expression<Int>("number")
    static let teamId = Expression<Int64>("teamid")
    static let position = Expression<String>("position")

   
    static let table = SQLiteDataStore.sharedInstance.BBDB[TABLE_NAME]
   
    typealias T = Player
   
    static func createTable() {
        let results = SQLiteDataStore.sharedInstance.BBDB.create(table: table, ifNotExists: true) { t in
            t.column(playerId, primaryKey: true)
            t.column(firstName)
            t.column(lastName)
            t.column(number)
            t.column(teamId)
            t.column(position)
       
        }
    }
   
    static func insert(item: T) -> Int64 {
        if (item.firstName != nil && item.lastName != nil && item.teamId != nil && item.position != nil) {
            if let results = table.insert(firstName <- item.firstName!, number <- item.number!, lastName <- item.lastName!, teamId <- item.teamId!, position <- item.position!.rawValue).rowid {
                return results
            }
        }
        return -1
       
    }
   
    static func delete (item: T) -> Void {
        if let id = item.playerId {
            let query = table.filter(playerId == id)
            query.delete()
        }
    }
   
    static func find(id: Int64) -> T? {
        let query = table.filter(playerId == id)
        var results: T?
        if let item = query.first {
            results = Player(playerId: item[playerId], firstName: item[firstName], lastName: item[lastName], number: item[number], teamId: item[teamId], position: Positions(rawValue: item[position]))
        }
        return results
    }
   
    static func findAll() -> [T]? {
        var retArray = [T]()
        for item in table {
            retArray.append(Player(playerId: item[playerId], firstName: item[firstName], lastName: item[lastName], number: item[number], teamId: item[teamId], position: Positions(rawValue: item[position])))
        }
        return retArray
    }
}

We start the PlayerDataHelper class by setting the TABLE_NAME property.  This property defines the name for the table within our database.  The next six properties (playerId, firstName, lastName,  number, teamId and position) define the name and type of each row in the table.  We then set the table property that will be used to access the Player table within the SQLite data store.
Within these data helper classes we can implement any other query methods that are needed for our application. 

Using the Data Access Layer


Now lets see how we would use this data access layer to read and write information to the data store.  To insert a row into a table, all we need to do is to create an instance of the appropriate model class (Player or Team) and then pass it to the appropriate data helper class (PlayerDataHelper or TeamDataHelper).  As an example, here is how we would create four rows in the Teams table:

let bosId = TeamDataHelper.insert(Team(teamId: 0, city: "Boston", nickName: "Red Sox", abbreviation: "BOS"))

let baltId = TeamDataHelper.insert(Team(teamId: 0, city: "Baltimore", nickName: "Orioles", abbreviation: "BAL"))

let tampId = TeamDataHelper.insert(Team(teamId: 0, city: "Tampa Bay", nickName: "Rays", abbreviation: "TB"))

let torId = TeamDataHelper.insert(Team(teamId: 0, city: "Toronto", nickName: "Blue Jays", abbreviation: "TOR"))

Here is how we would create three rows in the Players table:

let ortizId = PlayerDataHelper.insert(Player(playerId: 0, firstName: "David", lastName: "Ortiz", number: 34, teamId: bosId, position: Positions.DesignatedHitter))

let napId = PlayerDataHelper.insert(Player(playerId: 0, firstName: "Mike", lastName: "Napoli", number: 12, teamId: bosId, position: Positions.FirstBase))

let pedId = PlayerDataHelper.insert(Player(playerId: 0, firstName: "Dustin", lastName: "Pedroia", number: 15, teamId: bosId, position: Positions.SecondBase))

To query the database we would call the appropriate method with the data helper class.  The following code would return a list of all teams in the Teams table and prints out the city and nickname for each team.

if let teams = TeamDataHelper.findAll() {
    for team in teams {
        println("\(team.city!) \(team.nickName!)")
    }
}

Conclusion

In this blog post we showed how we could use sqlite.swift and good development practices to create a data access layer that simplifies access to the data and hides the complexity of the underlying data store.  The example shown gives us a good abstraction layer that separates the backend data store from our main application. 
The one thing that our example is missing is a way to query the tables by different elements of the table.  For example, we do not have a way to query all players by team or position.  There are a number of ways that we could implement these queries depending on the complexity needed.  We could create a method for each type of query needed if there are not too many or we could create a single method that will query by each element set in the model object.  How you implement these queries is up to you and really depends on the complexity needed in your application.

In this post I describe how to create a data access layer with SQLite.swift.  In my new book titled Protocol Oriented Programming with Swift I show not only how to create this data access layer with SQLite.swift and Swift 2 but I also show how to use the Bridge pattern to integrate this layer with your application.  You can also read about Protocol-Oriented programming in my POP and OOP blog post.