Memokid relicensed under GPLv3 !

Memokid is now free software. The game, which used to be marketed by the now defunct eveil-et-savoirs.com online store, has been re-licensed under GPLv3. The source code is available at this URL on gitlab: https://gitlab.com/vectomatic/memokid

The source base has been modernized. This was quite a challenge in itself since the code base was six years old, which is a lot in the javascript/react world. The build chain, which relied on a custom webpack 1.14.0 toolchain, got migrated to create-react-app 5.0. The base frameworks were upgraded to their latest versions where needed (react 18.x). The UI was migrated from react-toolbox (which no longer exists) to material-ui, internationalization from react-i18next tor react-intl.

There were a few functional improvements made to the game too. All 12 card decks are now available (the previous online version was just a two-decks demo version for the full-feature game marketed by eveil-et-savoirs: this is no longer the case). A new setting in the application settings page makes it easier to select another language. I have created translation site at https://crowdin.com/project/memokid to encourage user to translate the application to their native language (currently, the application is available in english and french but I would love to incorporate more translations to it).

Installable versions, based on Electron, for PC and Linux are now also free under GPLv3 (they used to be for sale at eveil-et-savoirs.com) and can be downloaded from this URL https://webinstit.net/memokid/index.html (webpage in french but apps are internationalized). One of the goals of making an installable version is to allow the game to be installed on old PCs without internet connections. This kind of hardware is common in french public kindergarten schools, which often do not have the funding to purchase recent hardware and rely on hardware donations from parents.

lib-gwt-svg 0.5.15 released to address dropped SVG1.1 features in Firefox 59+)

I am releasing a new version of lib-gwt-svg to preserve compatibility with Firefox 59+. After Chrome 48+, Firefox has begun dropping compatibility with SVG1.1 features (to prepare for SVG2.0 I guess ?). Luckily for us SVG1.1 users, Philip Rogers has updated his polyfill to address just that. Restoring compatibility was just a matter of upgrading the polyfill, which is the only new (though crucial) feature of this release.

Update to gwt-2.8.2

Following the release of gwt-2.8.2, I am releasing new versions of all my GWT-based libraries and applications to provide compatibility with this new release. No other notable changes for this build.

Update to GWT 2.8.1

Following the release of gwt-2.8.1, I am releasing new versions of all my GWT-based libraries and applications to provide compatibility with this new release. No other notable changes except 2 minor bug fixes.

New Game Memokid

I am launching a new game today called Memokid. The purpose of the game is to train your memory, and it can appeal to anybody from 3 to 103 ! Here are some of the highlights of the game:

  1. You can choose from eight decks of cards: food, animals, transportation. One of the decks even features animated cards. Some of the decks were made thinking of young kindergarten children who need to familiarize themselves with digits and letters.
  2. You can have between one and four players, and if you have no partners available, the also game features an AI with 5 levels of difficulty.
  3. The games by default requires you to remember pairs, but you can make it much more challenging by selecting triplets or quadruplets, or easier by selecting the number of cards in the game.
  4. The game works on any device, including tablets and large television screens. It is available in english and in french.

From the technical point of view, the game is a departure from other development stacks I have been using. It is made entirely using ES2017 and webpack, with a full redux / react stack, and of course SVG and web-animations. I am not currently releasing the source code as I have granted exclusivity for the time being to the eveil-et-savoirs partner site, but I plan to eventually release it in open-source in a few months.

Enjoy !

Lukas

Update to gwt-2.8.0

Following the release of gwt-2.8.0, I am releasing new versions of all my GWT-based libraries and applications to provide compatibility with this new release. The whole stack has been migrated to JDK8.

lib-gwt-svg 0.5.11 released to address dropped SVG1.1 features in Chome 48+

I am releasing a new version of lib-gwt-svg to preserve compatibility with Chrome 48+. Indeed Chrome 48+ has begun dropping compatibility with several SVG1.1 features in their quest to implement new SVG2.0 features. The sad thing is that they dropped SVG 1.1 features before they even provided a working SVG2.0 replacement !

You can get details on the removed APIs here:
SVGPathSeg interfaces (removed)
Deprecate/Remove SVGGraphicsElement.getTransformToElement (removed)

Luckily for us SVG1.1 users, I have been able to restore compatibility by leveraging the excellent polyfills developed by David Durman and Philip Rogers.

I have also noted another difference in the behavior of Chrome 48 which broke some of my HTML games. SVG elements with a width and height of 100% will not be sized correctly: they will scale to the greatest of the two dimensions and not fit into the viewport anymore. I do not think this can be addressed with a polyfill, but I was able to use the following workaround: make the SVG elements absolute and use absolute CSS positioning with width=100% and height=100% to restore the original behavior.

Basic mistakes to avoid when creating a FirefoxOS app

I would like to write in this post about problems I have had recently with my dictaphone FirefoxOS app, hoping it will help other developers avoiding the pitfalls I have fallen into. My advice falls into two categories

Think twice before you choose a FirefoxOS app type

When one wants to develop a FirefoxOS app, one first has to choose a type of application: either hosted or packaged, then submit the app to the FirefoxOS marketplace for review. A hosted app (as the name implies) is hosted on the developer own web server and can be consumed by any number of browser (FirefoxOS, Firefox desktop, Chrome, iOS…), because it is basically a classic SPA with an extra manifest file. A packaged app is hosted by the marketplace itself, and distributed as one zip file. It is specific to FirefoxOS. Packaged apps can request extra privileges (such as access to the device SD card using the Device Storage API): code reviewers at the marketplace make sure apps do not abuse these privileges.

The difference between the two types of app is well explained in MSDN, however the fact that this initial choice is crucial and has far-reaching consequences is not sufficiently emphasized. Indeed, there is no upgrade path from a hosted app to a packaged app. One cannot say: “I will start with a lightweight hosted app, add more features, and if it turns out I need more control of the device for these features, I will migrate the app to a packaged app”. This scenario is not supported. The only way out is to create a second, different app (even though the code is completely identical, except the manifest) and re-submit it as a packaged app.

Alas, this has far-reaching consequences. Developers basically loose their user base and need to start afresh, under a new app name. They need to convince users to install the new packaged app and use it instead of the original hosted one. Users of the original hosted app are stranded with data stored in that app IndexedDB. That data cannot be imported into the new packaged app.

Why is that ? It boils down to the model used by FirefoxOS to identify an app. Hosted apps are identified by the URI at which they can be downloaded, whereas packaged apps are identified by a automatically, install-time generated GUID. The OS has no notion of relationships between apps. Since it cannot for obvious security reasons let one app tap into the data generated by another one, data migration between a hosted and a packaged app is not possible (unless one uses an external server to manage export/import, which would cause all kinds of new problems).

I did not make the right choice with the dictaphone app. I started as a hosted app. A that time, I saw no need for privileged APIs because all I needed was to grab the microphone (WebAudio/MediaCapture) to capture sound and use IndexedDB to record them. Other more advanced APIs (such as the Recorder API, which appeared in FFOS2.x) had not been developed at the time. Furthermore, I saw no reason to limit the app to FirefoxOS if it could work on other browsers too, an approach which seemed encouraged at the time by MDN through articles documenting “Open Web Apps”. The app was very successful at first, because it added a feature which is useful to a lot of people. However very quickly users began rightfully to ask for a feature to export their recordings out of IndexedDB to the device SD card. Alas to access the SD card, one needs to use the Device Storage API, which is a privileged app available only to packaged apps. Ooops ! There is no way I can provide this functionality. I need to create a new app for that.

Be aware of fragmentation and stick to basic APIs

Fragmentation does not only happen in Android. It also happens to FirefoxOS devices and a lot of the early adopters are stuck with early versions of the operating system (1.0x), either because the manufacturer has not ported FirefoxOS upgrades to their device, or because the phone operator does not provide support for upgrades. The marketplace does not currently filter the apps based on the capabilities of the device or its operating system version. Therefore, developers had better have an application which can degrade gracefully for early versions of the operating system. If it turns out the core functionality of the application cannot be implemented in old FirefoxOS devices at all (as is the case with dictaphone), developers should consider whether or not to develop the app at all.

Indeed, the bulk of the users for these apps are non-technical people. They expect the thing to just work and if it does not they will blame the developer. This translates into a bad experience of angry feedback, insults and 1 star grades.

Conclusion

Paul Rouget from Mozilla very gently contacted me to inform me about the new Recorder API (available in FFOS2.x), suggesting I should changed the app to use it instead of my homemade WebAudio/MediaCapture codec. He is right of course (technically). However at the moment I have not found the will to do that, because I will face the following issues. Users of 1.x who are currently satisfied by the app will be pissed off because they will not be able to re-import their data in 2.x. Users of 1.x who cannot currently use the app because it requires at least 1.2 will be even more unhappy if I suggest they try 2.x instead. Users of 1.x who cannot upgrade their OS to 2.x will also be unhappy.

update to gwt-2.7.0

Following the release of gwt-2.7.0, I am releasing new versions of all my GWT-based libraries and applications to provide compatibility with this new release. The whole maven stack also receives a big overhaul, with a migration to maven 3.x and gwt-plugin-2.7.0 for building.

update to lib-gwt-svg and lib-gwt-file for gwt-2.6.0

gwt-2.6.0 has finally been released, which is very good news. I am releasing new versions of all my GWT-based libraries and applications to provide compatibility with this new release. The whole software stack actually receives a big overhaul, and now uses JDK1.7u51 and the just released maven-gwt-plugin-2.6.0 for building.