Category: Experiential

For this week, I was working on the feature to compute the existing and final quantities of history.

Started off by coding an algorithm to compute these values, the aim was to design an algorithm with minimal computational complexity. Since in my last meeting with Mr. Peter, I was informed that any changes in database would only be made when all other ways of performing this task return unsuccessful. Therefore, I was left with no other option than to store the data locally. The idea was to store the final quantity of a history quantity which would be the existing quantity of the following history for the same item.

Created a static class to hold global variables, stored final and initial quantity in a global variable to prevent data being lost on a new API call. Eventually, I was able to design an algorithm which correctly computes each quantity; However, storing data locally meant that the data will be lost when the App restarts. After considering these facts and also the computational cost Mr. Peter instructed me to change my approach and use a database for storing quantities.

To store the values in the database, I added four new fields to the entity. I override the create method for history entity so that it now populates the new fields based on the logic. Finally, I ran a stock adjustment test to see if the new fields were being filled in.

In the last week at Tong Hin, I managed to refactor the cancel ongoing accept stock take command to fit with the refactor background service which uses channel. Afterward, I need to fix the some of the problem for the signalR where the if the process is finished faster than the connection being establish the progress bar will not being updated.

In order to figure on how to fix the existing problem, I needed to mock the signalr service in the background service so the output of the signalr will be display on the unit test instead. The mock is done in order to simulate the client connection which will establish the connection and receive the input from the server.

After some fail attempt in mocking the background service, I move on to doing the code review with Mr. Peter.

For this week, I was able to implement some new features and fix bugs in the History View. Started by separating the View and ViewModel from ItemView and ItemViewModel respectively. Successfully displaying it as a separate tab in ItemView.

Next, I made the barcode disabled, along with its checkbox, to prevent any changes from being made. Discovered that the application was making pointless calls to the API even when it was not being used, this issue was fixed. Moreover, I implemented another feature that gives users an option to view the item’s history in ascending or descending date format. To achieve this I had to make changes to both the API and UI, the UI now contains a checkbox which on checking/unchecking will make separate API calls to display data in different date order. Furthermore, I was able to provide users with the ability to alter the number of rows displayed per page.

Finally, I started brainstorming on a new task which involves comparing and computing old and new data for warehouses. I discovered that I needed to make a separate API call to get the final item quantity. I was able to make the API call in such a way that the entire data set loaded at the same time. Adding logic to determine existing item quantity still remains.

Last week, I completed various tasks related to the StockTake Detail view functionality that I had done the week before. Search matches with the highlight, bugs in the edit item section, and other minor issues were effectively resolved.

First, the highlight function must be consistent with the search, such that the item is highlighted anytime the user searches for the thing. If there are many results, the first one must be highlighted. I took the wrong approach to fix it, but Mr. Peter showed me how to solve it by adding a highlight boolean attribute.

Next, I made the search matches, using the up and down arrows to navigate the match result. Even though, after a few attempts, the matcher navigator functions ideally, it still has some issues, particularly when the matches swap list pages. More setStates were required to keep the value of the result and the selected result. And I needed to add a useEffect to change the currentPosts, which is the data presented to the user.

Finally, several minor bugs in the editing part needed to be addressed. The quantity and barcode were both changed at the same time, and if only the quantity changes, the barcode becomes empty. That was solved by adding if statements into the edit handlers. I also fixed the bug of updating the Stock Take List data when an item is updated, by adding an useEffect to set mount true and I also added an useInterval to refresh the data.

Overall, last week’s outcome was good after also revising the data table style to align the components in a better way for the user to be displayed.

For this week, I managed to complete the History View which now queries the API, based on the input, and presents the user with item’s history details.

Begun by defining properties for history tab then updated the data binding in the view, to establish a connection between the UI and the data it displays. Defined Wrapper, to map the queried result according to the relevant properties.

Next, started implementing Commands which are used to handle a user interaction or action. Finally, establishing  connection between UI and the API , through Refit, to make the application work. 

Lastly, made the View more robust by making the API result and item’s barcode appear (automatically), when the View loads. Furthermore, implemented logic to accept different Type in any case, basically making it case insensitive. 

As for this week, the problem of the web application factory running the dependency injection during testing was managed to be solve with the help of Mr. Peter. Now the services registered in the dependency injection will no longer be instantiate twice during testing.

Next, after changing the stock take background service to using channel instead of concurrent dictionary. I ran into some problem where the channel is not being dequeue after an item is being queued to the channel. With some help from Mr.Peter, I’m manage to figured the problem was the instantiation of the channel.

The problem was that I instantiate a new channel in the accept command service class hence the item is never dequeue from the channel. Lastly, I refactor the cancel ongoing accept stock take command so that it will work with the current implementation of the background service. Now, I have make so that the channel can take multiple entries and the user will be able to cancel the ongoing accept stock take that they requested.

This week, I concentrated on the StocktakeLineItems. Functions such as deleting a specific item were also completed successfully, as were the search function and the edit section for each item.

First, I needed to modify the search functionality, as it is designed to take you to the page that contains the item. The search result must also be highlighted, which was a bit difficult to implement, but with Mr. Peter’s assistance and explanation, I was able to complete it. However, I’m still having issues with the highlight because it isn’t resetting.

Next, I added a delete handler function to delete a specific item based on its Id. In addition, I created a Model to adjust an Item’s barcode or quantity. The layout was initially straightforward, with only one text box and two buttons to save the newly inserted data. Following that, I changed the layout to display the item-selected data and moved the delete button into the modal view. That was useful because the model is now similar to the edit section, where you have complete control over editing and deleting an item.

Finally, I wanted to finish the search function with a highlight, but that didn’t go so well. The main issue was that the highlight did not reset, and it occasionally kept highlighting all items and becoming stuck on that. After speaking with my supervisor, he explained another logic to solve the problem, which I will implement the following week.

For this week, I managed to finish up learning the fundamentals of WPF application and Prism framework which is a UI (user interface) framework used to create desktop applications. Furthermore, I designed the View of ItemMovement tab which now accepts the barcode, reference #, movement type and dates to filter item movement search.

One of the most important WPF application concepts is the MVVM model. This is a powerful concept as it allows to separate the program logic to the user interface. Moreover, data binding in WPF allows data to flow between UI elements and data objects on the user interface. Furthermore, the Prism framework implements a set of design patterns that aid in the creation of well-structured and maintainable XAML applications, this makes the WPF application easier to manage.

Lastly, I need to implement the logic for History so the query is successfully carried. I have updated the View to include more fields to enable advanced search options. Currently, I’m still trying to implement the ViewModel and Wrapper.

For this week, I managed to complete the client side of the signalR which will receive the progress of the ongoing accept stock take process. This is done using channel to publish the current accept progress to the client. In order to do this, the server and the client has to be in a group to send and receive the information.

On the server side, the server only has to publish the progress to the proper group. The group name is decided using the guid that is created when the accept command is requested. On the client side, the client on has to join the group using the guid provided to receive the progress.

Lastly, the current problem that I have resolve is to change the background service from using concurrent queue to channel. But when trying to resolve this problem and discussing it with Mr.Peter. I’m require to resolve the problem of the custom web application factory running twice during the testing in order to properly debug the background service.

Begun by adding test cases for the new feature Status. Considered on the Entity Relation Diagram (ERD) for the Payment model of the system, sat with my supervisor to finalize the ERD of payment.

Next, I began with the coding aspect of the Payment model, defined entities Payment (which contains the details of that transaction) and PaymentType (having the various means of payment). Moreover, I defined their relation and researched upon many-to-many relation in Entity Framework as one order can have multiple payments and one payment can comprise multiple orders.

Lastly, I got a new task to create a History Query API and display History details on the UI for users to check on any general history. Completed the Query with successful testing and shifted my focus on the UI part. Went through some courses to understand Windows Presentation Foundation (WPF) which is a UI framework used at Tong Hin.