Ладно интерфейс - это вопрос решаемый. Хотя автор тут уже, по-моему, неоднократно говорил о проблеме перегруженности интерфейса. Правда, возникает вопрос - каким по форме и размеру делать поле для формулы на экране? Таким как примечание? Но тут уже некоторые жаловались на то, что примечание не полностью видно. Но это примечание, Бог с ним, не критично, а вот если виден только кусочек формулы, то какая от такой формулы польза? Да и неудобно пользоваться, на мой взгляд. Тогда что, делать поле для формулы на экране достаточно большим? Насколько большим? В приведённом выше "коммунальном" примере всего-то 3 переменных, 2 скобки и 2 знака арифметических операций, а длина формулы получилась - ого-го. На какую длину формулы нужно расчитывать? Естествнно, на произвольную (как примечание). Но где размещать поле с формулой произвольной длины? Если в том же поле, что и сумма с дополнительной кнопкой переключения - будет полностью не видна большая формула. Если в отдельном поле - опять приходим к проблеме перегруженности интерфейса.
Что ещё? Ну ещё добавить нужно внутрь базы новое поле для формулы... Поле произвольной длины, как примечание. При этом размер базы данных увеличится... Я, кстати, всегда, когда "рекламирую" AbilityCash своим знакомым, в качестве большого плюса говорю об очень компактной по размеру базе данных. Остаётся надеяться, что реализация формул не приведёт к разрастанию базы.
Кстати, добавление нового поля в сущестующую базу данных - это дополнительные трудозатраты разработчика на реализацию корректного перехода на новую версию. Ну чтобы в уже существующих операциях не попортить что-нибудь. А это время. И верятность ошибок. И опять время на их исправление.
А как быть с функциями? Например, с округлением? Где гарантия, что в жизни реальные суммы всегда получаются по правилам математического округления? Пример, та же коммуналка. По тарифам суммы получаются с копейками (а есть у нас такие тарифы, что и с десятыми долями копеек). Но когда приходишь платить в банк, то там или недодают сдачу, или "прощают" отсутствие мелочи. Вот такое округление. А однажды у меня был случай, когда "зарплатный" банк вдруг в банкоматах перестал проводить операции платежей с копейками. Только в целых рублях. В другой раз вдруг перестали проводить операции оплаты мобильной связи на суммы менее 10 руб.
Так вот это я к чему. Даже простейшая функция округления в чистом виде не всегда даст результат, совпадающий с реальным. Значит, пользователю в свою формулу нужно будет добавлять некую дельту. Ну и зачем мне такая формула, которая даёт приблизительный результат? Лично мне - незачем.
Далее. Округление - это как бы "внутренняя" функция. Оно должно выполнятся автоматически при подсчёте результата формулы, пользователь не должен ничего добавлять в свою формулу, чтобы произошло округление полученной суммы до 2 знаков после запятой. Но даже здесь возможны варианты. Можно округлять при выполнении каждого действия, а можно округлять только конечный результат вычислений. И суммы при этом зачастую получаются разные. Каким способом делать округление - решать разработчику. Но удовлетворит ли выбранный им вариант всех пользователей - неизвестно. При этом нужно помнить, что, например, курсы валют имеют не 2, а 4 знака после запятой.
Ну, а потом (есть у меня какое-то нехорошее предчувствие) кто-нибудь захочет, чтобы в формулах можно было использовать какие-нибудь дополнительные готовые функции
В общем, если автор всё-таки нацелился на реализацию ввода и использования формул в операциях, будет очень интересно посмотреть, как это в конце концов реализуется. И пожелать успеха.
А вообще, пока писала, поняла, что за 2,5 года пользования AbilityCash настолько сроднилась с программой, что "болею" за неё, как за свою
, б. методику банка. Если сделать, чтобы она считала тупо % на последний день месяца и это не будет соответствовать реальной сумме на счете в банке - мне такая автоматизация не нужна.