Where I’m at

What’s on the cards for today - Back to App Development

Ok so we need to break down the schema for the stocktake in PostGres and then we can figure out how we’re going to create this thing.

Once the schema is done, I think we’ll have a good handle on how we’ll determine the look and all that.

What I learnt

Random wisdom - to add to key wisdom:

PROBLEM SOLVING: Creating this application is 80% problem solving and 20% code. Let’s go through how to problem solve. 

Let’s run through some of the key ideas:

• Identify the problem
• Research and refine the problem
• Write psuedocode to get your thoughts down
• Write tests with test data
• Write the code
• Reflect on the code / make it more readable

Let’s adapt that to the problem which is implementing the add stocktake functionality - expanding on each

1. Identify the problem

Let’s break this down into 3 sections - context, issue and why do I care?

Context: We need to implement the Add Stocktake functionality to the mobile app.

Issue: Need to understand what data I need to store, how I am going to store it, what validation logic I need, and how the user will input that data.

Why do I care? If we can streamline the input of quality data for stock, we would’ve cut down on a long and difficult task for managers and head office.

2. Research and Refine:

You’re likely not the first person to come across this problem. So use that person’s solution as a starting point.

So let’s break down the problems we have into smaller ones:

• What data should I store?
  • What is the data that we’re storing right now? Excel spreadsheet application
  • Can we mimic that Excel application and take those tables into Postgres? Yes
• How am I going to store it?
  • Clarification - I know we’ll use Postgres. This is asking more about relationships with other tables.
  • What are the tables to even begin with?
    • Once we know the “rough” tables we can understand what it’s doing in Excel. We know them.
    • Then we can map out some table relationships and if we need to import from other tables. Check the logic for what is being reused, and how does Postgres “understand” them?
• What validation logic do I need?
  • What are the most important aspects of this process? What do I want at the end? Quality data that is easily retrievable.
    • What are examples of where data has not been quality data? Or requires clean up efforts afterwards?
      • Mismatched or incorrectly formatted data / data types (Int vs str)
      • Missing data (null but not 0)
      • Duplicate entries (user forgetting they’ve already completed it and doing it again)
      • On the database end as well: Items not listed
      • Ambigious or unclear item name / descriptions
    • How could we make sure that the data is retrievable or correctly written to the database?
      • Error handling
      • Visual confirmation of success / failure of write to DB
      • Test runs of input
• How will the user input the data?
  • Who will input the data? Who does it now? Managers and supervisors
  • What is the method of data input? A form
  • How do we design the flow so the important aspects of the process are met?
    • Stocktake Dashboard has buttons at the bottom - user presses the Add Stocktake button
    • Two screens are placed on top of the Dashboard Screen - topmost screen is a helper screen.
    • When that has been completed and users “exit” they will then clear that and then see the next layer down being the actual stocktake form.
    • It will act sort of like an image carousel / book “format”. Basically the locations will match the “pages” of the carousel.
    • The form will enforce data type entry so should avoid entering strings where integers are supposed to, etc.
    • Default items will be displayed on each page that corresponds with the location, with options to delete items, add items, or revert to the default.
    • At the end of the “pages” there will be validation logic that will be done to ensure that no items are missing (null but not 0) and will display those items to enter those details in. The user can hit submit to mark them all as “0” if they do not enter their numbers in.
    • By going through the pages - this should prompt users to walk through their locations and not have duplicate entries (duplicates items in the different locations within their location is ok) of stocktakes.
    • Give the users a custom item that allows for manual input of name and description. This makes it easier for us to copy these items when submitted to add to the DB for later.
    • Have a report item feature that allows users to bring to our attention incorrect, unclear or ambigious item names / descriptions.
    • At the end of hitting submit there will be a popup screen that will go above the stocktake form screen. This will a confirmation screen that will initially display an message that data is being transmitted and then change to a success or failure mssage.
    • Failure will keep the stocktake state as is, until the user clears the error or discards the record.
    • A failure message shows the error message and then they can return to their current stocktake.
    • Successful write to the DB will close the hidden screen below the popup screen.
    • A success message then shows the user a message that it was successful. When they clear that screen, they will be back at the stocktake menu screen again.

3. Psuedocode

Write out in the editor the logic of the application - as much as possible in the target language. In this case - it’d be Dart:

addStocktake function

define API caller - caller to DB
define screens(helper screens, stocktake form screens, confirmation screen, success/failure screens)
define layersIndex (helper screens = 1, stocktake form screens = 4, confirmation screen = 3, success/failure = 2)

display startingScreens (helper screens, stocktake form screen)

for itemCount = null item add to unaccountedItems array
for itemCount > 30 add item to unusualCount array

when pageCount = 5 display submit button

on user press of submit button:

- check items for duplicate entries and sum up total
- if unusualCount + unaccountedItems == null then display success/failure screen and submit data via API
- if unusualCount + unaccountedItems =/= null then display confirmation screen with relevant items

on user press of submit button on confirmation screen:

- display success/failure screen
- submit data via API
- show failure message and return to stocktake form screen by clearing screen by user button press
- show success message, clear the stocktake form screen, and then allow the user to clear the screen by button

Stocktake Form:

stocktakeFormScreen function

define stocktakeForm(locations(5), defaultItems, tableRows)
define stocktakeFormPages(locations = page number)

Also! Research! Check how the API works, and test it using Postman. Research how others completed it beforehand to see what is done.

4. Writing tests

There is a simple flow to testing:

• Write a test for what you want to happen
• Write code that makes it pass
• Optimise it

For example in the addStocktake function:

test('to ensure that item count does not have invalid data types')

define itemCountTest = simulatedCount(mockData)

expect itemCountTest = true

define incorrectCountTest =/= simulatedCount(mockData)

expect incorrectCountTest = true

5. Implement

Do it as quickly as possible. Just get it working.

No - really, just try to get it done as quickly as possible.

6. Reflect

Get a good nights sleep. Take a 15 minute break. Drink some water. Do some exercise.

But do this to make your code better:

• Improve the readability
• Add comments
• Remove duplication
• Optimise time/space complexity (e.g. add caching to reduce cloud computing costs)
• Add errror handling

It’s always easier to refactor a complete piece of code - then to write a perfect piece of code.

Random things I need to write down:

• Couple idea for a mobile game? It works using the moving object technique of communication, that is enforced by the application. Anyway it’s a random idea.