Tuesday, January 29, 2019

A Significant Step Towards Creating an APP

This Version 54 of toraware is my first real attempt at creating toraware.com's website to run as a mobile app.

The main problem all along had been my original option for the gematria method, where I allowed the user to choose between keyboard textual input -- or numerical input. This option is the last of the 3 option sets of the Options Page for the Gematria Method.

Although from the very beginning of my development I foresaw adapting my website to be suitable for an app, as you can see with the way I created navigation to be with my own inserted buttons (instead of navigating with the browser's buttons), the way I navigate from page to page with the press of a button, as if the thumb holding the gadget would had easy access, the way the whole appearance of the website looks like, looking much like an app running on a website, so I had always been close enough to modeling an app as a website. But there was always this gnawing problem I couldn't easily bypass, until I got the idea recently how to go about it.

In other words, not having good foresight yet, I created a pop-up keyboard feature that would be intrusive to the user of a mobile gadget should suddenly his screen pop up with a 2nd keyboard, let alone the ugliness that display would manifest. So I had to go back to my code to fix this problem.

Here are two screen shots to show this option's two different displays, as they appear in version 53, depending on the 3rd option set's radiobutton selection (the one with the legend that reads, "How will you enter the value?"):

User can enter a number directly
Keyboard pops up on this option

If I wanted to port my code into an app, this radiobutton option of entering a value into a numeric field, or by means of keying in letters into a text field, presented a problem. Why? Because if this were on your iPhone or Android device, my website's keyboard would pop up on the gadget's display, this even though the gadget itself already has a built-in keyboard and entry field. I had to eliminate this option because on a gadget, two input keyboards would be a horrible design dilemma.

Then I realized I could eliminate this problem simply by suppressing all keyboard display on my part, leaving the user only with one field of entry and the use of his own gadget's keyboard, and all I had to do was identify - in the program's code itself, whether the input was numeric or textual, if gematria was the method used.

Once this gematria methodology was changed, all methods shared investigation of the same single input field. This allowed me to simply suppress the display of the keyboard altogether. This keyboard feature of toraware.com was old baggage I carried since toraware's early development - when not all keyboards were easily switchable to Hebrew language input. Today every mobile has its input facility, and today's computers easily toggle to Hebrew keyboard input, so the user on my website no longer needs to peck at my original primitive keyboard for input.

This involved many changes in the code. Most files had to be modified. Many fontawesone icons were also removed. The keyboard of course was removed. Gematria input could all be done by the use of one input field; If a number is encountered, or whether it's a string of letters the user enters, the code itself detects whether it's a number or Hebrew text.

Here's how the new Options Page for the Gematria Method looks like now. Note that the 3rd set of options on this page no longer exists.

User can now enter EITHER text OR a number in the same field
Now, with this significant change in place, I think app creation will be rather a simple chore. Certainly much simpler than before! The simplification saved more than 20K bytes as well.

Inasmuch as this version is to expedite navigation to a working app, the previous version remains the version in production.