Recent Posts

Pages: [1] 2 3 ... 10
Only a few minor kinks to work out before the geo-located payee feature will be ready to release to beta. Itís going to be a hefty update so Iím going doin extensive testing before send it out into the wild. But so far things are coming together really nicely. Hopefully it will streamline transaction entry on the go.
Sounds like you have some great ideas there! Well, I'm pretty good at breaking things, so once it's in beta I will do my best :)
And just like that, literally a minute or two after I made the last post, the transaction loading is fixed (sort of). I have some other weird scrolling issues to fix, but hopefully I can have it all wrapped up by tomorrow night.
My wife went to the grocery store this evening to test out the new location stuff, and the app saved the coordinates for our apartment to the grocery store payee. The first field test was a failure! However, it's likely already fixed since the app was set to use the last known location in its memory cache on lookup failure. This was also due to the app not throwing an error due to no timeout value being set, so that was added as well. We'll see how further testing goes tomorrow.

I am currently buried under the payee manager revamp, mostly due to going slightly overboard on the functionality. When viewing a payee, a list of the saved locations and transactions for that payee will be displayed. Unfortunately, I'm having issues with the transaction list loading all of the transactions for the payee at once instead of 50 at a time like the account view does. This is critical for performance, so I need to make it work. Transactions will have full editing capability from the payee view, and locations will as well. In fact, a location editor will be added that will have a built in map so you can tweak a saved location if the GPS coordinates were not accurate when the location was saved. Well... that's the current plan depending on how easy it is to implement a google map interface.

I also updated the font across the entire app to Roboto, and tweaked the amount bubbles so the numbers look like they're popping out instead of indented. The next beta release is going to be a significant update, so I'm really looking forward to seeing what's broken!  :parrot:
Search is going to get some more attention before I call it complete. I wanted to get the basics working before moving to wrapping up the geo-located payees and payee manager changes. I'm not sure if I will build a special search panel for advanced searching, or implement some sort of parsed search "language" that you type into the existing text box.

I assumed that was probably the case, sounds good! FYI I got my tax done yesterday, and I had to search for some specific transactions whilst I was at the accountant due to stupid Australian tax laws changing... Yawn... Worked really well and was fast too, first official use I have had, gets a green tick!  :parrot:

After some considerable difficulty last night with the advanced calculator being broken on iOS/Safari, the solution was to replace the "mathjs" library with "expr-eval" to handle the parsing of the calculator entry string.

How annoying! The geo-located payees sound really good, that was one thing i really liked about the ynab mobile app, made it really quick to enter transactions on the fly. Looking forward to giving it a run once in beta.

Search is going to get some more attention before I call it complete. I wanted to get the basics working before moving to wrapping up the geo-located payees and payee manager changes. I'm not sure if I will build a special search panel for advanced searching, or implement some sort of parsed search "language" that you type into the existing text box.

Example: "date>=2019-01-01 amount>10.00 amount <20.00 memo~beer payee!~walmart"

That search string would show transactions that were created on or after January 1st, 2019, that have an amount greater than $10, an amount less than $20, a memo that includes the word "beer", and limited to payees that do not include "walmart" in their name. It's a lot to type into that small textbox, and remembering that out in the field may be a challenge considering how infrequently searching may be needed. The alternative is build an advanced search panel that includes a limited set of common filter types, but is much more intuitive to use. I will do some more homework before proceeding.

After some considerable difficulty last night with the advanced calculator being broken on iOS/Safari, the solution was to replace the "mathjs" library with "expr-eval" to handle parsing of the calculator entry string. After updating the entire app framework and libraries to the latest versions, I found that mathjs just does not work in Safari like it used to. So, out with the old and in with the new, and I can finally get back to updating the payee manager UI. I am already "alpha testing" the geo-located payees with my own budget on special build, so it won't be long before that feature is pushed to the beta app for everyone else to play with.
Sounds good! I didn't get a chance to reply yesterday but I have been continuing to use the beta version with no issues. The search seems to be working well, though I haven't had a valid use for it yet other than just to test it out for the sake of it. It's one of those tasks that you do intermittently but when you do it's really handy!

Thanks also for implementing the reconciliation changes, works well :)

The only suggestion I have for search at the moment would be to somehow search the transaction flags so you could search for "Yellow" for example, helps to find all these transactions at tax time or whatever you use the different flags for without having to export open in excel etc.

Question: How will the Geo-Location data work, will it only save it to the local webapp or is there some provision in the Sync API for it already?

EDIT: Ignore the question, i should actually read the post before last ;)
I took it a step further and completely replaced the vuejs/webpack framework that the app is built on, which brings it up to current. It took all evening just to get the app to build, but itís mostly functional. There are a few things that are completely broken, like the calculator, and that is mostly due to libraries that have been updated. A few imports and deprecated functions need to be fixed, removed, or replaced, and then I can get back to business on the app development.
Geo-located payees is coming along nicely.  I forgot how much I had working last year before the big UI update. In fact, the only thing left to add is a method for clearing all location data from the budget and the abiity to remove individual payee locations. The payee editor needs an overhaul to streamline both of those functions, and that should be working within the next day or two. After that I'll take the app out for some field testing before rolling the changes into the next beta app version later this week.

One thing to note is that the location data is saved in the data for each payee, so it is included in the syncing mechanism. This serves two purposes: logging out and clearing data will not lose your location data, and two or more mobile devices will have access to the shared location data. If my wife saves a location for a payee, I will have access to it when I visit that payee in the future. I considered making the payee location memory work also with local storage (clearing your browser data would clear the location memory), but it would be a lot more complicated to support both methods. Location services is turned off by default with the app so it will ignore any location data saved in the payees and will not save any location data when entering a transaction. Enabling location services in the settings will instruct the app to use your mobile device's GPS via the browser. You will likely have to allow the browser to access your location through a dialog on the first transaction entry. If you block the browser from accessing your location, geo-located payee lookups and saving will not work even if you have the location setting enabled. You will have to re-enable location services for the mobile site in the browser settings if this happens.

I am also taking the plunge and updating almost every dependency library in the app, which is just a little bit risky. The good news is that some manual patches and hacks are no longer necessary due to improvements in some of the libraries. The bad news is that there is definitely some risk for things to break, but that's what a beta is for!
Disclaimer: Backup your budget before testing the beta mobile app, and make sure to pay attention to the recommendations that were posted here to avoid bloating your database:

  • Implemented the All Accounts view which displays a combined list of transactions from all on-budget and off-budget accounts.
  • Added basic transaction search.
  • Fixed transaction memo editor not accepting blank memo value.

Transaction Search
Basic transaction search is now available on the Account view. Look for the magnifying glass icon next to the account balance values, and tap the icon to toggle the search box. Typing a value in the search box will filter the transactions based on matches found in the following list of fields. All search terms must be present in at least one of the fields for the transaction to be included in the results. This is just a first revision so there may be some bugs and odd behavior.  Let me know if you have any issues or a specific type of search that you would like added!
  • Payee
  • Category
  • Memo
  • Amount

Up Next
Geo-located payees is a feature that I have been missing, and it's about time to finish the implementation since it's the last major feature that I have planned for the mobile app. I started working on it last year and ran into quite a few UI/UX issues, and that spurred the complete app rewrite. Now that all of that is out of the way, I can finally get back to business. The goal is to utilize the GPS receiver on your mobile device (which should be available to the browser) to add location memory for a payee when entering a transaction on the go. When adding a new transaction in the future, the mobile app should look for payees that are within a certain physical range from where you are currently standing and either auto-fill the payee or give you a short list of nearby payees to choose from. This should speed up transaction entry considerably for frequently visited payees. Of course, this will be an optional feature that will have to be explicitly enabled in the mobile app settings.

Beta App:
Current App:
Pages: [1] 2 3 ... 10