For a long while, I wanted to refactor the Project Archive in order for Jekyll to render that page faster and to access data about my projects in other parts of the blog.

Previously, projects were merely Jekyll pages with YAML-front-end-matter (YFEM) data and page “content”. The problem with this method was that it was difficult to query what projects existed on my blog. I would previously have to loop through all posts to find out.

I wanted to move project data into Jekyll’s data files, but all project data would have to be shoved into one giant file, which I didn’t like. You also cannot render page content with data files in any easy way.

The solution to this was Jekyll’s collections feature, a very powerful alternative to data files, which allowed me to make 1 entity (here meaning a project) per file and write content for every entity as if they were pages or posts. For projects, this allowed me to make a file per project, establish project metadata (name, type, domain, etc.), and write pages about every project. For this to work, I added the following data to the _config.yml:

collections:
  projects:
    output: true
    permalink: /projects/:name/

defaults:
  - scope:
      path: ""
      type: "projects"
    values:
      layout: project
      share: true
      comments: false

Jekyll needs to know that I have a collection called projects, and every project date file will be placed in a folder called _projects (note the underscore). Also, make output equal true so that Jekyll renders pages for every project in the projects folder. In addition to this, I added some common data into defaults so that I don’t have to write those values in every YFEM of every project file.

With the project collection implemented, I refactored how projects were listed in the Project Archive by looping through them instead of posts. There were multiple loops before, now there are only 2 nested loops. I’m actually not sure if the page is rendering faster, but the code is sure easier to read now.

Now that projects have easy to access metadata, I had the liberty of enhancing the look of the Project Archive by adding a date range, header image, and posts’ domains to the project listings. The difference is like night and day. On the left side of the screenshot below is the old Project Archive, and on the right side is the new version:

I’m glad to announce that Chott is now available on the App Store!

In case you didn’t know, Chott is a time tracking app aiming specifically for tracking personal creative projects. I made a prototypical version of this for Android before, but this version has more features, like deleting projects and sessions.

For more information about Chott for iOS, you can check out its project page here. Or you can click the black button below to get the app. It’s free!

When making an iOS app that uses Core Data, you would usually make dummy data in the app on a Simulator and see if your data logic is working or not. But what if you wanted to test the app on another Simulator while using the data you’ve already made before? A naïve solution would be to go into the app installed in the other Simulator and recreate the dummy data. This is of course a waste of time.

A better way is to copy the Core Data database files on one Simulator and transfer them into another. That way, you can now test the app on the new Simulator without needing to recreate data.

To be able to do this, a few assumptions are made:

• You are developing an iOS app with Xcode that utilizes Core Data
• You already made the data model and are using the entity objects in your code
• You opened your app in one Simulator and made all sorts of dummy data in it
• You opened your app in another Simulator and made at least 1 piece of data that’s saved.
  • This is important, because if your Core Data app has no data, it won’t have the folders you need to drag the database files into!

For this demonstration, I have Core Data entities saved into an iPhone 8 Plus Simulator and I want to transfer them to an iPhone SE Simulator. The app being used for demonstration is called “Chott”.

Here’s how to transfer the Core Data storage from one Simulator into another:

Usually, when you want an object in code to have a unique ID, a practical solution would be to use something like a GUID (or in Apple’s SDKs: a UUID). These IDs can be converted into strings for serialization purposes, but comparing the IDs as strings is probably not an optimal task.

In iOS 11, Apple allowed Core Data entities to have a new type of attribute: UUID. According to this Stack Overflow answer, the UUID will be stored as a binary when that entity is saved with Core Data, which is more optimal than using strings for storage. This can be used to give your data objects a unique identity when needed.

If you needed to fetch an object (or objects) from Core Data based off a UUID, this can now be done using NSPredicate objects, but you have to cast the UUID as CVarArg in order for the predicate code to work.

Here’s an example of what can be done:

Suppose you had two entities in your iOS 11 app:

• A Project which has a UUID (called id in code) and relevant data
• And a Session which holds time information and the Project’s UUID (called projectId in code).

If you were given a Project object and wanted to fetch an array of Session objects matching that project’s ID, the following is a good way of doing that:

func getSessions(forProject proj: Project) -> [Session]? {
    let requestSessions: NSFetchRequest<Session> = Session.fetchRequest()

    // Make a predicate asking only for sessions of a certain "projectId"
    let query = NSPredicate(format: "%K == %@", "projectId", proj.id! as CVarArg)
    requestSessions.predicate = query

    // Perform the fetch with the predicate
    do {
        let foundEntities: [Session] = try CoreDataService.getContext().fetch(requestSessions)
        return foundEntities
    } catch {
        let fetchError = error as NSError
        debugPrint(fetchError)
    }

    return nil
}

Notice the initializer for NSPredicate takes a format string representing a query into Core Data. NSPredicate also allows for use of a Swift closure instead of a type-unsafe string for query, but quite unfortunately, Core Data will NOT take predicates that were initialized with a closure; it needs the silly formatted string.

The formatted string is simple enough. The parameter represented by "%K" is the key of the attribute you want to search for, and the "%@" is the value of the search. The key we want is Session’s attribute projectId, and we are searching for the UUID object represented in code as proj.id, but this must be casted as CVarArg or the code won’t work.

After setting the predicate and performing the fetch, it should return an array of Session objects associated with the given Project, if they exist in persistent storage of Core Data.

This code would have worked fine if UUIDs were converted to strings, but string comparison is usually slow, and this can add up if there are many instances of an entity you want to search for.

A couple of years ago, I was learning Android development in graduate school, and as a final project, I wanted to make a time tracking app for personal hobbies, which came to fruition as Chott. Now that I’m learning iOS development, I wanted to remake this app for iPhones.

I’m using Core Data as the local storage solution. I’ve use a tiny bit before, but now I’m using a new feature that allows Core Data entries to have UUIDs as a attribute. (UUIDs are like GUIDs in other languages.) Unfortunately, this feature has forced me to target the app at iOS 11 (the latest version at the time of this writing). I wanted to support to iOS 10, but I wanted to use the new UUID attributes, because I felt it would be faster than storing strings IDs.

I developed the UI of this app to look almost identical to the original Android version. I would have liked it to be on iPads, but I had a little dilemma: I wanted the iPhone version to be only in portrait orientation, while somehow allowing any orientation on the iPad. I currently didn’t know how to do this. And also, since Chott currently doesn’t have cloud sync support, I figured that it would be good for now to just target iPhones and not iPads.

I’m ready to submit to the App Store soon. If you want to find out more about Chott for iOS, check out it’s project page here for a list of features and screenshots.

After learning iOS development from Devslopes, I figured that I should start making apps myself as a learning experience. I wanted to start off with something relatively simple, like an alarm clock.

I already use an alarm clock app, so I utilized it as a reference to make this new app. I wanted a dimmable clock face that works on different orientations and different screen sizes. The idea was to make an alarm clock app that can also serve as a bedside clock (which is what I do at the moment).

I call this app Minapps Alarm Clock. The “Minapps” is just short for “minimal apps”, because I wanted it to be relatively simple in functionality. If I make more simple apps, I intend to attach the “Minapps” name to them.

I’m a little surprised how long it took to develop this alarm clock (about two weeks), but I fortunately learned some new nuances of iOS development. Here’s a list of skills I gained from making this app:

• How make multiple text labels scale properly on iPad and iPhone screens.
• How to schedule functionality with the Timer class.
• Wrangling with the difficult Date class.
• Reading the UIDevice class in order to disable auto-lock and to read the device battery life.
• Using UserNotifications to send local notifications to a user when their alarms ring outside of the app.
• Using a Settings Bundle to tweak the alarm clock settings.

I’m happy to say that Minapps Alarm Clock is available on the App Store.

If there are any bugs, open a new Github issue here.

Lately, I was learning mobile app development on iOS platforms. Since I always use an iPhone (and sometimes an iPad), I figured that I should be able to write software for these things.

I was actually exposed to iOS development before, in the distant past. Back then, it was very difficult and confusing, but I must admit that my programming skills were not as sharp back then either.

But now I finished learning the basics of iOS development from the DevSlopes team on Udemy. If you like being self-directed in your learning but want some guidance, DevSlopes is great for that.

Last month, I completed their iOS 11 & Swift 4 course. You can see my Certificate of Completion here.

At DevSlopes, you code several projects, learning the different aspects of the iOS platform. The following is a select list of such projects I uploaded onto GitHub. You can see screenshots and more information there:

• RetroCalc: A simple iOS calculator app
• Ramp Up: An iOS ARKit demo featuring live-sized skateboard ramps
• Rainy Shine: A very simple weather app for iOS with 5-day forecast
• Goal Post: An iOS app demo utilizing Core Data to try to track new goals
• Bot Vision: An iOS machine learning demo (using CoreML) where the app tries to recognize everyday objects
• Pixel City: An iOS app demo were users can browse Flickr photos based off map locations
• Breakpoint: A micro social networking iOS app demo aimed for coders and other geeks, powered by Firebase
• Confaby: An iOS Slack clone demo app that features realtime chat messaging
• Scribe: An iOS app demo that dictates a pre-recorded voice message

Since moving to Jekyll and GitHub Pages, I wanted a way to write a new blog post from a mobile device. I admit that I might not write from a mobile device very often, but it’s nice feature to have, and Wordpress.com has an app to make this task easier.

I searched long and hard for ways to write posts on an iOS device and post them to this blog. Long story short, I found a way from hardscrabble that involves using an app called Editorial. It’s a pretty advanced text writing app that has tons of features like templates and custom workflows. Instruction provided by hardscrabble show how to set up the app to write to your Jekyll-powered blog (if it’s hosted on GitHub Pages). The custom workflow hardscrabble made can be found here. I did a few tiny tweaks, but it works perfectly.

This post was written in and sent from the Editorial app.

At DePaul University, typical coding projects take about 3 months to complete. However, if you are assigned to make a game engine, it can take 9 months! (That’s 3 quarter terms at DePaul).

LGE is the result of a long-term sequence of game engine development courses where students are tasked with making a game engine. You start with graphics and math, but then build up many other systems like run-time formats, hierarchy trees, and even skinned animation, on the GPU! You take the same engine you made the previous course and keep developing it.

Let’s just say it wasn’t a walk in the park.

But it’s definitely the most advanced code I’ve written yet. It may be useable for a simple animated game (although LGE doesn’t have an audio system).

You can learn more about the LGE game engine at the project’s page, or download the code from GitHub.

In interactive media (ie. video games), procedural generation is gaining momentum, and I think it’s a really cool concept; making computers do the art (or level design).

Another thing I think is cool is outer space, especially planets. The best of both worlds collided back in the early 2010’s with an old iPad app called Planetary. It made very good use of procedural generation techniques to make life-like planets on the screen. Unfortunately that app doesn’t exist anymore (although the source code is available).

That app inspired me to try to make procedurally generated planets. I found an opportunity to do so as a grad school research project. The result is the library Procedutex, which can procedurally generate textures of many kinds, although I mostly used it to demonstrate planetary textures.

You can read more about it at the project’s page, or you can get the source directly from GitHub (code is Windows only).

Through the last couple of years, I’ve been making a few software systems in C++ (mostly game code for grad school). But all of that C++ code was always written for the Windows platform.

I really wanted to know what it would be like to write C++ game code on a Mac (since I use Macs quite a bit). I must admit, it wasn’t easy, since Xcode thinks you only want to write C++ for non-visual command line stuff (and not something visual like a game).

I looked long and hard for a way to make a GUI project in C++ on Xcode. It seems that you have to make a Cocoa Application and use Objective-C as the language. That seems counter-intuitive, but since the main() function is mostly C-style, you can remove the Objective-C code, rename the file main.mm, and use a 3rd party GUI library like GLFW to launch a window with OpenGL context.

From there, you can make an OpenGL-powered game engine in C++ that runs on Macs. I did exactly that with an engine I call Sea2D (Sprite Engine Apple 2D). You can go the project’s page to find out more, or you can get the source code directly from Github.

During college, I took an Android Development course, and the result of my final project was a neat app called Chott (an acronym for “Creative Hobby Occurrence Time Tracker”). The premise behind the app was to track the time spend on creative hobbies/work, a concept partially inspired by Devine Lu Linvega’s Horaire.

I actually use iPhone most of the time, so I don’t use Chott. I’ll consider making something similar in iOS later. Regardless, it’s a usable app (although you cannot delete records made in the app). If you have an Android device and Android Studio, you can go straight to GitHub to get the source, or go to Chott’s page for more info on the project.