Best practices iOS meetup - pmd

Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved.
C2M – Best
Practices
iOS
Presented by:
Suyash Gupta

Copyright © 2016 Talentica Software (I) Pvt Ltd. All rights reserved.Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 2
Agenda
 Design principles in Swift
 Recommended libraries
 Testing
 Continuous Integration
 Localization
 Best practises

Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 3
Design principles in
Swift

Design principles (SOLIDS)
• Single Responsibility Principle
• Open/Closed Principle
• Liskov Substitution Principle : Any child type of a parent
type should be able to stand in for that parent without
things blowing up.
• Interface Segregation Principle: you don't want to force
clients to depend on things they don't actually need.
• Dependency Inversion: entities should depends upon
abstractions rather than upon concrete details.

Single Responsibility Principle
class Handler { // BAD EXAMPLE
func handle() {
let data = requestDataToAPI()
let array = parse(data: data)
saveToDB(array: array)
}
private func requestDataToAPI() -> Data {
// send API request and wait the response
}
private func parse(data: Data) -> [String] {
// parse the data and create the array
}
private func saveToDB(array: [String]) {
// save the array in a database (CoreData/Realm/...)
}
}

Liskov Substitution Principle
protocol Bird {
var altitudeToFly: Double? {get}
func setLocation(longitude: Double , latitude: Double)
mutating func setAltitude(altitude: Double) //WRONG IMPLEMENTATION
}
class Penguin: Bird {
@override func setAltitude(altitude: Double) {
//Altitude can't be set because penguins can't fly
//throw exception
}
} //If an override method does nothing or just throws an exception, then
you’re probably violating the LSP.

protocol Bird {
var altitudeToFly: Double? {get}
func setLocation(longitude: Double , latitude: Double)
}
protocol Flying {
mutating func setAltitude(altitude: Double)
}
protocol FlyingBird: Bird, Flying {
}

struct Owl: FlyingBird {
var altitudeToFly: Double?
mutating func setAltitude(altitude: Double) {
altitudeToFly = altitude
}
func setLocation(longitude: Double, latitude: Double) {
//Set location value
}
}
struct Penguin: Bird {
var altitudeToFly: Double?
func setLocation(longitude: Double, latitude: Double) {
//Set location value
}
}

Dependency Inversion Principle
struct Developer {
func work() {
// ....working
}
}
struct Manager {
let worker: Developer;
init (w: Developer) { //BAD EXAMPLE
worker = w;
}
func manage() {
worker.work();
}
}

//NEW TYPE
struct Tester {
func work() {
//.... working
}
}

protocol IEmployee {
func work()
}
struct Developer: IEmployee {
func work() {
print("Developer working...") // Developer working...
}
}
struct Tester: IEmployee {
func work() {
print("Tester working...") // Tester working...
}
}

struct Management {
let employee: IEmployee;
init (e: IEmployee) {
employee = e;
}
func manage() {
employee.work();
}
}
//Let’s give it a try,
let employee = Developer()
let management = Management(e:employee)
management.manage() // Output - Developer working...
let employer2 = Tester()
let management2 = Management(e:employer2)
management2.manage() // Output - Tester working...

Design principles in Swift
• Whilst analysing the wireframes, look for View
Controllers that have a common theme.
• Spot repeating elements – and make them as a
reusable widget to the project structure.
• Think long term. This is a project you may have to
deal with in 12 months time. Do yourself a favour
and make the right decisions now.

Facade pattern
• Keeps the API’s normalised
• Hides complexity behind a simple method
• Makes it easier to refactor code

Facade pattern Demo
class Engine {
func produceEngine() {
print("prodce engine")
}
}
class Body {
func produceBody() {
print("prodce body")
}
}
class Accessories {
func produceAccessories() {
print("prodce accessories")
}
}

Facade pattern Demo
class FactoryFacade {
let engine = Engine()
let body = Body()
let accessories = Accessories()
func produceCar() {
engine.produceEngine()
body.produceBody()
accessories.produceAccessories()
}
}

Singleton - Good and Bad
• Ask yourself these questions:
• “Does the object need to be referenced by multiple
other objects at the same time e.g. needs to be ‘Thread
safe’ ?“
• “Does the current ‘state’ need to be always up to date
when referenced ?”
• “Is there a risk that if a duplicate object is created, the
calling object might be pointing at the wrong object?”
• If yes to all of these - USE A SINGLETON!

Design Patterns
• More Patterns:
https://github.com/ochococo/Design-Patterns-In-
Swift

Delegate vs Notifications
• Use a delegate pattern if it is only a single object
that cares about the event.
• Use NSNotifications when you need more then one
object to know about the event.
• Remember to use NSNotifications add and remove
callbacks in standard way.

Recommended Libraries

# UI Customization
pod 'PureLayout'
pod 'SnapKit'
pod ‘UIColor_Hex_Swift’ // let fillColor = UIColor("#FFCC00DD").CGColor
# Camera / Photo
pod 'TOCropViewController'
pod 'Fusuma’ // Instagram-like photo browser with camera
# Bug Tracking
pod 'Fabric'
pod 'Crashlytics'

# Analytics
pod 'GoogleAnalytics'
pod 'Appsee'
pod 'FBSDKCoreKit'
pod 'Mixpanel-swift’
# Address Book Data
pod 'APAddressBook/Swift '
pod ' PhoneNumberKit’ // parsing, formatting and validating international phone
numbers
# Network & JSON
pod 'Alamofire’ / pod ‘AFNetworking’
pod ‘SDWebImage'
pod 'SwiftyJSON'

# AB Testing
pod 'Firebase/Core'
pod 'Firebase/DynamicLinks'
pod 'Firebase/Performance'
pod 'GoogleTagManager’
# Debug
pod 'Dotzu’
# Data Storage
pod ‘RealmSwift'
pod ‘KeychainAccess’
#Quality
Pod ‘SwiftLint’

# Permission
Pod ‘Permission/Camera’ // unified API to request permissions
# Common
pod ‘DateTools’
# Billing
pod ‘SwiftyStoreKit’ // In App Purchases framework
# Communication With Customers
pod 'Intercom'
# Rate App
pod 'Armchair’

Testing

Testing
• You should have one XCTestCase file for every
component you test.
• The key to writing good unit tests is understanding
that you need to break your app into smaller pieces
that you can test.
• Do include inverse behaviors, a.k.a. negative test
cases

Testing
• A well-architected set of unit tests should function
as documentation.
• Also make use of code-coverage to evaluate the
part of code left to test.
• Integrate it with CI/CD.

Continuous Integration

CI and CD
• Continuous Integration (CI) is a development practice
that requires developers to integrate code into a shared
repository several times a day. Each check-in is then
verified by an automated build, allowing teams to
detect problems early.
• Continuous Delivery (CD) is a software engineering
approach in which teams produce software in short
cycles, ensuring that the software can be reliably
released at any time. It aims at building, testing, and
releasing software faster and more frequently.

Continuous Integration
• There are a lot of tools available that can help you with
continuous integration of iOS apps like Xcode Server,
Jenkins and Travis CI.
• Why use Continuous Delivery?
– Save days of preparing app submission, uploading
screenshots and releasing the app
– Colleague on vacation and a critical bugfix needs to be
released? Don’t rely on one person releasing updates
– Increase software quality and reaction time with more
frequent and smaller releases

Localization

Localization
• iOS Localization is the process of rendering the
content of your app into multiple languages.
• Users in other countries want to use your app in a
language they understand.
• Using iTunes Connect, you can indicate whether your
app is available in all territories or specific territories.

Localization
DEMO
https://github.com/suyashgupta25/xib-localization

Best Practices

Best Practices - Xcode
• Xcode is the IDE of choice for most iOS developers,
and the only one officially supported by Apple.
There are some alternatives, of which AppCode is
arguably the most famous, but unless you're
already a seasoned iOS person, go with Xcode.
Despite its shortcomings, it's actually quite usable
nowadays!
• To install, simply download Xcode on the Mac App
Store.

• CoreData: Contains DataModel and Entity Classes.
• Extension: extensions+project class extensions
• Helper: Contain Third Party classes/Frameworks + Bridging
classes (eg. Obj C class in Swift based project)
• Model: The Web Service Response parsing and storing data
is also done here.
• Services: Contain Web Service processes (eg. Login
Verification, HTTP Request/Response)
• View: Contain storyboard, LaunchScreen.xib and View
Classes. Make a sub folder Cells - contain UITableViewCell,
UICollectionViewCell etc.
• Controller: Contain ViewControllers

CocoaPods : it's a standard package manager for iOS
projects.
# It'll eat up 1,5gigs of space (the master repository under
~/.cocoapods), it creates unnecessary things too.
# It's the worst option, but it's the most popular one

Best Practices - AGILE
• Create ‘user stories’ from the specification
• Be Data driven - Gut feeling will only get you so
far!!!!!
• Be user driven - What do your users want ?
• Be Involved - Don’t be shy, have an opinion, use
your knowledge to advance the idea. Spot flaws
NOW, not 1 month down the line. You will save
yourself time, money and a lot of headaches.
• Iterate - Check, Do, Check, Change

Best Practices
• D.R.Y - Dont Repeat Yourself
– Don’t write lengthy methods, divide logic into
smaller reusable pieces.
– It will become a natural part of your refactoring
– Don’t do magic to achieve D.R.Y
• Unit Testing
– Try and add unit tests from the beginning of a
project. Retrofitting unit tests can be painful .
– Great UITesting tools in Xcode.

Best Practices
Comments + Verbose method names
• COMMENT YOUR CODE - NO EXCUSES.
• Saves 1000’s of man hours.
• Is just common courtesy.
• Name of method should explain what it does
• Add a comment in the .h advising what the
class does.

Best Practices
• Prototype
– Great to show stakeholders (Storyboards designed
for it)
– Can trust implementation without the ‘noise’ of
existing code
– Can help spot issues earlier.
• Do pair programming - Make it 20% of your weekly
schedule

Best Practices
• Keep your project organized Git - Commit little and
often
– Don’t be an ‘end of the day’ committer
– Get into the habit even when working solo
– Commit should reflect what was actually done.

HAPPY CODING!!

Demo Repository
https://github.com/suyashgupta25/xib-localization

Best practices iOS meetup - pmd

More Related Content

Similar to Best practices iOS meetup - pmd (20)

Recently uploaded (20)

Best practices iOS meetup - pmd

Editor's Notes