Blog

STUPID principles | Quick Notes

Recent blog: SOLID vs STUPID

STUPID principles and yes this may hurt your feeling but yes if you are following this you are writing stupid code.

Singleton

Well known design pattern, but mostly understood one as well. Like me, people are also fighting with Singleton syndrome. In that case, whenever we create a class we create it Singleton but why? That is definability not cool. Singleton also considered anti-patterns. We should think and avoid if possible because the program using Singleton are hard to test because of global state, with the global state they hide their dependencies.

Tight Coupling

Avoiding static things is important to avoid tight coupling. If it’s there then making a change in one module requires to changes another module too. Now it’s really difficult to reuse and difficult to test.

Untestability

Testing is not hard, what you think? We don’t write test case may be because we don’t have the time or the code we are writing is bad because of tight coupling?

Premature Optimization

One of my favorite quote from Donald Knuth, premature is the root of all evil. There are only cost and no benefits. Actually optimised code is much complex as compared to just writing a loop.

Indescriptive Naming

That’s what I like most and I try to follow as much as possible. Name of your class, variables or methods should be clear because at the end of the day human is only going to read because programming languages are for human not for computers, computers can understand 0 or 1 very well.

Duplication

That’s bad. Writing same code again and again so don’t repeat yourself, keep it simple and strong. Write Code only once.

Thank you for reading the quick introduction of STUPID principles, next will be SOLID principles.

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.

Signs of wrong architecture? | Quick Notes

Recently I have got one iOS Application codebase to review and it always gives a thought, where to start?

Here are the 3 important first steps for me that I always do.

find . -type f -exec wc -l {} + | sort -n

Execute the terminal command in your project location, it will give you count of number of lines, like mentioned below

3000 ./ViewControllers/DashboardVC.swift
5655 ./AppDelegate.swift

where 3000/5655 is the lines of code.

Second, I track are we using Appdelete directly?

grep -rnw . -e "UIApplication.shared"

Last, but not the least. Swift/Objective-C dependency visualizer. It creates object dependency graphs and gives you the clear picture.

Screen Shot 2017-11-22 at 5.33.12 PM

Thanks for reading. I hope it was quick and informative for you.

Safety In Swift | Fun Time

Let’s say we have a Car and we want it to be safe so we have seatbelts and airbags and we don’t want to let the truck drive unless safety points passed.

Code Sample

enum Safety {
    case seat
    case door
    case airbag
}

struct Car {
    var seatBeltEnabled: Bool
    var doorLocked: Bool
    var airBagsWorking: Bool
}

extension Car   {
    func drive() throws {
        guard seatBeltEnabled else {
            throw Safety.seat
        }

        guard doorLocked else {
            throw Safety.door
        }

        guard airBagsWorking else {
            throw Safety.airbag
        }
        //Everything fine.... drive carefully
    }
}

I hope everything is looking fine so that’s the beauty of Swift otherwise in other approaches we need to manage it with if-else before we start driving.
That’s all about the small beautiful thing I learned today.

iOS Phishing Trick

I would like to add this iOS Phishing tricks that I guess you should know.

Whenever we do compare iOS with other Mobile OS the main point comes up is security (iPhone is more secure/private) but there is a small Phishing technique that can make you fool.

Screen Shot 2017-10-24 at 1.21.33 PM.png

As an iOS Developer, I can make an alert something like this within my iOS Application, because it’s giving you the same look and feel as App Store Alert (Randomly Ask for password). but it’s not from App Store.

This just trail, phishing attacks are illegal please do not use within your apps.

As a user the solution will be, whenever this Alert comes just press the home button, if it closes with the Application it’s fake else it’s correct one.

I hope you like it, please do share your comment.

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.

 

 

 

How to Respond to an Authentication Challenge | iOS

How to Respond to an Authentication Challenge

If a session requires authentication it creates authentication challenge

 URLSession:task:didReceiveChallenge:completionHandler: 

in order for the connection to continue, the delegate has three options.

  • Provide authentication credentials
  • Attempt to continue without credentails
  • Cancel the authentication request.

NSURLProtectionSpace will give all information about the authentication type and failure if any attempts failed earlier.

Providing Credentials

To attempt to authenticate, the application should create an NSURLCredential object with authentication information of the form expected by the server. You can determine the server’s authentication method by calling authenticationMethod on the protection space.

  • HTTP basic authentication (NSURLAuthenticationMethodHTTPBasic) requires a user name and password. P
  • HTTP digest authentication (NSURLAuthenticationMethodHTTPDigest), like basic authentication, requires a user name and password.withcredentialWithUser:password:persistence:.
  • Client certificate authentication (NSURLAuthenticationMethodClientCertificate) requires the system identity and all certificates needed to authenticate with the server. Create an NSURLCredential object.
  • Server trust authentication (NSURLAuthenticationMethodServerTrust) requires a trust provided by the protection space of the authentication challenge.

Continuing Without Credentials

If the delegate chooses not to provide a credential for the authentication challenge, it can attempt to continue without one.

NSURLSessionAuthChallengePerformDefaultHandling processes the request as though the delegate did not provide a delegate method to handle the challenge.

  • NSURLSessionAuthChallengeRejectProtectionSpace rejects the challenge. Depending on the authentication types allowed by the server’s response, the URL loading class may call this delegate method more than once, for additional protection spaces.

Canceling the Connection

The delegate may also choose to cancel the authentication challenge, by passing NSURLSessionAuthChallengeCancelAuthenticationChallenge to the provided completion handler block.