Native Payment - Part 1 - Transcript.pdf

Native Payment - Part I
As I built this app I took the code I used within it and created a cn1lib that implements the native interface described here. So a better way to implement braintree
support would be to use the oﬃcial braintree cn1lib. However, this is still useful as an educational tool explaining both braintree and how to map a native interface

Braintree
© Codename One 2017 all rights reserved
Braintree is a pretty simple API on the client side as most of the charging process is handled on the server side of the API. The reason for this is that the client side if far
more hackable even in a native app.

In order to work with the API we start with a token which we can get from server code and then perform the charge process which is handled mostly seamlessly by the
library API.

What do we Need to Do?
✦Get a nonce using a token, heres the API snippet for
Android:
public void onBraintreeSubmit(View v) {
DropInRequest dropInRequest = new DropInRequest()
.clientToken(token);
startActivityForResult(dropInRequest.getIntent(this), REQUEST_CODE);
}
If you go to the braintree online docs and look at the integration instructions for native Android code you will find this code. This is native Android code for making a
request, the token is something we need to get from the server although conveniently the braintree site provides a helpful debugging token we can work with. This can fit
right into our native interface but first I want to review the native API to decide what sort of native calls we would need… Notice that even though a view object is passed,
it isn’t really used and that a token value is needed even though it isn’t passed.

And iOS
✦This is what we need to do in iOS:
- (void)showDropIn:(NSString *)clientTokenOrTokenizationKey {
BTDropInRequest *request = [[BTDropInRequest alloc] init];
BTDropInController *dropIn = [[BTDropInController alloc]
initWithAuthorization:clientTokenOrTokenizationKey request:request handler:^(BTDropInController *
_Nonnull controller, BTDropInResult * _Nullable result, NSError * _Nullable error) {
if (error != nil) {
NSLog(@"ERROR");
} else if (result.cancelled) {
NSLog(@"CANCELLED");
} else {
// Use the BTDropInResult properties to update your UI
}
}];
[self presentViewController:dropIn animated:YES completion:nil];
}
Moving to the iOS side the Objective-C code isn’t as readable for Java developers so let’s review this in pieces

And iOS
if (error != nil) {
NSLog(@"ERROR");
} else {
}
}];
}
This is a method declaration that accepts one string argument. Technically in objective-c these are messages not methods but I won’t go into subtle language diﬀerences

And iOS
if (error != nil) {
NSLog(@"ERROR");
} else {
}
}];
}
Here we allocate a request, notice that this is the equivalent of a “new” call in Java. The init entry is a method invocation of init. Methods are invoked using a square
bracket syntax.  
init is a special case method in Objective-C and is usually used as a constructor.

And iOS
if (error != nil) {
NSLog(@"ERROR");
} else {
}
}];
}
This is a really interesting block so I’ll split the block itself into several pieces

And iOS
if (error != nil) {
NSLog(@"ERROR");
} else {
}
}];
}
That’s simple, it’s just code that allocates the drop in controller. Not much to it, this is like Java’s new. However, you will notice that the brackets aren’t closed because
the init method or the constructor should be invoked…

And iOS
if (error != nil) {
NSLog(@"ERROR");
} else {
}
}];
}
The init method here is special… It accepts the token as an argument as well as the request. Notice two interesting things. The client token is just passed but request is
written twice!  
In Objective-C arguments are named, that means that you need to type the name of every argument to a method and you can have two methods with the same name but
diﬀerent argument names. To make matters more confusing the first argument is a special case that doesn’t need a name so we have one argument followed by the other
arguments each containging the name of the argument and then the value. So the request argument name and value make sense but the last argument might seem odd.
Handler is an argument that accepts a lambda expression with a callback. That callback accepts several argument types and will be invoked asynchronously when a
purchase produces a result

And iOS
if (error != nil) {
NSLog(@"ERROR");
} else {
}
}];
}
The lambda expression itself checks if the arguments represent an error, cancellation or success, this code should be pretty familiar to Java programmers. The one
“weird” things is that Objective-C strings start with the @ character which I won’t go into here

And iOS
if (error != nil) {
NSLog(@"ERROR");
} else {
}
}];
}
The final piece of code is the present view controller which shows the UI, notice it happens before the lambda expression is invoked as that is a callback. Also notice we
used the Objective-C keyword self which is the Objective-C equivalent of Java’s this keyword. In this particular case self is assumed to be a view controller.

So now that we reviewed everything in the method its pretty clear that the big thing that’s needed from the Java side of the API is the token and not much else.

So all we need…
✦Is one method:
import com.codename1.system.NativeInterface;
public interface BraintreeNative extends NativeInterface {
public void showChargeUI(String clientToken);
}
Tip
We generate stubs by right
clicking the native interface
and selecting Generate
Native Stubs
This is something we can represent with this simple method. Once we implement that in the Java side we can use generate native stubs to generate stub code for the
various native platforms and fill up that stub code

But we also need…
✦Callbacks for results… Left them as stubs for now
public class BraintreePaymentCallback {
public static void onPurchaseSuccess(String nonce) {
}
public static void onPurchaseFail(String errorMessage) {
}
public static void onPurchaseCancel() {
}
}
One important piece that’s missing from the native interface is the callback code. We need to monitor callback events so we can know if a purchase succeeded or failed.
A more common approach would be to pass the callback object instance to the call but here I use static callback code. The reason for this is simple, native interfaces
have a lot of restrictions on them and one of those is that we can’t pass arbitrary object types. The reason for those restrictions is simplicity and portability. How would
you represent an object instance in the Objective-C mapping? 
To implement callbacks we use static methods and some platform specific code.

Purchase Class
✦ Invoking native interfaces directly is bad practice
✦ They are an implementation detail and should be
abstracted
✦ Enter the Purchase class which hides the
implementation and also provides a generic
implementation based on the JavaScript port of
Braintree
Calling the native interface directly is often a “bad practice”

Native interfaces are often fragile and should be wrapped in an abstraction that hides potential platform issues. For instance if the iOS & Android native interfaces have
diﬀerent features we might be able to hide/abstract it in the Java side which is normally much easier to do than implementing native code.

In this code we even have an attempt at fallback code based on the JavaScript port of braintree. It doesn’t work all that well but that’s mostly because I didn’t pay that
much attention to it.

public class Purchase {
boolean flag;
public void startOrder() {
BraintreeNative bn = NativeLookup.create(BraintreeNative.class);
String token = "token-snipped";
if(bn != null && bn.isSupported()) {
bn.showChargeUI(token);
} else {
Form buy = new Form(new BorderLayout());
buy.getToolbar().setUIID("DarkToolbar");
Form previous = Display.getInstance().getCurrent();
buy.getToolbar().addMaterialCommandToLeftBar("", FontImage.MATERIAL_CANCEL, e ->
previous.showBack());
BrowserComponent cmp = new BrowserComponent();
buy.add(BorderLayout.CENTER, cmp);
cmp.setPage("html-snipped", null);
buy.show();
}
if(flag) {
BraintreePaymentCallback.onPurchaseCancel();
BraintreePaymentCallback.onPurchaseFail(null);
BraintreePaymentCallback.onPurchaseSuccess(null);
}
}
}
Purchase
Compiler Issue
iOS VM strips unused code and could
remove these without that flag…
This class is mostly trivial since the native interface is trivial too.

Notice the code at the bottom that invokes the static callbacks. This is a special case for iOS where the VM strips away unused code. By writing this the compiler can’t
tell that the code will never be invoked and will keep it in place. Notice that even making a seemingly small change like making “flag” into a private variable might break
this…

Native Payment - Part 1 - Transcript.pdf

Recommended

Recommended

More Related Content

Similar to Native Payment - Part 1 - Transcript.pdf

Similar to Native Payment - Part 1 - Transcript.pdf (20)

More from ShaiAlmog1

More from ShaiAlmog1 (20)

Recently uploaded

Recently uploaded (20)

Native Payment - Part 1 - Transcript.pdf