Which list it’s on actually matters a lot.

I’ve now changed things around so that patterns can be removed from the stash without being deleted from the program – something that became necessary once I started tracking finishes. I’m still not sure how useful folks will find this feature, but it does make some level of logical sense.

Of course, implementing that was not without its own pitfalls.

Logically, it would make sense that this is something that you would want to provide access to from the pattern page itself. It’s likely not something that will be used frequently – not compared to the other features in the program – and so it can be hidden up in a menu button. So far, straightforward.

The real question comes when looking at what happens to the page when you are looking at it in the stash list. Things were set up to allow swiping from side to side to browse the patterns in the stash without having to go back up to the pattern page, but that meant that when the pattern was removed from the stash list …what happened?

Underneath it, of course, is a FragmentPagerStateAdapter. Merely calling notifyDataSetChanged() was insufficient to cause the adapter to update the views (a problem I have run into often on this project) but even more importantly, calling it essentially caused the adapter to overwrite the information for the next pattern in the list with the previous one – the one that had just been removed from the stash. The end result being, of course, that I could end up with 5 versions of the same pattern and several missing.

Setting the getItemPosition() to return NONE did not accomplish the desired result either; the adapter still doesn’t seem to be updating the fragments in memory, leaving the old data there to overwrite the new stuff (and I have words about the fact that Google fires onTextChangedListeners out of apparent order, but that’s a rant held from the issue caught while trying to solve a different problem). It might work if I set the number of fragments offscreen to zero, but that would be less ideal when I (hopefully) start having photos available – having the fragment loaded offscreen helps decrease the visible loading time.

This also drives home a more serious point about the behavior of things that I was skirting around previously when dealing with threads and embellishments – when the quantity in the stash is decreased to 0, those items are immediately removed from the stash list. According to the thought that, if opened from the stash tab, I should only be looking at items in the stash, the item in question should then be removed from view immediately – and I’m not a big fan of that. Misclicks happen. I’d rather the user have time to correct the mistake instead of having to go back through another 4 screens in order to fix it.

The solution I’ve settled on isn’t the prettiest – it seems a little counter-intuitive to me to have stuff not in the stash show up when you’re swiping between items that you’ve called from the stash, for example – but it sidesteps some of these other major problems that have come up. When swiping, the user has access to the full list of everything, in stash or not. Swiping isn’t really meant for searching through the overall list anyway, and so in that sense this is a more logical approach.  There are places I wish I could have it function slightly differently, but at least for the moment, this is the best compromise between functionality, my time, and logical behavior.