useFocusEffect

By defintion:

It just has an effect to run.

For useFocusEffect, when you hit the current page, it runs the effect, and caches the cleanup.
When you go to the next page, it’ll execute the next page’s effect first. And then runs the clean up of the previous page.

So in our case

when we hit Page1, execute effect Page 1 (A).
Goes to page 2, execute effect page 2 (K), clean up Page 1 (Z)
Goes to page 3, execute effect page 3 (M), clean up Page 2 (R)

From page 3 back to page 2, clean up Page 3 (N), execute effect Page 2 (K)
From page 2 back to page 1, clean up Page 2 (R), execute effect Page 1 (A)

A huge difference is that useFocusEffect does not have a dependency list, which it depends on for it to run its cleanup/effect.

useEffect

Whereas for useEffect, we also have an effect and cleanup, but they depend on the dependency list’s variables changing.
If it changes, then we’ll run the clean up, and then the effect.

If nothing changes in the variables, then we do nothing!

KeepAlive
The keep alive is a time interval in seconds that the client specifies and communicates to the broker when the connection established. This interval defines the longest period of time that the broker and client can endure without sending a message. The client commits to sending regular PING Request messages to the broker. The broker responds with a PING response. This method allows both sides to determine if the other one is still available. See part 10 of this series for detailed information about the MQTT keep alive functionality.

Basically, that is all the information that is all you need to connect to an MQTT broker from an MQTT 3.1.1 client. Individual libraries often have additional options that you can configure. For example, the way that queued messages are stored in a specific implementation.

Let’s combine some types and test for them:

ref – https://developer.apple.com/forums/thread/123790

I usually have this problem when a dependency is not updated.

Delete your Podfile.lock (I like to use the command ‘-rm -rf Podfile.lock’ on the terminal for this)
Delete your Pods folder (I like to use the command ‘-rm -rf Pods’ in the terminal for this)
Pod install

Clear your project in XCode > Product > Clean Build Folder

https://www.geeksforgeeks.org/how-to-use-react-cloneelement-function/

ref –

• https://blog.sessionstack.com/how-javascript-works-the-publisher-subscriber-pattern-9edc62ef1a68
• https://refactoring.guru/design-patterns/observer/typescript/example
• Broker Demo

The broker demo is to describe the pub/sub broker. To run it:

yarn install
yarn develop
open browser at “localhost:8080”

First, let’s take a look at the Observer Pattern.

Conceptual example on Observer Pattern

In the observer pattern, observers are attached to a subject. When the subjects notifies them all, it calls update on the subjects. That’s how the subjects are all notified.

In other words, with the observer pattern, each observer is required to be attached to the subject, so that it can get a notification. However, the pub/sub pattern does not require this.

Difference between pub/sub and Observer

The pub/sub pattern uses a middleware that sits between the objects firing the event. In this case, the publishers and the subscribed objects.

The pub/sub pattern involves a middleware that is also referred to as the broker.

The pub/sub broker handles interactions between the publishers and the subscribers via data structures and its implementations.
Publishers publish contents or publications to the pub/sub broker and it handles the delivery of these contents to the appropriate subscriber.

The pub/sub broker also enables loose decoupling of publishers and subscribers and it supports many to many relationships between the publishers and the subscribers.

So unlike the observer pattern, the pub/sub pattern allows multiple publishers and multiple subscribers.

Example – React app that subscribes to certain topics and receives the data in the UI component

Let’s see how it is used.
In our case subscribers are clients such as a React app. In its UI component, it needs to receive data about what to change and update on certain pages.
So the React code may be like so:

subscribing on the UI

Callback to receive published data

callback will start receiving data once an entity publishes to racePageTopic.

We can also use the broker in other components to subscribe to different topics to receive different data.
Again, the callback would receive the data and update the UI accordingly:

callback will start receiving data once an entity publishes to investmentViewTopic.

The Broker

We have a Map structure that keeps track of a string key and an array of functions.
The key is the topic that different clients will subscribe to, and the array of functions keep track of the subscribers.

We use subscription to return an object that has two functionalities: subscribe and unsubscribe. It uses closure to access the needed topic name and subscriber.

When subscribe, we simply keep track of the topic name as keys in our Map, and then append subscribers (from clients) onto the value array.

The publishers will want to publish data according to topic name. This means all subscribers to that topic name, will receive that data.

Subscribe

We first to check whether we have an entry for this topic. If we do, simply push. If not, create one, then push the subscriber onto it.

Unsubscribe

We unsubscribe a client subscriber by iterating our values array to find it. Then remove it.

Publish

Backend apps can act as publishers and push data like so. All it needs is to know which topic it should push to.
Once we give a topic name, it’ll search for that topic, seems which subscribers are stored in the value array, and then
execute each subscriber with data as args.

Publishers

A node server may act as a publisher. It will import PSBroker, then use it to publish data
to all the subscribers for that event topic.

ref –

• https://medium.com/@bhagvankommadi/mosquitto-mqtt-2a352bd8f179
• https://github.com/GR34SE/react-typescript-starter

React Project with MQTT client
‘yarn’ to install packages
‘yarn develop’ to run on localhost:8080

Mosquitto is an open source MQTT message broker service. It uses MQTT protocol for device to communicate by sending and receiving messages. Among the message brokers that support MQTT, Mosquitto is a small and light weight implementation of MQTT v3.1/3.1.1.

Installing Mosquitto locally on your Mac

make sure you have brew installed. brew –version

Then we install mosquitto. brew install mosquitto

Create a script where we start up mosquitto. We run it by going sh mos.sh

Create password file

create a file called say, p2.txt
enter your username:password like so:

admin/root
root/root

Then place the p2.txt file into /usr/local/etc/mosquitto

Make sure we hash it:

mosquitto_passwd -U passwordfile

Then we edit mosquitto.conf in /usr/local/etc/mosquitto

restart mosquitto and then open MQTTX app.

Setting up MQTTX

MQTT X is a cross-platform MQTT 5.0 client tool open-sourced by EMQ, designed to help develop and debug MQTT services and applications faster.

name: localhost
client ID: auto-generated
username: ‘put the username you inserted into p2.txt’
password: ‘the matching password for the username’

Press connect.

Now that we’re connected, let’s create a topic. Click on ‘New Subscription’.
Let’s type topic as “/covid/#”

By using MQTTX, we send payload for topic “/covid/….” to our local MQTT broker. It will then send to all the MQTT clients that have subscribed to “/covid/….”.

Getting local MQTT broker to work with local MQTT client

Now that our local MQTT broker is working, let’s create a MQTT client.

We start off with a very basic functional component. We create strings for our MQTT broker url, which is ws://localhost:9001. The reason why we use ws here is for web service, which is the way how MQTT clients communicate with brokers. We do this over port 9001, which is reserved for ws.

src/components/HelloWorld/index.tsx

step 1 – create an instance of the MQTT client make sure we are connected

step 2 – we subscribe

Step 1 – Functionality

We create an object where we return functionality to:

• subscribe
• unsubscribe
• terminate

So we have something like this

Step 2 – Singleton

Note that arrow functions cannot be instantiated, only function constructors can be instantiated. So this arrow function explicitly tells the readers that we intend to work with one instance only. And that this one instance will operate on these three functions. However, if it gets called over and over, it will result in multiple instances being created. So we must implement a singleton in order to ensure we only have one instance.

We create a singleton for this instance, at the top.
We call this singleton client of type InternalClient.

Our interface InternalClient calls for property _instance, which references the mqtt client object itself.
And also getL function instance, where it uses lazy loading to check if _instance is created.
If so, we return _instance. If not, we create it using create(). This ensures a singleton.

src/components/HelloWorld/index.tsx

In other words, we see that whenever another source uses client, it will try to access instance. The get function ‘instance’ lazy loads _instance. Because it is null initially, it will proceed to create a new mqtt client object.

If it already has created and point to it, then we just return _instance.

Let’s take a look at how a mqtt client object is created.

We first use import npm MQTT package. We need mqtt to execute its connect function in order to return us a client object. We import MqttClient type because that is the client object’s type.

Hence, we call connect and insert our strings as parameters.
Remember that the un and pwd are username passwords we insert into p2.txt earlier into /usr/local/etc/mosquitto

Once we get that client object we simply return it to be used.

src/components/HelloWorld/index.tsx

Now run the app and make sure the returned object is valid.

MQTT event handler

So now that we have a working mqtt client object, we need to implement event handlers so that we know when we are connected, messages come in, etc.

What this means is that say another Node Server acts as a data center. It wants to inform all of us mqtt clients a ‘good morning’ message on topic “/messages/morning/#”. So any mqtt client that subscribes to /messages/morning/{wildcard} will receive it.

So our Node server sends the messages to our local MQTT broker. The MQTT broker will then relay this message to us via the ‘message’ event handler.

Let’s first do event handler for “connect”. When our mqtt client is connected to the MQTT broker, we will arrive here.

when we receive message as explained, it will come here:

Let’s send a message from our MQTTX test client:

Now, in our event handlers, we see that first, when we start up as an app, we are connected.
Then we receive this message.

Great! So we know the messages are getting received.
But we see that the packet data come in as a stream of data via Uint8Array…where each integer represents utf-8 data.
We will use Pako to inflate the message.

JSON messages sent by MQTT broker

ref – https://stackoverflow.com/questions/50000744/why-is-a-json-parsed-as-uint8array-by-mqtt-js

All MQTT message payloads are just byte arrays at the transport level. If any client library is automatically converting payloads that look like strings to strings this is most likely based on a default encoding (most likely UTF-8)

That JSON contains UTF-16 chars (“Nuages \u00e9pars d\u00e9butant dans l\u2019apr\u00e8s…”) and I would guess that the UTF-8 decoder is failing so the client library is returning the byte representation you to do your own decoding:

ref – https://www.lifesize.com/en/blog/tcp-vs-udp/

Transmission Control Protocol (TCP) is connection-oriented, meaning once a connection has been established, data can be transmitted in two directions.

TCP has built-in systems to check for errors and to guarantee data will be delivered in the order it was sent, making it the perfect protocol for transferring information like still images, data files, and web pages.

But while TCP is instinctively reliable, its feedback mechanisms also result in a larger overhead, translating to greater use of the available bandwidth on your network.

For example, the WebSocket protocol is an independent TCP-based protocol.

User Datagram Protocol (UDP) is a simpler, connectionless Internet protocol wherein error-checking and recovery services are not required. With UDP, there is no overhead for opening a connection, maintaining a connection, or terminating a connection; data is continuously sent to the recipient, whether or not they receive it.

Although UDP isn’t ideal for sending an email, viewing a webpage, or downloading a file, it is largely preferred for real-time communications like broadcast or multitask network transmission.

ref –

• https://stackoverflow.com/questions/479142/when-to-use-an-interface-instead-of-an-abstract-class-and-vice-versa
• http://chineseruleof8.com/code/index.php/2020/12/24/abstract-typescript/
• http://chineseruleof8.com/code/index.php/2021/03/24/interfaces-in-typescript/

An abstract class can have shared state or functionality
An interface is only a promise to provide the state or functionality

An abstract class allows you to create functionality that subclasses can implement or override

We can define instance variables and accept them as input using the abstract class constructor.

Remember that an abstract class is an abstraction, we can’t instantiate it directly. Trying anyway for demonstration purposes, we’ll notice that we get an error that looks like this:

We’ll introduce one of our specific types of Book concretions — the PDF class. We extend/inherit the abstract Book class as a new subclass to hook it up.
We can only extend one abstraction.

Even though we cannot instantiate an abstract class, we can treat it as a superclass and instantiate it by
1) extending from it
2) then call super on it in the constructor

An interface only allows you to define functionality, not implement it

And whereas a class can extend only one abstract class, it can take advantage of multiple interfaces

Abstract classes should be used primarily for objects that are closely related.

interfaces are best suited for providing common functionality to unrelated classes

If you are designing small, concise bits of functionality, use interfaces.

If you are designing large functional units, use an abstract class.

If you anticipate creating multiple versions of your component, create an abstract class. Abstract classes provide a simple and easy way to version your components. By updating the base class, all inheriting classes are automatically updated with the change.

Interfaces, on the other hand, cannot be changed once created in that way. If a new version of an interface is required, you must create a whole new interface.