I like having people to please! It'd be super easy to only do the fun stuff (and I do really want to rebuild the charts into something great!) but if I keep putting off stuff like image backups I'll probably never do them! You're a pretty special case too, in that for most users I suspect they'll be saving pictures of their (potentially rolling) collection, but you're using it to track some fantastic unique pieces, so just going and re-adding pictures feels more of a challenge!

Helping you out will help motivate me

For anyone else interested, I've settled on the below four activities for a mini-release, all adding a bit more value, but not sweeping change:

• Implement Crashlytics analysis (to let me get more detailed crash reporting

• Build in a backup/restore mechanism for watch images

• Add a new 'pre-ordered' status & filters (I'm planning to pre-order the new Erebus Origin and like the idea of seeing a countdown to the release date. This one is for the benefit of those that back lots of kickstarters!)

• Implement a 'sale' mechanism

These are all actually pretty quick changes I think (I don't think Crashlytics looks difficult, but I want to drill down into it I think) - the backup bit might be really easy, or it might be a total pain, but I'll cross that bridge when I come to it - I'm hopeful it'll not be too much change from what's already there.

I've had a wee bit of time this weekend, so thought I'd give a wee update on the above.

After a bit of research I've got Crashlytics integrated and working, and for unrelated reasons I had to push a quick update out for the Android version so since I'd tested this I included the Crashlytics code in the update - it looks like it gives a far better view of exceptions and errors, so hopefully this'll help me pinpoint the issue @rkovars is facing with the weird background crashes!
It has helped me identify some weird behaviour with the notification library that's apparently know on later versions of Android, so I'm going to do a wee code review of that area and make sure all the setup reflects the updated advice from the developer.

I've got the pre-order status working (with the previous releases work this was super easy!) You can now add watches you've ordered and track a due/expected date for them, so whether it's a Kickstarter project or an ADs waiting list, the app can now give a countdown to the expected date


Whilst reviewing the code relating to images I took a minute to make the camera/gallery picker a bit bigger and nicer to select: ...but the reason I was in there in the first place was to get my head around how I was accessing and saving the images, to help me then get them back out!

I've implemented a solution to download all of the watch images stored in the app based on the same 'share' function used in the improved database backup from the last release: Took a couple of tries, but I've got this working ok on Android and the iOS simulator (one note though, if you've got images that were added before version 1.3 these probably won't backup, as I think that's when I refactored the image saving code to work tidily!)

I've not tackled restoring the images yet, but backing them up is the more critical action - I'll hopefully get my head around that this week at some point!

That'll just leave the 'sale' functionality, which I can do in a couple of hours - I've already implemented that on my other app so just need to replicate the changes I made there, and then I'll do the wee notification library review I mentioned above.

So hopefully the next version will be landing pretty soon!

Thanks for all the hard work Grant! I’m really enjoying the whole app!

Thanks Grant! I'll keep an eye out for the update.

I was having a wee play with restoring watch images from a backup last night - I didn't try actually restoring them, just built a button on screen and some code that fired when it was pressed to:

• Open up a file picker to let the user pick the directory that the backup pictures were stored in

• Iterate over that directory to check for files ending "_front.jpg" or "_back.jpg" and then simply show a dialog box with a count of how many images were found

Nice and simple - it confirmed that I could access the files in a folder, and that it accurately filtered these to only access valid ones...

BUT weirdly it also deleted everything in the directory as part of this process

So I want to get my head around why it's doing this before progressing further! I may need to first copy the files or something... I'm tempted to initially just release the backup part to give me some more time to think this over...

So, I had hoped to have a release out by now, but I've hit a couple of bumps in the road.

Firstly, I've built out pretty much everything that I'd set out to include in this release (which will be a 1.6.x, rather than a jump to 1.7 as there's no major change this time around), with a small exception.

Following on from my last post, I've decided to hold off on implementing the 'restore images' side of things - I really want to get a better understanding of this space before building it all out - however, the backup does seem to work ok, so it does give an option to do a relatively easy manual restore of the images.

The other little bump relates to notifications - this is actively causing background crashes/failures on Android 14 as the notification permission model has changed slightly, which isn't too bad as I'd planned to work on an update here anyway... but to do so I need to jump the library version from version 11 to version 16... and to do that I've needed to update both Android Studio (the software I use to code), Java (the underlying instruction set this is built upon) and Gradle (the build automation software that Android uses to sequence and automate the code compilation)...

Now that should have been really easy, but it caused me two hours of pain last night as build after build failed completely! I decided to put it aside and join my wife to watch some TV, only to wake up this morning with an idea of how to proceed that saw the build work first time this morning

Anyway... long story short, I've got a bit of testing to do with notifications and then I'll get some beta builds together in the next couple of days - I'm hoping to fix the daylight savings / timezone issue that @timor54 mentioned previously, but again it turns out that's not as straightforward as it sounds! I think I have a fix to try though!

Stif wrote: ↑Tue Oct 24, 2023 11:24 am So, I had hoped to have a release out by now, but I've hit a couple of bumps in the road.

Firstly, I've built out pretty much everything that I'd set out to include in this release (which will be a 1.6.x, rather than a jump to 1.7 as there's no major change this time around), with a small exception.

Following on from my last post, I've decided to hold off on implementing the 'restore images' side of things - I really want to get a better understanding of this space before building it all out - however, the backup does seem to work ok, so it does give an option to do a relatively easy manual restore of the images.

The other little bump relates to notifications - this is actively causing background crashes/failures on Android 14 as the notification permission model has changed slightly, which isn't too bad as I'd planned to work on an update here anyway... but to do so I need to jump the library version from version 11 to version 16... and to do that I've needed to update both Android Studio (the software I use to code), Java (the underlying instruction set this is built upon) and Gradle (the build automation software that Android uses to sequence and automate the code compilation)...

Now that should have been really easy, but it caused me two hours of pain last night as build after build failed completely! I decided to put it aside and join my wife to watch some TV, only to wake up this morning with an idea of how to proceed that saw the build work first time this morning

Anyway... long story short, I've got a bit of testing to do with notifications and then I'll get some beta builds together in the next couple of days - I'm hoping to fix the daylight savings / timezone issue that @timor54 mentioned previously, but again it turns out that's not as straightforward as it sounds! I think I have a fix to try though!

I am glad I am not the only one who works through technical problems in their sleep!

I haven't had any crashes in a while and I am using the app the same as I have been. So I am not sure what is going on.

I'd meant to ask if they'd stopped happening or if you'd just stopped hitting 'report'! Glad it seems to be working, but frustrated we don't know why it was failing!

On the plus side, now that I've added Crashlytics I can get much clearer logs through, as well as notes on trends (it even seems to send me emails if it notices issues multiple times... although so far that's only been stuff while I've been messing around in test )

The app has never crashed on my Android phone.
Though it's only from the second most recent version onwards that the backup file was able to be created.

Thanks @asqwerth - overall the app has been pretty stable, but it'll be useful being able to identify if/when it is misbehaving! (Some of the recent Android crashes happen invisibly due to notification permission changes in Android 14).

I've generated the Apple build of v1.6.3 now, so will submit that for review for both live and TestFlight now (the live review often takes a bit longer, so I'm getting into the habit of submitting both at once - I can always reject the live build if issues are found!), so for those on the TestFlight list, look out for it over the next day or two

@timor54 - I think I've fixed the timezone issue - you may need to cancel and reset your notification to get a fresh one scheduled though! I should now use the phones time, rather than setting with an absolute time.

I'm looking forward to getting this one out - I think the Crashlytics and Analytics stuff from Firebase will be useful.

If this all goes smoothly, I'll be tackling the wear charts next (and maybe stretching myself a bit to also rebuild the service schedule, to replace it with a collection wide calendar view...)

I wrote a reply here yesterday, but it seems to have vanished!

Rich, I see another crash via Test Flight, but frustratingly no logs! Might be worth loading the live version incase the Test Flight wrapper just stops crashlytics reporting.

I also noticed that I've not properly fixed the Android 14 notification permission (I need to request two now!) - I'll release another patch for that asap, but while testing it I also noticed that my notification (after resetting it) is now an hour out

When fixing the timezone/daylight saving issue that Tumor mentioned I set the app to use 'wall clock time' (i.e. device time) rather than absolute time (i.e. once set it remains 'fixed') - however I think when I create the notification request, I build a datetime object in a way that'll nudge it out an hour is DST...I might be wrong, but I've seen a similar issue at a major UK bank, so...

I'll have a wee play today to see if I can get it all running properly!

Downloaded the latest live version just now. I'll send a report if it crashes again. It seems like the crashes are not as frequent lately. Not sure why as I am not using it any differently than before.

Stif wrote: ↑Sat Oct 28, 2023 10:57 am
When fixing the timezone/daylight saving issue that Tumor mentioned I set the app to use 'wall clock time' (i.e. device time) rather than absolute time (i.e. once set it remains 'fixed') - however I think when I create the notification request, I build a datetime object in a way that'll nudge it out an hour is DST...

I’m afraid to report that this still does not appear to be working. I missed the clocks reverting back to GMT at the weekend before the latest update was installed, but I’ve been playing with it over the last couple of days.

I reset the notification to fire @19:05 and it worked as expected. The next day I manually set the time forward one hour to simulate moving to GMT +1 and as before it now fired @20:05 i.e. still working on an absolute time from when the notification was setup.

Now, what I’ve done, manually changing time zones, is not the same as it happening automatically through physical movement so is this a factor? Also is the DST seasonal change handled in some esoteric way that isn’t replicated by a manual clock change?

I’m running 1.6.4 on iOS 16.6.1.

Thanks for the update Tim - did you set a new notification on the app? (I think you'd need to turn them off and on to ensure its registered with the new time - but it does sound like you did!).

I wonder if it'll only work with a genuine time change (and maybe not with a location change?)

It definitely now works on Android as I was pleasantly surprised that my notification continued to fire at 9:15 despite the clock change!

In slightly related news, I think in the past you also suggested you'd prefer to see the charts on a rolling 90 days, like OnMyWrist does, rather than monthly... and as part of the rework I'm doing on the wear charts I've now got that up and running.

So far I've rebuilt the page, much as it was before but with the filters separated out (similar to the way the way I implemented the collection ordering) and implemented a series of 'quick filters' that you can instantly flick between.

I'm going to put some 'advanced' filter options in place next...