A brief moment of silence at our GC Wizard Team Meeting – and Henrike’s eyes flashed. With a light laugh, she asked the group why we Germans would grill rabbits when caching?

Astonished faces – and Henrike broke the tension. When she read the word “Hasengrill” for the first time in a hint, she had to search a little bit longer before she knew what it was all about.

An entertaining discussion immediately ensued, with special terms and puzzling clues such as Biltema, Cacherautobahn, Meelhoppertje or olifantenpad.

And immediately an idea for a new tool was born: a lexicon with special terms or country-specific clues from a wide variety of countries.

But that won’t work without support. So let’s go – what special hint have you found that is worth spreading or that poses problems for non-native speakers? Send us your contributions with a picture and/or a short description.

Display the shortest distance between two points on the map:

Why is a curve the shortest route? Why not just draw a straight line? The answer is this: The earth is not a flat map, but a complicated body that can be described to the best approximation as a flattened sphere, a so-called rotational ellipsoid or spheroid. The map shown is a so-called projection of this ellipsoid. It is called a Mercator projection. The best way to explain this is to use the degree grid:

If you now imagine that all meridians, i.e. all vertical lines, actually meet at the top and bottom at one point, the poles, and that the left and right sides also touch, then you’ll get the body of the earth. In principle, therefore, all the apparently perfectly straight lines on the map are actually curved. If you were to draw an apparently straight connecting line on the map in the same way, it would of course also be curved when it is transformed into the body of the earth.

Conversely, a curved line on the ellipsoid may suddenly appear straight and direct:

In precisely this case, we are dealing with a so-called geodesic or orthodrome, which represents the actual shortest path on the surface of a body. The geodesic lies on a so-called great circle, a circle around the entire body on which both the start and end points lie.

Nevertheless, we have now implemented in version 3.1 of the GC Wizard the option to display this direct connection between two points (blue):

This is actually not the shortest real connection, but a so-called rhumb line or loxodrome. In contrast to orthodromes or geodesics, it has the property of being “angularly stable”. What does that mean? If you look at the geodesic, it always changes direction at every point on its curve. In our example, the red line starts in the west with a bearing of 36° to the east. However, if you were still following the course of 36° halfway along the route, you would end up somewhere completely different:

With a geodesic, the direction is therefore always corrected with regard to north. This is also the reason why you cannot simply turn the direction by 180° if you want to return from the destination to the start. In our example, this would not be 36° + 180° = 216°, but the geodesic actually starts in the return direction with a bearing of 305°.

The rhumb line, on the other hand, does not have this problem, or is even defined in such a way that it never changes its bearing:

What looks absolutely straight on the map, because every perpendicular meridian on the Mercator map has the same angle to the rhumb line, leads in reality to a spiral on the ellipsoid.

Today, rhumb lines play a subordinate role in navigation. As a really significant deviation is only really noticeable over large distances, they were only of interest for seafaring. On large maps, a ruler could simply be applied and a course was set NNW and held permanently – even if this meant not taking the shortest route. But you didn’t have to constantly calculate a new course. Today’s ships and airplanes always go as efficiently as possible along geodesics, thanks to GPS (given no other factors, such as politics or weather, play a role).

For geocachers, however, this function is actually not entirely uninteresting:

Suppose you know the north part of your coordinate (exactly 51° in the picture), but not the east part. So you want to draw a connecting line on the map and use it to see what it intersects. The map would actually show you the shortest route, but not a real interpolation line. In this extreme example, you can clearly see that, for example, in the middle between the two end points, the north value differs significantly from what you have already determined:

The north value can therefore change on the geodesic, which is not what your interpolation is for. Instead, a connection as a rhumb line is recommended here:

It also becomes interesting if you need a real projection but only barely know the distance. So you know: From point X, the target is at 45°. You could now project a very distant point at 45° onto the map and see what crosses the line again:

Due to the angular stability, the rhumb line (blue) can actually detect all points at any distance at a bearing of 45° from your point X, whereas the geodesic (red) differs. However, to be honest, the deviation in our playing areas is rather theoretical at a few 100 to a maximum of 1000 meters, but it is nice to know that the GC Wizard does not lack a certain accuracy here either. And who knows, maybe the global mystery of historical seafaring will come along one day

And how can you display these rhumb lines? As of version 3.1, you can simply click on your line in the map view, click on the edit icon and then change the line type in the line editor window. Of course, in the pop-up menu of the line, the length of the line will then be displayed as a rhumb line instead of the normal geodesic length. Of course, there will also be two new tools in the coordinates section which, like the familiar tools for calculating bearings and distances (based on geodesics), can also perform these calculations directly for rhumb lines beside the map.

Once upon a time … Holy Sepamaria … GC7DCXZ … what have I calculated …

There must be a better way. The banks can do it too.

And once again an adventurous journey to a new function began. The goal was clear: the function should calculate check digits, check numbers for correctness and calculate missing digits.

To better familiarize myself with the topic of check digits, I started with simple numbers: the German tax ID, the UIC, the ISBN and the IMEI. Just numbers, no letters, no special cases. After the first step was successful, I moved on to the next stage: the EAN or GTIN. Again, it was just a simple number, but with different lengths – 8, 12, 13, 14 digits – which had to be recognized and processed. This was also manageable. The next challenge was bold: EURO banknotes and their control number. Here, letters came into play for the first time and two different versions. The first series until 2013 and the second series from 2013, which differ in their structure. But this was also mastered.

So only the final opponent awaited: the IBAN.

Even the first glance at the German and English Wikipedia made me shudder. Standardization my ass. Only the two characters of the country code and the following two check digits were standardized. The rest was left to the nations. And they were inventive:

Country	Format
AD – Andorra	AD2!n4!n4!n12!c
…
DE – Germany	DE2!n8!n10!n
…
PK – Pakistan	PK2!n4!a16!c
…
XK – Kosovo	XK2!n4!n10!n2!n

But SWIFT and the IBAN registry didn’t let me down. The only challenge was

• to harmonize the three sources,
• to develop a data model for the structure of the IBAN,
• to type in what felt like 100 country-specific data and
• to develop an algorithm that would cover all these special cases.

But here, too, the devil is in the detail. Because, of course, every nation has its own rules for the sort code and account number. Even if the IBAN is correct, i.e. the check digit matches the character string, it is by no means necessarily valid.

In Germany, for example, there are over 14,000 bank sort codes, all of which have been created according to different standards. And, of course, each bank has its own system for generating account numbers. It’s a good thing that the Bundesbank exists. Here you will not only find biannually updated information on the valid bank codes, but also on the check digit calculation methods.
This would enable a further step to be taken, at least for Germany: checking whether the correct IBAN also stands for a real bank. Only

• these more than 14,000 bank sort codes need to be entered for the GC Wizard and
• generalize the approximately 100 check digit calculation methods for the account number and
• convert them into algorithms.

Good thing it’s Christmas, the nights are long and the weather makes it easy to stay indoors to see if that works in GC Wizard.

The range of functions is slowly growing and a new feature is slowly appearing on the horizon for the next version of the GC Wizard.

We have just released the new bugfix version 3.0.3. Actually, it’s nothing spectacular: we find a bug or get one reported, we search and find a solution. Anger, developing ambition, childish joy. The normal emotional life of a software developer.

The world could actually be so beautifully simple: develop, create a new version, press a button and publish. In fact, this has worked pretty smoothly so far, especially with the web version. There are a few legal issues to consider, such as data protection and imprint, but otherwise publishing is a matter of a few minutes. Even the Android version is now relatively quickly done, even if Google is always coming up with some, sometimes very frustrating, harassment. But thanks to a significantly reduced build time of just 1-2 minutes compared to 15-20 minutes a year ago, a new test version or even the final version is created relatively quickly. And then it comes to the iOS version.

This article is intended to show a different side that we normally only discuss in our team internally. Not everything is always peace, joy and happiness. In my specific case, the story is about our iOS version, which is increasingly threatening to become a burden.

Unfortunately, it has become the norm for Apple to cause problems. It’s not so much about any new restrictions in the AppStore; as described, Google has them to the same frustrating extent. I’ll tell you about two specific examples that made the release of versions 3.0.x more difficult.

The Hardware

When we were ready to launch the new version 3.0 after almost a year of development, it was clear that we still had to check the iOS version. As we have said several times, we are only Android developers and it is therefore almost impossible for our team to work on the iOS version at the same time. This essentially fails due to the hardware required, a MacBook. Only I myself have a very old model that I once financed with your donations. And I booted it up. When I had created the new version, as I always did, the AppStore suddenly popped up with the following message:

The app must be built for at least iOS version 11.

This happens from time to time, even on Google’s side. So I changed something internally and tried again. And this triggered a chain reaction: the new standard could only be created with the new XCode version 14.1. XCode is the essential tool needed to create the apps and the only reason why all this has to be done on a Mac. However, it turned out that this XCode version could not be installed on my Mac. Because my MacOS was too old. Took a deep breath and moved on. So I tried to update the MacOS, which Apple friends say is always so easy and trouble-free. It wasn’t to be, because MacOS 13.6 stubbornly refused to be installed and always aborted the installation without any further error messages. After many hours, it turned out that my MacBook Air was too old!

You have to slowly think about it: Apple’s AppStore is forcing me to buy a new MacBook so that I can upload my free OpenSource software to them! This is incomprehensible from several points of view, because I refuse to discard a device that actually works and, on the other hand, because I am forced to buy expensive hardware. It’s not as if there are cheap variants in the Apple world, isn’t it?

I had already written to the team and announced that I was currently not willing to spend so much money and that the iPhones would probably no longer be supplied with updates. However, I had developed a little ambition and found a way to install the new MacOS somewhere in the corners of the internet. Now there is a USB stick permanently attached to my MacBook Air, from which the operating system is started.

I can’t say how long this temporary solution will last, but I can say that we don’t get enough donations in to be able to afford to replace a functioning device. So I don’t know what will happen after that. You also have to remember that Apple charges additional costs, unlike Google. We have to pay $100 a year to be allowed to publish anything at all in their AppStore – regardless of whether it’s freeware or not (which doesn’t stop them from taking the same percentage from the paid apps as Google does). And all this despite the fact that none of us have an iPhone and we couldn’t really care less.

The Software

Once everything was up and running again, I set about creating the new version. I’m familiar with the steps, I know where to do which selection – and I know that the entire process still takes about 15 minutes per version. Not including the waiting time for the initial checks in the AppStore. Strange errors occur again and again. These are actually the reason why we always hesitate so long to check the iPhone version: We want to be sure that functionally, on the side of our code, everything runs as we envision it before we worry about iOS-specific issues. And we want to avoid doing this more often than necessary because strange errors occur completely by chance. What worked yesterday doesn’t necessarily have to work today.

That’s exactly how it was yesterday afternoon when I decided to release what was actually a very small bugfix version. There were only very minor changes to the code, absolutely nothing that had any kind of different impact on the operating system than the version that was created before. Nothing at all. But bugs appeared:

Stored properties cannot be marked potentially unavailable with ‘@available’

I have absolutely no idea what that means. So I put it in the search engine. As it always turns out: The error has nothing to do with anything we can influence directly. It’s not a classic programming error, nothing where you say: Oh, we’ve forgotten a bracket, yes, that makes sense. No, this error seems to appear completely by chance for thousands of people all over the world and the relevant websites are full of oracle attempts to solve it. And because one of them is as incomprehensible as the other, I can’t do anything other than blindly try one after the other. At some point, one of them worked. I usually save such findings internally in a “cheat sheet”. Then it worked again – for a few minutes:

Command PhaseScriptExecution failed with a nonzero exit code

I can do about as much with this as with the previous statement. The difference to the previous error is that there are even MORE obscure solutions on the internet. And that means it took much longer to try them all. This ranges from the classic restart to complex interventions in some internal parts of the compiler or even the operating system. People on the internet seem to write completely randomly what they can think of and that this or that would have helped them, often with the clear statement that they don’t actually understand it either and are just parroting the solution that another guy posted on the other side of the internet. And almost everywhere there are up to hundreds of thumbs up and thumbs down. It’s not clear what helps why in the end. The only thing that is clear is that sometimes something helps and sometimes it doesn’t, and that you’re not alone, so it’s not a problem specific to your own project.

The problem here is actually that you don’t gain any kind of insight either from the error message itself or from the solution approaches. You don’t get the feeling that you are learning something. You don’t learn what specifically went wrong, what you need to do in future to avoid this. The changes seem completely arbitrary, I’m even afraid that the option that finally seems to work won’t break something internally so that something in the app no longer works the way it’s supposed to. Does the locating still work? Can we still save files? In the end, I can only try it out randomly and hope that firstly the AppStore won’t reject the app for ominous reasons, secondly that everything works properly and thirdly that the error won’t occur again in the future – or even lead to new errors of this kind.

Of course, strange errors occur from time to time, even in Android development. But it has never happened to me that I didn’t understand at some point what the problem was, what the error message was trying to tell me and why the solution worked the way it did in the end. I always tell my team members: When you fix a bug, I want you to understand and be able to explain to me why your fix works and why the code didn’t have the desired behavior without that fix. This is essential to avoid similar bugs in the future, it’s part of the learning process. I myself strictly adhere to this: I only commit fixes that I copy from the internet once I have really fully understood what they do. But that seems completely impossible to me with these iOS-specific problems. And that’s not because of my own limitations or my real fear of contact with the Apple world, but simply because of the mass of forum participants and the thousands of completely different solutions that actually only have one thing in common: They never have an explanation, they only ever mention the potential how, never the why. There seems to be no logic behind such error messages, not even the technology used for programming seems relevant in any way.

You also have to consider that every trial and error easily costs a quarter hour of your life, because that’s the time it takes to get a new version to the point where it crashes or not. It’s extremely frustrating on many different levels. And yes, there were more of these messages yesterday, including a rejection by the AppStore itself that was as implausible as the rest of the evening, because it worked when repeated identically.

The Leisure Time

I never tire of emphasizing that the GC Wizard is purely a hobby, a leisure project. And leisure projects should be fun and relaxing. At the moment, however, this part in particular is causing me nothing but frustration. It’s no fun to spend your time like this. You can’t even classify it as learning and training because, as I said, you don’t gain any knowledge.

I created the iOS version back then because I wanted to serve the entire Geocaching community. That’s why I chose the Flutter technology at the time, because it promised that you could serve several platforms without much extra effort. And that worked very well for a long time – and basically still does. But here we seem to be dealing with errors that are completely unaffected by this and may or may not occur, no matter what you do or how you do it. The fact is, the iPhone version is currently costing us a lot of time and even more nerves. For us, it’s an unpopular burden that’s getting bigger and heavier, and it’s all down to me. Nobody in my team wants to take over this task from me, which is understandable. None of us feel comfortable in the Apple world and cases like the ones described here don’t make anyone want to get involved. At some point, we have to ask ourselves clearly whether we are willing to continue spending our free time on such almost exclusively negative emotions and whether we want to continue running the iPhone version.

I think it would be better if we had a dedicated iPhone developer in the team, also because he or she would probably bring the appropriate working material with them. In fact, I personally have the theory that there are unlikely to be any open source developers in the community; all the projects I know of in this direction are Android projects. In contrast, all Geocaching projects for iOS, Cachly and Looking4Cache, are closed source and paid (or in the case of L4C, which is now free indeed, but only because it is no longer being developed). That seems to be Apple’s world: If it doesn’t make money, nobody does it. And conversely, I only know people who enter the Apple world because everything is so easy. Perhaps such (apparent!) perfection doesn’t create any incentive to build something on their own – someone will put something there for me. Funnily enough, however, it’s by no means the case that people are happy to pay for something if they don’t need to. The Gold version has only marginally more sales than Android: on both platforms, we are well below one percent of users.

I don’t want to send you home in such a strange mood, especially because you seem to have been reading along for so long. In general, I just want to say that I think the current version is really great. That my team and I have managed over the last four years to provide an incredibly powerful and highly professional software for all Geocachers free of charge and open source. A tool that should leave no wish open. I’m a really proud daddy who often just opens his baby and gently swipes through his many tools. It makes me happy every time that we have made it this far against all odds. Who would have thought that four years ago?

Wow, I have to say first of all: I am really glad that this milestone has (almost) reached its end. It’s not visible to the outside world, we’ve always tried to touch on the issue through (admittedly relatively infrequent) reports, but the truth is: It was an incredible mammoth task that was initially completely underestimated even by us who deal with software projects on a daily basis in our professional lives.

The last release, version 2.3.1, is now about 9 months ago. After that, first primarily I, later an upgrade of the internal programming language Dart, forced us to have an entire review and in order of that a renewal of the code base. It is simply necessary from time to time to take a critical look at one’s work and see which parts are still up to date, which are outdated and which have meanwhile grown so much that nobody understands them anymore. Wipe through, re-sort, renovate. And since the programming language Dart slowly grew up together with our project, it just so happened that it also got a make-over, which meant for us: even more restructuring.

We already talked about our refactoring goals here and here in January, so I’ll skip the explanatory details now. The important thing is the bottom line: We had gotten the plague on board. Even though we didn’t write it explicitly, there were rarely two days in a row where at least one of us didn’t work intensively on the code. I actually only had such an intensive workload during the first ten months when I launched this baby. Besides many private projects, family and Covid, this task here was really extremely stressful for us. And in contrast to the initial phase back then, the current one was really anything but nice, because it was thankless to the highest degree: In the best case, after days of programming, the tool “only” did what it did before, in the more likely case, something else broke.

We learned to structure ourselves, we involved the testers even more closely in the development process, and we also tried to integrate you, the users, directly by providing a separate test version (which unfortunately went rather meeeh, as we hardly ever got any external feedback). We massively revised, updated and expanded our internal testing so that we could catch our own bugs as early as possible. We thought we were at the finish line several times, but new bug reports from ourselves kept coming in over and over again. It drove us crazy. It was frustrating. Changing the code base was no fun, but I think we all learned along the way and the team matured within itself.

Of course, my thanks go to all the members of the team who have dedicated all their energy to this great goal! You all were incredible!

The Limits of the Version

Besides the code refactoring, version 3.0 initially had very ambitious goals. However, since the refactoring itself kept us much busier than expected, some things have of course not yet been achieved as we would have liked. In the refactoring itself, the complete chapter around the Reflection thing is missing, where it’s still not clear anyway if it won’t lead to an extreme slowdown of the startup process. But I will definitely test it in the next weeks.

Also with the “Web API” we did not reach the final goal, which was to ask our server internally for the solution of a problem and to get an answer. Nevertheless, we have made a very big step here, because at least it is now possible not only to call individual tools by means of special URL, but even to fill the most common ones explicitly with inputs.

But why don’t we just wait longer? On the one hand, Google is again giving us an ultimatum, because they are currently threatening to throw all apps out of the Play Store that do not have a new minimum requirement, which we could not yet aim with the old versions. On the other hand, a line simply has to be drawn. Sure, there will always be things here and there that we need to work on, but ultimately we don’t want to keep users waiting, some of whom we promised a new feature months ago or who reported a bug in the existing version. Thanks for that by the way (I hope we didn’t forget any bug reporter for our tester list in all the chaos, otherwise feel free to contact us).

Highlights of the Version 3.0.0

Enough of what we didn’t get done. I think it’s time to reveal what makes the new version not only internally entitled to a major version jump, but also visible to you users:

First of all, I would actually like to mention the Web Interface, which goes to Mike’s account. Because unlike before, all tools can now be accessed directly by calling them up in the address bar of the browser. The advantage of that is that you can now link directly to a tool instead of always saying, “Go to the web page for GCW, then click here, then click there.” It is even already possible for a number of common, simple tools to immediately include the input text and possibly some parameters directly in the link. This now opens up the possibility that external tools or browser plugins can be designed to take certain codes directly and use them to go directly to our website, where the solution is displayed immediately. (As said, the step of playing the solution directly back to the caller is already being worked on – without promising anything).

• https://gcwizard.net/#/? Overview of the web links of all tools. The ones with a check mark have a continuative API for direct input or parameters etc.. On the question mark button behind you get an OpenAPI-like description of the interface
• https://gcwizard.net/#/vigenere?input=Ohisr+Drosg&mode=decode&a=1&key=GCW Example of a direct call of a tool with parameters in the URL

Besides the mammoth project of stabilizing and test-proofing the Wherigo tool, Thomas’ goal was to implement the scripting engine GCW Script. The older ones among you can surely remember the script function of Mopsos. This here is an attempt to create an analogue, and I think it looks pretty good already. GCW Script is basically based on a BASIC dialect. Some of GCW’s own functions are already directly integrated as function interfaces. I personally think that there is still a lot of maturing to do here, but this can only happen through concrete applications on your, the users’, part, which is why the BETA flag is applied on this.

The only right moment to include so-called Breaking Changes are major version changes? We took the chance to revise an earlier decision, which turned out to be impractical: The Formula Solver got the text functions some time ago, in order to be able to calculate the alphabet values directly, for example. This was simply done by av(C) = 3. But there was the problem, what if there was a variable C in parallel? We had a couple of algorithms that made sure that some consistent behavior was generated, but it was always not that lucky. When c:geo introduced its own formula engine, we thought it would be a good time to align ourselves: Texts will only be interpreted as texts if they are enclosed in quotes or quotation marks. bww("C") = 3, but av(C) would grumble if there was no variable C. With this, however, it is possible that your old formulas with text may now no longer work, which is what constitutes this breaking change.

(Separate posts for the Formula Solver and the Web API will follow)

So what?

Unlike usual, we will roll out the individual versions in stages – due to the size of the update:

• Today, the normal Android version went into public beta. It will stay there longer than usual, because we really want to make sure that we didn’t break something fundamental. I have my reservations about the cooperation of our almost 600 beta testers, but you can still dream
• At the same time we updated the Web version, so that interested people can have a look at the Web API and leave feedback.
• If everything seems fine so far, we can follow up with the Android Gold version in a few weeks. Of course, the Gold users are not disadvantaged and can use the new features in the same way, because they can install both versions in parallel.
• In parallel, we will test the iOS version. Yes, in all these months we haven’t done that yet – we’re simply afraid of it, since we’re all only Android users (at this point, once again, the call: If any iOS user would like to contribute: Always welcome!), and iOS still has its own problems. So the iPhönes will have to be patient a bit longer, sorry

Changelog

Well, and since I’ve already talked too much again: Here is the obligatory, final changelog of the release, in which of course the thousands of bugfixes and small, partly well hidden tool improvements could not be listed individually:

[chg] New internal structure
[new] WebAPI, Deep Links
[new] GCW Script
[new] Number Pyramid
[new] Diplomat License Plate Codes
[new] Spelling Alphabets
[new] Stellar Images
[new] Base64: Detect Files
[new] Least Common Multiple
[new] Greatest Common Divisor
[new] Geohashing
[new] Ave Maria Code
[new] UFI Codes
[new] Unix/Excel Times
[new] Velocity/Acceleration
[new] Calendar Week
[new] Settings: Save/Restore
[new] Keyboards: Smartphone Layouts
[new] Segment Displays Types
[new] Open Map: Lock Points
[new] Units: Acceleration
[new] Coord Measurement: Map View
[new] Formula Solver: c:geo Export
[new] UpDownLeftRight: Diagonals
[new] Symbol Tables
[new] Gade: Export to Formula Solver
[new] Settings: DMM Default Precision
[chg] BREAKING: Formula Solver Texts

We are now basically done with the restructuring and we are very happy with the result. I actually can’t stop scrolling back and forth in the new file structure, because I love so much

Unfortunately, this was only the first step before a much bigger one.

The “New” Language

The programming language used for the project is Dart. Dart is currently available in version 2. But one has decided to switch to a new version 3, which brings massive changes.

These announcements are not new for us. A year ago, I had already taken a look at what it would mean for us if we were to upgrade to the new version internally. And I immediately discarded this thought. Every single one of our approximately 1500 code files became completely unusable. The compiler simply would not build them anymore. The changes in this new version 3 of Dart are extremely massive.

Null Safety

In principle, Dart introduces a fundamental new concept. Programming languages, simply said, work with variables. These variables are given a value. For example, variable A can be given the value 1. But it is also possible for a variable to have no value at all, for example because a particular calculation has not yet been performed. We are then talking about a NULL value.

The more complex a program becomes, the greater the number of variables and calculations. It can then easily happen that one loses the overview here and there, whether a variable has already been provided with a value and or not. If now by mistake an empty variable is used for another calculation, say for example that A is now used in the addition A + B, then an error occurs because the computer does not know how to add an empty variable, a NULL value. A so-called Null Pointer Exception occurs which immedially yields an app crash.

The new Dart version now integrates a concept called Null Safety. Internally, this makes it extremely difficult to use variables that have not yet been initialized. The change forces the programmer to pay much more attention, which leads to much cleaner and far less error-prone code.

For the techies among you: Here the concept is described in more detail.

Code Cleanup

Actually, every programmer is convinced that he always delivers the best possible code. Of course, this is fundamentally wrong. It is said that about every 1000th line of code contains a bug. That doesn’t sound much, but extrapolated to the 200,000 lines of code that the GC Wizard contains, that’s 200 bugs that could probably be found quite easily.

Well, we were refactoring the code base anyway and so we decided to try the upgrade. After the compiler version change we were shown about 4500 (!) incompatibilities. So on average three per file. It is hardly possible to set any automatisms there, each place must be subjected individually. So a much work was waiting for us here.

We had to get into old code, re-understand what it was doing, and check whether the compiler was right about the error message here. In most cases he was. It turned out that although we always try to program cleanly, we had significantly more potential bugs – places where we might have accessed empty variables – than just in every 1000th line. I estimate I found 1000 actual dramatic bugs by myself, Mike probably more. Some of these bugs could be fixed quickly, but for some we had to go deep into the code, sometimes even rethinking and rewriting whole files.

The Actual Problem

Now you can certainly imagine that if you have to edit 4500 places, you quickly lose the overview. With the normal development one changes a place, starts the program and looks whether everything still functions as expected. But here we face the problem that the compiler is constantly complaining. As long as only one place is marked incorrect, we will not be able to start the program. That means, we cannot look after a single change, if the error correction was successful. We work in blind flight.

Only when all marked areas are eradicated, we can start the app again and see if everything still works. Although we are absolutely mindful of what we are doing, it is certainly easy to imagine that new bugs have crept in, especially with the larger necessary changes. We will know in a few days.

What Happens Next

We have already made good progress with the error locations. However, I have to admit that we lost track of which of the thousands of places required major changes and which were trivial. We are forced to put the entire app through its paces. Every single tool has to be tried out. Every single input field has to be checked and fed with all kinds of different data. Does everything still work as expected?

Automated tests can help us with many things. This is especially true for the logic, i.e. the internal calculations of the functions. But what we can hardly automate are the graphical user interfaces: Does this text field really only accept digits? Does that drop-down menu still work with all entries?

Here we will need massive help from everyone who can give. We’re working on a test plan right now that everyone will be able to see. We’re currently discussing internally within the team whether it might make sense that we don’t just release a new update, but a new temporary app just for testing. “GCW 3.0 Beta” or something like that. Simply to avoid that the upcoming update overwrites your actually working app and maybe some tools don’t work anymore.

Who wants to support us?

So far, the web version has been treated rather neglectfully by us. Some features don’t work, some look a bit strange. For some features, it’s absolutely unclear to us why they don’t work, and partly due to lack of time, but often also due to lack of technical competence, these things are simply ignored. If it works in the app versions, that’s fine. Disclaimer at the start, that’s it.

Well, some things will still not change. However, the web version will become more important in the new major version.

Third-party usage

Actually, from the very beginning, the idea was not only to consider GC Wizard as a standalone app, but also to give third-parties the possibility to access the numerous internal tools. How would it be if you could tell a website: “Please decode the marked text from GC Wizard right now!“; or if apps like c:geo could immediately solve the code in the listing?

One way would be that the apps implement their own tool collections or to wait for the umpteenth programmer to program ROT-13 for the hundredth time, this time specifically for that website. The GC Wizard was always meant as a community project. And with that not only the free of costs or the Open Source thing is meant, but also, the usage by third-parties. But the way to get there turned out to be much more difficult than I expected at the beginning.

Linking Apps

There are numerous discussions on various platforms where we already examined how we could communicate directly with apps like c:geo. In the past, it wouldn’t have been that complicated, but over the years, Google and Apple have made a simple way to communicate more and more difficult for security reasons. There are still ways to let two Android apps interact with each other, but GC Wizard is not a classic Android app. The GC Wizard is based on a technology that supports Android and iOS (and of course web somehow), which thus, roughly speaking, puts itself in front of the operating system as a kind of intermediate layer. This makes everything much more complicated. Now, you could say that you just write a channel for Android and one for iOS separately, but we neither have the time nor the appropriate iOS know-how to do that.

The way we’re now examining is to make the web version more capable so that third-parties will not ask our app but our website for help.

Deep Links

Well, most of you will have noticed that the web version has especially problems when you want to access specific tools directly. It simply lacks the possibility to directly access such a tool via URL in the browser. If you can’t do that as a normal human user, how could the developer of an app do it?

Thus, the first step is to finally introduce the so-called Deep Links, the URLs for specific functions. We haven’t done it so far because it seemed very complicated to us to implement them afterwards. Above all, it meant that we had to touch every single tool directly, which simply no one wanted to do because of their sheer number.

However, Mike has now found a way to automate this work more or less in the code and was able to come up with a test version a few days ago that allows direct control of the individual functions.

Web API

Now it is possible to call the tool from any place, an app or another website, with one click, assuming the URL for the corresponding tool is known. An installation of the app is (although of course desired ) not even necessary. However, of course, then an Internet access will be. Unfortunately, this is a possible disadvantage.

The next step is that the code to be decrypted is also transferred at the same time, so that you don’t have to manually enter the text in the field after a web page call of the GC Wizard.

Using so-called Query Parameters, this step is also already done. Everything that the corresponding tool needs to work can be entered into the URL. However, a lot of manual work actually has to be done here. Each GC Wizard tool is very different in its function. Each tool needs different options and parameters. Thus, unfortunately, little can be automated here. That’s why we decided to start with a limited set of tools and then expand step by step as needed.

So, now it is possible to access the GC Wizard web page directly from the outside with the desired tool, populate it with values and display the result. After this step, we have left the original app and are staring at a browser. This is rather unattractive for the usability of the original app, because a) you don’t see the result directly in this app and b) the user is forced to switch back and forth between browser and app. A really nice interface should actually hide the way the information is obtained. Click – and there is the decrypted text. The fact that internally the GC Wizard was asked for help should actually remain invisible to the user. Even though we somehow deprive ourselves of our own glory, admittedly

So the final step is to offer an interface that, when called, simply performs the calculation and sends the data – instead of displaying it on its own website – directly back to the third-party tool. This would then be a real web interface, a so-called API.

First tests by Mike look promising. Whether version 3.0 has the maturity for it, we will see, but surely we are on a very good way!

First customers for such an interface are already in the starting blocks. For example, @capoaira has already started many months ago building a Firefox plugin that allows to directly access the GC Wizard from any website. I am very curious myself how this will turn out!

The last version is a version 2.x. Apart from possible urgently needed bugfix releases – let’s hope that won’t be necessary – there won’t be another version 2.

A version change in the so-called major version usually only occurs when there is a very fundamental change to the software product. With the version change from 1 to 2, for example, completely new functionality was added with the file functions, which required, among other things, the additional permissions to the file system access on your devices.

After more than three years of more or less uninterrupted development, the GC Wizard has become much bigger and more complex than it could even have been dreamed of at the beginning. The steadily growing complexity also led to many problems in the internal development. So it is now time to take the underlying code base and critically review it. Is the structure and approaches chosen at that time still appropriate concerning the today’s project? And can it still support further potential growth?

Software Architecture

Decisions about the structure of code and the programming principles can – roughly speaking – be described as Software Architecture. The decisions that led to the current architecture were based on assumptions of much less supported tools and also the pessimistic view that no one but me would ever really work on the project permanently. Now, thanks to Thomas and Mike, I’ve been proven wrong, and on the other hand, I’ve had to realize that the decisions I made back then no longer meet today’s requirements.

We have many places where the code base no longer meets the requirements of clean code. The most serious part is the current Technical Layering. This means that I had originally decided to strictly separate calculation logic and output entirely, i.e. the representation in the app, which is a as classical approach in the theory of software architecture. This leads to writing the code for the logic of a concrete tool into one directory and the code for the presentation into a directory in a completely different path. This works well as long as one thinks in small scales.

But by now, in addition to program logic and displays, we have translation files, files for searching, the registry for the main menu, and more. So a new tool, as small and simple as it may be, immediately spreads all over the entire project, which now has over a thousand folders. So it’s increasingly hard to keep track of which part belongs to a certain tool and where you would find it.

The solution is a so-called Domain Layering. Here, the technical view “calculation logic vs. output” does not take precedence, instead it is tried to keep all parts of a specific tool, a closed domain, together. After that, you can think about how to do the technical layering – just on a smaller scale, exclusively at the tool level and not project-wide. This makes it easier for us to get an overview and also simplifies the entry for potential future co-developers.

The Steps

First, of course, a lot of files and directories have to be rearranged. Here we can rely a little on the support of our development environment, but there is still a lot of manual work to do within such a complex construct.

After that, it should also be checked whether certain files can be merged or should be separated. Do they still fit into the context in which they were introduced earlier? In the worst case, this leads to a manual review and check of all files.

We have two files, which are several thousand lines long – much too long to still master them as a human being – because we register all our tools there, i.e. for the main menu. The goal is to create a possibility, where also here on the one hand the complexity of these files is reduced, but on the other hand also the here likewise existing spreading of the tools further to reduce (the file for the main menu is naturally not to be found somewhere at a certain tool, but is a further point somewhere in the code). This possibility is called Reflection, which is common in the area of other programming languages, like Java, but is not easy to realize in our Dart-based system. It will technically work, but in some circumstances this could give significant speed penalty on app launching. However, we can only try this out. And if the worst comes to the worst, we will have to look for a compromise.

Conclusion

Currently, the largest internal rebuild that the project has seen so far is taking place. Many things have to be considered and in the end everything should remain the same for the user. The user does not benefit from a change of the version number so far, but for us as programmers this Sisyphos work is a huge step to make the project more future-proof.

But of course, from the user’s point of view, a lot of things will happen after the rebuild and great things are in the offing. More about that later