Design Thinking

In the previous week, we worked to design a better concept and solution to satisfy our customer by thinking and acting like a user.

As I did the week before, I continued to work on the system’s programming, linking the Pick navigation to the API, and creating a new screen that is intended to help the user comprehend the specifics of that item as well as the stages that have been passed from.

We went through a few steps before deciding to add that screen.

For a human-centered design method like design thinking, empathy is essential. It enables you to put aside your own worldview assumptions and obtain genuine understanding of our users and their needs.

Then we evaluate our findings and defined the main issues that the current design shows. After that, we started looking for solutions to these issues, and one of those solutions was to design a screen with a choose details view attached to it, allowing the user to switch between them by using the bottom tab navigation.

So as a programmer or designer, you should consider and care about what the user needs and feels, and you should also always look for better ways to improve the user experience. I then started applying that principle into our system.

New Screen to the System

In the last week, I produced a new screen, which now completes the new navigator.

My new objective was to construct a new screen after linking the API with the navigator last week. as the prior wasn’t too difficult to make
This screen is connected to create API, and it has two API queries, just like last week. The first is a GET request, followed by a POST request.

Following that, I began creating databases to test if there were any bugs. After experimenting with several cases, I discovered that there is something wrong with the answers, as the server provides a 200 status response and accepts the request when it should be an error. Mr. Peter saw the bag and is now repairing it.

Mr. Peter was really concerned about it, so I saw the benefit of the automation testing that I had done previously. By adopting a variety of scenarios, automation testing aids in the detection of any issues.

Add pagination to the two list view screens, and this time the page number and size are provided with the request, rather than dividing the pages as I obtain the data as before.

Connecting with API

We had a lot of trouble connecting the system to the backend last week.

Last week, I realised the significance and necessity of dealing with setup to the programmers. The initial problem was with the SSL certificate, which prevented us from creating a purchase order to test whether the service worked or not. This was a backend issue that was resolved by Mr. Peter.

After that, we discovered another IP address issue, which required me to update all of the IP addresses with my computer’s IP address. Also, we discovered that the ports we declared were not the same as the ones on the docker. After making the necessary changes, we are now able to connect the produced API to the system.

I provide a header to the API that includes the URL and the access token, but it doesn’t function and returns an error. After doing some research to figure out what that error meant, I discovered that we needed to install the react-native-url-polyfill library and add its function to the header to make  everything to work properly, and that was the clue. After installing it and adding it to my API service, I was able to request the API and receive a 200 status.

After testing all of the requests, the service is now completely functional, and the responses are exactly what I expected. Also, all of this is created by a type model, with the exception of the error, which I will resolve next week.

Generating Client API and Defined with the OpenAPI

On the past week, I finished the OpenId server login last week and started a new work, which is generating the swagger API.

Mr. Peter added the log out to the server, and then the thing was quite easy, it’s almost like the log but just has two arguments, the issuer and the logout argument, so now the user can log in and log out to the system through the OpenId server.

After completing this task, the next goal is to convert the swagger API to Typescript. This was a new technology for me, and all I knew was that we could link the backend to the front end using the endpoint’s URL. Mr. Peter provided me with a link to the Swagger CodeGen library so that I could investigate it and integrate it into our system.

I found the instructions for that library to be a little hazy, so I started watching YouTube videos where YouTubers hardcoded the generation, and I did the same until Mr. Peter came along and showed me that I only needed to perform one command. Then there was the difficulty of the SSL certificate, where I needed to figure out how to include those certifications on the command. This technology isn’t widely used, so I couldn’t find much information about it. Eventually, I figured it out and generated the code.

Integrating OpenId to System

I finalised the design of the Navigators this week, and I’m working on integrating the openId identity into our app.

In order to design the app, I added a search box to some UI so that the user could search for the customer’s name if they couldn’t find it in the long list, and I’ll also utilise the search bar to look through all of our system’s lists.

The second task is to integrate OpenId technology into our app, for which I watched many videos and read a lot of information in order to grasp the technology and apply it to our system. It wasn’t easy to grasp at first, as I assumed we would simply connect the app to the backend using the url endpoint.

I could only discover theories about it and couldn’t find anyone who has used it to see how it was implemented, so I followed the react native auth library and began to explore. After numerous attempts, I was able to get the program to launch Chrome and login view. However, the challenge I’m having now is calling back the app after a successful log in, which is something I’m going to investigate over the next week in order to make the app completely functional with this OpenId server.

Last Touches to The App UI

I updated the UI of the app and added a new screens to the system last week.

A novel navigator, comprises two screens, the first of which contains data and the second of which contains some information and implementation. Actually, I had no problems with the navigation. It was different from the prior screens, but it was simple for me to complete.

I also work on the user interface of all screens, beginning with the picker navigation. At first, I assumed that designing was as simple as changing colors and gridding the data on the screen. But I was completely wrong, because I need to build a design that promotes user engagement, improves functionality, and establishes a great friendship between the user and the app.

I learned a lot of useful information about user interfaces, and I also discovered the react native paper library, which provides a better component than react native library.

Finally, as I do every week, I implemented plenty of hooks, beginning with useState and finishing with useRef. I also addressed a problem highlighted by Mr. Peter, which was data loading delay.

New Navigators to the System

So far, I’ve completed everything Mr. Peter has given me.

By the end of last week, I had completed the shifting navigation and two other navigations that Mr. Peter had requested, as well as all of the logic business that was required on the screens.

The picking and packing screens were similar to the shifting screens. definitely still not exactly the same, I believe I have a better understanding of how the system works and have begun to formulate a strategy to cope with it. I am grateful to Mr. Peter and the Tong Hin Company for providing me with this opportunity to further my development skills.

I also included an unpicked option to the PickNavigation that lets the user to unpick any product, similar to the Pick Screen. Then I started beautifying the system’s user interface.

The issues I worked on last week were with the focus of UI, which refused to focus on the next input. After many attempts, I discovered that the useEffect is not closed after the initial rendering, and that to close it, I must include an empty array at the end of the hook.

Pack Navigator

During the previous week, I improved the pick navigation and added Pack displays.

Last week, I added two new screens to the warehouse system: packs screens and pick navigator screens. Pack screens allow users to pack things that have previously been picked.

The first page is about tables, where data about the client is displayed, and the second screen is about pack detail view, where information about the packed item is displayed, as well as some implementation details.

When I finished the final touches on the choose navigation screens, I limited the user’s flexibility in using it by creating preconditions to practically everything to limit the error rate at work .

The most difficult problem I encountered last week was focusing on the same area after receiving an error, where the app did not respond to the focus until we read the useref documentation and determined that we needed to remove focus to allow it to work again by blurring focus.

Picker Role Navigator

In the passed week I have completed The PickNavigator screens

I finished The PickNavigator last week. After finishing the log-in, my task was to make 3 more screens. This past week I created three more screens for the PickNavigator, the first of which had a button to access to the rest of the screens. The second screen appears with tables after you click on the button.

The third screen, the order detail view, is about displaying details based on the tables. The most challenging thing I’ve faced on making this screens is using the useRef to focus on a field on the screen and perform the default location. For useRef, Mr. Peter set an example for me and let me deal with the remainder, where I discovered how simple it is.

Setting the default location was a little more difficult comparing with the other difficulties that I have a faced. I wanted to make a useRef to focus on that location, so I started looking for a useRef for TouchableOpacity that would focus on a click on the location once the screen appeared. Since it was my first time utilising useRef, that was my logic until Mr. Peter explained the way, which was not too far from my logic.

In the last week, I’ve learned a lot of useful stuff, such as how to utilise the scanner, which I was completely unfamiliar to me at the start of the week, and how to use the useRef Hook to focus in any textInput field. I also was dealt with a bunch of useEffect hooks and others.

Json Web Token

Following the completion of the design phase, we move on to the development phase.

This new system will be integrated with the old one, which has its own tracking. That the very first task was to handle the log in for two different users: those who will navigate to the Picker and those who will navigate to the Item Navigator. Mr. Peter guided me through the JWT method for solving this problem.

I first learned about JWT when I tried to make a user log into a separate navigation depending on his role. Finally, I created a token that, if the user role is Picker, navigates to the PickerNavigator; otherwise, he navigates to the ItemNavigator. And it was the first time I used the useEffect Hook that I truly grasped its concept.

After logging in, I also construct a screen for the Picker role. After hitting the button on that screen, you will be taken to the following screen. The second screen is about tables and orders data, and when you arrive there, you’ll see a table with all of the clients who have placed orders, along with their data, and the raw of each client is clickable, which will take you to another table.