This is the next blog in my series of blogs on how quick it is to develop software using Low-code, as well as to show the progress being made for the Train44ir platform I am building. The last few days have slipped by really quickly again. Time flies when you are having fun. Again when I look back there has been quite a lot of new learning (read slowness) and progress (read speed). It never quite feels like it when you progress hour by hour. But Day by day using Low-code software development is really quite quick and adds up quickly. So far I have been at it from the 1st April working about 5 to 6 days a week, on average about 7 to 8 hours a day. What you see below is what was done since my last blog on 3 working days ago. i.e. Below is three days work.
Refined the Course state machines
Once I’d built the screen that let Students select courses from a larger menu of course selections, I realised I’d need a lot more structure around the state transition of each of the boolean variables that define the Course entity. From is the Course active for this learning Track? Is the Course active in this Level of the Track? Then on the Course entity itself, it goes through a process of being Inactive, then is Selected and is Active (but could be cancelled again), then is Studied, then Completed, then the learner obtains a Certificate or not, plus all the variations on that which could happen. I considered doing a formal proper diagram model of this state machine, but decided to just use my hand written scrawl instead for speed.
Last Touch Dates & Timeline
Another thing I realised as I was working was that in order to see when something happened, I had to add a bunch of LastTouched Date & Times, to each of the various database tables. I then had to revisit all the screens where these were updated. This on both the Mobile App as well as the Web App. Your standard audit type information, who and when in each context. Below is an example of one of the Mobile screens, showing one example of the last touched date time.
I also wanted to make use of the Timeline Screen Object that works along with the Boolean items mention above. e.g. Has_Completed, Is_Active, Has-Certificate, etc. This same screen below shows the example of implementing that timeline into the screen opened by the Study a Course menu option. So if the student clicks on one of the Course Titles (which is a URL) it will open in the browser for them to be able to study that course.
Levels, many of them, solved
The next thing was to try and consolidate a lot of information onto one easy screen for simple and quick selection. The reason being is that for each Track a student studies, there are 15 Levels and each Level has 5 Courses = 75 Courses per Track. One would not want to scroll through 73 Courses to get to the second last one. So the solution to that challenge was to use the Accordion Object, which allows for only one item to be open at once and closes any other one that is already open. I made one Accordion item one Level, which contracted it all onto one screen (more or less – ok 1.5 screens) – see below.
I then added my timeline object into each level Object and changed the selection criteria to select only the level that was open and it all worked first time.
Course Provider APIs
Most of the fun was had in this piece of work. I’d been wanting to experiment with how easy it was to build an API consumer from within the Platform to access information from one of the course provider companies we will be using in future. I started with Udemy.com who gave me permissions to access their Affiliate API 2.0. The goal was to programmatically access a list of all courses they offer and store them locally in our Platform database, in order to evaluate them for which ones to put into which Tracks and understand costs, durations of courses, etc.
Somehow I thought this may be a little finicky but to be honest, it was a breeze. Of course I got tripped up by making a few assumptions, without actually looking at the actual JSON being returned from the GET query and it failed. I assumed that all image information would come to me as a Binary but when I looked closer I saw they simply pass the image as a URL string to the actual JPG. Even easier! So the screen below is the result of my set of records I pulled into the database.
I then made a Query Screen so that I could pull certain information out based on what I was looking for at any given time. This started small and as it went I added more and more selection criteria based upon the API specification I was offered. This is how it ended up looking. The idea being that I just go to this screen, put in my selection criteria in and click on “Query Udemy API” button to fetch the records. I also used their unique identifier my unique identifier (as opposed to the default auto increment identifier) to make it such that no matter how many times I query and get the same record, it simply creates or updates/overwrites it with the latest version to avoid any duplication. This will also allow us to keep information to date later.
To be fair, the JSON coming back from the query is not a simple flat record structure, it consists of records within records with a varied number of sub-records per higher level record. So I had to parse this to populate two separate tables I was interesting in. So not exactly non-trivial.
Well APIs are easy to consume and implement which to me is great news and bodes well for future software development. This may not always be the case in all API implementations but certainly the one from Udemy.com was easy and well written enough to just work, pretty much first time. I added my own incremental enhancements on the consuming end as I got braver. Also in the mean-time the whole Platform is taking shape and getting ready to roll in the near future.