February 16, 2015 at 17:19DIY math package for Android
The reason for writing this post was the article "Mathcad Express - a free mathematical editor about which few people know . "
I liked the discussion surrounding this article. However, I’m more interested in a slightly different aspect of the problem being discussed, namely: do I need a computer algebra system on a smartphone or tablet, or is it such a strange cockroach in the head of a near-engineer engineer?
As you know, the life of a simple programmer is hard and plain. 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. The play market can do anything, I thought then.
There were no special restrictions; during my scientific career I managed to use Mathcad with MATLAB, Mathematics, and FEM systems (Ansys). Therefore, for a start, I began to look at everything.
There was such a picture (I will not provide links, anyone who wants can easily find it on the Play store):
Why did I mention Mathcad here and at the beginning of the post? In my opinion, this idea fits well with the tasks of mobile mathematics:
That is, I would love to install Mathcad mobile on my smartphone. But here it is (in the sense of "Matkada", and not a smartphone) on the Play Market and was not there. From here the idea was born to develop something similar independently.
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:
And, probably, the most important thing. This is a hobby. Therefore, it is important to remain realistic and not to aim at the fact that it is impossible to realize one person in 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 coming year," there are two important consequences:
At the same time, I am opposed to a complete freebie. Therefore, I chose the following monetization model:
Such a model is easily implemented using a version control system (in my case, SVN), where the main branch is for experimentation and development, and two children are for releases of the paid and free versions, respectively.
On this, you can draw a line under the input data and start discussing the implementation.
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 compose a single document capable of self-calculation from these formulas, graphs, text and images downloaded from a file?
Many of you probably used the WordPress formula editor. On the big screen, and with a keyboard and mouse at hand, everything is very simple. Various mathematical palettes are visible on the screen (or are easily accessible from the menu), the cursor is positioned with the mouse, and then the desired character is entered either from the keyboard or with the mouse from the palette. 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. It’s 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 (in landscape orientation half) of the screen?
I'll start by arranging the objects in the document. In fact, there are not many options:
So far I have refused the mode of capturing and dragging objects when I move my finger across the screen, since such an interface in the case of a two-dimensional list requires some study. Instead, the possibility of group selection of objects and group operations via the context menu is implemented: deleting, copying to the buffer and replacing the selected object with contents from the buffer.
The next question is related to the input of information. Many calculators have their own virtual mathematical keyboard for this. To me, this approach does not seem optimal. For example, I myself use a tablet with an external USB keyboard, in which case it has a landscape orientation. Rolling out a virtual keyboard in such a situation, which occupies half the screen, is not entirely logical. Therefore, I initially aimed that the application will work with a standard system keyboard and do not require special keyboard extensions. That is, absolutely all mathematical symbols can be entered in the form of code from the keyboard, and this idea is again borrowed from Matkad. To enter Greek characters, I simply added Greek to my keyboard layouts.
However, forcing the user to remember all codes is not a good idea. Therefore, at the bottom of the screen, regardless of orientation, there is a second toolbar, identical in design and size to the top main one. All the mathematical symbols, of which there are now about 50, are located in one line on this panel, and it itself scrolls left and right. By short pressing the character is entered. With a long press on a symbol, a hint pops up that it and what code corresponds to it:
In support of this idea I want to quote a review of one of the users: “Beeing able to use shortcuts instead of symbolic buttons (but not beeing forced to do so) makes the app perfect ".
Where are the codes or symbols entered? Here again, everything looks like Matkad. When adding an object, empty input fields appear. You can enter text, numbers, or characters in them. When you enter, for example, a division symbol, a fraction with two fields appears instead of the input field, the text entered earlier in the deleted field will go to one of them. This is the main input mode, which is good when you know exactly the 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 clicking on 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 by this method, himself performs the main work on its parsing. And the application in gratitude for this formula will calculate.
Thus, each formula has two aspects:
And here a serious ambush awaited me. De facto, Android has a limit on the number of nested layouts associated with the size of the procedure call stack. The compiler in this case 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 the StackOverflowErrors type. Read more about it here .
It is real to catch this exception, since I have my own implementation of the onDraw () method at the very beginning of this chain of calls, but at the same time, starting from a certain complexity of the formula, it will simply stop being drawn. I had to manually control the depth of attachment of the elements of the formula, and, starting from a certain critical depth (experimentally selected), issue an unsympathetic, but nevertheless necessary message "Unfortunately, the limit for the depth of the formula for this version of Android has been reached."
Experimentally, I picked up the following values of the limiting depth, counting from the root RelativeLayout fragment:
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 does not suit me in any way. The solution is clumsy, but it works - I took the sources of the standard ScrollView and HorizontalScrollView, combined them into one component and screwed on the detection and processing of zooming. What I couldn’t bring to mind at the same time was the correct positioning in the document after zooming.
Reading user reviews on the Play Market about various scientific calculators, I found that one of the weaknesses of most calculators is the lack of documentation. Sometimes complete. Therefore, I decided to pay a lot of attention to the documentation. And he added it both to the application itself (the NavigationDraver side menu was convenient for this purpose), and posted it on the network as a PDF and added links for direct download to the application.
In the application, sections of the documentation 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. Development according to an old habit is conducted in English. When the program has compiled and started (that is, ready for sale), the interface and documentation of the newly added feature 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 is held in high esteem! By the way, I did not release the Russian version right away, but when the number of downloads approached a thousand. But this practically did not increase the already high percentage of downloads from Russia and neighboring countries. Currently, the distribution of downloads for the free version by language and country 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 with only a slight margin.
Well, a lot has already been written, it's time to round off. From a computational point of view, many 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, and there is no solution to equations. But here a reasonable question arises - is it necessary on the phone? It is interesting to hear the opinion of a reputable audience.
As for the immediate tasks, so far the main wishes of the users relate to increasing export opportunities. For example, one of the last comments: “Such a question interests me, is there any way to connect the document with matkad? That there would be an opportunity to finalize the document on the PC ". Regarding Matkad, I personally doubt it, since the format is proprietary, but things like exporting to HTML (literally today I discovered the MathJax framework), in PDF, or some open office format can be implemented.
On this I want to thank for the attention of everyone who read to the end, and with a sense of accomplishment to leave. I will be glad to questions, if any.
I liked the discussion surrounding this article. However, I’m more interested in a slightly different aspect of the problem being discussed, namely: do I need a computer algebra system 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 plain. 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. The play market can do anything, I thought then.
There were no special restrictions; during my scientific career I managed to use Mathcad with MATLAB, Mathematics, and FEM systems (Ansys). Therefore, for a start, I began to look at everything.
There was such a picture (I will not provide links, anyone who wants can easily find it on the Play store):
- Matlab Mobile, as an extension of a licensed copy of the desktop version. I didn’t have one at home, so this option, unfortunately, has disappeared;
- The Wolfram Alpha service and the cloud of trainers from the Wolfram Group are not quite what I associate with the words “calculate by yourself”;
- Clones of Matlaba and Octave for Android are already warm, 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 - input and presentation of the results are organized as in a classic (hardware) graphing calculator. The main disadvantage of such an idea is the lack of a “document” that can be saved, modified and recounted again and again;
- Nothing that would be like Matkad, then could not be found.
Why did I mention Mathcad here and at the beginning of the post? In my opinion, this idea fits well with the tasks of mobile mathematics:
- On a small screen of a device with a finger-oriented interface, it is still more convenient to work with a formula if it is written in a natural mathematical form, and not in the form of 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 serious computing capabilities are not required;
- Ideally, in such a system, I need the PR function. That is, not only quickly write down a complex formula and build a couple of graphs, but it’s also convenient to publish it on all your social networks. Formulas in natural mathematical notation are also more convenient here than a script.
That is, I would love to install Mathcad mobile on my smartphone. But here it is (in the sense of "Matkada", and not a smartphone) on the Play Market and was not there. From here the idea was born to develop something similar independently.
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 - own based on XML;
- Detailed documentation. In order not to produce entities, the same format is used for documentation in which the documents themselves are stored;
- To create printed documentation, provide export to LaTeX, as it is convenient for writing formulas and makes it possible to generate PDF;
- The math is limitless. All does not implement. Therefore, the initial functional includes the functions of many variables, graphics (2D and 3D), numerical integration and differentiation, a logical operator. Further, depending on the users' wishes;
- The ability to insert text and images, but the functionality of editing text to start is minimal;
- Ease of use and quality take precedence over functionality;
- Languages are only those that I know myself and can develop and support without resorting to a translator.
And, probably, the most important thing. This is a hobby. Therefore, it is important to remain realistic and not to aim at the fact that it is impossible to realize one person in 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 coming year," there are two important consequences:
- I decided not to limit myself to a reasonable spending on equipment / promotion / services, if any;
- Such goals as “Earn at any cost” and “Get in the top” are not set, so I decided not to add ads to applications and refuse promotion through motivated downloads.
At the same time, I am opposed to a complete freebie. 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 reduced mathematics. Moreover, this functionality is not deactivated, but absent at the code level. That is, the free version cannot be physically switched to full mode and it is distributed wherever possible.
Such a model is easily implemented using a version control system (in my case, SVN), where the main branch is for experimentation and development, and two children are for releases of the paid and free versions, respectively.
On this, 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 compose a single document capable of self-calculation from these formulas, graphs, text and images downloaded from a file?
Many of you probably used the WordPress formula editor. On the big screen, and with a keyboard and mouse at hand, everything is very simple. Various mathematical palettes are visible on the screen (or are easily accessible from the menu), the cursor is positioned with the mouse, and then the desired character is entered either from the keyboard or with the mouse from the palette. 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. It’s 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 (in landscape orientation half) of the screen?
I'll start by arranging the objects in the document. In fact, there are not 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 Matkad itself. Under Android, you can use the obsolete AbsoluteLayout for this, but you must implement the alignment / distribution of objects and groups of objects. That is, in this option, 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 the mobile application, in my opinion, will make it worse;
- The location in the table cells, as in MS Excel. I dismissed this option immediately, since a mathematical document is anything, but not a table;
- A simple list where each object in its own line. This is how most scientific calculators work. This is exactly what I implemented in the first version of the application. Cheap and cheerful. To which I 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 (at the bottom of the selected object), but with the help of a single window, you can add an object both to the right and to the left of the selected:
So far I have refused the mode of capturing and dragging objects when I move my finger across the screen, since such an interface in the case of a two-dimensional list requires some study. Instead, the possibility of group selection of objects and group operations via the context menu is implemented: deleting, copying to the buffer and replacing the selected object with contents from the buffer.
The next question is related to the input of information. Many calculators have their own virtual mathematical keyboard for this. To me, this approach does not seem optimal. For example, I myself use a tablet with an external USB keyboard, in which case it has a landscape orientation. Rolling out a virtual keyboard in such a situation, which occupies half the screen, is not entirely logical. Therefore, I initially aimed that the application will work with a standard system keyboard and do not require special keyboard extensions. That is, absolutely all mathematical symbols can be entered in the form of code from the keyboard, and this idea is again borrowed from Matkad. To enter Greek characters, I simply added Greek to my keyboard layouts.
However, forcing the user to remember all codes is not a good idea. Therefore, at the bottom of the screen, regardless of orientation, there is a second toolbar, identical in design and size to the top main one. All the mathematical symbols, of which there are now about 50, are located in one line on this panel, and it itself scrolls left and right. By short pressing the character is entered. With a long press on a symbol, a hint pops up that it and what code corresponds to it:
In support of this idea I want to quote a review of one of the users: “Beeing able to use shortcuts instead of symbolic buttons (but not beeing forced to do so) makes the app perfect ".
Where are the codes or symbols entered? Here again, everything looks like Matkad. When adding an object, empty input fields appear. You can enter text, numbers, or characters in them. When you enter, for example, a division symbol, a fraction with two fields appears instead of the input field, the text entered earlier in the deleted field will go to one of them. This is the main input mode, which is good when you know exactly the 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 clicking on 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 by this method, himself performs the main work on its parsing. And the application in gratitude for this formula will calculate.
Thus, each formula has two aspects:
- Firstly, it is a hierarchy of nested layouts that contain both input fields and mathematical notation. Visually, this is the usual formula.
- Secondly, this is the hierarchical structure of primitive mathematical tokens, each of which can be calculated. Each token is associated with its corresponding layout and is its owner.
Underwater rocks
And here a serious ambush awaited me. De facto, Android has a limit on the number of nested layouts associated with the size of the procedure call stack. The compiler in this case 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 the StackOverflowErrors type. Read more about it here .
It is real to catch this exception, since I have my own implementation of the onDraw () method at the very beginning of this chain of calls, but at the same time, starting from a certain complexity of the formula, it will simply stop being drawn. I had to manually control the depth of attachment of the elements of the formula, and, starting from a certain critical depth (experimentally selected), issue an unsympathetic, but nevertheless necessary message "Unfortunately, the limit for the depth of the formula for this version of Android has been reached."
Experimentally, I picked up the following values of the limiting 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 lightouts;
- if the 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 does not suit me in any way. The solution is clumsy, but it works - I took the sources of the standard ScrollView and HorizontalScrollView, combined them into one component and screwed on the detection and processing of zooming. What I couldn’t bring to mind at the same time was the correct positioning in the document after zooming.
Documentation and Localization
Reading user reviews on the Play Market about various scientific calculators, I found that one of the weaknesses of most calculators is the lack of documentation. Sometimes complete. Therefore, I decided to pay a lot of attention to the documentation. And he added it both to the application itself (the NavigationDraver side menu was convenient for this purpose), and posted it on the network as a PDF and added links for direct download to the application.
In the application, sections of the documentation 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. Development according to an old habit is conducted in English. When the program has compiled and started (that is, ready for sale), the interface and documentation of the newly added feature 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 is held in high esteem! By the way, I did not release the Russian version right away, but when the number of downloads approached a thousand. But this practically did not increase the already high percentage of downloads from Russia and neighboring countries. Currently, the distribution of downloads for the free version by language and country 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 with only a slight margin.
Conclusion
Well, a lot has already been written, it's time to round off. From a computational point of view, many 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, and there is no solution to equations. But here a reasonable question arises - is it necessary on the phone? It is interesting to hear the opinion of a reputable audience.
As for the immediate tasks, so far the main wishes of the users relate to increasing export opportunities. For example, one of the last comments: “Such a question interests me, is there any way to connect the document with matkad? That there would be an opportunity to finalize the document on the PC ". Regarding Matkad, I personally doubt it, since the format is proprietary, but things like exporting to HTML (literally today I discovered the MathJax framework), in PDF, or some open office format can be implemented.
On this I want to thank for the attention of everyone who read to the end, and with a sense of accomplishment to leave. I will be glad to questions, if any.