Yesterday (day #2) and today (day #3) I continued to work on further adding features to App Tracker. Below is my report on those two days. While this summarizes some of my activities throughout the challenge, I would like to eventually expand on some topics and write additional posts on those. If you have any specific ideas on further detailed posts, let me know.
What’d we do today?
Here’s the short and sweet version.
- Implemented MacOS Support. Now support Windows + MacOS and tested on a real Mac. Linux support to follow.
- Web UI. A very, very simplistic web UI that shows a bar chart and table of the top most used apps. Utilizes the API we built the previous days. This is a Vue.js, Chart.js implementation.
- General code cleanup. This is essential on any project, general code cleanup to ensure the code continues to be readable, usable, and maintainable.
More details on each of these elements below.
MacOS Support
App Tracker now supports MacOS on the client/server side. The client side runs locally via just the basic app-tracker.py. The server side can run either via executing the app-tracker-server.py or building/running the Docker container (using the Dockerfile).
MacOS support was pretty simple. Frankly, I didn’t know exactly how to support this out of the box, but as always, StackOverflow came to the rescue. I tried this out briefly on my Mac to ensure it at least worked and produced the results I was aiming to get.
This solution utilizes Apple’s AppKit. As Apple refers to it:
AppKit contains all the objects you need to implement the user interface for a macOS app—windows, panels, buttons, menus, scrollers, and text fields—and it handles all the details for you as it efficiently draws on the screen, communicates with hardware devices and screen buffers, clears areas of the screen before drawing, and clips views.
https://developer.apple.com/documentation/appkit
Utilizing AppKit in Python is similar in concept to utilizing Windows APIs in Python. It leverages the ObjC libraries in MacOS in order to perform this magic.
Web UI
There is now a web UI that you can use to visually see your app usage / data. The UI is written using Vue.js – again a language (JavaScript) and a framework (Vue.js) that I’m not very familiar with – so this is allowing me to learn some new tools along the way. The UI also spins up nicely in a Docker container for the most minimalistic setup.
There’s a bit going on here and probably the most complex aspect of the entire project so far – probably more than I can ellaborate in one post. At a high level, I’m using the following components:
- Vue.js as the presentation layer.
- Chart.js + vue-chartjs libraries to create the chart.
- Axios as the HTTP library to send/receive requests to our server side API.
Of all the work I’ve done so far, this is probably the piece that I will probably not change the overall tech stack. I like working with Vue.js so far and the more I learn how to use it, the more I see how great of a framework it is to use for web development. Of all the different aspects of software development, web UIs is probably where I have the least experience though. Hence, this is actually what I find the most interesting to learn and work on.
Oh, and most importantly, you can find the UI on my GitHub.
General code cleanup
Continuing to refine the general code cleanup for App Tracker – this will always be an ongoing process, but is an essential process in ensuring we have a good, clean code base. The code was split out a little more into individual classes, more methods, etc. This is still in the prototype phases and I’m not as well experienced with these languages/frameworks, so I’m sure there’s even more improvements to be made here.
What’s next?
- User support. Right now the entire process tracks apps globally – i.e. not related to any particular user. I’d like to add support for users in the near term. (Note: not to be confused with customer service/user support. :) )
- Create a more robust API. The API is current pretty simplistic at the moment and is just a Python Flask server. Long term, I’d like to investigate migrating to a different type of server + build in robustness to the API itself.
- Host in Azure. Once this gets fleshed out to support multiple users, a more robust API, etc., I’d like to eventually host this out on Azure.
- Future tech stack. Python is great to initially spool something up and get things going. While I may stick with Python for some elements, I will probably transition some elements of this project to C# or utilize other languages, frameworks, and libraries.
That’s it?
That’s it for days #2 and #3. Stay tuned for more. (I may remove this section in future posts.)
WinQuire 