The next release of our Ancient Maya App is planned for March. It will include the audio for Yaxchilan Stela 11 in Yucatecan Maya, add support for Spanish language user interface and refresh of the software development environment. The rest of this post describes the issues involved in app development in case you’re interested in understanding what goes on “behind the scenes”.
The app currently includes three audio tracks for Stela 11: English, Spanish and K’iche. In software development, adding an entirely new feature can be a lot of work. Generalizing a feature, for example going from supporting one audio track to two audio tracks, is some work but not too much. By the time one adds the fourth of something it should be pretty simple. You’re just turning a crank: updating the user interface with another button and specifying another set of timestamps to synchronize the highlighting of glyphs with the new audio track. Along with that work the audio track must be cleaned up. The audio was recorded on a laptop’s microphone in a quiet room with substantial echo. In the future I’ll use a better microphone. I used iMovie to reduce echo, raise audio levels and put a small consistent pause between glyph block. None of that is hard, it just takes a little time.
These days adding support for multiple languages is pretty straightforward. It’s not like the old days where limited support Unicode made supporting non-ASCII characters difficult. Instead there’s always some localization framework you can integrate into the app’s code. Typically you create a separate file for each language your app supports. Each entry in this kind of file contains some label name or tag and the appropriate user interface text. For example, the file for English user interface text would associate the tag “convertDate” with the text “Convert Date”. Meanwhile, the file for Spanish user interface text would associate the tag “convertDate” with “Convertir Fecha”. Each file contains dozens or hundreds of entries, depending on what the app needs. Your smartphone includes your language preferences (which defaults to something reasonable so you probably never changed them). When the app runs it displays user interface text based on these preferences and what languages the app supports. The only complications with supporting another language deals with layout of user interface components. It’s a problem when you have a button where one language needs a very long text where another language needs only a short text. The long text button breaks the layout (that is, it doesn’t fit on the screen) and you look for a shorter string or change the layout of widgets. The next version of the app will support English and Spanish, although the Spanish support will not be complete. Once the app supports two languages, adding more will be straightforward. Again it will be turning a crank to create some new language file and tweaking the app’s list of supported languages. We’d really like to support a couple Maya languages!
The final task for this release is updating the development environment. Smartphones constantly get updates to their operating systems. And these updates change the environment that the apps run in. Maybe the security regulations change. Maybe the user interface preferences change. Something is always changing. App stores don’t want ancient versions of apps. They want apps that support the current guidelines, rules and constraints. So apps need to be periodically tweaked and rebuilt from the source code to comply. The Ancient Maya App is pretty simple. It’s not like some high performance graphics intensive game or super high security bank app or an important part of a billion dollar business. In those cases the app is written twice, once for iOS devices and once for Android devices. For simpler apps one typically writes the code only once and builds separate releases for iOS and for Android. There are several “write once” languages and frameworks to choose from. I chose Dart/Flutter. It’s a free and open solution from Google with somewhat broad community support. It’s not the most popular approach, but I thought it was reasonable, well documented and fun to use. It also supports more than just mobile app development. I could deploy my existing code to a website or even as regular applications that run on MacOS or Windows. As part of updating the development environment I updated Dart (from 2.13.4 to 2.19.0), Flutter (2.2.3 to 3.7.0), the VS Code editor, etc. A lot of this updating is pretty straightforward but you always run into some errors like learning you’re running an incompatible version of CocoaPods. I’d never even heard of CocoaPods so it takes some googling to figure out out how to fix the error. Updating the development environment is something I do about once a year. It should really do it with every significant release.