Bonsai Lesson 4

Goal

• Complete the LoginService to pass the actual user name and password from the user input.
• Address negative scenario.

LoginService

As I mentioned before web service interactions come a in all shapes and sizes. Bonsai has a default operating procedure implemented for a standard REST Web service. If you have trouble interacting with your required web service while using Bonsai, please consider accessing our Developer channel to interact with us.

Again we will be using WireMock to act as our web service.

WireMock is very configurable. I really encourage you to take a serious look at the product and what it offers in terms of setting up and maintaining a mock version of your Live Web service. Remember, testing will always save the day. Putting in the extra effort upfront to ensure your business logic is implemented correctly will save you and your benefactors countless hours and you can't use a live service to test with anyway.

I once worked on a project where the previous developer probably spent over a month writing complex mocking code to facilitate a mobile development project. I left the project ten months later in tears as people lost faith in our team because we could never quite get to any deadline because not only was too much time spent on writing the wrong code, but by then the web service development kept changing contracts and people fell over each other due to an over all lack of foresight when it came to the Web service development and it's facilitation.

We had no idea if the business logic of the Server would come back in a timely fashion because no one could even envisage what the inputs and outputs were going to be while we struggled rearranging frontend look and feels in a tightly coupled solution that caused logic rewrites for simple frontend changes.

After two years dreaming and building a successful methodology for the same client in a previous project, I had no way of predicting any sort of timelines in the problematic project and this proved fatal in the end. It became painfully obvious that a developer will only be as good as the code that they work on and design decisions affect developer productivity and performance directly.

With all this learning built into the Bonsais Methodology, We aim to not only address the visibility problem, but we leverage on the gained visibility and treat the source like one big collection of libraries that provide their own unique set of functions rather than duplicate code all over the place. This notion also pulls through the usage of third party toolsets in the methodology.

We just don't have time to rewrite code all the time. Ninety nine percent of the time the functionality has by now been implemented in a control on all available platforms. All you need to do is use it.

When it comes to services, you can use any sort of service be it for testing or as the production system, the point is, because we adhered to the standard architectural principle of Low Coupling and High Cohesion, we have gained a massive advantage in flexibility, but we have to protect that advantage and remain proactive in our every approach to adding code. It definitely makes more sense to have an agreed on set of inputs and outputs expected from and by the Web service.

I'll state it clearly, if you don't have an agreed on set of web service communication contracts, the project is at serious risk of failure and I urge an immediate cease and reevaluation of scope, budget and timelines.

Our LoginService now describes one input and one output contract. Those are reflected firstly in the WireMock Login.json and then in our code as the LoginModel and the UserModel under DataContracts.

The LoginView uses the Input Contract to bind user input into Bonsai through Xamarin Forms DataBinding techniques.

It's interesting to note the Configuration of Bonsai into the project at this point at Line 12

x:TypeArguments="p:LoginViewController, m:LoginViewModel" 

The next point of configuration is the LoginViewController

The inheritance and initialisation is setup via the inheritance layer in Bonsai.

ProjectBaseViewController<LoginViewModel>, ILoginViewController

The Bonsai framework relies heavily on a concept that only quite recently came into our understanding.

Dependency injection.

Its short and concise definition goes something like this: The idea implemented within a set of logic code with the contractual agreement that interchangeable, unrelated pieces of logic will be injected into it's scope at runtime.

This idea found it's roots at the heart of Polymorphism and Generics. Basically cleverly wrapping and passing along tested and working code definitely made sense for a while, in professional software thinking but only now has it reached maturity as an invaluable tool in the understanding of software development.

To the point then, Bonsai abstracted thousands of uniquely interacting lines of code to provide you with a sane development interface into it's internals.

All you have to do is provide the bits of logic you require to be implemented and the rest is already done for you. These pieces are structured in a such a way that testing becomes easy and concise.

Such implementations mainly reside in the Repos and in the services.

We use the LoginService and the LoginRepository in the LoginViewController as it ties everything together for us but beware the Massive View Controller issue.

Keep your core business logic in Repositories and test them. Don't let business logic clutter ViewControllers because we can't test it there and worse, we can't use it again anywhere else if it lives in the ViewController.

Let's make sure our service lines up with this:

The Last thing for now is to make sure we do some null checks in the Repository.

Running our code will now give us the required behaviour for the ground level level understanding of Bonsai.

Conclusion

This lesson concludes and exposes you to the broad implementation of Bonsai.

The next lessons will address specific topics and assume your basic understanding of Bonsai and it's implementation and setup.