The reason for writing this post was the article
"Mathcad Express - a free math editor about which few people know .
"I liked the discussion around this article. However, I am more interested in a slightly different aspect of the problem being discussed, namely: is a computer algebra system needed on a smartphone or tablet, or is it such a strange cockroach in the head of a near-engineer engineer?
Formulation of the problem
As you know, the life of a simple programmer is hard and unsightly. About a year ago, when I realized the computational capabilities of my china phone with four cores on the Android platform, I wanted to shake my scientific antiquity and count something on the phone. Play-market can do everything, it was thought then.
There were no special restrictions, for my scientific career I managed to use both Mathcad with MATLAB, and Mathematics, and FEM-systems (Ansys). Therefore, to begin to look everything.
')
Such a picture has taken shape (I will not provide links; those who wish can easily find it on the Play Market):
- Matlab Mobile, as an extension of the licensed copy of the desktop version. I did not have one at home, so, unfortunately, this option has disappeared;
- The Wolfram Alpha service and a cloud of tutorials from the Wolfram Group are not exactly what I associate with the words “calculate on my own”;
- The Matlab and Octave clones for Android are already warmer, but writing code on a 5-inch screen is not very convenient;
- A huge number of scientific calculators of varying degrees of sophistication. They all have one thing in common - the input and presentation of results are organized as in a classical (hardware) graphing calculator. The main disadvantage of such an idea is the absence of a “document” that can be saved, changed and recounted again and again;
- Nothing that looked like a Matkad could then be found.
Why am I here and at the beginning of the post mentioned Mathcad? In my opinion, this idea fits well with the tasks of mobile mathematics:
- On a small device screen with a finger-oriented interface, it’s still more convenient to work with a formula if it is written in a natural mathematical form, and not as a code in a scripting language;
- A mobile device is well suited to try something quickly. Therefore, a convenient interface is required from the mobile mathematical system, but no serious computational capabilities are required;
- Ideally, in such a system, I need a PR feature. That is, not only to quickly write down a complex formula and build a couple of graphs, but it is also convenient to publish it in all your social networks. The formulas in the natural mathematical notation here are also more convenient than the script.
That is, I would love to install Mathcad mobile on my smartphone. But there was no such thing (in the sense of “Matkad”, but not a smartphone) on the Play-market. Hence the idea to develop something like this on your own.
Task statement
So, I decided to write from scratch an Android application designed to create and work with mathematical calculated documents.
I formulated the requirements for the application as follows:
- The widest possible coverage of supported devices. Hence the minimum API level 8;
- Support for screens of various resolutions and landscape / portrait orientation;
- Document storage format - custom based on XML;
- Detailed documentation. In order not to produce entities, the same format in which the documents themselves are stored is used for documentation;
- To create printed documentation, provide for export to LaTeX, since it is convenient for writing formulas and makes it possible to generate PDF;
- Math is limitless. Do not implement everything. Therefore, the initial functional includes functions of several variables, graphics (2D and 3D), numerical integration and differentiation, a logical operator. Further, depending on the user likes;
- The ability to insert text and images, but the text editing functionality for a start is minimal;
- Convenience and quality take precedence over functionality;
- Languages ​​are only those that I know myself and can develop and maintain without recourse to a translator.
And, probably, the most important thing. This is a hobby. Therefore, it is important to remain realistic and not aim at the fact that it is impossible for one person to realize at a reasonable time in the mode of 5-6 days a week for 2 hours.
Since the project received the status of "favorite hobby for the next year," then there are two important consequences:
- I decided not to limit myself to reasonable expenses for equipment / promotion / services, if any;
- Goals such as “Earn at any cost” and “Be at the top” are not set, so I decided not to add ads to applications and refuse to promote through motivated downloads.
At the same time, I am opposed to complete freebies. Therefore, I chose the following monetization model:
- The application itself is paid and is distributed only through the Play-market;
- There is a free version with an identical appearance and interface, but with a stripped down math. Moreover, this functionality is not deactivated, but is missing at the code level. That is, the free version cannot be physically switched to full mode and it is distributed wherever possible.
This model is easily implemented using a version control system (in my case, SVN), where the main branch is intended for experiments and development, and two subsidiaries are for the releases of the paid and free versions, respectively.
At this point, you can draw a line under the input data and start discussing the implementation.
Solution Method
In my opinion, the most important question is how to organize on a smartphone the input and editing of formulas that can be calculated (for a start, only numerically), but at the same time they are presented in a natural mathematical form? How to combine from these formulas, graphs, text and images loaded from a file a single document capable of self-calculation?
Many of you have probably used the Word's formula editor. On the big screen, but with a keyboard and mouse at hand, everything is very simple. You can see various mathematical palettes on the screen (or are easily accessible from the menu), the mouse is positioned with the mouse, and then the desired character is entered either from the keyboard or with the mouse. Part of the formula can be easily selected with the mouse, copied, replaced or dragged to another location. The formulas themselves as floating objects can be dragged with the mouse to any part of the document. Familiar, yes?
And now the same thing on the touch screen, without a mouse, without a hardware keyboard, where does the virtual keyboard cover a third (half of the landscape orientation) of the screen?
I'll start with the layout of the objects in the document. There are actually not very many options:
- Each object has its own coordinates and objects can be positioned relative to each other arbitrarily, as in a vector graphics editor. This option is implemented in the Matkad itself. Under Android, you can use outdated AbsoluteLayout for this, but you must also implement the alignment / distribution of objects and groups of objects. That is, in this embodiment, an additional user interface is needed that is not related to the main task. For a desktop computer, this is not critical, but the usability of a mobile application, in my opinion, will be worse;
- Location in the cells of the table, as in MS Excel. I dismissed this option immediately, since the math document is anything but a table;
- A simple list where each object is in its own line. This is how most scientific calculators work. This is what I implemented in the first version of the application. Cheap and angry. He received quite reasonable comments from users that such a method is very inconvenient, since there is an objective need to group some formulas in rows;
- The result is a simplified version of RelativeLayout, a sort of two-dimensional list where, by default, objects are added vertically (from the bottom of the selected object), but with a single window you can add an object both to the right and to the left of the selected one:

So far I have abandoned the mode of capturing and dragging objects while moving a finger across the screen, since such an interface in the case of a two-dimensional list requires some work. Instead, the possibility of group selection of objects and group operations through the context menu is implemented: deleting, copying to the buffer and replacing the selected object with the contents from the buffer.
The next question is related to the input of information. Many calculators have their own virtual math keyboard for this. To me, this approach does not seem optimal. For example, I myself use a tablet with an external USB keyboard, and in this case it has a landscape orientation. To roll out a virtual keyboard in such a situation, which takes up half of the screen, is not entirely logical. Therefore, I initially aimed at the fact that the application will work with a standard system keyboard and not require special keyboard extensions. That is, absolutely all mathematical symbols can be entered as a code from the keyboard, and this idea is again borrowed from Matkad. To enter Greek characters, I simply added Greek to the keyboard layouts.
However, forcing the user to memorize all the codes is not a good idea. Therefore, at the bottom of the screen, regardless of orientation, there is a second toolbar, in design and size identical to the top main one. All mathematical symbols, of which there are now about 50, are located in one line on this panel, and it scrolls to the right and left. With a short press, the character is entered. With a long press on the symbol, a hint pops up that is and which code corresponds to it:

In support of this idea, I want to quote the feedback of one of the users: "it makes the app perfect".
And where are codes or characters entered? Here again, everything looks like a Matkad. When adding an object, empty input fields appear. You can enter text, numbers or symbols into them. When you enter, for example, a division symbol, a fraction with two fields appears in one of the input fields, one of which will include the text entered earlier in the deleted field. This is the main input mode, which is good when you know the exact sequence of typing the desired formula:

And if you do not know or need to change something in the formula? Context menu to help. It is activated by long pressing on the part of the formula and provides access to the clipboard. In addition, there is a button to expand the selection area. From the bottom toolbar, you can enter a symbol that will be applied to the selected block:

It turned out a kind of cooperation. The user, entering the formula in such a way, does the main work on its syntactic analysis. And the application in gratitude for this formula will calculate.
Thus, each formula has two aspects:
- First, it is a hierarchy of nested layouts, which contain both input fields and mathematical notation. Visually, this is the usual formula.

- Secondly, it is the hierarchical structure of primitive mathematical tokens, each of which is able to be calculated. Each token is associated with its corresponding layout and is its owner.
Underwater rocks
And here a serious ambush was waiting for me. De facto, Android has a limit on the number of nested layouts related to the size of the procedure call stack. In this case, the compiler will not say anything, but during operation (in the android.view.View.draw method of one of the nested layouts), the application crashes with the exception of StackOverflowErrors. Read more about it
here .
To catch this exception is real, since I have my own implementation of the onDraw () method at the very beginning of this call chain, but at the same time, starting with a certain complexity of the formula, it will simply cease to be drawn. I had to manually control the depth of attachments of the elements of the formula, and, starting from a certain critical depth (selected experimentally), give an unsympathetic, but still necessary message “Unfortunately, the formula depth limit for this version of Android has been reached”.
Experimentally, I picked up the following values ​​of the maximum depth, counting from the root RelativeLayout fragment:
- if API level <15 (Android 2.2.x - 4.0.x), then the maximum depth is 7 nested levels of layouts;
- if API level is from 15 to 17 (4.1.x - 4.2.x), then 9 levels;
- if API level> 17 (4.3.x and higher), then 15 levels.
The second problem is the lack of a standard component that would combine horizontal-vertical scrolling and scaling. These actions seem to be supported by WebView, but WebView itself doesn't suit me at all. The solution is clumsy, but it works - I took the sources of the standard ScrollView and HorizontalScrollView, combined them into one component and screwed in the detection and processing of zoom. What I still could not bring to mind is the correct positioning in the document after a change in scale.
Documentation and localization
Reading the user reviews on the Play Store about various scientific calculators, I found that one of the weak points of most calculators is the lack of documentation. Sometimes full. Therefore, I decided to give the documentation a lot of attention. And I added it both to the application itself (the NavigationDraver sidebar turned out to be convenient for this purpose) and uploaded it to the network as a PDF and added links to the application for direct download to the application.


In the application, the documentation sections are stored in XML and opened as separate frames. There is a function to convert the document to LaTeX. The pdfletx utility in the workplace completes the job. The result is not ashamed to put on
public display .
Now a few words about localization. The development of the old habit is conducted in English. When the program is compiled and launched (that is, ready for sale), the interface and documentation of the newly added chips are translated into two other languages, one of which is Russian.
And here I was pleasantly surprised by the download statistics in the developer console. Mathematics in RuNet honored! By the way, I did not release the Russian version right away, but when the number of downloads approached a thousand. But it practically did not increase the already high percentage of downloads from Russia and neighboring countries. At the moment, the distribution of downloads for the
free version by languages ​​and countries looks like this:


That is, Russia, Ukraine and Kazakhstan together provide more than 40% of downloads. The paid version gives a different picture: downloads from Russia dominate only with a slight margin.
Conclusion
Well, a lot has already been written, it’s time to go round. From a computational point of view, many of the necessary things have not yet been realized: there are no complex numbers, there is no support for arrays, there is not even primitive matrix arithmetic, there is no solution of equations. But then a reasonable question arises - is it necessary on the phone? It is interesting to hear the opinion of a respected audience.
As for the immediate tasks, while the basic wishes of users relate to increasing export opportunities. For example, one of the last comments: “Interested in such a question, is there any way to link a document with a match? That would be an opportunity to finalize the document on the PC. Regarding Matkad, I personally doubt it, since the format is proprietary, but such things as exporting to HTML (just today I found the
MathJax framework), to PDF, or some open office format can be implemented.
At this I want to thank for the attention of all who read to the end, and with a sense of accomplishment, to bow out. I will be glad to questions, if any.