Author: nurlailiyuzi

Last week, I successfully updated the chart upon button click, but encountered a challenge when integrating the region manager code, which prevented the chart from reflecting updated values. After some troubleshooting, I discovered that changing the XAML property from Prism region manager to a local property allowed the chart to update its values appropriately. Upon further testing, I found that using the local approach, where I explicitly set the data context for data binding, provides more direct control and ensures changes are reflected when a command is triggered. However, I still intended to investigate why using ContentControl is not working; there might be something missing in the code.

Moving forward, I aimed to test the chart’s responsiveness and implement date-based data filtering for a more refined display of values. I encountered an issue with the method not working, despite using a simple ‘Linq’ approach and correctly retrieving the data. It turned out to be a simple mistake where my model and JSON date names were not identical. I made the necessary adjustments and the charts was able to work as expected.

The following day, I was assigned a small UI modification to enhance the user experience in my previous task. Towards the end of the week, I successfully modified the UI, ensuring the changes reflected in both the view and view model. As the new week began, my intention was to thoroughly test the UI to ensure no careless bugs would surface.

At the onset of the previous week, I was notified about a bug in the UI of a feature I had previously implemented. Upon investigation, I uncovered three bugs demanding my immediate attention. The initial issue surfaced in the backend, specifically in the pagination of the entity list, which displayed inaccurate pages when users applied filters due to a misconfigured logic. A minor adjustment rectified this, ensuring accurate pagination details.

The subsequent backend bug pertained to the logic governing an update feature for the same entity. While all previous tests, including the update logic, had passed successfully, I overlooked a condition where the update involved adding more than one new contact. Identifying the source of the bug, I invested time in refining the logic to incorporate this new condition without unnecessarily complicating the existing structure.

The final bug resided in the UI and required a slight modification of the code. Following resolution, I conducted a new test specifically targeting the previously overlooked condition, as advised by Mr. Peter. Subsequently, I returned to my ongoing task which is the report data module. My primary objective for the week was to enable the LiveChart-implemented chart to dynamically update its values and display the latest data. Although successful in updating the chart upon button click, integrating the region manager code posed a challenge, preventing the chart from reflecting updated values.

Addressing this issue will be my foremost priority in the upcoming week. Additionally, I aim to enhance the chart’s responsiveness and implement date-based data filtering for a more refined display of values.

Last week, I started out by concentrating on a specific segment of the report and exploring the functionality of LiveCharts packages for practical applications. To begin, I set up a blank solution and systematically established folders in adherence to the MVVM approach. After ensuring the smooth execution of the application in the initial stage, I proceeded to create views and view models, integrating a fundamental chart as per the LiveCharts documentation.

With the successful display of charts, I transitioned to the subsequent important step. I commenced by generating a JSON file encompassing essential data elements such as IDs, barcodes, and names. Integrating this data into the properties, I concurrently implemented the region manager to facilitate the presentation of multiple charts within a single view. Later, I noticed that keeping track of the changes I made over time became challenging as the application expanded. To address this issue, I decided to set up a Git repository for efficient revision management.

Following the integration of the region manager and Prism into the solution, I encountered a hurdle wherein the charts were not displaying. It took some time to identify the issue, which was eventually resolved by refining the way I passed the data into the LiveCharts element. After updating Mr. Peter on my progress, he recommended an additional step: ensuring that LiveCharts values respond to interactions. This will be my focus in the upcoming week.

Last week, I addressed a minor bug in the pagination functionality and incorporated an additional progress bar that was deemed necessary. Following that, I delved into researching the components to include in the data report and began outlining drafts to present to Mr. Peter.

Initially, I outlined four segments: the dashboard page, finance, customer, and comparison charts. The dashboard page serves as the main hub, featuring total sales, sales trends and etc. For the customer pages, I integrated charts and bar graph visualizations derived from customer data. For instance, a donut bar illustrating the percentage of high spenders, moderate buyers, and low buyers based on customer revenue. To outline these, I utilized Google Slides, focusing on conveying the general idea and content layout without delving into design intricacies.

Upon presenting the overall concept of the data report to Mr. Peter, he suggested trying out the first small section of the report and immediately experimenting with the LiveCharts packages I recommended to assess their practicality for real-world use. This is also the direction I will be pursuing in this upcoming week.

Earlier, I came across a bug related to progress bars experiencing lags whenever a user attempted to click the cancel button. As I’ve mentioned in the previous blog, I observed that GUIDs were overseeing the progress bar, causing it to increment each time a user initiated the cancel action. I suspected that the cancellation process might not be fully executed, and the accumulation of GUIDs during each cancellation could be the root cause of the lagging problem. Thankfully, Mr Peter helped and solved the GUID bug by eliminating the progress signal that triggered multiple GUIDs. As a result, the problem of the bug of the unresponsive cancel button of the progress bar was effectively resolved.

Subsequently, I made sure to clean up the code before making the final commit and push. The following day, Mr. Peter assigned me a new and interesting task. This was prompted by the software’s maturation, which allowed for the collection of extensive data with the aim of extracting more information and insights. Mr. Peter provided a general overview of the task, where the objective of this new task is to get the most value out of the data that had been made. He instructed me to conduct preliminary research.

I began my exploration on YouTube to gain a general understanding of report data and data analysis, aiming to discern the optimal outcomes. Next, I delved into researching the appropriate medium to use, debating between PowerBI and WPF. My initial inclination leans towards WPF, incorporating the widely-used LiveCharts package. This lightweight library is known for its ease of use and seamless integration into applications, particularly excelling in real-time data visualization scenarios where data is frequently updated. LiveCharts being open-source adds to its appeal, allowing for free and customizable use by developers. While PowerBI boasts a broader range of features for data visualization, business intelligence, and analytics, its learning curve may pose a challenge for new users. Further research is needed to make an informed decision.

Approaching the end of the week, a minor bug surfaced in the previously committed code. Pagination was malfunctioning, and additional progress bar implementations were deemed necessary.

During the past week, my primary goal was to address various bugs in the modified section of the application where the progress bar with SignalR had been recently implemented. As mentioned in my previous blog, a critical issue arose when attempting to save changes after the loading bar reached 100 of saving batch data, triggering an error message stating “batch too large.” After thorough debugging, it was identified that the problem originated from Cassandra. To resolve this, Mr. Peter showed me a temporary solution by directly overwriting the save changes in the database. The rationale behind this approach is the potential removal of Cassandra usage in the future.

The next bug involved the progress bar not advancing and continuously displaying “Queue (0/0)” after the user clicked ‘cancel’ during a previous process. This issue was rectified by making minor changes to the conditional statements. However, the most time-consuming bug to diagnose was an unresponsive UI on the cancel button during data generation. This occurred after the user initiated another process in the same section. Initially, a thread-related problem was suspected, but even after converting certain parts of the code to asynchronous, the issue persisted. 

Towards the end of the week, I inserted a line of code to monitor the changes in the progress bar and its GUID. It became evident that with each cancellation, multiple GUIDs were managing the progress in the subsequent progress bar. My initial hypothesis was that the cancellation process might not be completed and the multiplication of GUID during each cancellation could be the root cause of the lagging issue. Unfortunately, by the end of the week, I was unable to resolve this particular section of the code.

At the onset of last week, my initial assignment involved implementing a temporary item filter functionality within a specific entity section of the application. This entailed making minor adjustments to the view model and slightly modifying the context. Following the implementation, I rigorously tested the filtration process to ensure flawless functionality and accurate data transmission. Subsequently, I undertook another task to incorporate a progress dialog bar in a similar part of the application. Although this task required minimal modifications, I conducted thorough unit tests to identify and address any potential oversights. During testing, I discovered some test failures, which traced back to the omission of mock services necessary after the implementation of SignalR.

Upon Mr. Peter’s review of my work, it became apparent that I had misunderstood the assigned task. It turns out that I was instructed to create an additional button instead of implementing another filter. Upon completing the task, I dedicated time to cleaning up my code, ensuring the removal of any unused or redundant segments. I then proceeded to inspect the user interface of the newly added feature.

Towards the conclusion of the week, several bugs were identified that necessitated fixing and code modifications. One notable issue involved a progress bar loading data, but when it exceeded 100 generations, a message indicating a batch size too large would appear. This particular issue will be my primary focus for the beginning of this week.

Last week, I was required to solve a bug where the progress was not being displayed gradually but immediately showed completion. Initially, I suspected the issue might be in the implementation of the progress bar within the view model. However, after multiple debugging attempts, I shifted my focus to the server-side code.

Despite several debugging sessions, I found myself perplexed about which part of the code was responsible for updating the progress of the progress bar. Taking a deliberate approach, I meticulously studied the flow of the sample code and compared it to my own implementation. While I suspected a missing piece of code, pinpointing its location proved elusive.

Ultimately, I seeked guidance and consulted with Mr. Peter to clarify some aspects of the code that were unclear to me. It was brought to attention that a callback function, responsible for sending progress data to the client side, had not been implemented as of yet. This newfound understanding allowed me to comprehend how the callback could be effectively incorporated.

Following this insight, I made modifications to various sections of the code that involved implementing progress bars with SignalR. I ensured that the progress bar functioned seamlessly after the adjustments.

As mentioned last week, my task was to employ a progress bar that implements SignalR. However, this approach revealed a bug that necessitates some debugging. Initially, upon integrating the SignalR method into the feature, I observed that the progress bar was not functioning properly. This prompted me to embark on a debugging session to identify the source of the mistake.

It turned out that the issue arose from me directly using instances injected through the constructor. This led to problems with transactions, as these instances might be associated with a different scope or not properly disposed of when the loop iterated over different input or command. To address this, I created a new scope and obtained instances of the contexts from that scope. This ensures that each transaction operates within the correct scope, preventing interference between transactions and potential issues with the lifetimes of the database contexts.

Subsequently, I focused on the main objective of the week, which was identifying a bug in the progress bar when users repeatedly clicked on a button requiring the usage of the progress bar. Initially, I assumed that the bug might originate from the context. However, after conducting multiple tests, all aspects within the context successfully passed data without encountering any errors. The issue, as it turned out, originated from the client side, specifically during the attempt to initiate the SignalR connection after the initial connection had already been established.

In my initial attempt to resolve the bug, I proposed a solution and discussed it with Mr. Peter. He then refined the code to implement a cleaner approach. As the week concluded, one lingering issue still required debugging: the progress did not display its progress but instead showed completion right away. I plan to address this in the upcoming week.

Last week, I completed the UI design for the cleanup task and proceeded to test the UI flow to catch any potential bugs I might have missed. After ensuring that the basic interactions, such as using the search bar and checking data checkboxes, were smooth and functional before the actual data cleanup, I began to assess the cleanup logic. I meticulously examined the results to confirm if the cleanup process was working correctly.

During this process, I not only fixed the logic but also cleaned up the code. Given that this task was not new to me, I took extra care in placing the code precisely where it belonged. While validating the data’s accuracy, I identified a few instances where the logic did not fully align with the intended conditions. This prompted me to refine the logic and code, resulting in a more robust implementation. I encountered challenges when dealing with specific data. Achieving the correct data required a tricky approach, involving retrieving data from different repositories before obtaining the desired data.

Toward the end of the week, I presented my progress to Mr. Peter. One decision I made, which I had reservations about, was using a loading bar dialog instead of a progress bar dialog during the cleanup process. This choice was influenced by the complexity of sending a list of data to the backend, making it difficult to track and update the cleanup progress bar. However, Mr. Peter introduced me to an alternative method using SignalR to execute tasks and achieve the desired progress data. However, adopting this method also necessitated my efforts to identify bugs within its implementation, which is my main task for this upcoming week.