Cashew | Программа управления личными финансами (доходы, расходы)



Реп: (17)
Cashew
версия: 1.0.6

Последнее обновление программы в шапке: 10.03.2010

Прикрепленное изображение Прикрепленное изображение Прикрепленное изображение

Описание:
Первая программа для управления личными финансами платформы Google Android. Имея дружественный и интуитивный пользовательский интерфейс, Cashew дает вам возможность отслеживать свои доходы и расходы без знания бухгалтерии (описание с сайта разработчика, перевод мой).
  • Поддерживает неограниченное количество счетов
  • Удобный ввод и фильтрация транзакций
  • Мощный движок дает возможность создавать множество отчетов пользователя
  • Иерархические категории
  • Поддержка множества валют


В общем, рекомендую. Глюки не обнаружены.


Домашняя страница: http://cashewmobile.com
Cyrket: http://www.cyrket.com/p/android/com.cashew/
Androlib: http://www.androlib.com/android.applicatio...ashew-pwqi.aspx


Скачать:
Версия 1.0.6 http://4pda.to/forum/dl/post/440484/Cashew_1.0.6.apk
Версия 1.0.5.62 Прикрепленный файлCashew_1.0.5.62.apk ( 366.21 КБ )


Сообщение отредактировал freemsk1 - 10.03.10, 20:27
Причина редактирования: добавил новую версию



Реп: (0)
интересненько. на телефоне такую программулину иметь давно хотел.



Реп: (83)
предпочитаю EasyMoney , разработчик отечественный)



Реп: (42)
А я – Financisto. Тоже наш разработчик, есть активный баг-трекер.



Реп: (0)
сейчас попробовал все три. самая удобная для меня Financisto.



Реп: (1)
Доброго времени суток!

С позволения топикстартера воспользуюсь уже существующей темой, чтобы не создавать новую.

Я представляю команду, которая разрабатывает Cashew. С удовольствием выслушаем комментарии, пожелания и конструктивную критику. :)

Cashew 1.0.6 доступна на Android Market, альтернативных market place'ах и нашем сайте.

В данном релизе добавлена поддержка устройств с маленьким разрешением экрана, таких как HTC Tattoo (320x240).



Реп: (1082)
v1.0.6 Прикрепленный файлCashew_1.0.6.apk ( 366.3 КБ )



Реп: (17)
У меня сейчас установлены две программы: Cashew и Financisto. Но пользуюсь пока третьей - старой доброй SpbFinance (под winMobile), т.к. в ней намного удобнее реализованы функции ввода новых транзакций. Обе программы под Android имеют примерно равную для меня ценность (хоть в Financisto иконки красивее ;) ) и мне сложно выбрать одну из них.

Однако повторю то, что я писал про Financisto - это в полной мере относится и к Cashew:
Однако, SPB Finance имеет более удобный интерфейс для ввода новых транзакций. Например, названия транзакций сохраняются и при вводе новой транзакции иожно выбрать из списка (причем список фильтруется после ввода каждой буквы). Например, ввожу букву П, и список позиционируется на "Парикмахерская", "Продукты" и одним кликом можно выбрать нужное. Ведь названия покупок на 90 процентов повторяются...

Кроме того, в SPB Finance категория подставляется автоматически после выбора названия транзакции из списка.

В общем, развиваться этой программе еще есть куда.

В общем, если нужно подробнее, то могу расписать со скриншотами. Главное удобство - поле "название" ("получатель") стоит первым в форме ввода (значения можно вводить, но можно и выбирать из списка), и к нему автоматически заполняются остальные реквизиты - категория, проект, даже сумма (дата и примечание не заполняются). Значения для заполнения берутся из последней транзакции к таким же названием (получателем) (пример: каждый день хожу пить кофе, ввожу "Ко", подтверждаю в списке "Кофе" и опа - все поля уже заполнены, включая сумму и категорию, осталось кликнуть на Ok). Несколько кликов - и транзакция готова. Особенно актуально для тех, кому трудно попадать по кнопкам виртуальной клавиатуры...

Вот этого мне не хватает...
Спасибо за внимание.

Прикрепленные изображения
Прикрепленное изображениеПрикрепленное изображение



Реп: (1)
TaciturnMan

В общих чертах, суть пожелания я уловил. У нас изначально была дискуссия на тему организации ввода значений, который выбираются из списка. Решили остановиться на том варианте, который есть сейчас. Есть несколько идей, как можно было бы улучшить. Хотя они возможно идут вразрез с пожеланием, так как в идеале, хотелось бы не прибегать к помощи виртуальной клавиатуры (по крайней мере стандартной). К сожалению, в TODO листе изыскания по поводу usability стоят не очень высоко, так как достаточно запросов по функциональным требованиям, но хочется верить, что мы до них когда-то дойдем.

По поводу use case'а с кофе, предложу попробовать функцию Copy transaction (длинное нажатие на транзакции вызывает контекстное меню, где доступна эта функция, так же она доступна в основном меню экрана Transaction details view). В результате выполнения данной команды отображается форма ввода информации о транзакции, со всеми значениями исходной, кроме даты. Дата подставляется по тем же правилам, что и в случае с созданием новой транзакции:

- если сегодня новых транзакций не создавалось, то используется сегодняшняя дата.
- если транзакции сегодня создавались, то подставляется дата последней созданной транзакции (если я, например, сегодня решил ввести список всех транзакций за вчера, то чтобы каждый раз не переставлять дату на вчера).

Таким образом, выбирая вчерашнюю транзакцию и применяя к ней команду Copy transaction, я попадаю в форму где все поля заполнены значениями из вчерашней транзакции, а дата сегодняшняя, т.е. мне остается только нажать Done, чтобы добавить транзакцию в базу.

Это, конечно, частный случай, но для примера с кофе, кажется, вполне подходит. Я именно по такому принципу каждый день ввожу транзакции оплаты за стоянку/парковку автомобиля.

Вообще, если с английским проблем нет, то рекомендую

Cashew User's Manual (PDF, ~1M)

(хоть мы и старались, сделать Cashew максимально интуитивным) оттуда можно почерпнуть информацию, которая может быть не совсем очевидной при работе с приложением.



Реп: (9)
Русский давай! И мы с Вами!



Реп: (0)
Напоминаю Вам (писал на емайл) о проектах ;) ....... (с учетом расходной-и доходной категорий)......
Про русский - полностью подерживаю!!!! :yes2:



Реп: (41)
Про русский интерфейс уже писалось, просто +1
По удобству:
Когда заходишь в пункты "Accounts", "Register" и прочие слева сверху иконка нарисована.
Почему бы её не сделать кнопкой, "Создать новый ХХХХХ (Счёт, транзакцию)", а то так очень неудобно через контекстное меню, надо 2 нажатия, а через картинку - одно.
В настройках сделать возможность скрывать часть полей по транзакциям, к примеру, мне не нужно поле Number. (можно на каждый счёт свою настройку)
Думаю большинству для домашнего применения за глаза хватит Даты, Суммы, Категории и Описания.



Реп: (17)
Andriy Zakharchuk @ 11.3.10, 18:06 *
Таким образом, выбирая вчерашнюю транзакцию и применяя к ней команду Copy transaction, я попадаю в форму где все поля заполнены значениями из вчерашней транзакции, а дата сегодняшняя, т.е. мне остается только нажать Done, чтобы добавить транзакцию в базу.

Это, конечно, частный случай, но для примера с кофе, кажется, вполне подходит. Я именно по такому принципу каждый день ввожу транзакции оплаты за стоянку/парковку автомобиля.

Это спасет ситуацию только частично, ведь суть моего предложения была несколько другая: при вводе новых транзакций сделать упор на удобство ввода повторяющихся транзакций, так как их бывает значительно больше, чем совершенно новых...
Все варианты имеют право на жизнь, которая и покажет, какой был предпочтительней...
В любом случае, спасибо за ответ.



Реп: (1)
g-m @ 15.3.10, 7:10 *
Напоминаю Вам (писал на емайл) о проектах wink.gif ....... (с учетом расходной-и доходной категорий)......
Про русский - полностью подерживаю!!!!


Я помню :) Но, пожеланий много, рук, увы, мало. Поэтому добавление проектов, в среднесрочной перспективе. В 1.1, 1.2, 1.3 они точно не попадут. :(

Локализация задача попроще. Отдельную версию под нее делать не будем, будет просто небольшой релиз.


stanbel @ 15.3.10, 13:47 *
По удобству:
Когда заходишь в пункты "Accounts", "Register" и прочие слева сверху иконка нарисована.
Почему бы её не сделать кнопкой, "Создать новый ХХХХХ (Счёт, транзакцию)", а то так очень неудобно через контекстное меню, надо 2 нажатия, а через картинку - одно.

В общем, usability - это один из самых сложных моментов для нас. В отличии, от остальных мобильных платформ, Google не предоставил разработчикам каких-либо (полноценных) user interface guidelines. Это документ, который призван добиться единого стиля во всех приложениях.

Мы отталкивались от того, что имели на руках на момент разработки UI: G1 и SDK. Исходили из предположения, что организация пользовательского интерфейса должна соответствовать, другим подобным приложениям, чтобы у пользователя не возникало сложностей в работе. За основу решили взять приложения работающие с записями (БД) - Contacts/Calendar. Т.е. если пользователь каждый день работает с телефонной книгой (Contacts), то приложение, которое имеет сходную организацию интерфейса, не должно вызывать проблем в освоении.

Но тут появился HTC, с существенно переписанными Contacts/Calendar. Где уже не нужно лезть в меню для добавления записи, так как кнопка для добавления записи доступна сразу на экране, на котором отображается список.

Справедливости ради, нужно отметить что Google пытается делать какие-то шаги в эту сторону. Например, есть документ, который регламентирует как должны выглядеть различные иконки, чтобы добиться стилистического единства. И что забавно, иконки Nexus One идут вразрез с этими рекомендациями. Рекомендациям следуют G1/G2, модели от Samsung. HTC тоже нарисовали по своему. В декабре доводилось держать в руках Xperia (инженерный образец), там тоже все по-своему нарисовано, тоже переписаны приложения.

Таким образом перед Android-разработчиками, стоит достаточно сложная задача, сделать приложение, которое будет органично вписываться в устройства от разных производителей, и органично выглядит на фоне других приложений. Мы решили не делать каких-то телодвижений на эту тему, до тех пор пока не получим доступ к Xperia и Milestone. Посмотрим, что в окончательном варианте придумано там, а после этого будет решать, можно ли что-то сделать, чтобы сгладить углы.

В частности, использование иконки в левом верхнем, углу для добавления транзакций, с моей точки зрения не очень интуитивно, так как по опыту работы с Contacts, пользователь ожидает увидеть там Image Picker, и возможность поменять иконку. Кроме того, у нас есть более интересное решения для повышения удобства ввода.

stanbel @ 15.3.10, 13:47 *
В настройках сделать возможность скрывать часть полей по транзакциям, к примеру, мне не нужно поле Number. (можно на каждый счёт свою настройку)
Думаю большинству для домашнего применения за глаза хватит Даты, Суммы, Категории и Описания.


Это есть в TODO list'е. Голос учтен :)

TaciturnMan @ 15.3.10, 15:39 *
Это спасет ситуацию только частично, ведь суть моего предложения была несколько другая: при вводе новых транзакций сделать упор на удобство ввода повторяющихся транзакций, так как их бывает значительно больше, чем совершенно новых...

Я не настаиваю на том, что мой пример с парковкой, полноценная замена способу реализованному в SpbFinance. Просто, как по мне, достаточно подходящее решение для конкретной озвученной проблемы (с кофе).



Реп: (17)
Andriy Zakharchuk @ 16.3.10, 14:50 *
Я не настаиваю на том, что мой пример с парковкой, полноценная замена способу реализованному в SpbFinance. Просто, как по мне, достаточно подходящее решение для конкретной озвученной проблемы (с кофе).

Спасибо, Андрей. Буду ждать с нетерпением новых функций.

Покрутил на досуге две программы - Cashew и Financisto, и уже решил переходить на Cashew, да вовремя вспомнил об одной важной функции - резервном копировании... Как забекапить файл с данными? У кого есть root, тот, может, и найдет файл где-то в /data/... А всем остальным что делать? Видимо, придется делать rooting...

Подскажите, пожалуйста, есть ли в планах сделать функции backup/restore базы? Если только планируется, хотелось бы повлиять на выбор формата резервного файла. :) Например, в какой-нибудь xml-файл, чтобы из него можно было бы путем несложного xslt-преобразования получить документ для Excel для анализа на PC. Что-то подобное (хоть и корявенько) делает SpbFinance, вываливая все данные в xml-файл с таким заголовком :
<?xml version="1.0" ?>
<?mso-application progid="Excel.Sheet"?>
+ <Workbook xmlns="urn:schemas-microsoft-com:office:spreadsheet" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:html="http://www.w3.org/TR/REC-html40"> ...



Реп: (1)
TaciturnMan @ 25.3.10, 16:19 *
Как забекапить файл с данными? У кого есть root, тот, может, и найдет файл где-то в /data/... А всем остальным что делать? Видимо, придется делать rooting...


Для rooted устройства, могу даже дать ссылку на файл с .bat-скриптами, которые делают backup/restore :)

TaciturnMan @ 25.3.10, 16:19 *
Подскажите, пожалуйста, есть ли в планах сделать функции backup/restore базы?


На данный момент, в процессе разработки, будет добавлено в версии 1.1.

TaciturnMan @ 25.3.10, 16:19 *
Если только планируется, хотелось бы повлиять на выбор формата резервного файла. smile_good.gif Например, в какой-нибудь xml-файл, чтобы из него можно было бы путем несложного xslt-преобразования получить документ для Excel для анализа на PC. Что-то подобное (хоть и корявенько) делает SpbFinance, вываливая все данные в xml-файл с таким заголовком :


Оно уже есть XML файл, правда не OpenXML, и не ODF.

А XSLT трансформация - это отличная идея! Спасибо! :)

Сообщение отредактировал Andriy Zakharchuk - 25.03.10, 17:29



Реп: (17)
Andriy Zakharchuk @ 25.3.10, 14:28 *
Для rooted устройства, могу даже дать ссылку на файл с .bat-скриптами, которые делают backup/restore

Это было бы отлично! Скоро сделаю себе root (как раз кончился 2-х недельный испытательный период для аппарата :))

Andriy Zakharchuk @ 25.3.10, 14:28 *
Оно уже есть XML файл, правда не OpenXML, и не ODF.

Неужели данные не в SQLite? Я, как DBA, даже несколько разочарован... Это же так удобно! Люблю ковыряться в базах ;)
Очень интересно, а проверяли, как будет работать программа, если в базе хотя бы 3-5 тысяч транзакций? Не тормозит?



Реп: (1)
TaciturnMan @ 25.3.10, 18:14 *
Неужели данные не в SQLite? Я, как DBA, даже несколько разочарован... Это же так удобно! Люблю ковыряться в базах wink.gif


Нет, данные, конечно же, в SQLite. Я имел в виду, что при создании backup'а уже используется XML.

Понятно, что мы, как и все программисты, достаточно ленивы для того, чтобы не использовать встроенный движок. Так что SQLite при нас. Обратной стороной медали, оказалась группа пользователей, которая запросила шифрование БД. Вот с этим у встроенного движка проблемы. При том, что решения существуют, но в стандартной поставке их нет, и прикрутить на уровне приложния не видится возможным. В принципе, большинство довольны существующим вариантом, но мысль о создании защищенного приложения нас не покидает.

TaciturnMan @ 25.3.10, 18:14 *
Очень интересно, а проверяли, как будет работать программа, если в базе хотя бы 3-5 тысяч транзакций? Не тормозит?


Проверяли на 1000-1200, вроде бегает. На некоторых запросах (в отчетах преимущественно) были проблемы. Над некоторыми запросами пришлось подумать, переписать. Что смогли выжать - выжали.

А откуда число "хотя бы 3-5 тысяч"? Из реального опыта? Я просто взял свои базы за 7 лет, в среднем получалось 800-900 транзакций в год. Хранить период больше чем год? Не знаю, насколько это реалистично/необходимо. Но в целом учитывая, что тестировали мы на G1, и то какие процессора и сколько памяти сейчас тулят в устройства, думаю, к моменту когда у кого-то накопиться 3-5 тысяч записей это уже не будет проблемой. :)

Будем тестировать производительность backup/restore, попробуем прогнать на тестовой базе с 3-5К транзакций. Тут могут всплыть интересные моменты. :)



Реп: (328)
Локализую под немецкий (пришлите TXT)... меня не устраивает английский.



Реп: (17)
Andriy Zakharchuk @ 25.3.10, 18:33 *
Нет, данные, конечно же, в SQLite. Я имел в виду, что при создании backup'а уже используется XML.

Да, это в высшей мере правильно. :)
Andriy Zakharchuk @ 25.3.10, 18:33 *
Обратной стороной медали, оказалась группа пользователей, которая запросила шифрование БД. Вот с этим у встроенного движка проблемы. При том, что решения существуют, но в стандартной поставке их нет, и прикрутить на уровне приложния не видится возможным. В принципе, большинство довольны существующим вариантом, но мысль о создании защищенного приложения нас не покидает.

Думаю, нужно ориентироваться на здравомыслящих пользователей, подавляющему большинству которых защита нужна только на уровне "чтобы жена не увидела". А все эти сложности с шифрованием только усложняют жизнь программисту и пользователю. Все равно, если серьезному органу понадобится получить такого рода данные, они найдут адекватные средства взлома, или что более вероятно, получат такие сведения, пользуясь другими методами.
Andriy Zakharchuk @ 25.3.10, 18:33 *
А откуда число "хотя бы 3-5 тысяч"? Из реального опыта?

У меня за последние 2.5 года накопилось около 3 тысяч транзакций и это при том, что детально я не записываю. В последнее время SpbMobile уже подтормаживает на Marvell 416Mhz. Так что это важно, ориентироваться хотя бы на 3 тысячи (больше не стоит - "що занадто, то не здраво").

Спасибо Вам за внимание к нашим потребностям.



Реп: (17)
В процессе работы с программой появилось такое пожелание:

В программе существует функция "Reconcile", которая помечает транзакции как "сверенные". При попытке редактирования таких транзакций выдается предупреждение. Однако, при этом ничто не мешает ошибочно ввести новую транзакцию между сверенными в прошлом году и тем самым нарушить весь баланс, начиная с прошлого года.

Однако более полезной эта функция была бы, если реализовать ее иначе.

Пример из жизни: обычно я сверяю остатки на счетах регулярно (например, раз в месяц). Если после такой сверки при вводе новой транзакции я промахивась при вводе даты и новая транзакция может быть где-угодно, в уже сверенных периодах (в прошлых месяцах, годах и т.д.) - найти ее бывает очень тяжело, если не запомнил, какую ошибочную дату ввел.

Если же в качестве функции "Reconcile" фиксировать в свойствах счета конечную дату для периода, в котором все операции были сверены с источником (например, банковской выпиской), то этих ошибок можна избежать.

Интерфейс: форма Reconcile для счета:
- поле ввода: конечная дата сверенного периода (программа тут же может показать рядом баланс по счету на эту дату)
- кнопка Ok.

И главное: при вводе новой транзакции, дата которой попадает ранее в уже сверенный период программа выдает предупреждение "Этот период уже сверен" и не дает сохранить транзакцию. То же самое при редактировании транзакции - если старая или новая дата попадает в сверенный период, то выдавать сообщение и не позволять сохранить.

Спасибо за внимание. Если кто за или против - высказывайтесь.


Полная версия   Текстовая версия

Помощь   Правила

Сейчас: 28.03.24, 19:22