Friday, 12 June 2015

IOS:Apple Pay Integration



 Apple Pay (Apple payment gateway integration)

Apple Pay is a mobile payment technology that lets users give you their payment information for real-world goods and services in a way that is both convenient and secure.Here some step (what would be need to Apple Pay integration) are mention above steps to integrate Apple Pay in your app. 



Step 1 - Configuring Your Environment

A merchant ID identifies you to Apple Pay as being able to accept payments. The public key and certificate associated with your merchant ID is used as part of the payment process to encrypt payment information. Before your app can use Apple Pay, you need to register a merchant ID and configure its certificate.

- To register a merchant ID

In Member Center, select Certificates,Identifiers & Profiles. 
Under Identifiers, select Merchant IDs
Click the Add button (+) in the upper-right corner.
Enter a description and identifier, and click Continue.
Review the settings, and click Register.
Click Done.

-To configure a certificate for your merchant ID

In Member Center, select Certificates,Identifiers & Profiles.
Under Identifiers, select Merchant IDs
Select the merchant ID from the list, and click Edit.
Click Create Certificate, follow the instructions to obtain or generate your certificate signing request (CSR), and click Continue.
Click Choose File, select your CSR, and click Generate.
Download the certificate by clicking Download, and click Done.

If you see a warning in Keychain Access that the certificate was signed by an unknown authority or that it has an invalid issuer, make sure you have the WWDR intermediate certificate - G2 and the Apple Root CA - G2 installed in your keychain. 

To enable Apple Pay for your app in Xcode, open the Capabilities pane. Select the switch in the Apple Pay row, and then select the merchant IDs you want the app to use.




Step 2 - Setting Up

Apple Pay uses the PassKit framework, so you’ll need to be sure to include this in your project and import it into the necessary files.

#import <PassKit/PassKit.h>

You’ll also want to receive callbacks when Apple Pay processes information, so be sure to add the delegate to the receiving class:

@interface ViewController : UIViewController <PKPaymentAuthorizationViewControllerDelegate>

Step 3 - Create Payment Request

You’ll want to be sure to check whether or not the device will handle payments, which you can do with the code here:

if([PKPaymentAuthorizationViewController canMakePayments]) { ... }

Within that block, you can create a payment request using the `PKPayment` class. Modify this information as needed (make sure your `merchantIdentifier` matches the one you created in the previous step!).

PKPaymentRequest *request = [[PKPaymentRequest alloc] init];

        request.countryCode = @"US";
        request.currencyCode = @"USD";
        request.supportedNetworks = @[PKPaymentNetworkAmex,           PKPaymentNetworkMasterCard, PKPaymentNetworkVisa];
        request.merchantIdentifier = @"merchant.com.demo.crittercismdemo";
        request.merchantCapabilities = PKMerchantCapabilityEMV;

Step 4 - Add Items To Payment

You can create items to display using the `PKPaymentSummaryItem`. This object represents an item and a price. The last object in the array must be the total value.

 PKPaymentSummaryItem *widget1 = [PKPaymentSummaryItem summaryItemWithLabel:@"Widget 1"  amount:[NSDecimalNumber decimalNumberWithString:@"0.99"]];
        
PKPaymentSummaryItem *widget2 = [PKPaymentSummaryItem summaryItemWithLabel:@"Widget 2"  amount:[NSDecimalNumber decimalNumberWithString:@"1.00"]];
        
PKPaymentSummaryItem *total = [PKPaymentSummaryItem summaryItemWithLabel:@"Grand Total"amount:[NSDecimalNumber decimalNumberWithString:@"1.99"]];

request.paymentSummaryItems = @[widget1, widget2, total];

Step 5 - Present the Authorisation view controller

Finally, present the view controller that is provided by the PassKit framework. This will take care of the authorisation.

PKPaymentAuthorizationViewController *paymentPane = [[PKPaymentAuthorizationViewController alloc] initWithPaymentRequest:request];
 paymentPane.delegate = self;
 [self presentViewController:paymentPane animated:TRUE completion:nil];

Step 6 - Implement delegate methods

After the framework displays the transaction’s status, the authorisation view controller calls your delegate’s paymentAuthorizationViewControllerDidFinish: method. In your implementation, dismiss the authorisation view controller and then display your own app-specific order-confirmation page.

(void)paymentAuthorizationViewControllerDidFinish: (PKPaymentAuthorizationViewController *)controller

When the user authorises a payment request, the framework creates a payment token by coordinating with Apple’s server and the Secure Element, which is a dedicated chip on the user’s device. You send this payment token to your server in the paymentAuthorizationViewController:didAuthorizePayment:completion: delegate method, along with any other information you need to process the purchase

- (void)paymentAuthorizationViewController:(PKPaymentAuthorizationViewController *)controller
 didAuthorizePayment:(PKPayment *)payment completion:(void (^)(PKPaymentAuthorizationStatus status))completion


Saturday, 6 June 2015

Different ways to early returns from controllers

In some scenarios we don't need to execute full code of a controller method and want to return in-between.
So Here are different ways to early return from the controller methods :

1) redirect_to path and return


class Controller1 < ApplicationController
  def method1
    if something
      redirect_to edit_x_path(@object) and return
    end

    if something_else
      redirect_to index_path(@object) and return
    end
    # Code
    # Code
    #....etc
  end
end

It is the classic way. It is working properly If all redirects and return are in same method. If we call method2 in our method1 and try to redirect and return from method2, then it will give double render or redirect error.

So here are another ways to handle above scenario.

2) Extracted method return with AND


class Controller1 < ApplicationController
  def method1
    method2 and return
    # even more code over there ...
  end

  private

  def method2
    unless @var.some_condition? 
      redirect_to edit_x_path(@var) and return true
    end

    if some_condition_x?
      redirect_to y_path(@var) and return true
    end
  end
end

In this technique we need to write return true instead of only return. If you forgot to write true  
It can cause issue.

3) Extracted method return with OR


class Controller1 < ApplicationController
  def method1
    method2 or return
    # even more code over there ...
  end

  private

  def method2
    unless @var.some_condition? 
      redirect_to edit_x_path(@var) and return 
    end

    if some_condition_x?
      redirect_to y_path(@var) and return 
    end
  end
  return true
end

In this case we must need to add return true at the end.

4) Extracted method return via yield


class Controller1 < ApplicationController
  def method1
    method2  {return}
    # even more code over there ...
  end

  private

  def method2
    unless @var.some_condition? 
      redirect_to edit_x_path(@var) and yield 
    end

    if some_condition_x?
      redirect_to y_path(@var) and yield 
    end
  end
end

We can say it explicit return. It depends on callback block. If callback block contains {return} then it will perform early return.

5) Return with performed? method


class Controller1 < ApplicationController
  def method1
    method2; return  if performed?
    # even more code over there ...
  end

  private

  def method2
    unless @var.some_condition? 
      redirect_to edit_x_path(@var) and return 
    end

    if some_condition_x?
      redirect_to y_path(@var) and return 
    end
  end
end

performed? method is define in ActionController::Metal controller. Using this method we can test whether  render or redirect already performed. 

Monday, 1 June 2015

Disadvantages of creating excess instance variables


As we have heard that "creating unnecessary or excess instance variables is a bad practice."
but I don't understand why is it so, I started searching about this but couldn’t found a meaningful stuff, then I Dig a bit deeper and found that

As the number of instance variables increase there is a small increase in response time of application.

"A Rails view doesn’t have direct access to its controller’s instance variables."

After reading this a question arises "Then how can we access then controller's instance variable in view ??"

let me explain it: The source says that "The controller’s variables are transferred to the view renderer." which means all instance variables will be copied from the controller to the view you are using them or not, this process takes some CPU cycles which increases the response time of application by a time interval.

The Best practices say that we should have view with only a single instance variables as maintaining a single instance variable is simpler and easier