Flux is an architecture pattern created by Facebook and used to build client-side web application. It complements Reacts view components by utilizing an unidirectional data flow. Flux eschews MVC in favor of a unidirectional data flow.

Across this article we will explain how Flux works, together with how to implement it in our Android applications using an external framework developed for the Android platform using Kotlin thus allowing us to minimize the boilerplate that this architecture could produce in other languages without using popular JS framerworks.

Data Flow : Dispatchers, Stores and Views

The unidirectional data flow is the core idea of the Flux pattern. In order to ensure this flow we will use a series of structures. The Dispatcher, Stores and Views are independent nodes with different inputs and outputs. Actions are just bare objects that carries an optional payload of data.
Let’s see through an example how they work and interact with each other.

When an user interacts with a view, it propagates an Action (use case) that will be handled by a certain number of stores that hold the actual business logic of the application. The state of each of these Stores conforms the state of the application and will be mutated by the dispatch of Actions by means of the Dispatcher. Finally, our views will change reactivity based on the changes of these States.

Let’s see it in more detail.

Dispatcher

The dispatcher is the central hub that manages all data flow in a Flux application. It’s just a mechanism that distributes the actions to the stores. Each Store provides a callback for one or more Actions. When a new action go though the Dispatcher, all the stores receives this action and trigger their callbacks if needed.

Stores

Stores contains the application state and the logic. Their function is to hold and manage the state related to a particular domain within the application. Stores register itself to certain Actions and triggers, a state change together with other side effects when these Actions are dispatched. An action should result in an update to the state of one or multiple stores.

Views

Views on Flux listen reactively the changes emitted by the stores. On the Flux pattern, the changes in the views should be a side effect caused by a certain change in the stores.

Actions

The actions are simple objects dispatched though the Dispatcher to the Stores, containing new data provided to cause a state change. For example, the action LoginAction(email : String, password : String)contains the payload of data needed to make a call to an API REST with a login request.

The Clean pattern

Clean architecture is a pattern for a modular system, which strictly follows a design principle called separation of concerns. This style of architecture focuses on splitting software into different layers, looking forward of simplify the development and make easier the maintenance of the application itself. When layers are well-separated, individual pieces can be reused, as well as developed and updated independently.

The architecture is usually composed of four fundamental layers. These layers will be identified as:

• Enterprise Logic : Data models and entities.
• Application Logic : Business logic and use cases.
• Presentation Logic: Presentation design patterns.
• Infrastructure Logic: External dependencies.

Also, each layer should respect these rules:

1. Should be testable.
2. Should be independent of a user interface.
3. Should be independent of a database.
4. Should be independent of interfaces to third-party dependencies.
5. Should be respectful of boundaries.

Clean Problems

• Enforce the separation even if you don’t need to share modules with multiple projects can be overhead: as you need layer-specific objects and mapping in between
• Navigation should be a domain-layer responsibility, but it is a common problem that people abuse Activities and make navigation state implicitly part of the task stack.
• Hiding certain things under interfaces can be hard, often people still leak details, or their abstraction does not properly handle how their library of choice actually works.
• Lots of boilerplate

So how is Flux different from Clean?

• The Flow of the app is essential to Flux and there are very strict rules that are enforced by the Dispatcher. In Clean the flow isn’t enforced and most Clean patterns implement it differently
• Unidirectional flow: Every change goes through the dispatcher. A store can’t change other stores directly. Same applies for views and other actions. Changes must go through the dispatcher via actions. In Clean it’s very common to have bidirectional flow
• Stores don’t need to model anything and can store any application related state. In Clean models try to model something, usually single objects

Mini. A Minimal Android Flux Architecture

Mini is a minimal Flux architecture written in Kotlin that also adds a set of useful features to build UIs fast.

The objective of this framework is to develop a reactive application with good performance (using code-gen over reflection). Feature development using Mini is fast compared to traditional architectures (like CLEAN or MVP), low boilerplate and state based models make feature integration and bugfixing easy as well as removing several kind of issues like concurrency or view consistency across screens.

Sample case

Let’s pose a typical case for a backend related application. We want to do a login request to our backend. If this request success, the user will be redirected to the home screen, if it fails, an error will be shown.
For this we will just need to build:

• An Action as an use case for our login request and the result callback.

• A Store and that contains the application state regarding the session.

• A View subscription to SessionStore state changes. This can be made listening all the changes for mapping data or custom logic or a single one for navigation purposes.

With this code, the flow will happen in the next way:

• After click on the button login() is called and LoginAction is dispatched.
• The Reducer functions that receives LoginAction are executed.
• The state will change the value of loginTask to RUNNING in the state and the Controller makes the async operation over the backend. When the async operation will end LoginCompleteAction will be dispatched.
• The state will change the value of loginTask to SUCCESS or FAILURE depending of the data retrieved.
• The view will navigate to home or show an error depending of the state.

Testing

Mini includes an extra library called mini-android-testing with a few methods and Expresso TestRules to simplify your UI tests over this architecture.

• TestDispatcherRule : This rule will intercept any action that arrives to the Dispatcher, avoiding any call to the Store and their controllers. If we include this rule we will need to change the states manually in our tests.
• CleanStateRule : It just reset the state of your stores before and after each test.

Test that actions are correctly dispatched:

Test that a view correctly changes based on an specify state:

Mini on Github

You can grab Mini by adding dependency to your build.gradle file:

implementation 'com.github.pabloogc:Mini:1.0.7'
kapt 'com.github.pabloogc.Mini:mini-processor:1.0.7'
androidTestImplementation 'com.github.pabloogc.Mini:mini-android-testing:1.0.7' //Optional

These are just a few examples of how to use the library, feel free to use it, open issues, creating pull requests and contribute to the project.

Join us on Github! Happy coding!

pabloogc/Mini

Links and resources

• Flux architecture overview
• Model — View — Presenter
• The Clean architecture by Uncle Bob
• Flux vs MVC pattern
• Building abstractions for the sake of building abstractions.

Mini: Embrace Reactivity. Flux & Android was originally published in BQ Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

First, we classify the type of each headphone according to their shape and how they couple to the ear as follows

Although BT headphones have electronic components we are going to approach the analysis from a user point of view analyzing their acoustic performance.

Test equipment & setup

There are some international standards, such as IEC60268–7, which provides a set of recommendations on how to perform these tests. The required environment must be completely quiet and without sound reflections. Measurements must be done with very precise equipment.

In order to achieve that conditions, we perform all our measurement within our anechoic chamber (which prevents the acoustic sounds from reflections and isolate acoustically the test environment).

The audio analyzer used in the measurements is APx555.

In order to simulate the nonlinearities of the human ear at DRP (Drum Reference Point), a special HATS (Head and Torso Simulator) from Head Acoustics is used. The HATS is a fixture tool over which all measurements can be done.

Acoustic measurements of the headphones over the HATS are very sensitive to how the headphones are fixed to the HATS. In order to avoid measurements error, we repeat and average the measurements up 5 times removing and repositioning each time. This also allows us to have repeatability and realistic in our measures.

Now we will focus on a basic subset of measurements which can provide a good overview of a given DUT (Device Under Test). In our case, we will analyze a circumaural ANC (Active Noise Canceller) Headphone.

Measurements

Frequency Response

This is one of the most relevant measurements. It is generally thought to be the most representative characteristic of perceived quality. This measurement is done by playing a sweep tone (sinusoidal waves) from 20Hz to 20KHz at 94dB of Sound Pressure Level (dB SPL).

In this measurement, we can see how the headphone behaves reproducing different frequencies and their corresponding level in each channel (left & right).

Total Harmonic Distortion (THD)

This quality factor is related to the signal clarity. It is able to measure the amount of distortion present at every part of the audible spectrum.

The THD is given as a percentage which represents the amount of acoustic signal energy caused by the distortion related to the original signal.

Sound Pressure Level (SPL)

This is the method to determine what sound pressure levels the headphones will generate when the input signal is maximum (0dBFS) filtered pink noise test signal (pink noise is a lab test signal which is very similar to the music and voice test signals).

Crosstalk

It is the unwanted leakage of a signal from one channel to the other channel. This may be due to a signal coupling in the internal electronic circuit and influence the stereo separation. The test signals used for this test are 1kHz and 10kHz sine waves. We play the signal into one channel and measure how much of that signal appears in the other channel.

Signal-to-Noise Ratio (SNR)

SNR is the difference between the maximum loudness (1KHz tone) and the idle noise level (sound present at the headphone in the absence of input signal). SNR is always measured as a ratio in dBs.

Active Noise Cancellation (ANC)

ANC is a measure of how capable a headphone is of removing the ambient noise from entering the ear channel. We create a 90dBSPL pink noise atmosphere and measure how much of that noise is perceived by the HATS´ ears. The noise signal should be played for several seconds to allow the noise canceling algorithms to become stable.

The procedure can be split into three measurements.

1. Pink noise atmosphere is measured by the HATS with no headphones on it. This way we assure we are playing 90dBSPL pink noise at the hearing point.
2. We repeat test 1, just after placing the headphones over the HATS. That can give us the passive isolation of the DUT.
3. Finally, the measure is done again with the ANC turned on. Comparing these result to result in step 2, we can find how much noise our ANC algorithm is canceling.

The spectral analysis is typically smoothed in 1/3 octave band, which generates data that is more representative of how a human ear would hear

In this example, we observe the ANC works below 800Hz. Above this frequency, passive isolation becomes more relevant.

We can also check not only the spectrum but the perceived loudness on each test.

As I said before, there are much more key performance indicators that can be added to this basic analysis such us idle noise, impulse response, phase shift, compression, R&B, …

I hope you have found interesting this article and find it useful for next time you try a new pair of headphones.

How to analyze Bluetooth ANC Headphones acoustic performance was originally published in BQ Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today´s post is about the three most common Amplifying Structures used in smartphone´s industry. These ICs are based on a power amplifier (PA) adding some other components which provide to the system a certain degree of intelligence in order to optimize the amplification process.

The PA used as the amplifying unit is classified according to its properties which vary a lot depending on its electrical design. In our case, in most of the Amplifying Structures, the PA unit used is class-D as a consequence of the good balance this class has in terms of efficiency and performance.

Naked PA

These chips just contain the PA. Usually, the gain of the PA can be adjusted by HW through some external resistors and low&high cutoff frequencies through basic RC passive filters at the chip signal input.

Gain setting adjusts the output power level. This adjustment must take into account the worst use case so that the speaker is never overloaded (a) or the output on the PA is never saturated (b).

a)You need to consider the output level for the greatest possible input signal to make sure it won´t exceed the speaker max. rated power (if that happens you may get high distortion or even damage your speaker).

b)You need to consider the lowest possible battery level on the PA supply power, to make sure the output signal will never reach it (if that happens the output signal will be saturated).

*Typical designs using the “Naked PA” use an external DC-DC regulator to keep the power supply constant at 5V and avoid b).

This solution totally lacks of awareness about system status or input signal and that makes it low efficient in terms of how capable it is of keeping the system boosted to maximum whichever the use case/system status is.

This type of amplifying structure is used in cost-effective devices. They are simple, cheap and easy to integrate into any hardware solution.

AGC/DRC (Automated Gain Control/Dynamic Range Control)

This Amplifying Structure´s name is quite clarifying. Automated Gain Control sounds like a system which is somehow capable to automatically adjust its gain and this is one of the lacks that Naked PA has.

We explained before that fixing the gain requested to consider the worse use case (greater input signal) in order not to overload the speaker/saturate the output signal. What would happen if we were capable of using a variable gain which could be adjusted depending on the input signal level? That is exactly what the Automated Gain Control does.

The main advantage of that is that you can use higher gains for low input level signals. This way, we can get greater output signal for all those cases on which the input level is lower than the worse case.

Why do we call this system Dynamic Range Control? DRC, as well known simply as compressor, is an audio processing block which compresses the input dynamic range into a smaller output dynamic range.

Dynamic Range is the amount of different possible levels which can be observed. As you can see in the picture below, the main side-effect for using the compressor is that you will loose some dynamic range as a trade-off for the loudness increasement.

In order to give a better understanding about the difference between the Naked PA and the AGC, we can make an example. Using a piece of song which shows a great dynamic (the difference between lowest and highest level), we have simulated the effect of a 5dB Naked PA and an AGC which reaches same maximum output level (assuming both of them would be loading the same speaker).

You can clearly observe in that example, that the part of the song with the highest level is amplified quite the same, but the initial part, with low level, is boosted much more on the AGC, as a consequence of its adaptive gain which can be much higher for that part of the song.

Additionally, the AGC/DRC includes in most of the cases the DC-DC converter which sets the power supply to max voltage according to the maximum output level expected to avoid signal saturation.

These amplifiers are used nowadays in entry-level smartphones as they are still quite inexpensive and can enhance the loudness. The main advantages of this platform compared to Naked PA are basically thanks to the system awareness of the input level signal before applying a certain amplification gain.

Smart PA

There is a big loudness improvement on AGC related to Naked PAs but the Amplifying Structures “changed the rules” for reaching an outstanding improvement never seen before.

Up to the moment, we are always trying to maximize the amount of power delivered to the speaker for not overloading the speaker, understanding that the limit of the speaker is always the rated power specified by the speaker supplier. Is it the real limit? can we go beyond that limit?

If we just think on these questions, we can clearly understand, that if we could be able to find a new speaker limit which would allow delivering more power to it, the overall performance (PA+Speaker) could be improved.

• How do suppliers determine the rated power for a speaker?

The rated power is defined by analyzing the reliability of the component while playing a wideband signal (20Hz to 20kHz) at a given power for a long time (96 hours). If the speaker performance remains the same after several tests, we can assure that the speaker can handle that rated power.

This wideband signal is usually pink noise. This signal has a particular frequency density and peak to RMS relation (also known as crest factor) which mimics the average audio content which can be played through the speaker.

What if I am not playing all the time audio content similar to that pink noise? What if we can analyze in real time the type of audio content being played and adapt my system to maximize the signal delivered to the speaker?

• Which are truly the key parameters which set the speaker´s limit?

We need to understand what exactly is relevant to the speaker´s reliability and analyze those parameters in real-time based on the content being played.

Well, signal power looks like relevant, but it is not the key parameter to look into to check if the speaker may be or not reaching its limit. Speaker overload point can be tracked by two very low-level physical magnitudes: Temperature and Distance.

The speaker limit is truly fixed by the maximum temperature its coil can handle, and the maximum excursion (elongation) of its membrane. If we are able to observe and control the coil´s temperature and the membrane´s excursion, we can deliver as much power as we want.

The rule has been changed, speaker limit is not the power anymore but its excursion and temperature.

This new approach will request from the Amplification System the capability of tracking the status of the speaker. SmartPAs will be aware not only of the audio input signal but also of the speaker status.

• Do these systems require a greater power supply for avoiding saturation?

They do! As we are claiming, these systems are capable of delivering much more power to the speaker without reaching its limit (excursion/temperature ) so you may think that we should also increase the power supply voltage to avoid saturation, and that is correct.

While typical AGCs use a 5V power supply, it is normal that you can use a 10V power supply to avoid saturation under certain power peaks demand. Keep in mind making double the voltage, makes four times bigger the power demand!

This Amplifying Structures also use its smartness in terms of power handling! Any power supply has a constant current drain known as the quiescent current which is proportional to its output voltage. That means, the greater the voltage the power supply provides, the greater the standby consumption will be. Smart PAs, are aware of the input signal level so they can predict their output level. That level will not always reach the maximum output voltage so, why do we need to keep always the power supply set to max voltage? We don´t have to! Smart PAs use Smart Power Supplies, which dynamically adjust the power supply voltage to the minimum necessary level to avoid saturation.

We are not even close to fully explain how SmartPAs work, but we have just given some insights into the trigger which enabled such a big improvement on the Amplifying Structures.

*******************************************************************

I hope you all have enjoyed this article and keep reading. We will release soon the third and last part of this post on which we will go deep into Smart PA operation and explain in detail how these amazing amplifiers work.

Signal Amplification on Smartphone´s Audio — Part II was originally published in BQ Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

On the other hand, they also implement their own dependency injection, based on annotations and an application context that handler all beans initialization and tracking (pretty much as Spring).

So well, let's move on to a real example in order to see, about what we are talking about. We are going to setup this petstore example application and have a look how much memory they use at start time.

java -> petstore_pets_1 -> 162.5Mb

java -> petstore_mail_1 -> 58.52Mb

java -> petstore_offers_1 -> 149.6Mb

Mmm … It’s too far from this 8Mb that ‘OCI’, the Grails core team, claims. Why?. Maybe because they were talking about JAR size, however, this JAR will never work without a JVM. I am sure that if you use Java 11 and modules you will be able to reduce this JAR + JVM size. We already did the effort, and we got a microservice of 40 Mb using Vertx framework.

Hello World Micronaut Vs Hello World Spring

In order to make a fair comparison between both framework, we are going to set up the “same” HelloWorld application.

• Micronaut helloWorld app
• Spring helloWorld app

Micronaut Memory/Thread usage

We are going to run a performance test with 100 concurrent users that make one request per second, in order to see how each framework behaves in terms of memory consumption and threads.

1.Micronaut Memory

around … 76.3Mb

2.Micronaut Threads

Threads details

The behavior is as expected. Micronaut is an asynchronous none blocking threads framework (reactor), so we expected this behavior, a fixed thread pool (even one thread would be enough) that handler all request. This is quite handy when you have to design and develop a middleware that acts as a proxy of several pieces each one with their own latency.

Spring Memory/Thread usage

1. Memory needed

around … 233.7Mb

2.Spring Threads

… 1 min later the test was stopped…

Threads details

Look at the size of the scroll…

The behavior is also as expected. Spring has a huge legacy and has a lot of libraries that break the main golden rule of all ‘asynchronous none blocking’ frameworks:

Don’t Block the Event Loop

This is very important to keep in mind because if you use Micronaut you should pay attention to all of these third party libraries that you use in order to don’t finish up as Spring. Anyway, it’s quite interesting for this test, because this is a hello world application (there are no third-party libraries), and Spring behaves like an old synchronous and blocking framework.

Conclusion

Micronaut it’s a fresh air in the Spring world, they keep the annotation paradigm live at the same time that they remove all legacy ‘mess’. The result was a slim approach that handler in a smooth way all concurrency issues. I miss an eventbus as other JVM frameworks have, as Lagom, Akka, Vertx… that decouple the microservice (the business logic) with ‘how to deliver’ this logic.

Micronaut, ‘Spring’ fresh air… was originally published in BQ Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

We use this recording feature every time we send a voice memo using Whatsapp, audio is recorded in mono, or when we record a video, which is captured in stereo.

In this article I am going to focus on stereo recording and its signal processing techniques but same key points could be applied also for mono recording.

Recording Scenarios

We can distinguish between two different recording scenarios depending on Sound Pressure Level (SPL):

• High SPL scenario: recordings during concerts or in nightclubs. These recordings are characterised by high audio level which could cause so much distortion.
• Low SPL scenario: recordings in silence rooms such as libraries. These are characterised by low audio level which have to be amplified causing high noise floor.

These two scenarios will determine our recording signal processing strategy.

Common Recording Tuning

Our complete recording processing chain is composed by different modules, each module has a specific role. They are set in a specific order as the following image shows.

• Analog Gain: it could be set to different values (0, 6 ,12, 18 or 24 dB). We have set it to 0dB and applied all the necessary amplification in the digital part which gives you more accuracy.
• Analog to Digital Converter (ADC): one dedicated converter for each mic.
• High Pass Filter (HPF) IIR: used to attenuate low frequency components such as wind. Its cutoff frequency is set to 50Hz.
• Digital Gain: it could be set from -72.5 to 18dB in 0.5dB steps. We have set it to 11dB in order to avoid saturation before the compressor.
• Infinite Impulse Response (IIR) Filter: used to make flat mics frequency response. This is necessary due to some mics have a peak level in high frequencies, so it is used to attenuate it.
• Dynamic Range Control (DRC): used to characterise type of recording we want to achieve.

For now on, we are going to focus exclusively in DRC which will determine the behaviour in the different scenarios. I am going to explain how this module works, and different types of processing we can do depending on the scenario.

Dynamic Range Control

This module applies different gains depending on input signal level. It is formed by four parts as you can see in the next image.

• Makeup Gain: it is the total gain applied for middle level signals.
• Compressor: it acts when the signal is too high and needs to be less amplified or even attenuated.
• Noise gate: it acts when the signal is too low, in most cases it is noise, and needs to be less amplified.
• Limiter: it acts only when compressor can’t catch some specific audio sample. It is much more aggressive.

Once we have explained how a DRC works, we are going to described how to adjust it for three scenarios and the difference between them.

BQ Style

We are going to start describing main DRC parameters used in our final DRC. We want to achieve following behaviour:

• Makeup gain set to 18dB this will cause enough makeup gain to amplify low and middle levels.
• Soft compression from -34dBFS will avoid saturation in high SPL scenarios. For a 0dBFS level an attenuation of 5dBFS is applied.
• Soft noise gate from -53dBFS will avoid noise amplification in silent scenarios.
• Limiter is set to -4dBFS, and after it amplifies 3dB.

Loudness Optimized

The main purpose of this processing is to obtain more level so it is perfect for low SPL scenarios. Comparing with processing used changes to apply are:

• Makeup gain set to 24dB, which is the maximum level.
• Harder compression from -34dBFS. For a 0dBFS level same attenuation of 5dBFS is applied.
• Noise gate starts from -63dBFS. This will amplify very low sounds.
• Same limiter.

These changes will cause more noise presence and more low signal amplification. Also, more saturation in high SPL scenarios will be present due to its harder compressor.

Idle Noise & Distortion Optimised

The main purpose of this approach is to avoid idle noise and saturation so it is very convenient for high SPL scenarios. Comparing with tuning used changes to apply are:

• Makeup gain set to 8dB.
• Soft compression from -19dBFS. For a 0dBFS level same attenuation of 5dBFS is applied.
• Soft noise gate from -72dBFS with more drop. This will amplify very low sounds and attenuate silent scenarios.
• Same limiter.

Sacrificing so much level will cause less noise presence and more natural transitions between noise gate and amplification zone. Also, less saturation will be present.

A comparison between these three DRCs can be seen in the next images.

Recording Audio Tests

In our laboratory we do several tests to analyse and validate the recording performance. These tests are always done in a stable environment within an anechoic chamber. In this article we are going to show three of them and each result of the different approaches so you can get your own conclusions.

The first one is a woman talking at a very low volume, low SPL scenario. We recommend to use headphones for these listening tests setting volume to a high level.

Note: all the recordings were done with the smartphones in portrait mode. This is the reason why the right channel has more level than left one.

The second and third tests are done with the same song. During the second one, it was played at a middle volume. So we recommend to decrease a little the volume of your headphones.

In the third one the volume is set to a level similar to a concert scenario, so we recommend to decrease even more the volume of your headphones.

Which is your favourite processing policy? What would you change? We are willing to know your opinion!

AUDIO SIGNAL PROCESSING APPROACHES ON SOUND RECORDINGS was originally published in BQ Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

The command pattern is a behavioural design pattern that consists of encapsulating actions within generic objects that will be executed later. This allows us to create different actions from any part of our code and send them to a queue. This queue will then be consumed by an invoker, which has no idea where this command is coming from or what it does. This gives us the advantage of treating all the different actions in the same way, since they will all have the same interface.

In our case, the client creating the commands will be the QVtkFboItem, the invoker will be the QVtkFboRenderer and the receiver will be the ProcessingEngine in most cases.

Another advantage of using this pattern is the ease of integrating a QUndoStack. This will allow the user to undo/redo all the actions that are applied to the 3D canvas, such as importing a 3D model or translating it. To achieve this, all our command objects will inherit from QUndoCommand.

class CommandModel : public QUndoCommand

The QUndoCommand provides two virtual methods called undo() and redo(). Using the first one we will implement the particular action we want executed in the canvas. In the redo method, we will implement the action to revert it.

void CommandModelAdd::redo()
{
    m_vtkFboRenderer->addModelActor(m_model);
}

void CommandModelAdd::undo()
{
    m_vtkFboRenderer->deleteModelActor(m_model);
}

Compared with the code presented in the previous article, here we will add a QUndoStack where the commands will we pushed after being executed. In fact, the QUndoStack runs the redo method automatically when pushing to the stack. Then, when the user undoes an action the command will run the undo method and be popped out of the stack.

In the case of the Translate command we had to implement a small adaptation. Since the translation is done using the mouse, the objects being translated goes through several transformations that give feedback to the user while dragging the model. However, we do not want all these intermediate commands to be added to the stack, just the command after the user releases the mouse button. In order to achieve this we just added a parameter to the translate command objects that differentiate which ones need to be added to the stack and which ones do not.

if (command->addToStack())
{
    m_undoStack->push(command);
}
else
{
    command->execute();
}

Also, since the undo/redo actions need to be executed in the renderer thread, these are also implemented as commands. This way they are executed during the render step, just like all the other commands. Fortunately there is another reason why we want this behaviour. Imagine you are working on a really slow computer executing really demanding actions, a situation where the user can generate commands more quickly than the computer can process them. In this case, if an undo action is submitted we want it to be queued as well so that it reverts the last action from the queue and not the last action executed.

Another use case where this approach is helpful is when opening a project. A project could consist of several STL files with different instances, different position, rotation angle or scale factor. In this case, all these commands would be created and queued at once to be executed but stacked as a single command. This way, despite having multiple commands, the action of opening a project could be undone with just one click. To achieve this, QUndoStack provides developers with macros.

To further extend the capabilities of this example application we could add commands to rotate, scale or duplicate models. For now, only the Add, Delete and Translate commands have been implemented. You can find the source code in the following repository:

nicanor-romero/CommandPattern

The code was compiled using Qt 5.9.3 and VTK 8.1.1, tested both in Windows 10 and Ubuntu 16.04. Bear in mind that in order for this code to work you will need to add the vtkRenderingExternal module when compiling VTK. For more detailed building instructions check the README file found in the repository.

Using the command pattern to undo our mistakes was originally published in BQ Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ignore the “Real World”, learn from your mistakes. Allow that the function makes the organs, I am completely sure that the 80% of the mammal thought the dolphins were crazy, but there they are, alive and kicking.

On the other hand, remember that all the technology is volatile, it is conjunctural almost ephemeral. That today it’s “right” tomorrow could be “wrong”, that’s because we live in an ecosystem that is constantly changing, so something that today is important, tomorrow is not. For example, if quantum computing success all the cryptography that we have developed until now will not make sense anymore. But until that happens, asymmetric keys are “the truth”.

So, after these random thoughts, that make you think a little, and also allow me to excuse my self in case you bother me or blame me for something that I wrote, let’s move on to the main topic, cloud computing “Yes”, cloud computing “No”, Which Cloud?. I expected to create a dialog with the readers and based on their feedback start a conversation and put more light into the darkness.

Cloud computing, formal definition

Cloud computing is an information technology (IT) paradigm that enables ubiquitous access to shared pools of configurable system resources and higher-level services that can be rapidly provisioned with minimal management effort, often over the Internet. Cloud computing relies on sharing of resources to achieve coherence and economies of scale, similar to a public utility.

Not bad definition, from Wikipedia. And actually they are right. Cloud computing doesn’t talk about dropping your on-premise data center or delegate your operations to a third party like Amazon or Google. Cloud computing talks about virtualization, talks about share resources between departments, companies and/or people, improving the usage performance and reducing the cost of maintenance and hardware. And all of that only could be done if we guarantee that each workload (virtual machine, container, process) it’s well encapsulated, from security, data integrity, and memory/CPU cycles. And that job could be done by yourself, or delegated to a third party in a public or in a private way.

Public / private / hybrid cloud

Based on your need or your company policies you will (soon or later) move on to one of this solutions:

Private Cloud: A model of cloud computing where IT services are provisioned over private IT infrastructure for the dedicated use of a single organization. A private cloud is usually managed via internal resources. The terms private cloud and virtual private cloud (VPC) are often used interchangeably. So, in other words, if you decided to go through this solution is because you have (or are going to have) your own data center. In order to virtualize your stuff, you will need some virtualization providers as VMware, OpenStack (an open source solution, with open APIs and some free implementations), Softlayer or AzurePack. Also, you will need some technical support in order to install configure and maintain all of this solutions. One of the best partners/consultants in private/hybrid clouds is Rackspace.

OpenStack contributors chart

Public Cloud: computing services offered by third-party providers over the public Internet, making them available to anyone who wants to use or purchase them. They may be free or sold on-demand, allowing customers to pay only per usage for the CPU cycles, storage, or bandwidth they consume. So, in other words, we are not talking about security (this is one of the most commons errors). Indeed I think that most of professionals in the sector will agree that public cloud is more secure than a private cloud in the 99% of the cases. Maybe the key point in order to choose between public or private clouds is your capex budget. If it’s not big enough to invest in hardware, buildings, security, “diesel generator sets”, temperature control… and so on, and you only have a budget to run your current business (opex) from an operational point of view, then the public cloud should be your choice. You will be lucky because there are plenty of choices out of there that will give you an awesome cloud service. The most popular are AWS (amazon web services), Gcloud (Google Cloud Computing) and Azure (Microsft Azure). There are others like Digital Ocean, Heroku or Scaleway. Depends on your needs, some of them will fit better with your organization than others. But this analysis will take me another post.

Hybrid Cloud: A hybrid cloud is a computing environment that combines a public cloud and a private cloud by allowing data and applications to be shared between them. When computing and processing demand fluctuates, hybrid cloud computing gives businesses the ability to seamlessly scale their on-premises infrastructure up to the public cloud to handle any overflow — without giving third-party datacenters access to the entirety of their data. Organizations gain the flexibility and computing power of the public cloud for basic and non-sensitive computing tasks while keeping business-critical applications and data on-premises, safely behind a company firewall. So in other words, if you have your own data center, but you don’t have capex in your budget in order to make it bigger, one great solution could be cover this extra demand with public cloud. Companies will pay only for resources they temporarily use instead of having to purchase, program or buy hardware that have to maintain for a long-term.

As you can see there is plenty of choice according to your needs. But they are not all the same. Some providers are more focused on infrastructure, others are more abstract and are more focused on application services, while others remain in the middle. Indeed, there are three layers of services (Iaas, Paas, Saas) in the industry that you should know, in order to understand what each provider is selling you.

Iaas Vs Paas Vs Saas

Iaas (Infrastructure as a service): refers to online services that provide high-level APIs used to dereference various low-level details of underlying network infrastructure like physical computing resources, location, data partitioning, scaling, security, backup, etc. So in other words, Infrastructure as a service will give you a high level of control with a low level of abstraction. Your solutions should be based on this kind of services when the core of your business is to make the most of the hardware at different levels (Network, storage, compute …). There are plenty of choices here, as AWS (EC2, EBS, ELB, VPCs …), GCloud (VMinstances, Disk, LB, VPCs … ), Joyent, SoftLayer, Azure… etc.

Paas (Platform as a service): The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment. In other words: it provides balance between control and abstraction. When the core of your business is at the application level but you need to customize them, test them, in the end, build competitive applications at low cost (when what you need is a framework) then, this is your best choice. Examples of good Paas are Kubernetes, Firebase, Kuasars (private Paas developed by PyroStudios), Tongari (private Paas developed by BQ that allow you secure, monitor and order (service mesh), Kubernetes microservices ), Parse.com (deprecated by Facebook in an epic fail movement), etc.

Saas (Software as a service): The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., web-based email), or a program interface. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings. So in other words, minimum control, maximum abstraction. When the core of your business is at the application level and does not require special customization then this is your choice. As an example of good Saas could be Google Docs, Medium.com, Aws S3, Google BigQuery … etc

Conclusions

In this article, we dive into the most basic but core concepts of the cloud. The eternal debate, between cloud Yes or Cloud No, it has already concluded, and now the question should be Which Cloud. Unfortunately, there is not a clear answer to this question: that will depend on your need, but we saw that if you don’t have capex, then you must go for the public cloud. Finally, we saw that all Internet services could be classified into three classes, and again depends on your needs maybe one cloud provider could fit better with your requirements than others. In any case, remember what we said at the begging of the article: “Ignore the Real World, learn from your mistakes”, or…in other words “the movement is shown walking” so move on! Understand your problems and find your way.

Sources

https://en.wikipedia.org/wiki/Cloud_computing

https://www.techopedia.com/definition/13677/private-cloud

https://www.rackspace.com/

http://stackalytics.com/

https://azure.microsoft.com/en-us/overview/what-is-a-public-cloud/

https://azure.microsoft.com/en-us/overview/what-is-hybrid-cloud-computing/

https://en.wikipedia.org/wiki/Cloud_computing#Infrastructure_as_a_service_(IaaS)

https://en.wikipedia.org/wiki/Cloud_computing#Platform_as_a_service_(PaaS)

https://basecamp.com/books/rework

Cloud Computing “Yes”, Cloud Computing “No”, Which Cloud? was originally published in BQ Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

As you may already know, we plan to update some of our latest devices to Android Oreo. As a result of this upgrade, we’ve had to update our apps to target this new Android version in order to take advantage of the new features provided by the OS, as well as adjust some of our applications’ behaviour to comply with the new specifications defined by Google.

In this article we want to focus on the major changes included in Android Oreo and on our experience in implementing these in our apps in order to make them compatible.

Adaptive icons

One of the biggest UI changes in Android Oreo is the inclusion of adaptive launcher icons. In summary, adaptive icons allow developers and designers to create application icons that can be morphed using masks defined by the device’s launcher app, like our BQ Launcher. This allows launcher apps to normalise icon shapes and provide a more visually appealing experience.

To do this, we have to split our application icon into two separate layers:

• A background layer: a solid colour, a gradient…
• A foreground layer: typically contains the application’s main icon, which can be a raster image or a VectorDrawable.

Using these two layers, launchers apply a mask over them to display the final icon with a defined shape (circles, squares or more complex shapes, like squircles or teardrops). This also allows compatible launcher apps to animate both layers with different effects such as parallax.

We didn’t experience much trouble implementing the new icon format in our apps, especially since we already use VectorDrawables and drawables with layers in our applications to reduce their size (and to save our designers some headaches along the way :) ). It should be relatively simple to reuse your existing launcher icons and adapt them to this new scheme.

Notification channels

Starting in Android Oreo, notification channels have been added to allow fine-grained control over how and when certain notifications should be displayed to the user. This also lets users manage which notifications they want to receive as well as how they want them to be displayed.

The process of creating and using a notification channel is quite simple:

• Create a NotificationChannel with a unique ID and initial display settings: description, importance, sound, vibration, lights, privacy settings…
• Provide this NotificationChannel to the NotificationManager via NotificationManager.createNotificationChannel().
• Build your Notification the usual way (for example, we use NotificationCompat to support older Android versions).
• Publish your Notification using the NotificationManager and your notification channel ID.

Keep in mind that it’s mandatory to implement at least one notification channel if your app targets Android Oreo. This is really important because when we first tested targeting Android Oreo, our notifications weren’t displayed at all!

Alert windows and overlays changes

In order to fortify the OS security measures, some functionality and behaviour changes have been made to avoid Android APIs being used with malicious intentions. One of these changes involves the use of alert windows and draw overlays.

The “alert windows” feature is a way to display views over other applications. Two of the most famous uses of this feature are the chat heads used in the Facebook Messenger app, which let users quickly see incoming messages and start conversations with their friends, and the “Tap to translate” feature in Google Translate, that lets users translate texts with a few taps without having to open the app.
This feature is not to be confused with the new Picture-In-Picture mode also added to Android Oreo, which focuses on video playback over other apps.

One of the advantages of using this feature up to Android Oreo was that we could draw over any interface element, including the notification bar, to enhance user experience. This was used by apps such as Twilight or Status to add new functionality on top of the current system capabilities. However, apps that now use these kinds of overlays and target Android Oreo must use a specific Window type (TYPE_APPLICATION_OVERLAY) that breaks drawing over system UI elements or the keyboard, for example. Furthermore, existing apps that use alert windows in Android Oreo (even without explicitly targeting it) won’t be able to draw over system UI elements either.

Keep this in mind if you want to target Android Oreo in your applications that have this kind of functionality because these changes may affect their behaviour, or even cause them to malfunction.

File Uris and permission changes

A new restriction was added starting from Android Nougat prevented developers from exposing file:// Uris in given contexts, giving a FileUriExposedException reminding us that we can’t use file:// Uris and that we should use content:// Uris with the correct permissions for other apps to use them.

In Android Oreo these restrictions seem to be more severe, causing us some trouble with sharing files that are stored in an app’s private storage (for example, when users send internal app logs via email for us to analyse).

To resolve this issue, we had to implement a FileProvider to expose our private files using a content:// Uri, and then generate our Uris with FileProvider.getUriForFile() to get Uris that external applications can read by adjusting the permissions granted to them.

Final thoughts

Adapting current applications to newer Android versions can be somewhat daunting, especially when major changes are introduced, however, in doing so, full advantage can be taken of the new features included in these versions, and users will be sure to get the best experience possible when using our devices. Many other changes have been introduced in Android Oreo that haven’t been covered in this post (beware background execution limits, among others), however, these key points will give you a good idea on where to start should you decide to prepare your apps to target Android Oreo.

References

• Android 8.0 Behaviour changes: https://developer.android.com/about/versions/oreo/android-8.0-changes.html
• Adaptive icons design guidelines: https://developer.android.com/guide/practices/ui_guidelines/icon_design_adaptive.html
• How to manage notification channels: https://developer.android.com/guide/topics/ui/notifiers/notifications.html#ManageChannels
• Android 8.0 Behaviour changes in alert windows: https://developer.android.com/about/versions/oreo/android-8.0-changes.html#all-aw
• Android 7.0 Behaviour changes in Uri permissions: https://developer.android.com/about/versions/nougat/android-7.0-changes.html#perm

Portions of this page are reproduced from work created and shared by the Android Open Source Project and used according to terms described in the Creative Commons 2.5 Attribution License.

Adapting your apps to Android Oreo was originally published in BQ Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Applying this concept into a WIFI Mesh ecosystem, Backhaul is the communication way between the Main node and the remaining nodes attached in a mesh network. How good or bad is a WiFi Mesh is totally dependent with the Backhaul efficiency and the Backhaul technology choosed for communicating one node with each, so this concept shouldn’t be overlooked when choosing a mesh system.

Backhaul options?

Once we know the concept meaning, it is time to talk about the different backhaul systems. Depending on the backhaul transmission mode used we can classify the backhaul systems as follows:

• Wired: Backhaul connection is based on a cable between each node. The wire uses Gb Ethernet ports in the far ends and it's able to manage up to 1Gbps Bandwidth. This connection transit independent of the WIFI clients resources so clearly provides a good way to communicate the Mesh nodes between each other as the WiFi interfaces are 100% reserved for users/clients.

• Wireless: Backhaul connection is based on a Wi-Fi link between each node. The backhaul can travel in Wi-Fi 2,4Ghz or Wi-Fi 5Ghz radio bands. We can find two potential configurations for Wireless Backhaul:

• 1) Wi-Fi Shared: The backhaul connections share the front-end resources with the clients attached to the mesh network. It allows saving space in the WiFi devices (they do not have a specific radio resources for Backhauling) but the whole WIFI performance is shared between real clients and the nodes, so that, lower final users performance would be expected. This solution was adopted by Google Wi-Fi and this kind of devices are commonly called as “Dual-Band”.
• 2) Dedicated Wi-Fi : The backhaul connection takes place in a specific radio link interface, used exclusively to communicate any node with any other. It requires more hardware resources (i.e. Power amplifiers, Front-ends, radio filters, Wi-Fi antennas) but provides a clear and efficient communication solution, where the clients (real users) are attached in a different network (entirely used for clients) than the Wi-Fi nodes communication link, so better global performance is expected for users and also for Backhaul. Finally, it is important to highlight than in this case, the dedicated backhaul uses Wi-Fi 5Ghz radio band due to the high link speed capacity that this band is able provide. This is the solution used in Asus Lyra, Linksys Velop, Netgear Orbi and it is commonly called “Tri-Band” since there is two radio bands dedicated for Users and other additional band, the third, dedicated for Backhauling.

Now it is time to discuss about the capacity for each solution. Normally speaking, the Wi-Fi solutions come with a capacity code indicator such as AC2200 or AC3000. This code mention the highest protocol supported (in this case Wi-Fi 802.11ac) and the radio links capacity (adding 2,4Ghz and 5Ghz radio bands). To an easy understanding, let's go with a sample:

AC3000

• Best protocol supported is 802.11ac.
• Wi-Fi 2,4 capacity: 200 Mbps per antenna x 2 Antennas: 400 Mbps
• Wi-Fi 5 capacity: 433 Mbps per antenna x 6 Antennas: 2598 Mbps
• Total: 400+2598 = 2998 ~3000 Mbps

So we can now evaluate the numbers and general Wi-Fi device capacity but we also already know than depending on the Backhaul technology used, not 100% of the capacity is used for clients. In general terms, we can find in the market two Wi-Fi mesh solutions as I mentioned:

• Dual Band: Generally comes with a 2x2 Wi-Fi 2,4Ghz + 2x2 Wi-Fi 5Ghz in each node, so the total capacity is AC1200. As we saw above, dual band does not have a dedicated backhaul so that the 1200Mbps of Bandwidth manageable by the system is shared between Clients and Network nodes.
• Tri Band: We can find AC2200 or AC3000 versions depending on the antennas configuration. For AC2200, we have 2x2 Wi-Fi 2,4Ghz + 2x2 Wi-Fi 5Ghz subsystem dedicated for clients (1200Mhz) and 2x2 Wi-Fi 5Ghz dedicated exclusively for backhaul. In AC3000, the most common configuration is 2x2 Wi-Fi 2,4Ghz + 2x2 Wi-Fi 5Ghz subsystem dedicated for clients (1200Mhz) and 4x4 Wi-Fi 5Ghz dedicated exclusively for backhaul.

Backhaul was originally published in BQ Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Firstly, we will do an overview of the basic principles of the amplifiers before going into detail in the state of the art on audio amplifiers in smartphones industry.

What is an amplifier?

Amplifier´s target is increasing the signal level to adequate it to the next system in the signal path with the lowest signal perturbation. In the picture below we can see a very simple block diagram of an amplifier. Amplifiers replicate the input signal at a greater level. Most of amplifiers need a power supply as “raw material” source.

Types of amplifiers

There are many different types of amplifiers based on different parameters such as its input (signal nature, level, bandwidth, frequency,…), output, efficiency, quality and system limitations (size, cost, thermal performance , interferences shielding…). We can cover some of the most interesting amplifiers attending to the input signal nature:

• Acoustic amplifiers are very interesting since they can work without a power source. Acoustic signal reverberations within a cavity can amplify the original (input) signal. This is the physical phenomenon behind the speaker baffles.

• Electric amplifiers work with electric signals, and require an external power supply as source to output the increased signal. These are the most common amplifiers, and can be used for many different applications such as radio and audio (which will be our case of study).

Which parameters describe an amplifier?

• Input signal: Physical nature, level, spectrum

The physical nature of the signal describes which kind of input we have in the amplifier, it can be an optic, acoustic or electric signal among others.

Two of the most relevant parameters of an input signal are the amplitude and frequency. We can observe both either in the time domain or in the frequency domain. Time let us understand how the signal changes in time while frequency shows signal´s spectral content.

• Power Supply: level, noise, stability.

Raw material quality is essential in amplifying the input signal; we can’t construct a building if we lack a big amount of stable and pure concrete.

Boost level, is the maximum level the power supply can deliver. This level will obviously limit the maximum output level.

Power supply must be kept clean, with no interferences or instabilities, as every defect this signal has will be present in the output signal.

• Output: level, gain, load.

The output level will be defined by the gain set to the amplifier (as long as our boost voltage is high enough). The gain defines how many times bigger the output signal will be. Depending on which is the next system in the signal path (called load), our amplifier can be capable or not of supplying the output signal to it.

• Efficiency

Defines how efficient the amplifier is in terms of power. Which amount of the total used power is delivered in the output? Depending on the application, this parameter can be extremely relevant, or not.

Amplifier Quality

We already got the output signal! It is time to check how well it was amplified. These parameters describe the amplifier quality.

• Frequency Response (FR): Defines how constant the gain is across the different frequencies which compound the input signal, and which is the amplifier working bandwidth.

• Total Harmonic Distortion (THD): Distortion refers to “added” content in frequencies not present in the input. Harmonic signal is a type of distortion which appears on the harmonics of the original signal.

• Transient response: Besides spectral analysis, there are several time-dependent quality indicators, which define how the amplifier behaves in rapid signal changes. Slew Rate is the most common way of describing how fast the signal level can increase/decrease in the output.

Now that we have already explained amplifiers a bit, we can face a deeper analysis about which peculiarities audio amplifiers have, their types, which is the state of the art on smartphone´s industry and nowadays leading technology.

Hope you can all read the second part of the article soon!

Signal Amplification on Smartphone´s Audio — Part I was originally published in BQ Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.