I think it was when having my morning coffee and loitering the internets, I saw somewhere this discussion:
“Here something that woud be really useful for PG development going forward: A count of the occurrence of unicode code points used in PG texts.”
PG refers to Project Gutenberg, where they publish out-of-copyright books for anyone to read for free, in various languages and formats. Highly recommended, btw, if you didn’t know about them before!
Since I’ve done something like this before, just with words, not Unicode code points, I thought I’d give this a try. Especially when using several books from Project Gutenberg as test material in my Data Structures and Algorithms course. Gotta give back, as you know.
I only know just the basics of Unicode, like: it’s hard and complex, full of rabbit holes to fall into if you are ignorant or assume too much. On the other hand, Swift should be one of the best languages to handle Unicode correctly with the String and Character class.
The tool I made (ducking other responsibilities, again!) is available in GitHub. I commented about the tool in the PG issue discussion, as well as my noobness in correct Unicode processing. Hopefully this and/or the other implementations/data offered to them is usable for the purpose. If you know Unicode better than me, please tell me if there’s something to improve in the tool.
A useful site found while doing this is Unicode Explorer. Worth a bookmark.
As what comes to PG folks’ discussion on “…A recent issue #271 notes that the 2em dash is often used but missing in many typefaces.” — my implementation found that the 2em dash (“⸺”, Unicode symbol with codepoint U+2E3A) occurs in the provided book dataset 8 414 times.
Going to mark the hours of this little job in the category of “contributing to the culture & society” in my university work plan 🙌🏼✌🏼(the hands are codepoints U+1F64C U+1F3FC and U+270C U+1F3FC, the symbol itself plus the Fitzpatrick skin type / color…).
To end this post, here’s some technical details on the implementation. Processing the books is done using a Swift task group, concurrently (some details removed from the actual code):
try await withThrowingTaskGroup(of: [Character: Int].self) { group in
if let enumerator = fileManager.enumerator(atPath: books) {
while let file = enumerator.nextObject() as? String {
if file.hasSuffix(".txt") {
fileCount += 1
// Add a task to task group to handle one file
group.addTask { () -> [Character: Int] in
var taskCodePoints: [Character: Int] = [:]
let fullPath = booksDirectory + file
let fileContents = try String(contentsOf: URL(fileURLWithPath: fullPath), encoding: .utf8)
// ...taskCodePoints contains the result of one file
return taskCodePoints
}
}
}
// Combine the results from various concurrent tasks totaling the result
// from all files:
for try await partial in group {
for (key, value) in partial {
codePointsUsage[key, default: 0] += value
}
}
}
The data structure [Character: Int] is a Swift dictionary of key-value pairs. Key (Character) is the unique characters read from the files, and value (Int) is the occurrence count of each character — how many times it was occurring in the books.
Each subtask collects a count of character occurrences from one book, and then those are merged together in the for try await partial in group structure, as the subtasks finish.
Watching from the Mac Activity Monitor, I saw that the app used to have nine threads, processing the books in parallel on my Uni work laptop (MacBook Pro M2). For some reason, my own older MacBook Mini M1 was usually much faster in processing than the M2 MacBook.
Apparently I like coding with the Course Deadline Counter app, now renamed to Course Deadlines app. I really, really should stop doing this, and focus on something else more acute and important — that’s why the call for help. I need to be stopped!
[I am aware of this being my own responsibility, thank you so much, so plz do not send halp.]
As a new feature, the app now has a timeline View:
Where you can view the deadlines of courses currently ongoing. The view does not show courses that haven’t yet begun or courses where the last deadline already passed.
For a student user, viewing all ongoing courses is more important, to be able to view the deadlines of the courses she is currently taking and how they relate between all the work she needs to do.
For a teacher, it is more relevant to show the deadlines to students in a single course. So limiting the view to just that one course is more important, using the drop down list at the top of the view.
Considering the needs and usage patterns of different groups of users is taught in our GUI design and programming course (Programming 4). So obviously I have to be able to do this stuff myself. Consider that done, at least in this case.
For drawing the course and course deadlines, I used the SwiftUI Canvas and for the gradient background, MeshGradient. I should still test the colors with both light and dark modes and find a usable combination of colors and an overlay to mute the colors when and if they are in disagreement with the text.
Drawing on the canvas is just simple drawing operations using the GraphicsContext, plotting the text and symbols on calculated coordinates. For example, if there are no ongoing courses, the code draws only the text “No courses to show”, in the middle of the view:
Canvas { context, size in
var origin = CGPoint(x: 0, y: 0)
let text = Text("No courses to show").font(.title).bold()
let resolved = context.resolve(text)
if coursesToPlot.isEmpty {
// Draw info that there is no ongoing courses to show
var textSize = size
textSize = resolved.measure(in: size)
origin.x = size.width / 2 - textSize.width / 2
origin.y = size.height / 2 - textSize.height / 2
let rect = CGRect(origin: origin, size: textSize)
context.draw(resolved, in: rect)
} else {
// ...
With the Picker, choosing to show all courses or just one, I searched for different solutions from the internet, and chose this one:
So there is the “show all” option where the course selection is then set to nil. Otherwise, the selection is the selected course. This enables “no selection” or as it is handled in this case, “all are selected”.
I think I got to use the Swift if expression (different from the usual if conditional statement) here the first time, handling the above picker selection:
let coursesToPlot = if let selectedCourse {
[selectedCourse]
} else {
deadlines.ongoing.sorted(by: { $0.startDate < $1.startDate } )
}
In plain English: if the selectedCourse is not null, let the coursesToPlot be an array containing only the selectedCourse. Otherwise, get all the ongoing courses from the deadlines, sorted by starting date ascending, and let the coursesToPlot be those courses.
The next time I touch this app should really be in the end of August or beginning of September, when I decide on the deadlines of the courses I am responsible for.
In the other news, I was today awarded as the Distinguished Teacher of the Year (again) by the study program student guild Blanko. Thank you! I am so humbled to receive this appreciation for the work we are doing here.
Three days ago I wrote about the Course deadlines app:
I list some future improvement ideas in the GitHub readme, but don’t actually know if I am going to implement those. The app already fulfills the intended purpose, so anything else would be just something fun to implement, if I have the time or motivation to do them.
And now, after three days, I’ve implemented:
alerts; the app now alerts about the incoming deadline when it becomes “hot” using UserNotifications framework,
pick a symbol; the app now has preselected SF Symbols to choose from when adding or editing a deadline,
icon; app now has an icon,
app checks that the course name and deadline goal are not empty,
app checks that the course name is unique when creating a new course, and
several GUI enhancements and bug fixes.
As if it looks like I am using the app to avoid some other (not so fun) responsibilities and instead spend time on this hobby project… Though this is related to teaching work, really!! Valid work done here!!
One of the important bug fixes was related to setting the date and time for a deadline. I use the SwiftUI DatePicker for this, specifying that I want to select both date and time, using displayedComponents: [.date, .hourAndMinute] for the picker.
I was falsely assuming that the Date object would then contain the exact date/time selected by the user. Like if the user selects, using the picker, 2025-05-15 12.00, the date object then would have that exact time. Well, it does contain that date and that time, but since the user is not selecting seconds, the date object may then contain something in the seconds, like 2025-05-15 12.00.46, for example. Not good, since now the communicated deadline is actually later than the intended deadline.
I noticed this issue when I was testing the alerts feature and saw that the actual date and time shown in the alert was not the one specified in the deadline, by the seconds.
What I needed to do was to take the user selected Date object, then set the seconds part of the date to zero and then use that modified datetime as the actual deadline date:
extension Date {
func secondsRoundedToZero() -> Date {
var components = Calendar.current.dateComponents([.year, .month, .day, .hour, .minute], from: self)
components.second = 0
return Calendar.current.date(from: components)!
}
}
Oooh, those pesky dates and times can really be hard sometimes…
There was another interesting issue with SwiftUI and the deadline formatting. The app shows a hot deadline colored red, as in the example in this image:
A deadline coming after one day and five hours.
And when the deadline has passed, it should be grayed out, like this:
A deadline gone nine days and 17 hours ago.
This worked, when you open the app and view the deadlines just loaded from files. But if you open the app and actually watch a deadline date/time coming and passing, the formatting did not change. WTF?!
As you can see, the time is shown as relative to current time. That worked fine, but as the deadline came and passed, the relative time changed to past but coloring did not.
That was because SwiftUI updates the view when the @Observable object (Deadline in this case) changes. But the deadline object actually did not change at all. No member variables changed values when the deadline date/time comes and goes. The deadline’s date and time was still the same, of course.
The way the time is shown as relative time by SwiftUI Text element, gave me an illusion that something keeps changing. Since the view shows a countdown including seconds (when the deadline is very near) when .relative style is used:
Text(deadline.date, style: .relative)
From the SwiftUI viewpoint, nothing changed so view update was not needed, thus the formatting did not change.
I solved this by adding a property viewUpdateNeeded to the Deadline. That property was then updated in the isReached computed property…:
@Observable
class Deadline: Codable {
// ...
var viewUpdateNeeded: Bool = false
//...
var isReached: Bool {
viewUpdateNeeded = date <= Date.now
return viewUpdateNeeded
}
…used by the list item row view:
HStack {
if deadline.isReached {
// Show deadline as passed
Text("Deadline passed")
.padding(.trailing, 0)
// ...
} else {
// Show deadline as forthcoming
Text(deadline.date, style: .relative)
.padding(.trailing, 0)
Text("until deadline")
.padding(.leading, 0)
// ...
}
.foregroundStyle(deadlineColor)
Where the last line, .foregroundStyle(deadlineColor determines the color used (where the deadlineColor is a property in the deadline row view):
var deadlineColor: Color {
if deadline.isReached {
return .gray
} else if deadline.isHot {
return .red
} else if deadline.isDealBreaker {
return .orange
} else {
return .accentColor
}
}
OK, so the initial value of Deadline‘s viewUpdateNeeded is false. When the view accesses the isReached property to decide the formatting, and the deadline is still in the future, the value of viewUpdateNeeded is set.
As the value was originally false, and the new value is still false (since deadline date is not less than current date; in the past), so from the viewpoint of SwiftUI, nothing changed and view does not need updating.
When the deadline finally comes and goes, the value of viewUpdateNeeded now changes from false to true (deadline date is smaller than or equal to current datetime) and then SwiftUI sees a change in the state of the deadline object, and now the view is updated and the also formatting changes.
Of course I knew this already. Maybe I just got confused seeing the UI changing and thought, when looking at the deadline closing: “nice, things change and view is updated” and then was astonished why the formatting did not change. After a while, looking and thinking, I realized what I already knew and then added that member variable to handle the issue.
Often we stumble with the basics, and that is OK. I remember reading from somewhere that experienced programmers actually do more mistakes than novices since they typically work faster. The difference is that with experience, you are able to spot your mistakes much earlier and are usually able to solve the issues much faster. So go gather some more experience!
In the post last week I mentioned that I’ve added new features to the tool I use in Data Structures and Algorithms course to supervise, support, test and grade the student programming course work. I’ll describe here the new features and provide some (hopefully) interesting implementation details about those.
Background about the course that helps in understand the role of this tool:
students each have their own github or gitlab repository to where they fork the initial status of their course work from the teacher repository,
repository contains the task instructions, skeleton code to implement, unit tests code and other supporting code given ready for students,
repository tests enable testing the student’s implementation of the data structures and algorithms that are required to implement in the course,
teachers have access to the student repositories to assist students with any issues, and finally to grade the work.
Before going into details, a comment about the motivation for this tool to exist in the first place: The course the tool is used in, has 300+ enrolled students and only two full time teachers (sometimes we do have 1-2 assistants with small number of hours, like 50 hrs in total for the whole Autumn), simultaneously teaching 2-3 other 200-300 student courses. That totals around 900+ active students taught simultaneously, so providing individual support and attention to all is practically impossible, at least if no automation (and other support tools) is taken into use.
So the critical thing in managing all this work is, that we do need automated tools to:
keep track of how the students are progressing in the course and help those who desperately need it, and after the last deadline,
to evaluate and grade the students’ programming submissions as fast as possible.
The grading should be done in three weeks after the last deadline, so it cannot be done in time manually. The aim is to use this tool during the course, trying to catch those students that are not doing OK, and then try to contact and help them in getting their coursework going and spotting any possible mistakes in their work so that they can correct their mistakes before the final deadline.
Students next Fall will receive the same unit tests and the same code analysis tools (in Java unit tests) they can also themselves use. However, this is not enough, especially if the students do not contact the teachers about their issues soon enough or at all. A problem that is too common, unfortunately.
The new features added to the teachers’ tool during this Winter and Spring are:
Automatic source code analysis:
results of the source code analysis are stored in a database table; repository table has a column where problems found in code are flagged,
tool checks for java imports that are not allowed, notifies about this and sets error flag in the database table,
tool also uses the Antrl parser generator to check if method implementations in the source code violate any rules and if the code does not do the things it should do.
Remote repo checks for both github and gitlab:
checks that remote is not public, the rule of the course,
checks that remote has only allowed contributors.
Testing and grading enhancements
tests are now grouped to grade level tests,
when all tests in a grade group passes, grade is stored to repository table,
grade tests can be executed in whichever order, since grade value is bit flag,
test for a certain student repository can be disabled if they cause issues like tests never ending or taking way too much time,
if git pull updates code, grade is set to zero and test results are cleared.
Status reporting
the tool now generates a textual status report that can be sent to student by email, listing how test pass, if any forbidden things are used / things to use are not used, git statistics etc.
Let’s take a closer look at the code analysis done by the tool in this post. The other features are left for future possible posts to discuss.
Analyzing if the source code uses “forbidden” imports was implemented with simple text parsing techniques. The tool goes through the Java source files in a certain directory where student code is located, reads the .java files and checks if the source uses imports that are not allowed.
For example, when implementing a Stack data structure, student must not import the java.util.Stack and just use it instead of implementing their own stack from scratch, using an array as internal data structure. Or when sorting an array, java.util.Arrays is not imported and Arrays.sort is not used, because student should have used their own implementation of the sorting algorithms.
These kinds of mistakes can be found by analyzing the imports in the student’s .java files. You cannot call Arrays.sort without having import java.util.Arrays in the .java file.
The tool first reads a rules file that contains the import rules for the course:
For example, the java.util.Comparator may be used by the students in all of their .java files (*). The same goes with java.util.function.Predicate and all the files in package oy.interact.tira (the course source packages). The class SetImplementation may also import java.util.Iterator.
Et cetera. As you can see, this is an allow list, not a deny list. The imports that are allowed and can be used in the course are small in number, so it is easier to have an allow list than deny list.
Reading the allow list and analyzing the source files was straightforward to implement by simple file handling and text parsing. First read in the rules file and parse the import rules from there, into this structure:
fileprivate
struct SourceRequirementsSpecification {
var allowedImports: [String: [String]] = [:]
The Swift dictionary object allowedImports has the class as the key (either * or the name of the class rule is about), and then the array of allowed imports the class may contain.
Then the tool starts reading the student .java files and handles all lines beginning with import to check if that class may import that specific thing or not. If the .java file imports something that was not allowed, the tool database table (for the student’s repository) having a column with integer value, a specific bit in that number (a “flag”) is set to 1 (true). This indicates that the student’s code imported something it was supposed to not do.
This is the data structure keeping track of these repository flags, if they are set or not set:
struct Flags: OptionSet {
typealias RawValue = Int16
var rawValue: Int16
static let remoteFails = Flags(rawValue: 1 << 0)
static let buildFails = Flags(rawValue: 1 << 1)
static let usesForbiddenFeatures = Flags(rawValue: 1 << 2)
static let repositoryIsPublic = Flags(rawValue: 1 << 3)
static let repositoryHasOutsideCollaborators = Flags(rawValue: 1 << 4)
static let repositoryTestingIsOnHold = Flags(rawValue: 1 << 5)
}
The Swift OptionSet is a type that presents a mathematical set interface to a bit set. So each flag is a single bit in the 16 bit integer, being either off (0) or on (1). So instead of having six boolean columns in the database table, I can have one 16 bit integer column to store 16 different flags. Most of those still available for future needs.
The flag usesForbiddenFeatures is set in this case of student code using forbidden imports (or other features, discussed below). Other flags are used to:
track if the remote repository cannot be accessed at all (remoteFails) or is empty,
compiling the code fails (buildFails),
repository is public even though it must be private (repositoryIsPublic) and finally
if the repository has other collaborators than the student owning the repo and the course teachers (repositoryHasOutsideCollaborators).
These are all issues that have been met in the course during the previous years.
Final flag repositoryTestingIsOnHold can be set manually from the tool user interface for those repositories that mess up the testing, either because the tests are stuck or take too much time and therefore should not be executed before fixed.
That flag struct is a 16 bit integer, the datatype of the database column storing the flags in each student repository database table. If the code has issues related to these rules, the flag is set. When the git repository is updated from the remote, the user needs to run the code analysis again. If a violation of a rule was fixed, the flag is then reset to zero (false), if no other violations are found.
The imports checking from source code is not enough, though.
Sometimes students do mistakes in method implementations they are not supposed to do. Like when implementing a recursive binary search, they implement an iterative binary search. Or when sorting a table in descending order, they first sort in ascending order and then reverse the table order. Since time efficiency is the major topic of the course, this is not what they are supposed to do. Instead, they should use a comparator to sort the table to descending order in the first place, and then no reverse operation is needed at all, making the operation faster.
For checking these kinds of issues the import rules are not enough since these kind of mistakes can be made without importing something. Therefore, the same rules file contains also rules like this:
[codeRules]
# Algorithms.binarySearchRecursive must contain word binarySearchRecursive
Algorithms.binarySearchRecursive,must,binarySearchRecursive
# Algorithms.binarySearchRecursive must not contain word while
Algorithms.binarySearchRecursive,mustnot,while
Algorithms.binarySearchIterative,must,while
CodeWordsCounter.topCodeWords,must,Algorithms.fastSort
CodeWordsCounter.topCodeWords,mustnot,Algorithms.reverse
Here lines beginning with # are comments and ignored by the tool. Illustrating the examples of mistakes above, the rule:
Algorithms.binarySearchRecursive,mustnot,while
specifies that the algorithm binarySearchRecursive in class Algorithmsmust not contain the keyword while. Since breaking this rule implies that the student has implemented the recursive algorithm using iterative approach. Therefore, the learning goal of implementing a recursive binary search has not been met, and code needs to be fixed.
These rules are also parsed from the rules file into the above mentioned rules structure, which now looks like this:
enum Rule {
case must
case mustNot
}
struct CodeRule {
let methodName: String
let rule: Rule
let stringToMatch: String
}
fileprivate
struct SourceRequirementsSpecification {
var allowedImports: [String: [String]] = [:]
var rules: [String: [CodeRule]] = [:] // ClassName : CodeRules
}
In addition to the allowedImports rules, the structure now contains also rules for a class (the Swift dictionary key String has the class name), where the CodeRule structure has the name of the method the rule is about, then if the method must or must not (Rule) contain the string to match.
This is a very simple current implementation, and as I develop this further, it may change to something different later. For example, it should be possible to say that the recursive binary search algorithm must not contain “while” but also not the “for” keyword.
The second example about being able to realize that descending order can be implemented by a specific comparator (instead of ascending sort and then doing reverse, which is more time-consuming operation) is checked by the rule that the class CodeWordsCounter in the algorithm topCodeWords (where the work in the coding task is done) must not call Algorithms.reverse.
If a student uses the Java Collections.reverse or Apache Commons ArrayUtils.reverse for this, that mistake is already caught using the import rules.
For this feature implementation, I used the Antrl parser generator. Antlr has existing grammars for many languages, including Java, and it supports generating parsers also for Swift. So all I needed to do was to get the Antlr tool and the Java grammar files (Java20Lexer.g4 and Java20Parser.g4) and then generate the Java parser and lexer for Swift:
$ antlr -Dlanguage=Swift -message-format gnu -o Autogen Java20Lexer.g4
$ antlr -Dlanguage=Swift -message-format gnu -o Autogen Java20Parser.g4
Those commands place the generated Swift source code files in a subdirectory named Autogen.
Using the generated Swift code from Autogen, the tool can then parse Java code. All I needed was to implement a class that extends the Antlr generated Java20ParserBaseListener, give the rules to this class and start parsing the source string read from the student’s java file, containing the Java source code:
import Antlr4
class Java20MethodBodyChecker: Java20ParserBaseListener {
private let file: String
private let rules: [CodeRule]
private var currentMethod: String = ""
private var stream: ANTLRInputStream? = nil
var violations: [String] = []
func start(source: String) throws {
stream = ANTLRInputStream(source)
if let stream {
let lexer = Java20Lexer(stream)
let parser = try Java20Parser(CommonTokenStream(lexer))
let parserTree = try parser.compilationUnit()
let walker = ParseTreeWalker()
try walker.walk(self, parserTree)
}
}
// ...
Analysing the code happens in the overridden handler for parsing Java methods, enterMethodDeclaration. There, the implementation checks, using the rules, if the Java code contains any keywords that should not be there or does not contain keywords that should be here:
override func enterMethodDeclaration(_ ctx: Java20Parser.MethodDeclarationContext) {
if let identifier = ctx.methodHeader()?.methodDeclarator()?.identifier() {
currentMethod = identifier.getText()
let ruleSet = rules.filter( { $0.methodName == currentMethod } )
if !ruleSet.isEmpty {
if let body = ctx.methodBody() {
let bodyText = body.getText()
for rule in ruleSet {
switch rule.rule {
case .must:
if !bodyText.contains(rule.stringToMatch) {
violations.append("\(file).\(rule.methodName) ei käytä \(rule.stringToMatch), vaikka pitäisi")
}
case .mustNot:
if bodyText.contains(rule.stringToMatch) {
violations.append("\(file).\(rule.methodName) käyttää \(rule.stringToMatch), vaikka ei pitäisi")
}
}
}
}
}
}
}
The violations then contains all the things found to be against the rules.
This worked, except for one thing: if the code has comments that do/do not have the specified keywords of the rules, the code analysis did check those comments also. Even though the comments do not influence the implementation and are therefore totally irrelevant.
So if the comments of recursive binary search algorithm contains the keyword while, the tool would report that as a violation of the rule! Or if the code contains a required keyword, but not in the actual code implementation but only in the comments, the analysis would be satisfied. End result: not satisfactory at all.
First I started to fix this by implementing code myself to remove the comments from the code in a String variable before the analysis, but soon I realized that the Antlr parsing tool should somehow already handle this.
What I did instead, was (after some searching on the internet) to modify the Antrl lexer file for Java so that it does not parse the comments at all, but skips them:
Then I regenerated the Swift parser and lexer source files and added them to the tool project.
Using the new lexer/parsers, the parsed Java code does not anymore include comments and I do not have to consider them at all! This works perfectly.
Without asking anything about any “AI” tools out there. As usual, I do not touch them even with a long stick. I prefer to discover and learn myself, as long as the internet is not polluted with “AI” generated crap which makes everything impossible.
Below you can see the tool reporting about imports in a student repository, imports that should not be in the code, and that the code in CodeWordsCounter.topCodeWords does not call Algorithms.fastSort, even though it should, based on the rules in the rules file.
As you can see, the first violation is because the student has misnamed the class as setImplementation. In Java, classes (and therefore also class files) should always begin with capital letters and the name should be SetImplementation instead. So this is a mistake, but actually does not violate the import rule; the Set data structure implementation may use the Iterator. Therefore, when the rules are found to be violated, it often requires human rechecking to make sure no unfair judgments are made by the automation.
Considering the 300 something students in the course, perhaps each of them making at least 3-5 mistakes the code analysis could find, this results in 900-1500 mistakes in total. For the teacher to comb through all the hundreds of lines of code in each of the student projects, repeatedly during the course, working on this “code quality control” task manually is very time consuming and therefore not a realistic task. Especially considering the available teaching resources mentioned in the beginning.
Hopefully the new features of this tool and the similar tests given to students in Java test code, improve the support the teachers can provide during the course to lead the students to the correct path of implementing the required data structures and algorithms.
The post is getting quite long, so the rest of the new features will perhaps be discussed in future posts. Unless I decide to focus on other more interesting topics. Have a nice day!
Courses have deadlines. Oftentimes it happens that the deadline comes and the student work is not ready. Even though the deadlines are clearly communicated, often in several places in course materials and website. There may be many reasons for missing a deadline, but whatever the reason, missing one usually leads in to problems in passing the course.
Missing a deadline also causes extra work. Questions are asked, replies sent, and if there is a really good or valid reason, there may be an exception to the rule and extension to the deadline is granted. But if this happens often, in a course of hundreds of students, all this is extra work burdening and stressing both the teachers and the students.
If everybody gets an extension to the deadline, time after time, the concept of deadline becomes irrelevant. If one student gets an extension to the deadline, all others with the same reasons should also get it, since students must be treated equally. Therefore, it would be really, really nice if everybody would acknowledge the deadlines and schedule their work so that no deadlines are missed. A useful habit or skill to have also later in working life…
To make sure a deadlines are not missed since “I forgot it” or “It came sooner than I expected”, I started to remind students of one course about the forthcoming deadlines on my weekly Monday lecture. Since apps are cool, and I like to tinker with things, I wrote an app for this. Obviously, I could have just shown the list of deadlines from the course materials, slideshow or website, but that is boring. Also the app is yet another example of how to implement things, a demo that I can use in various programming courses and a topic for a blog post 🤓
Course deadlines app with a list of courses on the left. For the selected course, list of deadlines on the right. For more screenshots, click the GitHub link in the text and view them from the readme documentation.
The app is localized to English and Finnish, above you can see the Finnish localization screenshot, in GitHub readme, you can see the English locale version screenshots.
Each deadline has graphics and formatting to convey something about the deadline:
A symbol (trying) to convey the type of the deadline, an exam (notepad) or a programming task (hammer).
Deadlines that are “strict” (dealbreakers; will lead to failing the course if missed, others may be more flexible) are shown with an orange warning sign.
Deadlines already passed are shown in gray, and
deadlines coming soon (are “hot”) are highlighted in red.
See the GitHub readme document for examples of these. The app is actually better than a static list of text in web or slideshow in that it will dynamically format the deadlines, as listed above and shown in the GitHub readme.
The deadlines are stored, for each course, in a separate JSON file in the Documents/CourseDeadlines directory on the user’s Mac:
func store() throws {
let storagePath = URL.documentsDirectory.appending(component: Deadlines.appDocumentDirectory, directoryHint: .isDirectory)
deadlines.sort()
let fileManager = FileManager.default
let encoder = JSONEncoder()
encoder.outputFormatting = [.prettyPrinted, .sortedKeys]
let data = try encoder.encode(self)
let filePath = storagePath.appending(path: name + ".json").path(percentEncoded: false)
print("Storing file \(filePath)")
if !fileManager.createFile(atPath: filePath, contents: data) {
throw DeadlineErrors.fileSaveError
}
}
The design decision here was to make it easy to share the course deadlines — just send the JSON file to anyone with this app. Or another app anyone perhaps chooses to implement that is able to read the JSON file.
With the app, user can add end edit new courses, add and edit deadlines, and also delete deadlines and courses. Although the app was originally developed for a teacher (me), it could obviously be used also by students to manage the deadlines for the courses she takes.
I did present the deadlines with one course, weekly, using this app last Fall in the live lectures. I also sent a weekly newsletter in the course Moodle space and included a screenshot of the current deadline situation in the message.
I didn’t gather any data on the impact of the app. Did students actually miss the deadlines like in any other course? Cannot say. My main motivation was to make sure no one misses the deadlines because of not being aware of them. Hopefully the awareness of deadlines was improved, and there wasn’t (too much) annoyance in being repeatedly reminded of them, time and time again 😂
There are some Apple/Mac specific things in the JSON, an example of a course with four deadlines:
The deadline date is not milliseconds from 1970 as integer (perhaps more common), but as double. The symbol for the deadline is a name for Apple SF Symbol. If implementing an app for other platforms to show the same JSON data, the developer needs to figure out a way to show something as the symbol (or ignore it). Maybe a custom drawn image or something.
I list some future improvement ideas in the GitHub readme, but don’t actually know if I am going to implement those. The app already fulfills the intended purpose, so anything else would be just something fun to implement, if I have the time or motivation to do them. One thing not listed in the readme is to provide the app also for iPhone/iPad, but since the original idea as a teacher tool used in lectures, did this only as a Mac app.
If you have any use for an app like that, or just want to use it for learning Swift/SwiftUI, the app is open sourced so just take it and use it.
Many (most?) apps need some kind of settings the user can modify, that influence on the behavior of the app across app launches. In this post, I’ll show how to implement this with java.util.Properties class in a Java / Swing game.
As an example, I will use the Snakeses game from the previous post. In this game, user can change the difficulty, game mode and light/dark mode of the UI:
The selections will be saved to and read from a file named snakeses.ini:
#Snakeses Settings
#Tue May 06 19:28:32 EEST 2025
difficulty=hard
mode=dark
playername=Antti
style=classic
The settings file contains key-value pairs (e.g. on line difficulty=hard the difficulty is a key, and hard is the value). Managing the settings is then just handling these key-value pairs, providing a user a way to change these in a controlled manner, and then handling the saving and restoring the values with the settings file. The file can also contain commented lines (beginning with #) that are just for humans to read, and are not actual settings.
As you can see, also the latest player’s name, who entered the Hall of Fame, is also stored in the settings. Assuming the game is mostly played by the same player, she does not need to write her name again and again, but can just accept the notification as you can see in the previous post video.
The settings are managed in a single class, unsurprisingly named Settings:
public class Settings {
public Settings() {
difficulty = "easy";
style = "modern";
mode = "dark";
playerName = "Anonymous";
}
public String difficulty;
public String style;
public String mode;
public String playerName;
public boolean isDirty = false;
private static final String SETTINGS_FILE_NAME = "snakeses.ini";
As you can see, the constructor gives the default values to the various settings. You can also see that I’ve taken the easy road of letting the members be public instead of the default and recommended private. Lazy me, but I am myself making sure that as the only programmer in this project I will treat these public members responsibly and not mess the values with anything that is invalid. In a larger project I would let them be private and make sure that setter methods would check that the parameters to change the setting values would always be valid.
How to read the settings from the snakeses.ini file, is shown here:
Opening and reading the settings file is handled using java.io.File, java.io.FileInputStream and java.util.Properties classes. The Properties object will then contain the settings read from the ini file, after calling config.load(istream).
After that, it is simple to read the setting values from the properties object by calling config.getProperty, giving the name of the property. Just to be sure, the code checks if the properties contain that key (using config.containsKey, and if it does not, a default value is used. This is necessary, since the file could be changed outside of the app, by the user, for example, so as a programmer you cannot trust that the file (after saving it) will surely contain those key-value pairs.
Also, when the app launches for the first time, the settings file is not there. It could be delivered with the app with default values, but again, nothing stops the user accidentally or deliberately deleting that file. So the code must prepare for the situation that the settings file does not exist — that’s why the catch (FileNotFoundException e). If the file is not there, again, resort to the default setting values. And then save the settings immediately, calling save(). That makes sure that at least now we have the settings file there.
The member variable isDirty is also set to false. isDirty is convenient to have. When the user opens up the settings panel and closes it, there is no sense in saving the settings if they were not changed. As you can see below, the isDirty is set to true if the settings change, and only then the settings are actually saved. No need to do any disk access if there is no need for it.
Do note that the app in this demo does not check if the settings are actually different from the original when user leaves the settings panel. If there are lots of settings and changing them leads to lots of code to be executed, you might want to keep the old settings somewhere, let the user to manipulate the settings, and then when the user is done, actually compare the old setting values to new ones. For those values that are actually different, then handle the changes to those settings only.
Saving settings to a file is handled using java.io.File, java.io.FileOutputStream and java.util.Properties classes. In this case we just set the various properties of the Properties object, using config.setProperty, giving the key and value pairs to the configuration, and finally call config.store. As you can see, the string “Snakeses Settings” and the date of the update is saved as comments to the snakeses.ini file.
Also, the isDirty is set to false at this time; settings are now saved and not changed.
How the Settings panel then uses the settings when user is shown the current settings? As an example, let’s see how the game difficulty radio buttons are created and how the radio button corresponding to the current setting is selected, in SettingsPanel constructor, other details omitted:
public class SettingsPanel extends JPanel implements ActionListener {
private Settings settings;
public SettingsPanel(Settings settings) {
this.settings = settings;
ButtonGroup levelGroup = new ButtonGroup();
JRadioButton easy = new JRadioButton("Easy");
easy.setActionCommand("easy");
easy.addActionListener(this);
JRadioButton hard = new JRadioButton("Hard");
hard.setActionCommand("hard");
hard.addActionListener(this);
levelGroup.add(easy);
levelGroup.add(hard);
if (settings.difficulty.equals("easy")) {
easy.setSelected(true);
} else {
hard.setSelected(true);
}
The “Easy” and “Hard” radio buttons are created to a ButtonGroup. That takes care of managing the principle of the related radiobuttos that only one of them can be selected at one time. The last if-else block shows how the current value of the Settings is used to select one or the other from these game difficulty radio buttons.
Did you know that the name “radio button” for this control comes from the actual radios to listen to radio stations? Radios used to have several buttons for selecting preselected radio station frequencies to listen to. Obviously, you can only listen to one station at a time. So pressing down one station button would then deselect (pop up) the previously selected station button.
That’s why these buttons are called “radio buttons”. Radio buttons in GUI frameworks are round to distinguish them from check boxes, which are rectangular and function differently (many of them can be selected simultaneously).
Row of seven white rectangular radio buttons in a vintage radio divide. Image from https://www.collectorsweekly.com/stories/273171-1950s-grundig-fleetwood-tube-radio-mode
Obviously, the controls to use in managing the settings depends on the setting and the possible values of that setting. For example, if we would have a setting with multiple values, like e.g. 42 distinct values, using radio buttons would not be a good choice. Then one could use a dropdown / combobox list instead, populating the available options to the list and selecting the one found in the settings.
What happens then when user changes the setting? In the code above, you can see that the SettingsPanel is set as the action listener to the radiobuttons, e.g. in easy.addActionListener(this). Also, each radio button were given a name for the command they represent, e.g. like this: easy.setActionCommand("easy").
The panel implements the ActionListener interface, and therefore must have the method actionPerformed overridden. Again, let’s look at the relevant parts of this method:
public void actionPerformed(ActionEvent e) {
final String action = e.getActionCommand();
if (action.equals("easy") || action.equals("hard")) {
if (!settings.difficulty.equals(action)) {
settings.difficulty = action;
settings.isDirty = true;
}
} else if (action.equals("classic") || action.equals("modern")) {
// and the same for the other radio buttons...
Here, we check which was the action command related to the action event. So if the command was “easy” or “hard”, we check if the related setting value is different, we then change it and also set the isDirty of the setting to true indicating a need to actually save the settings to the snakeses.ini file as seen above.
So far we have seen how the Settings class manages the settings file, and how the SettingsPanel displays the current settings, and then changes the settings based on user actions.
How the app then actually initializes the settings and saves them if they have been changed? This is done, in this app, in the SnakesesApp class that contains the main method of the app.
When the app is launched, the settings object is the first one to be created:
public static void main( String[] args )
{
javax.swing.SwingUtilities.invokeLater(new Runnable() {
public void run() {
new SnakesesApp().run();
}
});
}
private static SnakesesGame game;
private static Settings settings;
private static HallOfFame hallOfFame;
// Later...
private void run() {
try {
settings = new Settings();
settings.read();
hallOfFame = new HallOfFame();
hallOfFame.read();
game = new SnakesesGame(GameViewConstants.GAME_WIDTH, GameViewConstants.GAME_HEIGHT, settings);
// GUI
JFrame mainFrame = new JFrame("Snakeses");
// And the rest of the GUI is then created...
Things to note here: The app object contains the relevant application objects as member variables (game, settings, hall of fame). Also the GUI objects (frame, panels) are member variables, but left out from code snippet above since they are not relevant in this post.
As you can see, the settings are read from the settings file as the very first step of the application launch. Therefore, they are read from the file and available to the rest of the application immediately.
How about saving the settings? This could have been done in the SettingsPanel, but in this implementation it is done also in the SnakesesApp. The reason is, that changing some of the settings needs to be reflected in other components of the app. The method SnakesesApp.switchTo is called by the SettingsPanel when the close button is pressed. The app then switches back to the game view.
But before that, the app first checks if the settings were changed (isDirty is true), and saves the settings. App also instructs the hall of fame object to switch the hall of fame visible to the user, to the corresponding game difficulty level hall of fame data. This is because the game always shows the hall of fame for the current difficulty level only. This is shown in the code snippet below:
Other game objects and panels read the settings continuously as they do their things, so they need not to be updated the same way as the hall of fame needs to be. For example, the game panel that draws the snake and the food, uses the light/dark mode setting in painting the graphics each time the game screen is drawn:
public void paintComponent(Graphics g) {
super.paintComponent(g);
if (settings.mode.equals("dark") && getBackground().equals(Color.WHITE)) {
setBackground(Color.BLACK);
} else if (settings.mode.equals("light") && getBackground().equals(Color.BLACK)) {
setBackground(Color.WHITE);
}
// ....
Summarizing, we have now seen:
how the game settings and the settings file can be managed using the Java Property class,
how game settings panel can display and enable changing the settings,
how the app initializes the settings at lauch and how it saves the settings if they are changed in the settings panel,
how settings are used in the app when drawing the game screen, and
how changed settings can be propagated, if necessary, to other game elements like the hall of fame.
I implemented the classic Snake game (a.k.a “matopeli” in Finnish) using Java and Swing in retro style:
Why Java and Swing?
Originally, the idea was to implement something to demonstrate to students in our GUI design & implementation course. Namely, how to have one frame (window; JFrame) and be able to easily switch between different content views (JPanels) within that window, by using Swing CardLayout. And since Java and Swing are the default tools to use in this course (they can pick almost anything else they like, though), that’s why.
The game settings panel, hall of fame panel and the actual game view panel are all included in the same frame using the CardLayout. The demo also shows how to use keyboard shortcuts and buttons to switch between the three cards.
As usual for me, things got out of hand and I ended up implementing the whole game with all the features (I came up with). Unnecessary for the original purpose of the demo, but more fun than other more boring responsibilities, like various macrodata refinement types of tasks.
Since this app is “too complete” and could be used to copy-paste solutions in the course, the plan is not to publish this in source code. But parts of this can be included in (future) tutorials on how to:
use the CardLayout,
play the game using keyboard,
control the game using a Timer and TimerTask,
draw graphics on the screen,
store and restore settings using Properties, and
store and restore the hall of fame stats so that users cannot (at least easily) cheat by editing the hall of fame file manually.
The Hall of Fame file is scrambled using Base64 encoding and the Cesar cipher, so not actually rocket science. The scrambled Hall of Fame contents you can see in the video looks something like this, when scrambled:
Anyone could try out implement the same scrambling algorithms (since I have now revealed all the important secrets about it!) and attempt to “decrypt” the file and then manually put themselves at the top, then “encrypt” it back into the file. They can then be proud no one ever reaches the same level of gameplay again… Damn those clever cheaters! Luckily one can always delete the file and start from scratch.
Thanks for reading and have a nice rest of your day!
So, another long break in blogging. This, of course, is due to having too much work and spending the remaining energy somewhere else (like running).
So I thought I’d write a couple of posts on what I have been doing in between the previous post in January:
Evaluating the Data Structures and Algorithms course programming assignments. This has been faster this year, since my automated tool that both unit tests all the submissions and now also checks the source code that it doesn’t use things students are not supposed to use, and does use things they are supposed to use. Later I’ll make a post about the latest and future improvements to this tool. I still use too much time on this, due to lacking teaching resources, so the only ways to improve the situation are to add more automation and forget about giving detailed feedback to students.
Launching and supervising six BSc student projects. This started in January and will continue to end of April or May, depending on individual project schedules. Groups of 4-6 students show the skills and knowledge they (hopefully) acquired during their BSc studies and design and/or implement a software for an external (or “external”) customer. Sometimes they continue development of already existing software. I have weekly status meetings with them and guide them through the project, and participate in official steering group meetings.
Preparing and conducting our MSc program applicant interviews. This took most of the February, almost full day.
In March, the Programming 4 course started. The course focuses on GUI design, usability and user experience. I am assisting my colleague in this course. Students design and implement a GUI app, often the first time in their lives. Up to this point, they have usually implemented only small command line apps with relatively small number of functions or classes. This week is the last week of the course.
Supervising some BSc and MSc thesis students and
Preparing courses for teaching in Fall.
So, lots of work and thus no time for blogging, considering my priorities.
Anyways, I thought that in addition to listing the jobs above, I could also show some demonstrations I prepared for the Programming 4 course. The one described below in this post is a very simple and small demonstration showing how to use a Publish/Subscribe pattern to update GUI views when a data object (a model) in software changes state.
The old school way to do this is the Observer design pattern, which has it’s pros and cons — easy to use but has its negative consequences too. Classes related to that in Java have been deprecated though still usable.
Instead of Observer, Java recommends using other techniques, like the Publish/Subscribe pattern, using Java Flow Publisher and Subscriber interfaces and classes.
So, I implemented a simple demo app in Java and Swing, WallClockApp (GitHub link to source). The app uses the Publish/Subsctibe pattern and looks like this:
You can add several timezones using the plus button, and see the time in these different timezones. The red circle and cross button in each timezone can be used to remove a timezone. Obviously, the times advance with each clock, as seconds tick forward.
The app follows the also common Model-View-Controller architecture in GUI apps. In the app the Model (class ClockTickSource) is an object that provides the time signal, once a second. The View objects (class WallClock) are the different time zone views (three visible in the screenshot above). The app object (class WallClockApp) acts as the Controller, creating the model, and adding clock Views for user selected timezones. The Views basically just show the time in their corresponding time zones.
Where does the Publish/Subscribe then fits into this? Well, the Model needs a way to tell the views when a second has passed. So it has to know about the views that need the time tick signal. When the Model’s timer ticks, once a second, it then needs to notify the views so that they can update the time visible in their timezones.
This has been implemented here using the Java Publish/Subscribe pattern. The model is the publisher, that publishes the current time in one second intervals. The current time is published as the Unix time, milliseconds since Jan 1st, 1970, in UTC time.
Views, the Subscribers, subscribe to the Publisher as they are created:
public WallClock(final ClockTickSource clock, final TimeZone timeZone) {
super();
setLayout( new BorderLayout());
this.clock = clock;
this.timeZone = timeZone;
this.clock.subscribe(this);
On the last line above, you can see the View object subscribing to the clock ticks, calling the clock.subscribe. The Publisher (clock, the Model) then will notify the Subscriber about successful subscription and the View can then request for the clock ticks (Long values; the milliseconds from Jan 1st, 1970 UTC):
The Publisher then (code below) starts the clock ticking using a Timer, but only once, for the first subscriber (since only one timer is needed to run the show; see the start() method on details on how to launch the timer):
public void subscribe(final Subscriber<Long> subscriber) {
if (publisher == null) {
publisher = new SubmissionPublisher<Long>(ForkJoinPool.commonPool(), 10);
}
publisher.subscribe(subscriber);
if (publisher.getNumberOfSubscribers() == 1) {
start();
}
}
A concrete Java class SubmissionPublisher does the actual work here in the Publisher side.
Then the subscribers (views) handle the published data (Unix timestamps) as they get the notification from the Publisher when onNext is called by the Java Flow framework. The views will then convert the UTC time in milliseconds in the parameter item to their respective timezones and show that to the user:
public void onNext(final Long item) {
final long currentTime = item;
Date time = new Date(currentTime);
ZonedDateTime zonedTime = time.toInstant().atZone(timeZone.toZoneId());
timeLabel.setText(DateTimeFormatter.ofPattern("HH:mm:ss", Locale.getDefault()).format(zonedTime));
}
When the view closes (from the red circle/cross button), it needs to unsubscribe from the publisher, using the subscription.cancel():
You can get the rest of the details from the linked GitHub repository. This was a very small demo, just to show how the pub-sub works with the Java interfaces and classes. If you are interested in the details, head to the GitHub demo, clone it and check it out in action!
In the following posts I’ll show some other demonstrations and also write about the updates to the automatic DSA course testing/checking tool. Have a nice day!
