CheerMeOn is a startup that wished to create an app, which would measure any goal a person might set for themselves. They knew that this was impossible, so they came to us with a shortlist of the objectives. We persuaded them that, for starters, they should go with one goal only. They agreed. And together, we developed a successful app.

First things first, the MVP

It is not unusual that the Partner asks us to create an application with several functionalities. But seldom do we develop such a product from the start. The complicated software is hard to test and hard to pitch to the VCs. We had to create something small and simple at first, the MVP. We cut CheerMeOn’s initial idea down to setting and tracking progress for the weight loss only. To this day, the app is quite similar to the MVP and is thriving.

How does this successful app work?

CheerMeOn is a simple weight loss tracker. The user puts in,

• Their current weight
• Their target weight
• The time in which they want to achieve the target weight

The app encourages the users to share their progress on social media too. Two psychological insights underlie this functionality. On the one hand, letting other people know about your targets makes you feel accountable; on the other, it triggers peer pressure from those who learned about your goal.

The technologies we used

We used React Native and Firebase, joined with Hasura hosted on Heroku. Thanks to this conjunction, we could use a relational Postgres database with graphQL API instead of the NoSQL Firebase Firestore database. We preferred the relational database because CheerMeOn benefits from uploading the feed with posts and comments. This functionality is much easier to implement with the use of the relational database.

And we are still developing!

The Partner is so happy with us that we are still working together today.

One of our long-term targets is the further development of the application so the users could set various goals like quitting smoking, creating a habit of regular training and so on. Our other long-term target is making the app more and more engaging to attract new users faster.

The collaboration

The collaboration has been going smoothly so far. The Partner had his bold vision when they came to us, but as I already mentioned, they agreed to reduce it to just one goal. They trusted us fully, and we are very thankful for it!

During our bi-weekly sprints, CheerMeOn usually praised us. They were pleased with our job’s results and not really interested in the processes that led to them.

Takeaways

• CheerMeOn is an example of a successful app that started as a complex idea
• For now the app tracks weight loss only
• We plan to enrich it with the functions the Partner desired at the beginning

Bonus; how to optimize Firebase Cloud Storage?

The genuine challenge we encountered while working with various Firebase projects was Cloud Storage Optimization. Below I will describe this problem based on an example from my experience.

Even though we didn’t have any Cloud Storage files, the indicator showed almost 425 MB of data.

Surprisingly, we found 63 objects in the Cloud Storage, even though we hadn’t kept any files there!

We went to https://console.cloud.google.com/storage/browser to find the Cloud Storage Buckets list. We have found the eu.artifacts mentioned above on this list. They were cache files that hadn’t been removed automatically.

Our further research showed that these files were connected to Cloud Function in Node Js v10 environment. More specifically, 4 small cloud functions (which had 10 to 15 lines of code). Each time we upgraded our functions (deployed them on the Firebase), new artifacts were generated. 

To optimize this issue, you need to go to console.cloud.google.com (link above), choose artifacts bucket, and click on the lifecycle tab.

Then, you need to add a new rule, “Delete object.”

After you click “Continue,” you should choose “Age” and fill the bracket with the number of days after which the artifacts should be removed automatically (we have decided to go with 3). Press continue and confirm with “Create” button.

Thanks to learning this, we know we can reduce the cost of the projects that use Firebase. The free limit of Cloud Storage is 5 only GB and some projects can generate even a few dozen of gigabytes with the mechanism I described above. The knowledge and experience we gained allow us to give you a better price for the apps that we develop using Firebase.

As a developer, you may face the need to introduce a payment method in the application logic at some point. Business is business, after all, and even a few cents at the end make a difference, regardless of you being a startup, scaleup or a corporation.

When you work with a backend infrastructure there are plenty of different players in the payment and credit card processing as a service to work with, and today we will focus on one of the most interesting and flexible solutions we have had to deal with recently.

Sorry, we’ve already spoiled it in the title, but it’s obviously Stripe we’ll be tackling here.

Libraries

One of the first checks that I like to do on an as-a-service solution is to figure out what is the language supported natively (and also if any third-party developer might have enhanced any of those already).

Support for Stripe is pretty wide. In the case I am going through in this article, I focused on Node.js to dig down a bit more and noticed that apart from the original library done by the original team, we have more than 640 other packages on NPM.

For sure it is something to think about, but mostly I see integration with the third-party framework, so nothing that makes me scared like “Oh, it’s so over-engineered that someone had to create a wrapper to make it more humane”.

Also, as you can see below, the library is being kept up to date. Since Stripe makes releases very often and timely, we can say that their average sprint time is around 1 week. Conclusively, the frequency of Stripe’s bug updates and fixes can be associated with the security of their library.

Having this in mind, all I need to do is to keep my package.json a bit more updated than usual, but I’d rather bother myself with periodic updates than regret and waste time for avoidable issues.

Last, but not least, even the attention with which Stripe treats PR seems quite tailor-made:

On top of that, Stripe’s willingness to accept PR and fixes even from externals is also worthwhile :+1:.

By the way, Stripe’s library supports typescript bindings too, so if you love force types - it’s a good one!

Documentation

As an old school developer I love to have clear documentation. I’m from the pre-internet era when books were the source of truth and you had to rely on them and trust them in order to accomplish anything. In this respect, I pay a lot of attention to having a well-documented API.

And this is where I think Stripe is able to provide a very detailed API reference to dig and play with before any implementation, which is very helpful.

Digging around is quite easy to get familiar with their unique naming conventions and to prepare a high-level flow of the steps we will need to achieve our project’s business goals.

A dedicated section is linked to errors, usually pretty verbose and detailed.

Worth mentioning, the package for Node.js supports automatic pagination, so again something less to be worried about.

TLDR; if you, unlike me, hate documentation and want to jump into the center of it as fast as possible, there’s a very detailed quick start documentation too with some examples of basic payment flows. Worth taking a look into it!

As mentioned before, Stripe's huge advantage is a micro-feature API structure that allows you to manipulate flows in the most profitable way for your company.

Keep in mind the first rule of business that rightfully claims not all the businesses work in the same way, hence both customization and flexibility Stripe provides are the two most essential features.

I know that first hand. Recently I had to take care of implementing Stripe’s API in two different projects. One of them was more of a common eCommerce approach with payment as the last step of the user flow to finalize the whole order. Pretty standard, no?

The second one involved more custom approach with steps that included credit card verification or payment holding during the pre-transaction and background check.

To be honest, I was very worried about the second one at first. According to my previous experience with other suppliers, namely the nightmare of having to debug the outdated documentation and figuring out how to deal with the related bugs.

In comparison Stripe seemed like a salvation right off the bat! I managed to achieve the goal quite fast and the documentation was well-prepared. and supportive, using the verbose response and snippet examples for your language. Time saver!

Deployment of Stripe

As a developer myself, I suggest having at least a bit of development training first (this is not entirely a no-code solution after all). Apple did it very well with Playground tool which is a powerful instrument as a sandbox for Swift code, where you can experiment quickly and easily without having to create the whole project. It is a way to test some algorithms or functions in a lean and fast way without wasting time on creating the whole project. For Node.js you can still find similar options like JSFiddle. Make sure you use them before taking your VSCode and creating a dummy project to save yourself some time.

Don’t forget to register to Stripe website before you dive deeper into integrating its API with your website or app.

One thing I’m pretty sure of is two keys that will become your best friends at the beginning of your journey through the Stripe’s sandbox:

• Publishable key
• Secret key

They can be found in Stripe Dashboard under the API keys section. Below you can see how they should look like.

Before you start any action, remember to switch to “Viewing test data”.

The orange colour of UI will confirm that you are sandboxed. By using this feature you will avoid a real financial transactions using any dummy card.

Okay, so we'll start our simulation with the most common flow for the eCommerce market, where we'll keep the user's payment details for future transactions. By the way, if you are interested in the eCommerce market, we recommend you to check out our article regarding the worst aspects of online shopping.

One additional aspect, assume we do not use any official or external credit card helper to collect the data. We will simulate that the data comes from a custom field.

But before you start writing your first line of code remember to check the logic of the whole process - always.

Once you have familiarized yourself with the above flow, you can go to the appropriate reference in the Stripe documentation. Now let’s get down to business.

Step 1

We have already gone through Libraries and Documentation - it's time to create a project:

Once we do this we should run our favorite editor and take a deep dive into the project.

Create a file called index.js and integrate Stripe API. In order to do this you just have to run following the command in the directory of our project:

Step 2

Let's create a boilerplate in the index.js to be able to use async/await approach:

const stripe = require('stripe')('REPLACE_WITH_YOUR_SECRET_KEY');
 
// helpers
const createUser = async () => {};
 
const addCreditCard = async (user, card) => {};
 
const processPayment = async (user, card) => {};
 
(async () => {
 try {
   console.log('Stripe demo');
   // TODO: create user
   const user = await createUser();
   // TODO: add credit card to user
   const creditCard = await addCreditCard(user, {
  	number: '4242424242424242',
  	exp_month: 9,
  	exp_year: 2021,
  	cvc: '314',
   });
   // TODO: create payment intent for user
   await processPayment(user, creditCard);
 } catch (e) {
   console.error(e);
 }
})();

I added a few comments in the code and intentionally left some console.logs to speed up the debugging, but the point is to mimic the flow that we defined above: create a user, add a credit card and finally process the payment.

In case you wonder: 4242 4242 4242 4242 is a dummy credit card that is supported by Stripe.

Remember to replace the secret code with one of your accounts. Otherwise, it will not work and you may be disappointed.

Ok, at this point we should focus on creating a client by adapting the code like this one below.

const createUser = async () => {
 try {
   const customer = await stripe.customers.create({
     email: 'jdoe@example.com',
   });
   console.log(customer);
   return customer;
 } catch (error) {
   console.error(error);
 }
};

As you can see, we are using the customers.create API, in particular, we are going very lean in this case using just the email, but we can provide additional data for the user, if needed.

Step 3

Next step is to add the credit card. Below you can find how the snippet will look like.

const addCreditCard = async (user, card) => {
 try {
   const paymentMethod = await stripe.paymentMethods.create({
     type: 'card',
     card,
   });
   console.log(paymentMethod);
   const attached = await stripe.paymentMethods.attach(paymentMethod.id, {
     customer: user.id,
   });
   console.log(attached);
   return paymentMethod;
 } catch (error) {
   console.error(error);
 }
};

Now, here we have to combine two APIs under the same roof: paymentMethods.create and paymentMethods.attach.

We need to create a payment method with our credit card data (code, expiry, CVV, etc.) and associate it with the user we have created a moment ago.

Step 4

Our last step is to put everything we’ve done so far together and process the payment:

const processPayment = async (user, card) => {
 try {
   const paymentIntent = await stripe.paymentIntents.create({
     amount: 1250,
     customer: user.id,
     currency: 'usd',
     payment_method: card.id,
   });
   console.log(paymentIntent);
 } catch (error) {
   console.error(error);
 }
};

Our wingman here is the paymentIntents.create function, it requires just a few parameters passed as an object:

• Amount
• Customer
• Currency
• Payment method

It shall be pretty straightforward from now on. You might, however, be wary of just one potentially tricky element…the amount.

Remember that Stripe API is expecting the amount as an integer number, so you will need to add a little helper to convert it, according to this logic:

$10,00 → 1000

$10,50 → 1050

$0,50 → 50

OK. so now it’s turn to run the code.

Let’s use:

And a little of JSON will start kicking in into our terminal.

You can also open Stripe Dashboard (remember to set the test mode!) and double check the payment and the user just created.

And we're done. It's time for you to start counting the incoming influx of cash from your eCommerce. Happy hunting!

If you want to see the whole code and play a bit with it - feel free! You can find it here.

P.S. Once you’re a millionaire, thanks to this, don’t forget to say thanks by letting us do some development work for you, will you?

HQ Trivia needs no introduction. It has had its ups and downs but one cannot deny the fact that when released, it was a completely new type of experience on our mobile devices and it took the market by storm notching 10 million downloads on Android and iOS devices.

How HQ Trivia works?

HQ Trivia has been all about questions and answers. And the question you may be asking yourself right now is how it all looks like under the hood?

There are a lot of moving parts inside the app’s engine, but one that plays the most crucial role is the producer panel that controls all sorts of stuff happening during the game.

It all starts with the creation of the new game, selecting what type of game it should be, and scheduling when should it happen.

The next step is, of course, adding a set of questions for which you can select a category, add possible answers, and then select which one of them is the correct answer. But that’s just the beginning.

Some questions, as you may know, have videos, photos, or audio files attached to them, and this is the place where the producer can add all of those things to the questions.

Then there is also a matter of not all questions being created equal from a reward standpoint.

After some questions, there are checkpoints that allow players to finish the game and get some bonuses or continue if they’re feeling lucky. This is also something that will be set during the process of creating questions.

The producer can also specify how many coins a specific checkpoint offers to the players. He basically designs the whole in-game reward/gamification system as he plunges in more questions for the day ahead.

Another feature that is a part of the process of game creation is adding gift drops. They won’t be appearing in every game, but have to be prepared and attached to specific questions in advance.

The challenges of HQ Trivia mechanics

As you can see there is a lot happening before the game even begins, but what happens when questions start to pop up on your screen. How do they even get there? Are they being sent to devices in advance? Or maybe there’s a way to take a look at them before they are asked?

It’s not that simple. It turns out the only safe haven for trivia questions to queue before they appear on players’ screens is the backend.

HQ knows this very well and that’s why they send each question only when the time is right, which is when the question is being asked. The way it’s being done is through socket connections which keep each player connected to the server for the entire duration of the game.

Sockets vs REST API

Let’s have a quick look at what sockets are and how they differ from REST APIs, which are used by most apps on our phones.

REST APIs are interfaces that allow us to get specific data from the server. It may be weather, recipes, or photos on Instagram, but the way the communication between devices works is the same: the app asks the server for some data, the server then answers by sending the requested data and the connection is closed.

You can read more about REST API in our article on integrating Google Fit with an Android app.

Sockets on the other hand keep the connection between the app and the server alive for as long as it’s needed, and this allows messages to go back and forth with no need to re-establish the connection.

Those messages, like in HQ Trivia’s example, may contain different kinds of data. For instance, when the presenter is ready to ask the new question, the producer simply clicks the “Start question” button which causes the server to send a message containing said question to all of the players, who then see the question appearing on their screens. Such a message doesn't contain the answer to the question, in case you were wondering, which makes this type of connection the safest for HQ Trivia's purpose.

This is how it works in practice:

1. 10 seconds after a question pops up on the screen, all the players are given the answer.

2. The results are being sent in the exact same way as questions, using a socket connection.

3. The producer selects the option to send the question summary which triggers the server to send each participating player a message with data such as:

• What was the correct answer?
• Was a player correct or not?
• How many points the correct answer has awarded the player?
• How many players selected particular answers?
• How many players are advancing to the next question?
• How many were eliminated? 

4. In the event of a player being wrong, the message will also contain the info whether the player should be saved by an extra life or a free pass or if he or she was eliminated.

Conclusion

I hope you enjoyed this behind the scenes of how HQ Trivia creates its quizzes. And hopefully, learning about it will help you come up with your idea for the next big thing.

If that’s the case, then we - at intent - will be happy to help you bring the product to life, using our extensive knowledge and experience. Don’t hesitate to contact us.

With the influx of health-conscious customers, ensuring that your fitness product delivers a holistic, integrated service is growing ever more important.

Every creator of a health-oriented application is practically obliged to connect it to a fitness service to facilitate the seamless transfer of data between various (often competing) applications. In the Android world, that solution is the Google Fit API.

REST API vs SDK

As is standard for Google’s server APIs, there are two ways to communicate with the server:

• classic REST API
• through SDK, which connects to the server on its own

These solutions do not share a code base, so for example, slightly different fitness activity (as in “rowing” or “kayaking”, not MainActivity) types are available:

Google Fit activity types list

Google APIs for Android documentation list

(Note the lack of “Guided breathing” activity type for SDK.)

The choice between the two mainly depends on the level of technical sophistication of the SDK - if it’s advanced enough, well maintained, and documented, it is almost always more convenient to use than raw REST endpoints.

However, some optimization techniques, especially in using cached data, might mean that the data provided by the SDK is less reliable than acquired directly. At least until recently, this was the case with the Fit APIs (plural), with its Local Storage (described below), so that is something worth testing before deciding on an approach. 

Local Storage vs Fit server

In order to improve performance and reduce server load, most API calls do not connect to the Google Fit server, using the local store for a reading and writing data instead. Unless explicitly demanded, data propagation happens only every few hours. This can lead to confusion if, for example, you expect the changed data to be immediately available on another device. On the other hand, this does make the data accessible to any local Fit-integrated applications even without a network. 

This is particularly important to keep in mind when testing the application since with data sync not happening immediately, false negatives can be reported.

On the other hand, all local changes will be available immediately, even if the device doesn’t have a network connection at the moment. This is a great solution performance-wise, but quite confusing (and currently under-documented) during testing. With that, of great help will be the Playground:

Oauth 2.0 Playground

One feature of Google APIs I personally found particularly useful was the possibility of seamless online testing of its REST APIs. Not just for Fit - the list is astonishingly long and only keeps growing. With real data underneath, the Playground allows for quick verification of the stored data, before writing a single line of code. 

Recognizing custom activities

As is often the case, an application might need to separate the Fit activities created by it from the remaining activities. There are two approaches to achieve that:

• using the app package name
• using a unique activity session identifier pattern

The first one is straightforward - simply call setAppPackageName when creating an activity, and verify that value when checking the downloaded activity’s type. The obvious downside is that this value will be identical for all activities an app creates, so if a more sophisticated separation is required, the package name alone is not enough. That’s when the naming pattern comes in - set the session identifier according to the chosen pattern and then verify, like below:

private fun activityIsCustomActivity(session: Session): Boolean {
   return session.activity == FitnessActivities.KITESURFING
    && CUSTOM_SESSION_KEY_REGEX.matches(session.identifier)
}

Data type permissions

In times when user’s privacy is an ever-growing concern, it is increasingly important to guarantee that an application will know about the user only as much (or as little) as it is required for it to function. It is entirely feasible for a user to wish to allow an app’s access to his basic biological data, but withhold some more sensitive data such as heart rate. In response, Fit allows very detailed compartmentalization of the accessed data. 

fun syncOptions(): GoogleSignInOptionsExtension =  FitnessOptions.builder()
             .addDataType(DataType.TYPE_ACTIVITY_SEGMENT, FitnessOptions.ACCESS_READ)
             .addDataType(DataType.TYPE_ACTIVITY_SEGMENT, FitnessOptions.ACCESS_WRITE) 
 

                   .addDataType(DataType.TYPE_HEART_RATE_BPM, FitnessOptions.ACCESS_READ)

 
             .addDataType(DataType.TYPE_HEART_RATE_BPM, FitnessOptions.ACCESS_WRITE)

 
              .addDataType(DataType.TYPE_HEIGHT, FitnessOptions.ACCESS_READ)
             .addDataType(DataType.TYPE_HEIGHT, FitnessOptions.ACCESS_WRITE)
             .addDataType(DataType.TYPE_WEIGHT, FitnessOptions.ACCESS_READ)
             .addDataType(DataType.TYPE_WEIGHT, FitnessOptions.ACCESS_WRITE)
             .build()

 

List of Google Fit datatypes.

Read data - example

For a simple example, let’s read the user’s height data from the server. First, we need a working Google Account object:

val signInAccount = GoogleSignIn.getLastSignedInAccount(context)

If the signInAccount value is not null, the app is authenticated, but not yet authorized. We need to request the permission to read/write data of the required data types.

fun syncOptions(): GoogleSignInOptionsExtension = FitnessOptions.builder()
              .addDataType(DataType.TYPE_HEIGHT, FitnessOptions.ACCESS_READ)
             .build()

val requestCode = 123
GoogleSignIn.requestPermissions(activity, requestCode, googleSignInAccount, syncOptions())

The SDK will display a permissions dialog to the user. The result of the user’s action will be returned in a standard onActivityResult callback. To use the SDK later, we only need to check if the permissions are still granted (as in they have not been revoked)

val hasSyncPermission = GoogleSignIn.hasPermissions(signInAccount, syncOptions())

If permitted, it is finally time to read the data from the server. We only need the latest height data, so the limit will be set to 1. We want to make sure that we get data from the server and not just from the local storage, so we set the “enableServerQueries” flag. And of course with the full-time limit, to get even the oldest data.

fun readPersonalProperty(
signInAccount: GoogleSignInAccount, dataType: DataType): Task<DataReadResponse> =
        Fitness.getHistoryClient(context, signInAccount)
                .readData(DataReadRequest.Builder()
                        .read(dataType)
                        .setTimeRange(1L, Instant.now().epochSecond, TimeUnit.SECONDS)
                        .setLimit(1)
                        .enableServerQueries()
                        .build())

readPersonalProperty(signInAccount, DataType.TYPE_HEIGHT)

Sensors data

Of all the APIs that compose the full fitness solution, Sensors Api is of particular importance. For all health applications that do not have a backing hardware device (like a bracelet or ring), the smartphone will be the source of all new data. 

In general, sensors on Android devices belong to three categories:

• Motion sensors - measure acceleration and rotation along three axes
• Environmental sensors - measure i.e. light, temperature, ambiance or air pressure
• Position sensors - measure the physical position of a device

The availability of sensor data depends on the presence of sensors of different types inside the device, hence the need to verify that in your application, before querying for the data. Therefore, a fallback mechanism needs to be implemented to provide a satisfying user experience even if most sensors are absent or malfunctioning.

Most of these sensors can have varying accuracy, of which the application will be notified by the onAccuracyChanged callback - particularly important for uses that require fine-grained data.

Photo by Ketut Subiyanto from Pexels

Arduino has been around for years, and you've probably heard the term. It is an open-source electronics platform that allows developers to connect hardware with software easily. The popularity of Arduino is vast because it offers a simple and accessible user experience. As an iOS developer, I wanted to play around with this platform, so I've built a toy car that can be controlled with a mobile app. Read this article to find out how I did it.

Project outline

There are two key components in this project:

• Arduino based toy car.
• iOS application for controlling it (connected via Bluetooth Low Energy)

You can see the final result in the picture below. On the left side is an iOS application, on the right side, a toy car.

iOS application

Let’s start with the car controller (iOS application). In this article, I won't go into details about iOS application implementation. I will describe briefly how it works from the user perspective.

The application connects to Arduino using BLE (Bluetooth Low Energy).

After launching it, the device discovery screen is displayed. The application starts searching for Bluetooth devices automatically and displays devices with matching service UUID. User can restart device discovery by pressing the Search button (in case of network errors). The application can automatically connect to the last selected device by checking the Auto-connect checkbox.

The controller screen has four controls:

• Drive forward and backward (bottom left corner)
• Turn left and right (bottom right corner)
• Change gear (buttons 1-5)
• Headlights on/off (top right corner)

It shows connection status in the top right corner. By pressing the back button, the application disconnects from the car and navigates back to the device discovery screen.

Toy car

The toy car was built using mechanical parts from an old toy: chassis with wheels and 2 DC motors (one for driving, the other one for turning).

The custom components are Arduino, DC motor controller, Bluetooth, LEDs.

How to build it?

Hardware components

1. Arduino Due

Arduino is an open-source electronics platform based on easy-to-use hardware and software. It can be used for prototyping hardware devices. Implementation is very fast and in a few days, we can have a working device for real-world testing.

It is responsible for controlling hardware components (motors, sensors, LEDs), Bluetooth communication, and handling iOS application commands.

Arduino Due main characteristics:

• 32-bit ARM core microcontroller (84 MHz clock)
• 54 digital input/output pins (of which 12 can be used as PWM outputs)
• 12 analog inputs
• 4 UARTs (hardware serial ports)
• Board runs at 3.3V (unlike most Arduino boards that run at 5V)
• Compatible with all Arduino shields that work at 3.3V

2. Waveshare Motor Control Shield L293D

It is capable of driving 4 DC motors or 2 stepper motors at one time.

When using an external power supply of 9V it allows you to adjust the speed and direction of the motors with current consumption up to 600mA (1.2A peak) and a voltage between 1.25V - 6.45V.

Toy car has two DC motors: the first one is used for driving, the second one for turning.

3. Bluetooth module HM-10

HM-10 is a Bluetooth 4.0 module. It works with voltage from 3.3V to 5V, it communicates over a serial UART interface (RX, TX pins). The maximum transmitter power is +6 dBm, the receiver sensitivity is -23 dBm.

4. Two DC motors

DC motor for driving (operation Voltage of 3-6V, free-run current of 200mA).

Mini DC motor for turning (operation Voltage of 3-6V, free-run current of 30mA).

Choose your DC motors depending on the weight of the car.

5. LED lights

4 x red LEDs for turn signals

4 x white LEDs for headlights

6. Other components

• 8 resistors 220Ω
• Potentiometer 10kΩ
• 6 AA batteries (1.5V)
• Wires
• Breadboard
• Old toy car chassis

How to connect everything?

The photo below shows how components are connected. It doesn’t look pretty, but I assure you that it works :)

And here is a schematic diagram:

Let’s examine each and every component individually.

1. Bluetooth and the main application loop

One of the biggest advantages of Arduino is that there is a vast set of ready to use components and libraries available. They are very easy to use and don’t require us to write much code. They are named Shields. In this project, I used a Bluetooth Module and a DC Motor Control Shield. 

Let’s start with the Bluetooth module first. It communicates with the Arduino board using the Serial port.

Connect Bluetooth module HM-10 pins to Arduino board:

• VCC > VCC (5V or 3.3V)
• GND > GND
• RX > TX3
• TX > RX3

Main application setup

Define a helper macro named HC06 that points to a Serial3. configureBle() method starts Bluetooth connection.

#define HC06 Serial3

void configureBle() {
  HC06.setTimeout(100);
  HC06.begin(9600);
}

Define Bluetooth commands for controlling the toy car. iOS application sends commands to the Arduino. Currently, the application supports the following commands: drive, turn on headlights, change gear, turn.

Command length is 3 bytes.

First byte is a command code defined as an enum BleApiCommand.

Second byte is an additional parameter, depending on the command code:

• cmdDrive - speed: 0-127 (drive backwards), 127 (stop), 128-255 (drive forward).
• cmdHeadlights - 1 (turn headlights on), 0 (turn headlights off).
• cmdGear - gear integer between 1-5.
• cmdTurn - turn angle: 0-126 (left), 127 (straight), 128-255 (right).

Third byte is a command terminator 0x0f.

const int commandTerminator = 0x0f;
const int commandLength = 3;

enum BleApiCommand {
    cmdDrive = 0x23,
    cmdHeadlights = 0x24,
    cmdGear = 0x25,
    cmdTurn = 0x40
};

Main application setup method.

void setup() {
    configureLightsPins();
    configureMotorPins();
    configureBle();
}

Main application loop

Main application loop responsibilities:

• Read the Bluetooth command. If it is valid, invoke a handleCommand() method. It supports the following commands: drive, turn headlights on and off, change gear, turn.
• Turn signals work automatically when car turns, it is handled inside a turnSignalControllerTick() method.
• handleTurn() method positions front wheels to the given angle.
• stopIfDisconnected() stop car if controller is disconnected.

void loop() {
    int tickTime = millis();
    // Command loop
    while(HC06.available()) {
        byte buffer[commandLength];
        int size = HC06.readBytes(buffer, commandLength);
        if (size != commandLength) {
            continue;
        }
        lastCommandTimestamp = tickTime;
        handleCommand(buffer);
    }
    handleTurn();
    turnSignalControllerTick(tickTime);
    stopIfDisconnected(tickTime);
}

Handling commands

Extract command code and parameter, then handle each command in a separate method.

void handleCommand(byte data[]) {
    byte code = data[0];
    byte param = data[1];
    byte terminator = data[2];
    if (terminator != commandTerminator) {
        return;
    }
    switch (code) {
        case cmdHeadlights: {
            bool on = param == 0x02;
            setHeadlights(on);
            break;
        }
        case cmdGear: {
            setGear(param);
            break;
        }
        case cmdTurn: {
            turnWheels(param);
            break;
        }
        case cmdDrive: {
            drive(param);
            break;
        }
    }
}

2. Headlights and turn signals

Headlights

Headlights (white LEDs) can be turned on and off manually by the user using a button in the top-right corner of an iOS application.

 Connect each LED to a separate digital PIN through a resistor (220Ω) as shown in the diagram above.

Declare 4 headlights and 4 turn signals pins as constants and set their mode to OUTPUT.

const int pinHeadlightsRight1 = 22; // Remaining headlights pin numbers: 24, 26, 28
const int pinTurnSignalLeftFront = 31; // Remaining turn signals pin numbers: 33, 35, 37
void configureLightsPins() {
    pinMode(pinHeadlightsRight1, OUTPUT);
    pinMode(pinTurnSignalLeftFront, OUTPUT);
    ...
}

void setHeadlights(bool on) {
  int value = on ? HIGH : LOW;
  digitalWrite(pinHeadlightsRight1, value);
  digitalWrite(pinHeadlightsRight2, value);
  digitalWrite(pinHeadlightsLeft1, value);
  digitalWrite(pinHeadlightsLeft2, value);
}

Turn signals

Turn signals (red LEDs) work automatically - they blink every 0.5 seconds when the car is turning. They work in four modes: disabled, blink left, blink right, blink both sides.

Define mode as an enum and tick interval as constant.

Use turnSignalControllerSetMode() method to change the blinking mode.

enum Modes {
    idle = 0,
    blinkLeft = 1,
    blinkRight = 2,
    blinkBoth = 3
};

const int tickInterval = 500; // milliseconds
int lastTickTimestamp = 0;
int mode = idle;
bool ledOn = false;

void turnSignalControllerSetMode(int newMode) {
    if (newMode == mode) {
      return;
    }
    mode = (Modes)newMode;
    lastTickTimestamp = 0;
    updateState();
}

turnSignalControllerTick() method is called from the main application loop. lastTickTimestamp stores the last timestamp (number of milliseconds passed since the Arduino board began running the current program) and compares it with the current timestamp. The result is a timer with a 500ms interval.

void turnSignalControllerTick(int currentTimestamp) {
    if (mode == idle) { return; }
    if ((currentTimestamp - lastTickTimestamp) > tickInterval) {
      lastTickTimestamp = currentTimestamp;
      updateState();
    }
}

Method updateState() turns LEDs on and off depending on the current mode.

void updateState() {
  if (mode == idle) {
    ledOn = false;
  } else {
    ledOn = !ledOn;
  }
  int value = ledOn ? HIGH : LOW;
  switch (mode) {
  case idle:
  case blinkBoth:
    digitalWrite(pinTurnSignalLeftFront, value);
    digitalWrite(pinTurnSignalLeftRear, value);
    digitalWrite(pinTurnSignalRightFront, value);
    digitalWrite(pinTurnSignalRightRear, value);
    break;
  case blinkLeft:
    digitalWrite(pinTurnSignalLeftFront, value);
    digitalWrite(pinTurnSignalLeftRear, value);
    digitalWrite(pinTurnSignalRightFront, LOW);
    digitalWrite(pinTurnSignalRightRear, LOW);
    break;
  case blinkRight:
    digitalWrite(pinTurnSignalLeftFront, LOW);
    digitalWrite(pinTurnSignalLeftRear, LOW);
    digitalWrite(pinTurnSignalRightFront, value);
    digitalWrite(pinTurnSignalRightRear, value);
    break;
  }

3. Driving

Connect DC motors to the Motor Control Shield L293D:

• DC motor for driving to M3 interface.
• DC motor for turning to M4 interface.

Define and configure DC the motor pins

const int pinMotorDrive_dir1 = 8;
const int pinMotorDrive_dir2 = 7;
const int pinMotorDriveSpeed_pwm = 10;
const int pinMotorTurn_dir1 = 12;
const int pinMotorTurn_dir2 = 13;
const int pinMotorTurnSpeed_pwm = 11;

void configureMotorPins() {
    pinMode(pinMotorDrive_dir1, OUTPUT);
    pinMode(pinMotorDrive_dir2, OUTPUT);
    pinMode(pinMotorDriveSpeed_pwm, OUTPUT);
    pinMode(pinMotorTurn_dir1, OUTPUT);
    pinMode(pinMotorTurn_dir2, OUTPUT);
    pinMode(pinMotorTurnSpeed_pwm, OUTPUT);
    digitalWrite(pinMotorDrive_dir1, 1); // set forward direction
    digitalWrite(pinMotorDrive_dir2, 0); // set forward direction
    digitalWrite(pinMotorDriveSpeed_pwm, HIGH); // set to high to enable the L293 driver chip
    analogWrite(pinMotorDriveSpeed_pwm, 0); // set speed to 0
    digitalWrite(pinMotorTurn_dir1, 1); // set forward direction
    digitalWrite(pinMotorTurn_dir2, 0); // set forward direction
    digitalWrite(pinMotorTurnSpeed_pwm, HIGH);  // set to high to enable the L293 driver chip
    analogWrite(pinMotorTurnSpeed_pwm, 0);  // set speed to 0
}

Handle the drive command

Speed parameter (0-127 - drive backwards, 127 - stop, 128-255 - drive forward) must be converted into a speed (0-255) and direction. Choose the minimum speed/voltage depending on the car weight and DC motor parameters.

void drive(byte value) {
    int minSpeedValue = 100;
    int maxSpeedValue = 255;  
    if (value < 127) { // backwards
        digitalWrite(pinMotorDrive_dir1, 0);
        digitalWrite(pinMotorDrive_dir2, 1);
        int speedValue = minSpeedValue + (maxSpeedValue - minSpeedValue) * (127 - value) / 127;
        analogWrite(pinMotorDriveSpeed_pwm, speedValue);
    } else if (value > 127) { // forward
          digitalWrite(pinMotorDrive_dir1, 1);
          digitalWrite(pinMotorDrive_dir2, 0);
          int speedValue = minSpeedValue + (maxSpeedValue - minSpeedValue) * (value - 127) / 127;
         analogWrite(pinMotorDriveSpeed_pwm, speedValue);
    } else { // 127 stop
          digitalWrite(pinMotorDrive_dir1, 1);
          digitalWrite(pinMotorDrive_dir2, 0);
          analogWrite(pinMotorDriveSpeed_pwm, 0);
    }
}

4. Turning

Read current front wheels angle using a potentiometer

Connect potentiometer pins to the board:

• First outer pin to the ground
• Second outer pin to 5V
• Middle pin to the Arduino analog pin number A0

const int pinPotentiometer = A0;

int readPotentiometer() {
    int sensorValue = analogRead(pinPotentiometer);
    return sensorValue;
}

Convert the target angle

Convert target angle received from an iPhone (0-255) to integer (0-1024) in order to compare it with the potentiometer reading.

void turnWheels(byte value) {
    int minLeft = 300; // it means that the wheels are turned all the way to the left
    int maxRight = 900; // wheels turned all the way to the right
    int center = 600; // wheels are straight
    if (value < 127) { // turn left
        turnSignalControllerSetMode(1);
        float factor = ((float)value)/127.0;
        targetTurnValue = minLeft + factor * (center - minLeft);
    } else if (value == 127) { // straight
          turnSignalControllerSetMode(0);
          targetTurnValue = center;
      } else if (value > 127) { // turn right
          turnSignalControllerSetMode(2);
          float factor = ((float)value - 127.0) / 128.0;
          targetTurnValue = center + 1 + factor * (maxRight - center - 1);

      }

}

Turn wheels

Method handleTurn() does a few things:

• Reads the current wheels angle using the potentiometer. analogRead() returns integer value between 0-1024 which represents an angle.

• Calculates which direction to turn the wheels to - left, right, or stop when the angle is reached. 
• Starts/stops turn signals.

Choose the speed/voltage depending on the DC motor parameters.

  void handleTurn() {
    int sensorValue = readPotentiometer();
    const int tolerance = 20;
    const int speed = 130;
    if (abs(sensorValue - targetTurnValue) < tolerance) {
        // value reached, stop motor
        analogWrite(pinMotorTurnSpeed_pwm, 0);
    } else if (sensorValue > targetTurnValue) {
        // turn left
        digitalWrite(pinMotorTurn_dir1, 0);
        digitalWrite(pinMotorTurn_dir2, 1);
        analogWrite(pinMotorTurnSpeed_pwm, speed);
    } else if (sensorValue < targetTurnValue) {
        // turn right
        digitalWrite(pinMotorTurn_dir1, 1);
        digitalWrite(pinMotorTurn_dir2, 0);
        analogWrite(pinMotorTurnSpeed_pwm, speed);
    }
}

That’s pretty much everything. I hope you enjoyed this article and you will build your toy car!

Android Automotive vs Android Auto

Automotive release roadmap

Adapting existing app to Automotive

Final words

1. RxKotlin

2. Lives 

liveDataVar
.distinctUntilChanged()
.map { /* do the RX magic */}
.nonNull()
.take(3)

3. RxBroadcastReceiver

RxBroadcastReceivers
   .fromIntentFilter(
      context, 
      IntentFilter(LocationManager.MODE_CHANGED_ACTION))
   .subscribe {
      // react to broadcast
}

4. RxRelay

• BehaviorRelay - observer gets the last item before subscription plus all the subsequent ones
• PublishRelay - observer gets only items emitted after it subscribes
• ReplayRelay - buffers and emits all items to all observers

5. RxDownload

disposable = url.download()
    .observeOn(AndroidSchedulers.mainThread())
    .subscribeBy(
        onNext = { progress ->
            //download progress
            button.text = "${progress.downloadSizeStr()}/${progress.totalSizeStr()}"
            button.setProgress(progress)
        },
        onComplete = {
            //download complete
            button.text = "Open"
        },
        onError = {
            //download failed
            button.text = "Retry"
        }
    ) 

6. MvRx

Summary

What is AWS Cognito for

Getting started

The pros of AWS Cognito

1. Fully configurable via the AWS control panel
2. Easy to connect with your application via provided AWS Amplify module (available for most popular frameworks/libraries, like Vue, Angular, React)
3. No need for an additional global state management solution in your app. AWS Amplify will check if the user is already logged for you. It provides its own global state which can be used across the whole application.
4. Out-of-the-box, UI forms for logging in, registration, password recovery, password change, federated authentication, MFA (Multi-Factor Authentication) e.g. SMS, Email, and TOTP (Temporary One Time Password) Confirm MFA Code’s and Provide QR codes for TOTP
5. All the data will be automatically stored in cloud AWS Cognito service (users information)
6. Confirmation emails (after user registration) will be automatically sent to the user as well as text messages to verify the user’s phone number
7. You can store custom attributes for users like address, phone number, city and any custom field which you want to
8. Data sent from the application is already encrypted and secured by the AWS Amplify module
9. Easy to connect with other AWS services like AWS AppSync
10. UI Form validations managed by AWS control panel
11. Integration with Social identity providers e.g. “Log in with Google” (or Facebook).
12. Error messages already provided by service
13. Several ways to handle forms on the application side
14. AWS Amplify allows for making HTTP requests (it’s using Axios module under the hood)
15. Out of the box security features like throttling (to prevent brute force attacks) or refresh tokens (to allow revoking access tokens)

The cons of AWS Cognito

1. It’s a paid solution
2. Documentation is rarely updated and not much detailed
3. Some of the options can be only set during the creation of an AWS Cognito user pool in the AWS administration panel. After that those options are disabled and if you want to change them you need to delete the whole instance and create a new one. This can be painful in the very beginnings of the project — when you are not sure which options you will eventually use in production.
4. Aligning provided UI forms with some of the designs can sometimes be problematic, then probably the fastest way is to create your own form components
5. Error messages provided by AWS Cognito are not very user friendly. Sometimes they are too technical, so you need to provide some kind of an error mapper in the application, to show more user-friendly messages. For example when a user tries to login with the wrong password.
6. There are no error messages for specific form fields, only general error messages
7. Confirmation emails (after user registration) are very limited. You need to create custom HTML email templates if you want more than just a plain text email with a verification link
8. There are limitations in the number of custom field attributes. You can’t create more than 25 custom attributes.
9. AWS Amplify module is a little heavy (minified + gzipped version is around 180 kB)

Final thoughts

Ethereum blockchain applications

Object-oriented programming vs Design by contract

Similarities and differences between Solidity and Java

contract NumberContract {
  address private contractIssuer;
  uint private number;
  
  modifier onlyContractIssuer {       
      require(contractIssuer == msg.sender);
      _;
  }
  
  function NumberContract() public {
      contractIssuer = msg.sender;    
  } 
  
  function setNumber(uint newNumber) onlyContractIssuer public {
      number = newNumber;
  }
}

Events are inheritable members of contracts. When they are called, they cause the arguments to be stored in the transaction’s log — a special data structure in the blockchain. These logs are associated with the address of the contract and will be incorporated into the blockchain and stay there as long as a block is accessible. Log and event data is not accessible from within contracts (not even from the contract that created them).

contract NumberContract {
  address private contractIssuer;
  uint private number;
  
  event NumberSet(uint number);
  
  modifier onlyContractIssuer {       
      require(contractIssuer == msg.sender);
      _;
  }
  
  function NumberContract() public {
      contractIssuer = msg.sender;    
  } 
  
  function setNumber(uint newNumber) onlyContractIssuer public {
      number = newNumber;
      NumberSet(newNumber);
  }
}

Solidity supports multiple inheritance by copying code including polymorphism. All function calls are virtual, which means that the most derived function is called, except when the contract name is explicitly given. When a contract inherits from multiple contracts, only a single contract is created on the blockchain, and the code from all the base contracts is copied into the created contract. The general inheritance system is very similar to Python’s, especially concerning multiple inheritance.

contract NumberContract {
  address private contractIssuer;
  uint private number;
  mapping(address => uint256) public availableWithdrawals;
  
  modifier onlyContractIssuer {       
      require(contractIssuer == msg.sender);
      _;
  }
  
  modifier hasPositiveBalance(address user) {
    require(availableWithdrawals[user] > 0);
    _;
  }
  
  function NumberContract() public {
      contractIssuer = msg.sender;
  } 
  
  function deposit() public payable {
      availableWithdrawals[msg.sender] = 
            safeAdd(availableWithdrawals[msg.sender], msg.value)
  }
  
  function withdraw() public payable hasPositiveBalance(msg.sender) {
    uint256 amount = availableWithdrawals[msg.sender];
    availableWithdrawals[msg.sender] = 0;
    msg.sender.transfer(amount);
  }
  
  function getAmountToWithdraw() public view returns (uint256) {
    return availableWithdrawals[msg.sender];
  }
  
  function safeAdd(uint256 a, uint256 b) internal pure returns (uint256) {
    uint256 c = a + b;
    assert(c >= a);
    return c;
  }
  
  function setNumber(uint newNumber) onlyContractIssuer public {
      number = newNumber;
  }
}

Pitfalls to avoid

for (var i = 0; i < a.length; i++) { a[i] = i; }

Operators have different semantics depending on whether the operands are literals or not. For example, 1/2 is 0.5, but x/y for x==1 and y==2 is 0. Precision of the operation is also determined in this manner — literals are arbitrary-precision, other values are constrained by their types.

Summary

Shared state and side effects

protocol LocationFetchterDelegate: class {
  func locationFetcher(_ fetcher: LocationFetcher, didUpdateLocation location: CLLocation)
}

final class LocationFetcher {
  weak var delegate: LocationFetcherDelgate?
  
  //Class implementation goes here
}

1. The field delegate can be freely modified by other components. One place can set a delegate and another one can choose to assign it to another object, which can cause one of the components not receiving results whatsoever.
2. We don’t know on which thread the results can be delivered on, without looking into the implementation. If we received this class as part of a closed-source library, we’d either need to disassemble the binary or check it in runtime.
3. What if we wanted multiple objects receiving the location updates? We’d need to change the class implementation, which would lead to public interface change and all relying components would need to update.

The solution

final class LocationFetcher {
let location: Observable<CLLocation>
}

let locationFetcher: LocationFetcher //Assume exists

locationFetcher.location
.observeOn(MainScheduler.instance)
.subscribe(onNext: { print("new location: \($0)") })
.disposed(by: disposeBag)

The downsides

Conclusion

1. Pulls out the key (e.g. from the pocket)
2. Unlocks the lock with the key
3. Person gets in

1. Types many numbers to unlock the lock (what if it’s unclear what’s the combination? :))
2. Intercom unlocks the electro lock
3. Person gets in

So, let's do it!

System listens to the presence of a person → Person near by the door (with smartphone) → System detects presence → Person launches the application → Person unlocks the door via the app → System verifies permissions → System unlocks the door

System listens to the presence of a person → Person near by the door (with iPhone) → System detects presence → Person presses the gate opening button on the door → System verifies the permissions → System unlocks the door

• The gate to the building with an electric lock (with access to a key and/or intercom)
• Internet access for the gateway controller (e.g. WiFi in range)
• A computer with macOS operating system

• Gate controller (Raspberry Pi)
• User’s smartphone (iPhone)
• Cloud service (backend application deployed on Heroku)

• HTTPS
• Bluetooth Low Energy (BLE 4.0)

What do we need to assemble our IoT solution?

• Raspberry Pi Zero W microcomputer (I’ll use also a short name: “RPi”) Thanks to this device, we will have, apart from an advanced controller with the Linux OS, also a WiFi and BLE 4 module, without the need to attach additional modules

• microSD card (at least 16GB) with an adapter for SD card reader

• iPhone 5 or newer with iOS 10.3 (or newer)

• Power supply with micro USB connector to drive the Raspberry Pi

• Breadboard

• 2 LED diodes (green and red)

• Relay module (e.g. SRD-05VDC-SL-C)

• Push-button

• Resistors: 2 × 300Ω and 1 × 10kΩ
• Wires

How to connect all elements with each other?

Configuration time

• communication with iPhone (via BLE 4.0)
• generating a token and sending it to the service in the cloud (via HTTPS)
• validation of the token transferred from the iPhone
• opening the electro lock of the main gate

Node.js installation

$ sudo apt-get update

$ sudo apt-get dist-upgrade

$ curl -sL https://deb.nodesource.com/setup_9.x | sudo -E bash -

$ sudo apt-get install -y nodejs

$ node --version

• UUID generator — generates an authorization token

  $ npm install uuid

• Cache — stores generated tokens

  $ npm install node-cache

• Console Log Formatter — makes log messages more developer-friendly $ npm install console-stamp
• GPIO Pins Controller — lets us read and write signals from/to RPi board pins

  $ npm install rpi-gpio

• Bluetooth Low Energy — handles all BLE communication Due to the fact that the installation is a bit more complicated, please follow the instruction given here
• GPIO Button Event Emitter — handles buttons’ events

  $ npm install rpi-gpio-buttons

• Request — supports HTTPS operations

  $ npm install request

$ mkdir /home/pi/gateguard

$ wget -O gateguard-rpi.zip https://github.com/inFullMobile/gateguard-rpi/archive/master.zip

$ unzip gateguard-rpi.zip

$ cp -r gateguard-rpi-master/* /home/pi/gateguard/

$ cd gateguardcloud

$ rm -rf .git #it removes current git version control files

$ heroku login #once asked, provide your username (email) and password

#create new git local repository

$ git init

$ git add .

$ git commit -m “Initial commit”

$ vapor heroku init

Would you like to provide a custom Heroku app name?

y/n> n

Would you like to deploy to a region other than the US?

y/n> y

Region code (us/eu):

> eu

https://pacific-lowlands-45092.herokuapp.com/ | https://git.heroku.com/pacific-lowlands-45092.git

Would you like to provide a custom Heroku buildpack?

y/n> n

Setting buildpack...

Are you using a custom Executable name?

y/n> n

Setting procfile...

Committing procfile...

Would you like to push to Heroku now?

y/n> y

This may take a while...

Building on Heroku ... ~5-10 minutes [ • ]

Building on Heroku ... ~5-10 minutes [Done]

Spinning up dynos [Done]

Visit https://dashboard.heroku.com/apps/

App is live on Heroku, visit

https://pacific-lowlands-45092.herokuapp.com/ | https://git.heroku.com/pacific-lowlands-45092.git

uri: ‘https://pacific-lowlands-45092.herokuapp.com/register-token'

$ uuidgen

• 93384AB6–9EB1–4AF2–90FB-F88ABB6F79AF

• 4E98BE1C-F8D9–46AD-9D08-C0AAA7DFEE7A

this.bleServiceUUID = '93384AB6-9EB1-4AF2-90FB-F88ABB6F79AF'
this.bleCharacteristicUUID = '4E98BE1C-F8D9-46AD-9D08-C0AAA7DFEE7A'

$ nohup sudo node /home/pi/gateguard/gateguard.js > /home/pi/gateguard/gateguard.log &

Time for the second element of the system — an application for the iPhone.

$ git clone https://github.com/inFullMobile/gateguard-ios.git

// That's my URL address! Use yours ;)
static let gateGuardHost = URL(string: "https://pacific-lowlands-45092.herokuapp.com")!

static var serviceUUID: CBUUID {

return CBUUID(string: "93384AB6-9EB1-4AF2-90FB-F88ABB6F79AF")

}

static var newTokenNotificationCharacteristicUUID: CBUUID {

return CBUUID(string: "4E98BE1C-F8D9-46AD-9D08-C0AAA7DFEE7A")

}

• The green LED blinks — the gate opening button has been pressed, the iPhone with the Gate Guard application is within RPi BLE range and the authorization is in progress
• The green LED is on — the door’s electro lock is open
• The red LED blinks — the gate opening button has been pressed but RPi has not identified the iPhone with the Gate Guard application running
• The red LED is on — the user hasn’t passed the authorization successfully (the token from the iPhone is invalid) and the gate will not be opened

A bit about code itself

What is happening on Raspberry Pi?

• acting as a BLE peripheral for iPhone connected to it
• generating a new token
• transferring token to the cloud app
• validation of a token transferred from the iPhone
• electro lock control

onSubscribe(maxValueSize, callback) {
console.log('BLE characteristic subscribed')

shared.subscribedToCharacteristic = true
this.valueDidChangeCallback = callback
}

const tokenId = Math.floor(Math.random() * MAX_TOKEN_ID)
const token = uuid()

    registerTokenInCloud(tokenId, token, completionCallback) {
        console.log('register token in cloud service')
        if (!this.requestInProgress) {
            console.log('http request')

            const _this = this

            this.requestInProgress = true

            request(this._requestOptions(tokenId, token), function(error, response, body) {
                console.log('http response')

                _this.requestInProgress = false

                if (!error && response.statusCode == 200) {
                    console.log('New token registered on cloud service with success')
                    completionCallback(true)
                } else {
                    console.error('Error while registering token in cloud service: ' + error)
                    completionCallback(false)
                }
            })
        }
    }

    _requestOptions(tokenId, token) {
        return {
            uri: 'https://gateguard.herokuapp.com/register-token',
            method: 'POST',
            json: {
                "id": tokenId,
                "token": token
            }
        }
    }

onWriteRequest(data, offset, withoutResponse, callback) {
        console.log('Authorization request from mobile phone')

        this.greenLedManager.off()

        var dataParts = data.toString().split('|')

        const tokenId = dataParts[0]
        const token = dataParts[1]

        var cachedToken = null

        try {
            cachedToken = shared.cache.get(tokenId, true)
            if (token.toUpperCase() == cachedToken.toUpperCase()) {
                console.log('Token is valid! Opening the gate...')

                this.greenLedManager.on(led.LEDModeEnum.solid, shared.ELECTROLOCK_ON_DURATION)
                this.relayManager.on(shared.ELECTROLOCK_ON_DURATION)
            } else {
                console.log('Token is invalid - access to the gate denied!')

                this.redLedManager.on(led.LEDModeEnum.solid, shared.ELECTROLOCK_ON_DURATION)
            }

            callback(0)
        } catch (err) {
            console.log('Error: ' + err)
            callback(1)
        }
    }

this.relayManager.on(shared.ELECTROLOCK_ON_DURATION)

What about iPhone’s role?

• is looking instantly for particular UUID which represents RPi service/characteristic
• gets requested token (request comes from RPi) from cloud service
• sends token back to RPi for further authorization procedure

    private func scanForPeripheral() {
        guard self.isElectronicKeyActive else { return }
        
        self.centralManager.scanForPeripherals(withServices: [CBUUID.serviceUUID],
                                               options: [CBCentralManagerScanOptionAllowDuplicatesKey: NSNumber(booleanLiteral: true)])
    }

func peripheral(_ peripheral: CBPeripheral, didDiscoverServices error: Error?) {
        guard error == nil else { return }
        
        guard let service = peripheral.services?.filter({ $0.uuid == CBUUID.serviceUUID }).first else {
            return
        }
        
        peripheral.discoverCharacteristics([CBUUID.newTokenNotificationCharacteristicUUID], for: service)
    }
    
    func peripheral(_ peripheral: CBPeripheral, didDiscoverCharacteristicsFor service: CBService, error: Error?) {
        guard let characteristic = service.characteristics?.filter({ $0.uuid == CBUUID.newTokenNotificationCharacteristicUUID }).first else {
            return
        }
        self.storedCharacteristic = characteristic
        peripheral.setNotifyValue(true, for: characteristic)
}

        self.bleService.tokenDidRequestCallback = { [weak tokenService, weak bleService] (_ tokenId: Int) in
            
            tokenService?.getToken(with: tokenId) { (_ result) in
                switch result {
                case .success(let token):
                    bleService?.respond(withToken: token)
                case .error(let error):
                    let errorMessage = String(describing: error)
                    print("Error: \(errorMessage)")
                }
            }
}

There is also a token exchange platform — service in the cloud.

• storing newly generated authorization token (for a limited time only)
• answering with token while being asked for it with tokenID

        post("register-token") { req in
            guard let id = req.json?["id"]?.int, let token = req.json?["token"]?.string else {
                return Response(status: .badRequest)
            }
            
            try self.cache.set("\(id)", token, expiration: Date(timeIntervalSinceNow: Constants.tokenDuration))
            
            return Response(status: .ok)
        }

        get("token") { req in
            guard let id = req.query?["id"]?.int else {
                return Response(status: .badRequest)
            }
            
            var json = JSON()
            
            guard let token = try self.cache.get("\(id)") else {
                return Response(status: .noContent)
            }
            
            try json.set("id", id)
            try json.set("token", token)
            
            return json
}

The goal of CanonHackathon was to prove that video projectors can be used not only for watching movies.

Let's make an app. Architecture setup

repositories {
    maven { url 'https://maven.infullmobile.com/public' }
}

compile 'com.infullmobile.android:infullmvp-kotlin:1.1.14'
testCcompile 'com.infullmobile.android:infullmvp-kotlin-basetest:1.1.14'

Moving, scaling and rotating imageView

allprojects {
		repositories {
			...
			maven { url 'https://jitpack.io' }
		}
	}

compile 'com.github.AmeerHamzaaa:TNImageView-Android:0.1.2'

<RelativeLayout
   android:layout_width="match_parent"
   android:layout_height="match_parent">


   <ImageView
       android:id="@+id/slideShowImage"
       android:layout_width="100dp"
       android:layout_height="100dp"
       android:clickable="true"
       android:src="@drawable/ice_cream"/>
</RelativeLayout>

class MainActivityView @Inject constructor() : PresentedActivityView<MainActivityPresenter>() {


    @LayoutRes override val layoutResId = R.layout.activity_main
    val slideShowImage: ImageView by bindView(R.id.slideShowImage)


    override fun onViewsBound() {
        TNImageView().makeRotatableScalable(slideShowImage)
    }
}

Matrix transformation for imageView

private fun skewBitmap(src: Bitmap, xSkew: Float, ySkew: Float): Bitmap {
        val xCoordinates = 0
        val yCoordinates = 0
        val matrix = Matrix()
        matrix.postSkew(xSkew, ySkew)
        return Bitmap.createBitmap(src, xCoordinates, yCoordinates, src.width, src.height, matrix, true)
}

Fetching images from Instagram by tag name

data class ResponseInstaByTag(
        @field:SerializedName("data")
        val data: List<DataItem>
)


data class DataItem(
        @field:SerializedName("images")
        val images: Images
)


data class Images(
        @field:SerializedName("standard_resolution")
        val standardResolution: StandardResolution
)


data class StandardResolution(
        @field:SerializedName("url")
        val url: String
)

interface InstagramApiService {
    @GET("tags/{tag}/media/recent?access_token=YOUR_ACCESS_TOKEN")
    fun getPicsByTag(@Path("tag") tag: String): Single<ResponseInstaByTag>
}

@Module
public abstract class MainActivityModule {


    private static String BASE_URL = "https://api.instagram.com/v1/";


    @MainActivityScope
    @Provides
    static Retrofit providesRetrofit() {
        return new Retrofit.Builder()
                .baseUrl(BASE_URL)
                .addConverterFactory(GsonConverterFactory.create())
                .addCallAdapterFactory(RxJava2CallAdapterFactory.create())
                .build();
    }


    @MainActivityScope
    @Provides
    static MainActivityView providesMvpView() {
        return new MainActivityView();
    }


    @MainActivityScope
    @Provides
    static InstagramApiService providesInstagramApiService(Retrofit retrofit) {
        return retrofit.create(InstagramApiService.class);
    }


    @MainActivityScope
    @Provides
    static Scheduler providesScheduler() {
        return Schedulers.io();
    }


    @MainActivityScope
    @Provides
    static GetPicturesByTagUseCase providesGetPicturesByTagUseCase(Scheduler scheduler,
                                                                   InstagramApiService instagramApiService) {
        return new GetPicturesByTagUseCase(scheduler, instagramApiService);
    }


    @MainActivityScope
    @Provides
    static MainActivityModel providesMvpModel(GetPicturesByTagUseCase getPicturesByTagUseCase) {
        return new MainActivityModel(getPicturesByTagUseCase);
    }


    @MainActivityScope
    @Provides
    static MainActivityPresenter providesMvpPresenter(
            MainActivityModel model,
            MainActivityView view
    ) {
        return new MainActivityPresenter(model, view);
    }


    @MainActivityScope
    @Binds
    abstract Context bindsContext(SampleMvpActivity activity);
}

class MainActivityPresenter @Inject constructor(
        private val model: MainActivityModel,
        view: MainActivityView
) : Presenter<MainActivityView>(view) {


    private var disposableApiService: Disposable? = null
    private val tagName = "sky"


    override fun bind(intentBundle: Bundle, savedInstanceState: Bundle, intentData: Uri?) {
        loadPictures(tagName)
    }


    private fun loadPictures(tag: String) {
        disposableApiService = model.getPicturesByTag(tag)
                .subscribe(
                        { imagesList ->
                            val links = imagesList.data.map { dataItem -> dataItem.images.standardResolution.url }
                            presentedView.startSlideShow(links)
                        },
                        { handleError(it) }
                )
    }
}

fun startSlideShow(urls: List<String>) {
        val delaySlideshow = 3L
        disposableTimer = Observable.interval(delaySlideshow, TimeUnit.SECONDS)
                .observeOn(AndroidSchedulers.mainThread())
                .map { getNextPictureUrl(currentIndex, urls) }
                .flatMap { url -> loadBitmapByUrl(url) }
                .map { bitmap -> skewBitmap(bitmap, skewX, skewY) }
                .subscribe(
                        { bitmap -> presentedView.showPicture(bitmap) },
                        { handleError(it) }
                )
    }


private fun getNextPictureUrl(urls: List<String>): String {
        if (currentIndex >= urls.size) currentIndex = 0
        return urls[currentIndex++]
}


private fun loadBitmapByUrl(url: String): Observable<Bitmap> {
        return Observable.create<Bitmap> { emiter ->
            Picasso.with(context).load(url).into(object : Target {
                override fun onBitmapLoaded(bitmapParam: Bitmap, from: LoadedFrom?) {
                    emiter.onSuccess(bitmapWithTransformation)
                }
                override fun onPrepareLoad(placeHolderDrawable: Drawable?) {}
                override fun onBitmapFailed(errorDrawable: Drawable?) {
                    emiter.onError(IllegalStateException("Bitmap loading has failed"))
                }
            })
        }
}

fun showPicture(bitmap: Bitmap) = slideShowImage.setImageBitmap(bitmap)

override fun unbind() {
        super.unbind()
        disposableApiService?.dispose()
        disposableTimer?.dispose()
}

Operation

Block operation

import UIKit

let printerOperation = BlockOperation()

printerOperation.addExecutionBlock { print("I") }
printerOperation.addExecutionBlock { print("am") }
printerOperation.addExecutionBlock { print("printing") }
printerOperation.addExecutionBlock { print("block") }
printerOperation.addExecutionBlock { print("operation") }

printerOperation.completionBlock = {
    print("I'm done printing")
}

let operationQueue = OperationQueue()
operationQueue.addOperation(printerOperation)

Creating custom Operation objects

Synchronous operation

import UIKit

class MonoImageOperation: Operation {

    var inputImage: UIImage?
    var outputImage: UIImage?

    init(inputImage: UIImage) {
        self.inputImage = inputImage
    }

    override public func main() {
        if self.isCancelled {
            return
        }
        outputImage = applyMonoEffectTo(image: inputImage)
    }

    private func applyMonoEffectTo(image: UIImage?) -> UIImage? {
        guard let image = image,
            let ciImage = CIImage(image: image),
            let mono = CIFilter(name: "CIPhotoEffectMono",
                                 withInputParameters: [kCIInputImageKey: ciImage])
        else { return nil }

        let ciContext = CIContext()
        guard let monoImage = mono.outputImage,
            let cgImage = ciContext.createCGImage(monoImage, from: monoImage.extent)
        else { return nil }

        return UIImage(cgImage: cgImage)
    }
}

import UIKit

class ViewController: UIViewController {

    @IBOutlet weak var imageView: UIImageView!

    override func viewDidLoad() {
        super.viewDidLoad()

        let image = UIImage(named: "image-1.jpg")
        let monoImageOperation = MonoImageOperation(inputImage: image!)
        monoImageOperation.completionBlock = {
            DispatchQueue.main.async {
                self.imageView.image = monoImageOperation.outputImage
            }
        }
        let operationQueue = OperationQueue()
        operationQueue.addOperation(monoImageOperation)
    }
}

Operation states

Asynchronous Operation

import Foundation

class AsyncOperation: Operation {
    public enum State: String {
        case ready, executing, finished

        fileprivate var keyPath: String {
            return "is" + rawValue.capitalized
        }
    }

    public var state = State.ready {
        willSet {
            willChangeValue(forKey: state.keyPath)
            willChangeValue(forKey: newValue.keyPath)
        }
        didSet {
            didChangeValue(forKey: oldValue.keyPath)
            didChangeValue(forKey: state.keyPath)
        }
    }
}

extension AsyncOperation {

    override var isAsynchronous: Bool {
        return true
    }

    override var isExecuting: Bool {
        return state == .executing
    }

    override var isFinished: Bool {
        return state == .finished
    }

    override func start() {
        if isCancelled {
            return
        }
        main()
        state = .executing
    }
}

import UIKit

class AsyncImageDownloadOperation: AsyncOperation {

    var downloadedImage: UIImage?

    override func main() {
        let defaultSession = URLSession(configuration: .default)
        guard let imgUrl = URL(string: "https://unsplash.com/photos/M9O6GRrEEDY/download?force=true") else { return }
        let dataTask = defaultSession.dataTask(with: imgUrl) { (data, response, error) in
            if let error = error {
                print("Image download encountered an error: \(error.localizedDescription)")
            } else if let data = data, let response = response as? HTTPURLResponse,
                response.statusCode == 200 {
                if self.isCancelled {
                    self.state = .finished
                    return
                }
                let image = UIImage(data: data)
                self.downloadedImage = image
                self.state = .finished
            }
        }
        dataTask.resume()
    }
}

Operation Queue

1. veryLow
2. low
3. normal
4. high
5. veryHigh

Quality of Service

Summary

The problem

Frameworks

1. SampleApp project contains the main application code: a user interface, the business logic, the database, etc. It also contains unit and UI tests related to the application itself.
2. The networking framework contains all classes that wrap up communication with external web services, data parsing, and validation. Unit tests are separated as well so that they won’t get mixed with application tests.

Configuration structure

1. useMockedApiClient — determines which API client to use: the mocked or the backend one. You can switch between them by setting the property in only one place.
2. mockedRequestDelay — the time after a mocked request is returned. It simulates communication latency between the server and the application over a network. It can be set to 0 for development in order not to waste time on loading so that new features can be tested quickly. The most important thing is having this property set to a huge value e.g. 10 seconds, and then testing if the application works correctly with a poor network connection. You can test if the user interface components are blocked and spinners displayed at a proper time. This wouldn’t be easy using a real connection or other tools that simulate network latency.

Networking class

1. configuration — described above.
2. apiClient — the API client that communicates with the real backend.
3. mockedAPIClient — the client that uses mocked data.
4. client — the public property exposed to the application in order to communicate with either the real or mocked backend depending on the useMockedApiClient property.

1. accessTokenProvider — the access token storage.
2. authentication, products — the group of endpoints divided into categories.

BackendAPIClient — the client that communicates with the backend.

MockedAPIClient — the client that uses mocks.

OHHTTPStubs

Kakapo

WireMock

Afterword

Setup

import CoreBluetooth

class MiService: NSObject, CBCentralManagerDelegate, CBPeripheralDelegate {
    lazy var manager = CBCentralManager(delegate: self, queue: DispatchQueue.main, options: nil)
}

Discovering nearby devices

func centralManagerDidUpdateState(_ central: CBCentralManager) {
    if central.state == .poweredOn {
        manager.scanForPeripherals(withServices: nil, options: nil)
    }
}

var discoveredPeripherals: [CBPeripheral] = []

func centralManager(_ central: CBCentralManager, didDiscover peripheral: CBPeripheral, advertisementData: [String : Any], rssi RSSI: NSNumber) {
    print(peripheral)
    discoveredPeripherals.append(peripheral)
}

Connecting to a device

var miBand: CBPeripheral?

func connectToPeripheral(at index: Int) {
    manager.connect(discoveredPeripherals[index], options: nil)
}

func centralManager(_ central: CBCentralManager, didConnect peripheral: CBPeripheral) {
    manager.stopScan()
    miBand = peripheral
    peripheral.delegate = self
    peripheral.discoverServices(nil)
}

func centralManager(_ central: CBCentralManager, didFailToConnect peripheral: CBPeripheral, error: Error?) {
    print(error)
}

Bluetooth LE interface introduction

Discovering device interface

func peripheral(_ peripheral: CBPeripheral, didDiscoverServices error: Error?) {
    print(error ?? peripheral.services)
    peripheral.services?.forEach { service in
        peripheral.discoverCharacteristics(nil, for: service)
    }
}

Reading device data

func peripheral(_ peripheral: CBPeripheral, didDiscoverCharacteristicsFor service: CBService, error: Error?) {
    print(error ?? service.characteristics)
    service.characteristics?.forEach { characteristic in	
        if characteristic.properties.contains(.read) {
            peripheral.readValue(for: characteristic)
        }
        if characteristic.properties.contains(.notify) {
            peripheral.setNotifyValue(true, for: characteristic)
        }
    }
}

func peripheral(_ peripheral: CBPeripheral, didUpdateValueFor characteristic: CBCharacteristic, error: Error?) {
    let valueBytes: [UInt8] = value?.map { $0 }
    print("New value for: \(characteristic)")
}

New value for: <CBCharacteristic: 0x1c40bf620, UUID = 00000007-0000-3512-2118-0009AF100700, properties = 0x12,
value = <0c0b0000 00070000 00010000 00>, notifying = YES>

<0c 0b000000 07000000 01000000>

extension UInt32 {
    static func from(bytes: [UInt8]) -> UInt32? {
        guard bytes.count <= 4 else { return nil }
        return bytes
            .enumerated()
            .map { UInt32($0.element) << UInt32($0.offset * 8) }
            .reduce(0, +)
    }
}

let stepsCount = UInt32.from(bytes: Array(valueBytes[1...4]))

Controlling a device

func measureHeartRate() {
    guard let miBand = miBand, 
          let hrControlPoint = miBand.services?.first(where: { $0.uuid.uuidString == "180D" })?
                                     .characteristics?.first(where: { $0.uuid.uuidString == "2A39" }) else { return }
    miBand.writeValue(Data(bytes: [0x15, 0x2, 0x1]), for: hrControlPoint, type: .withResponse)
}

Wrap up