Step 2 - Create the actual App

1. Review use cases I want to cover

   • I as a user want to be asked what I am doing every 15min so that something else can keep track of what I've done all day --> Feature: MVP time tracker

   • I as a user want to be able to see how my time has been spent all day/week/month/year so that I can:--> Feature: MVP time tracker/Better data feedback

     • Make decisions on how to change my workflow

     • Learn to be more accurate with my estimates for effort

     • Provide data backed suggestions on what is taking up my time and how my time could be better used

   • I as a user want to be able to categorize all my entries so that I can see at a macro/high level what type of tasks my time is taken up --> Feature: Better data feedback

   • I as a user want to be able to start and stop the tracking manually so that I do not get notifications when I am not trying to track time --> Feature: MVP time tracker

   • I as a user want to be able to set auto-start schedules based on time/day of week so that the app can start even if I am distracted at the typical start of the day --> Feature: Auto Start

   • I as a user want to be able to set auto-start based on my location so that the tracking only starts when I get to work --> Feature: Auto start

2. Group use cases into features

   • Feature: MVP time tracker

     • Use cases

       • I as a user want to be asked what I am doing every 15min so that something else can keep track of what I've done all day

         • Work Breakdown

           1. Create a basic app with a default page that asks the user to enter what they are doing

              • Decide on UI and layout

           2. Add a notification that turns on if the task hasn't changed for the last 15min

       • I as a user want to be able to see how my time has been spent all day/week/month/year since I last reset the data so that I can:

         • Make decisions on how to change my workflow

         • Learn to be more accurate with my estimates for effort

         • Provide data backed suggestions on what is taking up my time and how my time could be better used

       • I as a user want to be able to start and stop the tracking manually so that I do not get notifications when I am not trying to track time

   • Feature: Better data feedback

     • Use Cases

       • I as a user want to be able to see how my time has been spent all day/week/month/year so that I can:

         • Make decisions on how to change my workflow

         • Learn to be more accurate with my estimates for effort

         • Provide data backed suggestions on what is taking up my time and how my time could be better used

   • Feature: Auto start

     • Use Cases

       • I as a user want to be able to set auto-start schedules based on time/day of week so that the app can start even if I am distracted at the typical start of the day

       • I as a user want to be able to set auto-start based on my location so that the tracking only starts when I get to work

3. Modify sample app to create 'basic' layout of the Time Tracking App

Things to come back to:

• https://flutter.dev/docs/resources/architectural-overview --> Let me try something, then read so that I can tie application to actual

Thoughts:

• While trying to think of better ways to restructure real-time programs with TwinCAT, I thought that I could abstract a module to have inputs and outputs. While trying to structure this in PLC code and linking with live values from IO, I realized that there were also many 'rising edge' and 'falling edge' triggers I would use. These are actually just events. I realized we have inputs, outputs, and events that the module detects (input events), and events that the module publishes (output events). In fact, when I first started to think of ways to refactor, I thought that perhaps there were just input events and output events for a module, the reason I went back to keeping live values from IO is because we need to monitor things like a 'heartbeat'.

While watching this: https://www.youtube.com/watch?v=vl_AaCgudcY&list=PLjxrf2q8roU2HdJQDjJzOeO6J3FoFLWr2&index=14, I thought this sounds very similar to what I am trying to achieve. Then it somehow came to me, perhaps the live values should be thought more of like storage than IO. There is much similar between the two.

• Physical IO are just electrical signals representing data, same with registers in memory/database/file system

• Inputs are like read-only memory, outputs are read-write memory

• Persistence is not a problem because we have persistent and non-persistent storage

• TwinCAT and most other PLC/controllers really just map the physical IO signals to memory anyways

• Events are changes to memory/storage in many cases, which still applies here

• The mapping of the physical IO to the memory location is handled by a separate TwinCAT IO task(service) based on the links we configure it for, similar to asynchronous calls to update a database for example

If we think of live IO similar to the way we think of storage, maybe there are design patterns we can borrow from typical programming in this way that we did not consider in PLC programming previously. This is an interesting thought process that I'll need to think through a bit further, but for this app its not useful, so lets get back to topic