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.
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.
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.
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.
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!