SOLID principle with Swift | STUPID

SOLID principle is an acronym created by Robert C Martin also unknown as Uncle Bob. It represents five principles for OOPS.

Single responsibility
Open/Closed
Liskov Substitution
Interface Segregation
Dependency Inversion

Now the first thought that came to my mind is Why do we need this? Here is the answer, using these principles we can solve the problems of a bad architecture.

Fragility where A small change may break complete module it’s really very difficult to find this if you don’t have good test cases.

Immobility where A component is very hard to reuse in another project or we can say multiple places in the same project because of too many dependencies.

Rigidity where Single change requires lots of developer efforts because it affects several parts of the project.

Here I want to add principles will not turn a bad programmer into a good programmer you need a better judgment there. Principles have to apply with judgment and you must be smart enough to understand when to apply what.

I have also written one blog where they have mentioned one more acronym like SOLID and it’s STUPID. This may hurt your feeling but yes if you are following this you are writing stupid code.

Singleton
Tight Coupling
Untestability
Premature Optimization
Indescriptive Naming
Duplication

Thank you for reading the quick introduction, In next blogs, I will try to define all principles with Swift Code.

App Secure | URLSession | Authentication Challenge | NTLM | Security | Credentails

Yesterday, I have posted about How to response Authentication Challange but thoughts came in mind that if you are going with the first options Provide authentication credentials is it really secure and safe? how is client sharing the credentials with the server?

After lots of Google, I have found, how’s NTLM works and it’s pretty interesting to see that client don’t share the password with the server. here are the steps as follow.

Screen Shot 2017-10-12 at 1.06.51 PM.png

  1. The client makes the request to the server.
  2. The server needs to validate the user because there is no identity so server generates 16 bytes random number called as the challenge and sends it to the client.
  3. Client hash this challenge with the user’s password and return it back to the server that is called the response it also includes username as plain text and challenge sent to the client.
  4. The server sends everything to the domain controller and it uses the username to retrieve the hash of the user’s password from security account manager database and hash the challenge.
  5. Domain controller shares the response back to the server if they are identical then authentication is successful otherwise a failure.

So the interesting part is here that Network API doesn’t share the password with the server it means it very secure.

Thank you for reading.

Share your thoughts and feeback.

 

 

 

Top 10 reasons for iOS app rejection ?

Today apps are changing the world. The App Store has grown into an exciting and vibrant ecosystem for millions of developers. Whether you are a first-time developer or a large team of experienced programmers, we are excited that you are creating apps for the App Store and want to help you understand our guidelines so you can be confident your app will get through the review process quickly.

Here are top 10 reasons for app rejections from Apple.

16% Guideline 2.1 – Performance: App Completeness

14% More Information Needed

9% Guideline 4.1 – Design: Copycats

8% Guideline 2.3.7 – Performance: Accurate Metadata

4% Guideline 3.1.1 – Business: In-App Purchase

4% Guideline 2.3.3 – Performance: Accurate Metadata

3% Guideline 4.0 – Design: Spam

3% Guideline 4.0 – Design

3% Guideline 2.3.3 – Performance: Accurate Metadata

3% Did Not Comply with Program License Agreement

Failable Numeric Conversion Initializers | Swift 3.1

Swift 3.1 implements failable initializers for all numeric types like Int, Int8, Int16, Int32, UInt, UInt8, UInt16, UInt32, Float, Float80, Double. So which either completely successful without loss of information or simply returns nil.

This feature is very useful let’s see an example.

typealias JSONDictionary = [String: AnyObject]
class Employee  {
    let name: String
    let level: Double
    init?(json: JSONDictionary) {
       guard   let name = json["name"] as? String,
           let levelString = json["level"] as? String,
            let levelDouble = Double(levelString),
            let level = Int(exactly: levelDouble)  // 3.1 feature here
            else {
                return nil
        }
        self.name = name
        self.level = level
    }
}

func getEmployees(from data: Data) -> [Employee]?   {
    guard let json = try? JSONSerialization.jsonObject(with: data, options: .allowFragments),
        let jsonArray = json as? [JSONDictionary]   else {
            return nil
    }

    return jsonArray.flatMap(Employee.init)
}

let jsonString = "[{\"name\":\"John\", \"level\":\"7.2\"}]"
if let data = jsonString.data(using: .utf8) {
    let employees = getEmployees(from: data)
    print(employees ?? "its Nil")
} else {
    print("Data Nil")
}

@IBInspectable & @IBDesignable

IBInspectable – provided new ways to old features like user defined runtime attribute are powerful way to configuring any Key-value coded property of an instance XIB. But its really hard to manage and if you have multiple views with same or may be different properties.

for example, these properties in UIView subclass update the backing layer with their values.

@IBInspectable var corberRadius : CGFloat = 0 {
        didSet {
            layer.cornerRadius = corberRadius
            layer.masksToBounds = corberRadius > 0
        }
    }

IBDesignable lets interface builder know it should render the view directly in the canvas. This will allow you to see how’s your view will appear without even building the application.

@IBDesignable
class BaseView: UIView {
    @IBInspectable var corberRadius : CGFloat = 0 {
        didSet {
            layer.cornerRadius = corberRadius
            layer.masksToBounds = corberRadius > 0
        }
    }
}

Moreover any problems can be debugged without even compelling and running the whole project, how ? Just choose, Editor and Debug selected views.

whenever we are compiling the code prepareForInterfaceBuilder and there we can make required check either the target is interface builder or else.

nullable ? Swift – Objective C

Did you ever think? what will happen if your Objective C function will return nil to Swift function? because there is optional in Swift for managing nil values but in Objective C nothing.

//Objective-C code 
#import <Foundation/Foundation.h> 
@interface ObjCHello : NSObject 
-(NSArray * )getValue; 
@end  

//Swift code 
let objc = ObjCHello() 
print(objc.getValue()) 

//Objective-C 
#import <Foundation/Foundation.h> 
@interface ObjCHello : NSObject 
-(NSArray * _Nullable)getValue; 
@end

Now it will return value [Any]? and it won’t crash so just go for optional chaining.

MVC vs MVVM

Ever heard of MVC?

Yes, its massive view controller 🙂 some call it and its true, because a lot of logic get placed in the view controller only. so today we are trying to convert it into MVVM, yes its Model-View-ViewModel.

first of all here is typical setup of MVC.

MVC.png

Model represent data, views represent user interface and view controller mediate the interaction between two of them.

So there thing about that view and view controller are typically distinct components and they almost go together – tightly coupled. but a view could be paired with different view controllers or vice-versa. so why not formalise their connection.

MVC1.png

There are few things that we only need in view controller like presentation logic.  so make it more clear lets add it into flow.

MVVM.png

i know its looking much better now. its an argumented version of MVC where we move presentation logic out of the controller into a new object – the view model. The motivation behind that is reduce the complexity of view controller.