Everyone in the Flutter community knows Bloc is one of the leading state management techniques used in Flutter. I’ve been using Bloc for almost 5 years now. So I’ve gone through a lot of different use cases for using Bloc.

In the example projects provided with the Bloc package, lots of projects are usingSingle-State class to manage states. In this article, I want to talk about why we need to avoid using Single State Class where multiple states are possible.

In case you are wondering, this is how a Single-State class looks like

class SendEmailState {
  final Email? email;
  final bool isLoading;
  final String? failureMessage;
  final dynamic? exception;

  SendEmailState({
    this.email,
    this.isLoading = false,
    this.failureMessage,
    this.exception,
  });
}

First, let’s start with some basic questions,

What is a state?

A state is a thing that changes over the lifetime of the app or a page or a group of widgets or even a single widget.

For example, let’s consider sending an email. We have 4 states in sending an email.

1. Initial (User not yet pressed the send button)
2. Sending (Email is being sent to the server)
3. Succeed (Email successfully sent)
4. Failed (Failed to send)

We need to understand that at any point in time, the state of sending an email could only be one of these 4 states. It cannot be at Sending and Failed state at the same time.

What is state management then?

State management is nothing but the logic to update the current state based on some action. The action could be anything like

• A user pressing a button
• Receiving a notification
• System state change (eg: Screen orientation)
• App state change (eg: Login state changes User state)
• Backend stream

How does Bloc/Cubit manage the state?

Bloc works with streams as its core. Bloc is connected to 2 streams. Event stream and State stream. The event stream is used to carry and deliver events triggered by some action to Bloc. Bloc maps the event to a function that holds some logic which yields a new state into the State stream. State stream is used to broadcast the current state to its listeners. Then the listeners react based on the state change.

The difference between Bloc and Cubit is that Cubit doesn’t have an event stream. This means the action instead of generating an event, directly calls bloc methods that hold logic which yields state to State stream. And then the flow is the same as the bloc.

Let’s see the Email sending state management example in code using Cubit as the state manager.

We can represent the state change in 2 ways.

1. Each object type represents a different state. (Multi-Class states)

2. A single object having multiple nullable parameters belongs to one or many states. (Single-Class states)

And these are their respective cubit codes.

Let’s see the side-by-side comparison of state code to understand a bit more.

We all know the whole point of state management is that we need to be certain of the current state of the thing that could have multiple states.

• The first thing we could understand from the right side code is that we could not understand the different states this could have 😂. We can only guess the state with the combination of parameters. For that, we need to check all the existing yielded state combinations to be certain that our new combination will work for sure.

• But on the left side code, we can easily understand the state types with class type.

• On the right side code, we can see the object Email is declared nullable final Email? email;. This means that even though the email was sent successfully, we cannot access the email object without a null check. However on the left side code, if the state is SucceedState we can be sure that it holds an Email object final Email email;. The same thing happens with the failure case. Even though it failed, we cannot be certain that this holds the failureMessage and exception params.
• Worse than that, even though the email was sent successfully, the right-side code could hold email as well as failureMessage params and even the compiler won’t complain. Logically how could an email-sending state be both a success and a failure state at the same time? Please don’t talk about Quantum Physics here 😂. Now, from the State-listener’s perspective, how could we be certain of which param should be trusted? Should we show a failure message or a success message to the user?
• Also, note that some states could need multiple parameters. Here we need failureMessage and exception params in case of a failure. The compiler won’t complain even though we left a param on the right side code. But on the left side code, if we left something, the compiler won’t let us run the code. We can be certain that if it failed, we can access both failureMessage and exception with certainty.
• If you are a new developer on the team, how could you know what are the parameters that need to be updated for a state change with the right side code? We could accidentally create a new combination like having both email and failureMessage. In this case, there are 4 variables of which 3 are nullable and 1 is boolean. So there should be 2^n combinations. So here we have 16 combinations of params. Now think of having more parameters. We might not be handled all the combinations on the listeners. This could break the code. And it will be harder to debug based on the number of combinations. However, on the left side code, anyone can be certain that there are only 4 possible states(combinations). And even a newbie can be certain that we just need to hold email if it is a success case or we just need to hold failureMessage and exception in case of failure.
• Let’s say we have email as null with a success state on the right-side code. We only get the runtime error at the time of using the email param which too not at the yielded state source. It shows at the place where we used it. Then we need to backtrack to the code and find out the source to fix. In the case of left-side code, the compiler will not even give a chance to emit the email as null.

As we can see from this cubit comparison, we are emitting the state object with different parameter configurations on Single-Class state. But on the Multi-Class state, we are emitting different objects which makes it more clear.

You could argue why someone will ever write a code that has both email and failureMessage params together? That’s a good question. I believe this question is very similar to the question Why do we need Java if Javascript is that simple? and the simple answer is that we programmers are humans which means we are dumb 😂 and we make many mistakes. After all the most important point of having a programming language with a strong type system is to reduce human error right? If you are still not satisfied I’m sure you all know Murphy’s law Anything that can go wrong will go wrong. Don’t you think, the simple possibility of the Email param can be nullable itself is frightening?

Now let’s compare the flow diagram between Multi-Class states and Single-Class states to make it more obvious.

As we can see from the flow diagram, by using Single-Class state option,

• We are just deligating the current state-deciding logic to the UI. Feels like a big RED Flag, isn’t it?
• If UI is the one deciding the current state, then what is the whole point of having separate logic from UI for state management?
• The worse part is we need to repeat this state deciding logic wherever we are using this state. So if we need to add one more state in the future, we need to make changes everywhere. Huge RED Flag.
• Yes, we could solve this issue by adding a enum parameter to the state object. But this just solves this single problem. All the other problems I mentioned will still exist.

If we use Multi-Class states option, the UI just needs to reflect based on the current state.

Now what if we need multiple params at the same time? I’ve seen lots of people doing this same mistake while using pagination. If we are implementing pagination, we need to show the loading indicator at the bottom with the existing list at the top.

Let’s start with the worst implementation for obvious reasons mentioned throughout this article.

class NewsFeedState {
  final List<News>? news;
  final bool isLoading;
  final bool isPaginating; // <-- true if paginating.
  final String? failureMessage;
  final dynamic? exception;

  NewsFeedState(this.news, this.isLoading, this.isPaginating, this.failureMessage, this.exception);
}

We could just add isLoading parameter to the SucceedState like

sealed class NewsFeedState {}

final class InitialState implements NewsFeedState {}

final class SendingState implements NewsFeedState {}

final class SucceedState implements NewsFeedState {
  final List<News> news;
  final bool isLoading; // <-- true if paginating.

  SucceedState(this.news, this.isLoading);
}

final class FailedState implements SendEmailState {
  final String failureMessage;
  final dynamic exception;

  FailedState(this.failureMessage, this.exception);
}

But if we think about it, we are letting the UI decide whether this is Succeed without pagination or Succeed with pagination instead of having this logic in the cubit. And we need to understand, Succeed with pagination is just a subset of the succeed state. So the best approach is to extend the Succeed state like

I hope I delivered some of the important points to think about before selecting the right approach. Of-course Single-Class State logic feels easy to implement at first but only at the cost of suffering for it later. After all, this is the exact reason why we need Inheritance right?

Now if you ask me why Bloc team used this kind of solutions in some of its example projects, I can’t think of any point other than they don’t want to scare newbie developers with this Inheritance given that Bloc already using Stream while other popular state management solutions like Provider is very easy to start with.

I still believe that programming is one of the easiest and best jobs to exist. We just need to write code not only expecting the result but also by thinking of our future selves, because we are the ones who are going to read and update the code. All we need to do is write code for our future selves as straightforward as possible.

The only reason I could come up with for using Single-Class state is because of lots of boilerplates in Multi-Class states. For that sole reason, I've published a Wrapper package for Bloc called bloc_ease that could help us write Bloc/Cubit without we need to handle states (most cases). Also, we don’t even need to handle all the states in the UI. This could reduce more than 60% of boilerplates. Sounds fascinating right? Check out this package bloc_ease.

bloc_ease | Flutter Package

Connect with me for doubts and updates.

Bharath | Twitter, Instagram | Linktree

Thanks for your time. Happy coding! 💙

Unit testing is a part of the automated testing process in which small units of code are tested

Hello everyone. In this article, we are gonna learn all about unit testing in Flutter and Dart.

Agenda

• What is automated testing?
• What is unit testing?
• Why do we need to test?
• What can we test in a unit?
• How to do unit testing in Dart?
• Good unit testing practices
• Mocking
• Different ways to mock
• Mockito
• MockTail

What is Automated Testing?

Software automated testing is the process of evaluating and verifying if the software product or application does what it is supposed to do. It prevents bugs and reduces the development cost.

First, we need to understand something. Automated testing is just a way to prevent the software from expected bugs. It doesn’t mean the software does not have any bugs. It just means the software does not have any expected bugs.

“Testing shows the presence, not the absence of bugs.” — Edsger Dijkstra

The cycle always goes like the following:

As we can see, after the development phase, we write expected test cases (TDD is an exception). Once it passes all the test cases, we usually ship the software. While the software is in production, if any bug raises, we fix it and write the test cases to prevent the software from the same bug in the future.

Testing is just the act of verification. Under the development of a new feature or fixing an existing bug, test cases help us verify if all the existing features and units work as expected. It makes sure the current development doesn’t break any existing features.

What is Unit Testing?

Unit testing is a part of the automated testing process in which small units of code are tested with several use cases for their reliability. A unit may be a function, method, class, state, or just a variable.

Unit testing is the bottom-most layer in the test suite. In this layer, we test the internal working of every feature.

A unit test has three phases:

• Arrange
• Act
• Assert

In the Arrange phase, we just need to create the object of the unit that we need to test and prepare the prerequisites for our test, i.e., set up the state variable, set up mocks, etc. The Arrange phase may or may not exist based on the need.

In the Act phase, we run the unit with some state(passing arguments) and store the result if any.

In the Assert phase, we verify whether the unit behaves as expected. We may expect a method to be called or the result to be the same as the expected result.

The Arrange and Act phase are not compulsory.

Why do we need to unit test?

• Unit testing is very easy to write and run. Thus saves a lot of time.
• Unit testing helps us identify bugs at the early stage. Thus saves a lot of time and money.
• Since we write all the expected cases of the unit, anyone can understand what that unit is all about. Thus acts as better documentation.
• Often we won’t refactor our code by thinking, doing so might break the unit. Having unit tests gives us the confidence to refactor our code.
• Debugging is simple. Since we exactly know the cases that are failing, we can pinpoint the exact unit that causes the bug.
• By looking at the test cases, we can easily understand what the unit is all about. Thus long-term maintenance is easier.

What can we test in a unit?

In order to have a good unit test suite, we need to understand what we need to test in a unit.

Usually, unit testing is based on these aspects:

• State variables
• Function/variable calls
• Function arguments
• Function returns

State variables are variables outside the local scope. It may be a global variable or a class property that can be accessed by more than one unit. Usually, it holds a state.

Here are some of the cases we need to look for in a unit:

• Verify the constant or final variable’s value.
• Initial values of state variables.
• Verify if the unit calls certain function 1…n times.
• Verify if the unit never calls certain function.
• Make sure the state variables are updated as expected.
• The result of the unit is same as the expected.
• If there is a string, list, or any other complex DS involved, make sure to check empty cases, especially if we traverse through the DS.
• Check for null cases (Only for nullable types. Dart is null safe now)
• Check the type of the variable or argument (Don’t need to if we utilize Dart’s type system well)

Dart’s null safety and type system save a lot of test cases in all scenario.

How To Do Unit Testing in Dart?

• First, we need to include the dependency in the pubspec.yaml file.

• Create a dart test file with the _test suffix. It helps the dart analyzer to treat the file as a test file.

We are gonna test the area of the circle.

sample_project/
  lib/
    area.dart
    main.dart
  test/
    area_test.dart

Here is the Dart test file. Every test file should have a main() method in which the execution starts.

We need to wrap our test case inside a function and pass the function to the test() method as an argument along with a proper description of the test case.

This test expects the area of the circle to be 3.141592 when the radius is 1. Here the unit is the circle() method.

• In the Arrange(setup) phase, we created an instance for the Area class.
• In the Act(run) phase, we ran the unit we wanted to test with some input.
• In the Assert(verify) phase, we compared the result with the expected result.

Here is one more test that just verifies the value of the getter pi:

Here we can see that arrange and act phases are not present. Since pi is a static getter, we don’t need to set up or run anything. But we need to verify it, thus only the assert phase.

Grouping the test cases

Often, we need to write many similar test cases. The group() method helps us group similar test cases for easy management.

Everything is fine but we created the Area instance for each test. As the test cases grow, we need to repeat this same step for every test case. It is not a good practice.

The setUpApp() method runs first before all the test cases. Using this we can reduce the repetition.

As we can see, I moved the declaration and initialization to this main method’s scope. Thus, it runs first and then runs all the test cases, i.e., it uses the same instance to all the test cases. If the object doesn't hold any state, it won’t be a problem.

If the object holds a state, then having a common instance for all the states might end up giving many problems. Thus we need separate instances for every test case.

It is a bad practice to have a common state among many test cases.

We need to have separate state for every test case. We usually inject the initial state for every test. That is one of the works we need to do in the Arrange phase.

The setUp() method is similar to the setUpAll() method but the difference is that it runs every time before a test case in the current scope. Thus every test case gets its own state.

Here, setUp() method runs before each test case. Thus having separate instances for each test. Thus no state issues.

Always prefer the setUp() method over the setUpAll() method unless the callback is slow.

The tearDownAll() method can be used to run something after all the tests in the current scope are completed. Similarly, the tearDown() method is used to run something after every test case. Usually used to dispose instances or cancel the subscription.

setUp(), setUpAll(), tearDown(), and tearDownAll() can be used inside the group() to limit the scope.

Good Unit Testing Practices

• Unit tests should be fast
• Unit tests should be simple
• Unit tests should be deterministic
• Unit tests should be focused
• Code repetition is OK in unit tests
• Test description should be easily understandable

Unit tests should be fast. Our entire unit test suite should be able to run within a couple of minutes so that we will run the test suite ourselves in the development phase. This helps in fixing bugs early. If it takes longer, then we usually throw that work into some kind of pipeline.

Unit tests should be simple. When we go through a unit test case, all we need to know should be inside that test case. We don’t want to scroll around the code to understand a single test case. Unit test should be self-explanatory.

Unit tests should be deterministic. A unit test should behave exactly as before wherever or whenever it is been tested without altering the source code. Unit test should not depend on any external factors such as Current-Time, database, web, native API, etc. We usually mock those out.

Unit tests should be focused. A unit test should focus only on a single unit. We should not test the dependencies inside the unit test.

Code repetition is OK in unit tests. A unit test should focus more on simplicity rather than good coding practices. Anyone should understand the test case without searching for its dependencies or the current state of the unit. So, it is OK to repeat some parts of code if it improves easy understanding and simplicity.

Unit test description should be easily understandable. A good description must contain four parts:

• The unit we are gonna test
• The current state of the unit
• The input we are going to give
• The response we are expecting

In this test description, “area of the circle with radius 1 should be 3.141592,” we can break it apart like the following:

• “Area of the circle” is the unit we are gonna test
• “Radius 1" is the input we are going to use
• “3.141592” is the output we are expecting

This unit doesn’t have any state.

Mocking

The main idea behind unit testing is to isolate and focus on the current unit we are testing and not on the behavior of external dependencies. But in most cases, we need to depend on external dependencies like DB, web servers, platform API, external devices, etc.

Let’s assume that our current unit depends on a web API. The test works slowly but fine when the server is live. But when is server is offline, the unit test fails. This makes the unit test unpredictable. Because the web server won’t be in our control. It is not our fault when the web server goes down. This is where mocking comes in.

Mocking is just the process used in unit testing when the unit being tested has external dependencies. The purpose of mocking is to isolate and focus on the code being tested but not on the behaviour of external dependencies.

Let’s see an example.

We are gonna test this fetch() method in the repository class. As we can see, our unit depends on RemoteDataSource’s fetch() method which communicates with the web API, which is an external dependency. So, we need to stub the fetch() method from RemoteDataSource.

Stubbing refers to changing the behavior of some part of the unit without affecting anything else.

There are some ways with which we could mock.

Implementing the class we need to mock

Here we have implemented the RemoteDateSource class on two mock classes. MockRemoteDateSourceSuccess which mocks the success case and MockRemoteDateSourceFailure which mocks the failure case.

While writing test cases, we can choose what kind of implementation we need based on the test.

• In the first test, I used the MockRemoteDateSourceSuccess instance that mimics the success case and verified the result is an instance of Student.
• In the second test, I used the MockRemoteDateSourceFailure instance that mimics the failure case and verified the method call throws an exception.

Extending an abstract class we need to mock

This is similar to the previous method. The only difference is that, rather than implementing a concrete class, we just extend an abstract class that the concrete class is extending.

This helps in reducing some unnecessary implementation from a concrete class.

But both these techniques have two problems.

• They lack simplicity since we need to move to the mock code to know about its implementation details.
• Also, we need to have separate mock classes for all the test cases. Some part of code repetition is acceptable for unit tests. But this much code repetition is hard to maintain.

This is where mocking packages come into play.

Mockito — Mock library for Dart

This package solves both of these problems. The idea behind the Mockito library is that we just need to use @GenerateMocks() annotation to pass on the classes we need to mock. It generates the mock class for us with the help of the build_runner package (Don’t forget to include build_runner as the dev_dependency).

Here we did the stubbing part using the when() method from Mockito.

Don’t forget to generate the mock classes.

dart run build_runner build --delete-conflicting-outputs

build_runner will generate a file with a name based on the file containing the @GenerateMocks annotation. Here, in the repository_test.dart example, we import the generated library as repository_test.mocks.dart.

• We don’t need to move anywhere to see the implementation logic. Everything would be right there.
• Generation of the mock class is done by mockito, thus, it is easy to maintain.

We can just concentrate on stub, act, and assert. That’s it.

The only problem with Mockito is the code generation. We can overcome it with MockTail.

MockTail — Without Code Generation

Mocktail focuses on providing a familiar, simple API for creating mocks in Dart (with null safety) without the need for manual mocks or code generation.

This library is written by Felix Angelov, the same person who wrote bloc, equatable, etc. This library even has 100% code coverage like other packages he wrote.

That’s it. No annotation and no code generation. Just a single line.

class MockRemoteDataSource extends Mock implements RemoteDateSource{}

Well done, folks! You’re ready for unit testing.

I hope you enjoyed this article.

Connect with me

Bharath | Twitter, Instagram | Linktree

Thanks!

Flutter Unit Testing — The Beginner’s Guide was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

As explained with visual illustrations

The Clean Architecture is the system architecture guideline proposed by Robert C. Martin (Uncle Bob) derived from many architectural guidelines like Hexagonal Architecture, Onion Architecture, etc... over the years.

This is one of the guidelines adhered to by software engineers to build scalable, testable, and maintainable software.

Why do we need to architect?

“The goal of software architecture is to minimize the human resources required to build and maintain the required system.” ― Robert C. Martin, Clean Architecture

Advantages of Proper Architecture

• Testable
• Maintainable
• Changeable
• Easy to Develop
• Easy to Deploy
• Independent

The Clean Architecture

Here’s the clean architecture illustration created by Robert Martin:

We can see there are four layers in the diagram. Blue layer, Green layer, Red layer, and Yellow layer.

Each circle represents different areas of the software. The outermost layer is the lowest level of the software and as we move in deeper, the level will be higher. In general, as we move in deeper, the layer is less prone to change.

The Dependency Rule

The Dependency Rule states that the source code dependencies can only point inwards.

This means nothing in an inner circle can know anything at all about something in an outer circle. i.e. the inner circle shouldn’t depend on anything in the outer circle. The Black arrows represented in the diagram show the dependency rule.

This is the important rule that makes this architecture work. Also, this is hard to understand. So I’m gonna break this rule at first to let you understand what problems it brings and then explain and let’s see how to keep up with this rule. So please bear with me.

First of all, this circular representation might be confusing for many. So let's try to represent it vertically.

The colors represented here are the same as the colors represented in the clean architecture diagram.

Remember, the arrow should be read as “depend on”. i.e. Frameworks and Drivers should depend on Interface Adapters, which depend on Application Business Rules which depend on Enterprise Business Rules.

Nothing in the bottom layer should depend on the top layer.

Frameworks and Drivers

Software areas that reside inside this layer are

• User Interface
• Database
• External Interfaces (eg: Native platform API)
• Web (eg: Network Request)
• Devices (eg: Printers and Scanners)

Interface Adapters

This layer holds

• Presenters (UI Logic, States)
• Controllers (UI Logic, States)(Interface that holds methods needed by the application which is implemented by Web, Devices or External Interfaces)
• Gateways (Interface that holds every CRUD operation performed by the application, implemented by DB)

Application Business Rules

Rules which are not Core-business-rules but essential for this particular application come under this. This layer holds Use Cases. As the name suggests, it should provide every use case of the application. i.e. it holds each and every functionality provided by the application.

Also, this is the layer that determines which Controller / Gateway to be called for the particular use case. Sometimes we need controllers from different modules.

This is where different modules are coordinated. For instance, we want to apply a discount for the user who purchased for x amount within a month.

Here we need to get the amount the user has spent on this month from the purchase module and then with the result we need to apply the discount for the user in the checkout module. Here applyDiscountUseCase calls the purchase module’s controller for the data and then applies the discount in the checkout module.

Enterprise Business Rules

This is the layer that holds core-business rules or domain-specific business rules. Also, this layer is the least prone to change.

Change in any outer layer doesn’t affect this layer. Since Business Rules won’t change often, the change in this layer is very rare. This layer holds Entities.

An entity can either be a core data structure necessary for the business rules or an object with methods that hold business logic in it.

For example: calculating Interest module in the banking application is the core business logic that should be inside this layer.

Let’s look at a simple example to understand this well.

The example demonstrates a simple application that has only one network request.

How can we architect an app that translates the sentence given by the user using a translation API? let’s try to architect.

Each layer does a specific thing. Looks good right? Let’s check the dependency flow for this above architecture to know if anything is wrong.

Remember Dependency Rule? “The Dependency Rule states that the source code dependencies can only point inwards”.

UI → Presenter (✅ Not Violating)

Presenter → Translate Usecase (✅ Not Violating)

Translate Usecase → Translate Controller (❌ Violating)

Translate Controller → Web (❌ Violating)

But it seems correct, right?

UI requests data from Presenter which requests data from Use Case which should request data from Controller which should request data from Web.

After all, how can we expect the web to throw some data to the Controller without the Controller being dependent on it? Also, how can we expect the Use Case to get the proper data from the Controller without depending on it?

But the Dependency Rule strictly says dependencies can only point inwards. It adds up by saying this is the rule that makes the architecture work.

In order to pass this rule, we need to invert the arrow to the opposite direction. Is that possible? Here comes Polymorphism. When we include some Polymorphism here, something magic happens.

Simply by having an Interface between these 2 layers, we could invert the dependency. This is known as The Dependency Inversion Principle.

Let’s implement the Dependency Inversion Principle in the cases where the Dependency Rule is violated.

Thus the flow becomes:

Let’s check the dependency flow now to know if anything violates it.

Now we can see that no inner layer depends on any outer layer. Rather, the outer layer depends on the inner layer.

So why should the outer layer depend on the inner layer but not the other way around?

Imagine you’re in a hotel. We want the hotel to serve us what we want, but not what they offer right?. The same thing is happening here, we want the DB to give the data the application needs but not the data it has.

Application orders what data it wants and it doesn’t care how DB or API prepares the data. This way, the application doesn’t depend on DB or API. If we need/want to change the DB or API Schema in the future, we can simply change it. As far as it gives what the application asks for, the application doesn’t even know the change in DB or API.

Also, the single-way dependency rule saves the application from the deadlock state. i.e. imagine in a 2 layer architecture, the first layer depends on the second layer, and the second layer depends on the first layer. In such a case, If we need to change anything in the first layer, it breaks the second layer. If we need to change anything in the second layer, it breaks the first layer. This can be rejected by following the deadlock state.

This is the clean architecture described by Uncle Bob.

We are yet to see how to move the data across the boundaries and how to handle errors. We’ll do so in future articles.

Connect with me

Bharath | Twitter, Instagram | Linktree

Thanks for reading.

The Clean Architecture — Beginner’s Guide was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

These are the clocks we are gonna build today without any widgets like Transform to manipulate the position of the hour/minute/second hands or any PNG for the minute line. It looks like a very simple design and is easy to implement. But trust me, it’s not that simple.

What are the problems we will face while implementing it?

1. Implementing Minute lines

2. Implementing Hour text

3. Implementing Hour, Minute, Second hands

4. Hour hand’s position is affected by the minute and the minute hand’s position is affected by the second hand.

Hello all guys, In this article we are gonna build these clock from scratch.

First of all, let me tell you how I ended up building this. I just wanted to learn about Custom Paint. While researching about that, I saw many articles and youtube videos explains about Custom Paint with Clock app.

But most of the articles and videos talked only about the base circle of the clock as well as the hands. That too using some widgets like Transform to rotate or translate the hour/minute/second hands. Most of the tutorials used a PNG to implement Minute Lines (First problem we are gonna face), saying it’s gonna require many Math equations to implement it.

That’s how I got the spark to implement the clock purely with Custom Paint, without using Transform Widget or PNG for minute lines.

Let’s solve the problems one by one.

Before solving anything, I just moved the origin point from top left (default origin for a canvas)to the center of the circle using,

canvas.translate(clockRadius, clockRadius);

1. Implementing Minute lines

I wanted to solve this problem first since it is the trickiest problem of all.

Let’s concentrate on a single line first. (5 min line)

We all know that to draw a line we need two endpoints (Offset).

But, how are we gonna get the endpoints for 60 lines(minutes)?

Let’s say the radius of the circle is 100 Units.

Do we know anything else?

We know that angle of a circle is 360°(2π). We got 60 Minute lines.

So, if we divide 60-minute lines across 360°, we got 6°. This means each minute line is 6° apart from each other.

Thus we got,

• The radius of the circle r = 100,
• Number of minute lines = 60,
• The angle between each minute line = 6°.

With this informations, we need to find the two endpoints of the minute lines.

Can we do anything to find the offsets for all the minute lines with these pieces of information?

Yes! Here is where Trigonometry comes in.

If you guys gets shiver by the term Trigonometry, it’s not that hard. Check out my article Is TRIGONOMETRY that hard? Let’s build it from SCRATCH. There I described about what “sin”, “cos”, “tan”, “cosec”, “sec”, “cot” are? And how can we use it?

In that article, the section Application in programming describes more about this exact scenario. I suggest you read at least this section before continuing if you are not comfortable with Trigonometry.

A triangle consists of 3 lines and 3 angles.

By using Trigonometry, there are 2 ways to find these properties.

• If we know 2 lines, we could find the 3rd line and all 3 angles.
• Or If we know 1 line and 1 angle(other than 90°), we could find the other lines and angles.

Here we are gonna use the 2nd way to find the properties of a triangle and with those properties, we are gonna find the offset of the lines.

Let’s construct a triangle with what we got for 5 min line.

Sorry for my drawing. Here I constructed a right angle triangle with what we got.

We need to find the endpoints of the 5-minute line.

We have already seen that the angle between each minute line is 6°. Thus angle between the 60-minute line and the 5-minute line is 30° ( 5 x 6° ).

Therefore, θ = 30° and r = 100 units(Radius of the circle).

Formula for (x,y) is (r*cos(θ),r*sin(θ)).

Thus e2(x2,,y2) = (86.6,50).

Now we found the endpoint e2. How can we find the endpoint e1?

Just reducing the radius(r) we can get the endpoint of e1. Let’s say the minute line length is 10 units. Now by using radius = 90(100–10), e1 = (77.9,45).

By using this relation, we could find the minute endpoints of all minute lines.

Now we obtain this.

We successfully solved our first problem.

2. Implementing Hour text

By using the same technique to solve our first problem, we could find the offset to point the hour text. But here we will face a small problem. Since the text paint from the top left rather than the center, some texts won’t align properly.

By programmatically moves the hour text’s center to the offset we got, we could solve this problem.

We solved problem number 2.

3. Implementing Hour, Minute, Second hands

Hour, minute, second hands need just 2 offsets. One is obviously the center point(0,0). Thus we just need to find the 2nd offset to draw a line.

To find the second offset, we need the angle of the hands.

Hour hand:

The Angle between each hour line is 30°(360°/12).

And since the hour we got is in 24-hour format, by hour%12 converts it into 12-hour format.

Minute Hand:

The Angle between each minute line is 6°(360°/60).

Second Hand:

The Angle between each minute line is 6°(360°/60).

Everything is good, but there is a minor issue. Since we didn’t include minute in hour hand movement and seconds in minute hand movement, Hour hand and minute hand won’t move partially based on the current time. Rather it jumps from hour to hour and minute to minute. This is the 4th problem.

4. Hour hand’s position is affected by the minute and the minute hand’s position is affected by the second hand.

By slightly improving the θ we can resolve this issue.

Hour Hand:

Since minute hand affects the position of the hour hand, including the minute factor with the hour resolves this.

Minute Hand:

Since second-hand affects the position of the minute hand, including the second hand’s factor with the minute hand resolves this.

Now we got the clock we want.

We’ve successfully built the clock from SCRATCH with CUSTOM PAINT and TRIGONOMETRY.

If you find it hard to understand, consider looking at Is TRIGONOMETRY that hard? Let’s build it from SCRATCH.

The other 2 clocks shown initially are simple compared to this one.

Source code: GitHub

Follow me on GitHub, Medium, Instagram for more such articles.

If you liked this article, leave me a clap!

Thanks!

Trigonometry, one of the most hated subjects in our school days. But why?

All because of the terms “sin”, “cos”, “tan”, “cosec”, “sec”, “cot”. Are these that hard?

Hello all guys, in this article we are gonna build Trigonometry from scratch.

NOTE: I’m not pretending myself as a math genius. I’m a photographer who knows the importance of Trigonometry. If you find any mistakes or something, let me know. Thanks!

First of all, in this article, I’m gonna experiment with a different way of teaching. We are gonna,

• Face a problem
• Search for the solution
• see how Trigonometry offers the solution

Face a problem

Once during monument photography, I wanted to cover the full height of the monument in my frame. So I have to find the distance I should stand from the monument to capture its entire height. I had a 24mm lens which gives the angle of view around 59°.

Sorry for my drawing.

This is the exact scenario I faced,

• Distance between me and the monument = x
• The height of the monument I wanted to capture = 66m
• The height of my camera from the floor = 1.6m

Since I wanted the monument to be 90° to the frame, I didn’t tilt the camera.

So my camera is facing 90° from the ground.

• Camera’s angle with respect to ground = 90°
• The angle of view of my 24mm lens = 59°

Since my camera is facing 90° from the ground and the height of my camera from the ground is 1.6m, half of my lens’s angle of view( 59°/2 = 29.5° ) could only cover 1.6m out of 66m of the monument. i.e I should cover the remaining 64.4m with the remaining 29.5°.

Let’s revamp this diagram.

This is all we have to focus on.

• Height of the monument = 64.4m
• The angle of view = 29.5°
• Distance between me and the monument = x

This is the problem.

Searching for the solution

How Trigonometry offers the solution

Before talking about what Trignometry offers us, let’s try to solve it ourselves.

First of all, let’s try to learn what we could about triangles.

Let’s learn about sides first

We all know it has 3 sides. Let’s name them as a,b and c.

Here we need to remember the Pythagoras theorem.

It states that, In a right-angled triangle, the square of the hypotenuse side is equal to the sum of squares of the other two sides.

What does that mean?

It means that if we construct 2 squares with sides a and b, the sum of the areas of two squares is equal to the area of the square we could construct with side c.

This means we can able to find a missing side if we know 2 other sides.

Learn about angles in the triangle

The sum of the angles of any triangle is always equal to 180°.

Thus for a right-angled triangle, one angle should be 90°, other 2 angles should be θ and 90-θ. So θ is the only angle we need to worry about.

So far, we have seen only about the right-angled triangles. Is that mean Trigonometry is only applicable for right-angled triangles? Nooooo. Let’s worry about the non-right-angled triangle later. The solution for the non-right-angled triangle is so cool.

Learn about sides in the right triangle

Opposite to the θ => Opposite side

Below the θ => Adjacent side

Longer side => Hypotenuse side

Now, let’s talk about a right-angle triangle with all the required sides and angles, and let’s see what we could learn from them.

Here is a right-angled triangle with its sides and angle.

a = 3

b = 4

c = 5

θ = 36.87°

Ok now let’s see how we could get the unknown side if we have 2 known sides with the Pythagoras theorem.

i.e we can find the 3rd side if we know the other 2 sides.

But for our problem, we have only one side and one angle.

• Height of the monument = 64.4m
• The angle of view = 29.5°
• Distance between me and the monument = x

Now, let’s learn about θ

We know that to have an angle, there should be 2 intersecting lines.

Here we have 3 lines in the triangle. ( This point is more important than we think. We’ll come back to this line soon ).

Since we have 3 possible lines combination.

• Opposite side and adjacent side
• Opposite side and hypotenuse side
• Adjacent side and hypotenuse side

Let’s see what we could learn from these 3 lines combinations.

We are gonna take each combination and assign some sample values to it and find out how this combination affects θ.

Triangle representation of the above table:

Opposite side and adjacent side

As we can see opp/adj is directly proportional to θ.

As opp/adj increases, the θ value gets increasing and vice versa.

Opposite side and hypotenuse side

As we can see opp/hyp is directly proportional to θ.

As opp/hyp increases, the θ value gets increasing and vice versa but not at the same rate as opp/adj.

Adjacent side and hypotenuse side

Here we can see adj/hyp is inversely proportional to θ.

As adj/hyp increases, the θ value gets decreasing and vice versa.

Let’s combine the results we got.

opp/adj ∝ θ, Increasing in the rate r1.

opp/hyp ∝ θ, Increasing in the rate r2.

adj/hyp ∝ 1/ θ, Decreasing in the rate r3.

Thus by finding the rate, we can able to equate the relation like,

• opp/adj = r1 * θ
• opp/hyp = r2 * θ
• adj/hyp = r3 * θ

Now you might have realized that these equations look familiar. Let’s see…

• opp/adj = tan(θ)
• opp/hyp = sin(θ)
• adj/hyp = cos(θ)

Yes, the rate we need is given by “sin”, “cos”, “tan”, “cosec”, “sec”, “cot”. Simple as that. It gives the value from the θ based on the sides we use.

Since there are 3 sides in a triangle, It makes 3 combinations of sides. Each combination needs a different rate factor. Thus having “sin”, “cos” and “tan”.

“cosec”, “sec” and “cot” are nothing but the inverses of “sin”, “cos” and “tan”.

Now, let’s try to solve our problem,

• Height of the monument = 64.4m
• The angle of view = 29.5°
• Distance between me and the monument = x

Solution:

Opposite side = 64.4m

θ = 29.5°

Adjacent side = x

Since we know the opposite side and we need to find the adjacent side of the triangle, tan(θ) is the one having both opp and adj sides.

tan(θ) = opp/adj

=> tan(29.5°) = 64.4 / x

since tan(29.5°) = 2.78

=> 2.78 = 64.4/x

=> x = 64.4 / 2.78

x = 23.165 m.

Thus I need to stand 23.165 m from the monument to cover the entire height.

In case you wonder, what monument I’ve photographed?

It’s Brihadeeswara Temple ( Thanjai periya kovil ). If you haven't seen it in person, I recommend you to take a look. It’s such a fabulous place.

For more images of mine, https://www.instagram.com/bharathh_raj/

Congratulations, We have successfully built (basic) Trigonometry from scratch ourselves.

Now we look at an important question,

What is Trigonometry?

Trigonometry is a branch of mathematics that studies relationships involving the lengths and angles of triangles.

Thus with Trigonometry, we could find the third side if we know the other 2 sides.

Also, we could find 2 sides with one known side and θ.

Real-world applications

• Trigonometry can be used to measure the height of a building or mountains,
• Trigonometry used in navigation,
• It is used in the naval and aviation industries.

For more use cases, visit this.

Do you remember I told you I will talk about how trigonometry solves non-right-angled triangles? I also told you it was so cool.

If we think about it, we can easily divide any non-right triangle into 2 right triangles. Thus we can easily solve 2 right triangles to solve the non-right triangle.

Application in programming

Sometimes, we need to draw some custom shapes where we need some exact points to draw in the canvas. In such cases, we can use a circle as a reference to find the exact points we need.

We can clearly see that the “r” radius of the circle is nothing but the hypotenuse side.

We can solve this by,

x = r * cos(θ)

y = r * sin(θ)

Let’s understand this formula,

• x = adj side
• y = opp side
• r = hyp side

Revamping the formula,

adj = hyp * cos(θ)

opp = hyp * sin(θ)

Since cos(θ) = adj/hyp and sin(θ) = opp/hyp,

• x = r * cos(θ) is nothing but adj = hyp * adj/hyp
• y = r * sin(θ) is nothing but opp = hyp * opp/hyp

I hope now it all makes sense.

The trigonometry I covered in this article is just the basics. There is much more to learn.

Thanks for reading. If you like this kind of teaching or you have any suggestions or find any mistakes, feel free to use comments.

If you learn anything new from this article, just give me a clap.

Follow me on Medium and Instagram for more such articles.

If you like this article, take a look at Why do we need the Hexadecimal number system?

Thanks!

Is TRIGONOMETRY that hard? Let’s build it from SCRATCH. was originally published in Math Simplified on Medium, where people are continuing the conversation by highlighting and responding to this story.

You all might came across the question, Why couldn’t we simply use our traditional human-understandable decimal number system instead of those complex number systems like binary, octal, hexadecimal?

For example, the decimal number 512 is represented as

200 in Hexadecimal number system,

1000 in Octal number system,

0010 0000 0000 in Binary number system.

It obviously doesn’t make sense right? So, why do we need them again?

Also, you might have heard that the hexadecimal is human-readable other than decimal.

Ok, let’s break it down.

We all know that computers could not able to understand any form of number system without the protocol. It knows only 2 different digits. Either 0 or 1. It is known as binary.

At the hardware-level either the current flows, which is represented as 1 or not, which is represented as 0. Yes, Computers are so dumb. But humans can understand 10 different digits(0,1,2,3,4,5,6,7,8,9).

So at the time of the dawn of computing machines, Scientists are so obsessed with solving the problem of how could we ever make the computers understand human-readable digits.

At first, they think of the solution, by varying the power passing through the wire(system bus), they can able to make the computer understand different digits.

For example,

1 watt to represent the digit 0

2 watt to represent the digit 1

so on…

As you might have noticed there are many cons with this approach.

• First of all, at each level of processing and storing, we need to convert different power to a different digit.
• There are not only 10 digits we need to consider. We have different symbols like , ( % > “ . 26 English alphabets. There are also lower case letters. Also, there is a large number of languages with a different number of characters. In order to serve all these needs, we need to have a different power for each character. That’s hard for machines too.
• Due to those large numbers of different power possibilities, we need to limit the power difference between two consecutive characters. In such a small scale difference, wire’s resistance and length of the wire can vary the current passing through them.

But Bharath, we have a solution to that problem right?

• Just lower the current and increase the voltage to overcome this issue. But varying the voltage frequently causes voltage fluctuation, which is very bad for electrical components. Else we could add a transformer at every storage and processing layer. That sounds pragmatic😂😂😂.

Then at some point, people thought in order to represent a large decimal number, they just used a combination of the existing decimal numbers.

That thought gave the idea of combining binary numbers to get large numbers. But how to combine them?

That part also comes from the traditional number system. After the decimal numbers 1, 2, 3, 4, 5, 6, 7, 8, 9, we start to combine numbers to make 10, 11, 12…

Like that, in binary after 0 and 1, we start to combine 2 numbers(bits) to get 10 which represents 2, 11 which represents 3. Then we combine 3 bits 100 to get 4 and so on…

Now everything is fine and good. we can make the computer understand every number by combining binary digits.

Ok, the problem with this is that we need to make the computer understand when to look for the next character. For example,

For the number 1024, the binary number is 010000000000

and for number 1, the binary number is 1.

Here both numbers have different numbers of digits. Thus the computer could not understand when to look for the second number.

In order to rectify this issue, number systems were formed.

Now coming to the real question. Why do we need the Hexadecimal number system?

The main objective here is to have a group of bits that should more or less match the decimal number system which is human-understandable.

Which is how many binary digits we need to group to form the number system which should satisfy human needs.

Let’s start with a single bit. Obviously, it can represent either 0 or 1. Which is not enough for us.

Ok, let’s move to two bits. It can represent

• 0(00)
• 1(01)
• 2(10)
• 3(11)

which is also not enough for us, since we do more complex math which required more digits than these.

Then we move to three bits. It can represent

• 0(000)
• 1(001)
• 2(010)
• 3(011)
• 4(100)
• 5(101)
• 6(110)
• 7(111)

This is better than having 2 bits. It also misses only 2 decimal digits(8 and 9). We can able to manage the shortage of 8 and 9. Thus it evolved as the octal number system Since it can represent 8 decimal digits by using 3 binary digits. This is better but not perfect, thus we move to four bits.

Let’s see what a four-bit number system can do

• 0(0000)
• 1(0001)
• 2(0010)
• 3(0011)
• 4(0100)
• 5(0101)
• 6(0110)
• 7(0111)
• 8(1000)
• 9(1001)
• 10(1010) => A
• 11(1011) => B
• 12(1100) => C
• 13(1101) => D
• 14(1110) => E
• 15(1111) => F

It could satisfy our needs. However, it also represents digits which we don’t need. We could simply neglect those extra digits from a to f, right?

Actually, these extra digits have some advantages.

In order to get this, we need to understand what is the advantage of using decimal over binary?

Obviously, we can represent a large number with fewer digits.

For example,

In order to represent 1024 in binary, we need 11 digits. (10000000000)

Same way, in order to represent 999 in octal, we need 4 digits. (1747)

But the number 1024 in hexadecimal is 400. and the number 999 in hexadecimal is 3E7. Which minimizes the number of digits we need to use. This reduces the calculation time.

Thus, the hexadecimal number system is pretty much used everywhere.

We can even go higher than four digits, but those could not be human-readable. So we stick with the hexadecimal number system.

Now you may ask Bharath, for numbers it is ok. But for alphabets and special characters?

That is where different character encoding standards came in. eg. ASCII, Unicode, etc…

Additional note:

Quantum bit(qubit) can represent different states at once. Which is known as quantum superposition. i.e. 4 qubits can represent the same 16 combinations but all at the same time. which means it can compare all possible states at once. It sounds astonishing, right? Let’s see about that in detail in upcoming articles. Thanks!

return;

Why do we need the Hexadecimal number system? was originally published in CodeX on Medium, where people are continuing the conversation by highlighting and responding to this story.

First of all, If you didn't read my article “Why OOPS?” check out that one to have good continuity.

Today we are gonna learn about Encapsulation.

Encapsulation is one of the four principles of OOPS.

So, what is Encapsulation?

Encapsulation is just hiding the variables(properties) and functions(methods) of the same entity behind a Class. Those properties and methods can only be accessed by its object.

So, Why to hide those?

If we didn’t hide those, then any other variables or functions can able to access or change the data.

Ok, let’s see what was the real problem solved by encapsulation.

Scenario:

Let’s consider we need to process some data of a mom and her son.

For mom, we need to have her name, age, present month’s income one, present month’s income two, total savings, and the function which calculates the sum of the total amount she has.

For her son, we need to have his name, age, grade, math score, physics score, and the function which gives the total marks he scored.

Let’s solve this problem

• Without Encapsulation
• With Encapsulation

I’m using java to demonstrate these scenarios.

Without Encapsulation:

Hey Bharath, It seems like everything is clean and well organized. What’s the problem here?

Problem One:

Accidentally/Willingly accessing the wrong function.

Guess what will happen if son accidentally passed mathScore and physicsScore to the function “sum”, he will get 10574 as the total mark.

Guess what will happen if mom accidentally passed incomeOne and incomeTwo to the function “total”.(“This Little Maneuver’s Gonna Cost her 51 Years”😂)

Problem Two:

Your mom can access your score😱 just by calling the mathScore or physicsScore variable.

Ok Bharath, I got it. I won’t ask any other question 🤐. Just tell me how to hide.

Problem Three:

Caution: The stunt I’m gonna share is very dangerous and potentially fatal! Do not attempt this stunt without proper training!

Son can able to change his scores.(I never did that😁)

Here comes the Encapsulation part.

With Encapsulation:

Solution for problem one:

Encapsulation hides the variables and functions behind its object. Thus they cannot be accessed accidentally/willingly.

Solution for problem two:

No one can able to access your properties.

Solution for problem three:

It can even be secured with private properties and accessing them using getters. So that even the son cannot change the scores once assigned.

Bravo! We did it.

Thanks for your support guys!

return;

I like to divide this article into two parts.

• Without OOPS
• With OOPS

For easy understanding, I write the code snippets in java.

Scenario:

What if we have to process a large number of student’s details?

The details include their name, class, section, rank.

Without OOPS:

Without OOPS means obviously no classes. Then what do we got?

Primitive data types include:

• Byte
• Short
• Int
• Long
• Float
• Double
• Boolean
• Char

Non-Primitive data types include:

• String
• Array
• Classes ( I’ll come back to this later)

In order to store the Name, String must be the best option.

For Class, we can also use String.

For Section, we can use Char.

For Rank, we can use Int.

For Simplicity's sake, we consider there are only 3 students.

In order to store data of 3 students we need

Pros:

• You can call HTML as a programming language. (😂😂😂)

Cons:

• As you might have guessed, for more number of students more number of variables are needed.
• Keeping track of all those variables is a nightmare.
• Variables are vulnerable to accidental changes.

Ok, now look back at the code snippet above, and let’s try to understand something.

For all the names we used Strings, for all the classes we used int, for all the sections we used char and for all the ranks we used int.. i.e. common data type for common data. Yeah! You got it again.

It’s time for Hurray(Array😂😂).

By using Array, we can shrink the code to

Pros:

• Somewhat manageable.
• It does not require too many variables.

Cons:

• If a student’s name is removed from the array, we need to move most other student’s names.
• Also, we need to change the location of every other detail as well. Thus Maintainability is a dream.

Now, let's move to the more pragmatic approach. “THE OOPS APPROACH”

oh oh oh! wait. Don’t get scared by seeing its size. Let me explain.

Classes are nothing but to group different properties of the same entity. Here, for a student entity class, section, rank are the different properties. Of course, we can add any number of properties.

So why Classes again?

Pros:

• It does not need to have lots of variables.
• It does not need to change if someone’s data is changed.
• Accessing a property is very simple as <Object name>.<Property name>
• Encapsulation, Inheritance, and Polymorphism (What the *hello world* are those???🙄). Let’s see in another article. But trust me they are “Hello Universe!”. OOPS! It seems like I missed one principle. Let me know in the comments.
• Code reuse.

Cons:

• Honestly, I couldn’t come up with any cons. If you know any, let me know in the comments.

Also, we can use a constructor to reduce boilerplate.

Bravo! We did it.

Ok! wait, don’t forget to attend the death ceremony of those large numbers of variables and misused arrays. At least they served this long!

return;