Closed woj-tek closed 2 weeks ago
I have built this in now, but I'm playing around with a few things. The issue I'm having is launching the app and generating the app list now takes a couple seconds longer than it used to because it has to run through each app and calculate the size. For some reason swift is kind of slow at that portion since it has to recursively go into the app bundle and get the size of all its files and sum them up.
I will try to find a way to calculate the sizes faster as first step. But if I can't, I might add this under a setting which is off by default. Users who don't care to wait the extra couple seconds to launch the app, can enable this and show the sizes next to the app names.
This is what it looks like, hovering over an app shows the app version still:
It looks awesome! Thank you so much!
Do you plan to have option to sort by size as well?
The issue I'm having is launching the app and generating the app list now takes a couple seconds longer than it used to because it has to run through each app and calculate the size. For some reason swift is kind of slow at that portion since it has to recursively go into the app bundle and get the size of all its files and sum them up.
Hmmm. I'm more than fine with having it behind (off by default) option. Alas, have you considered updating it lazily? Open the app, show the list and then in background thread calculate the sizes (and having "update progress" icon instead of size while the calculcation takes place on each row)?
The sorting is already there, just no icon for it. Clicking the User or System headers flips to alphabetical or size sorting.
So lazy loading was one of the options I was playing with(my top choice currently), only thing I'm stuck on is say you have the sorting set to size on app load. If each item doesn't have sizes yet, how would the sorting behave? Default to alphabetical? But then once the sizes are fully loaded, the items would all move around to get in the right size sorting order. It seems jarring to the end-user experience.
Another idea(2nd choice) I had was maybe cache the app list data like app name, icon, version and size via core data. These shouldn't change very often at all. Then on launch, load everything from the cache and process any new apps that might not be already in there and add those to the cache as well. Also refresh these cached apps if it's been longer than 7 days to keep details updated.
I'm not sure yet what direction to go with, but I do know I don't think I want that loading delay on app launch. So will need to figure something out 😄
Give this a try and let me know what you think of the delay, maybe I'm overthinking it. For me, I have about 50 apps installed and it takes me 2-3 seconds to fully load in. Pearcleaner.zip
I think that defaulting to sorting by App name by default is fine.
Though the list could be updated dynamically. I'm using Doughnut podcast player and in there the default sort is by the number of new (unplayed) episodes. When the app starts (or if the update happens) then the list is just sorted/updated. It's not that jarring in the end.
I checked the attached app and it works great. With about 130 apps it took a couple of seconds but it's not a problem (for me at least) :-)
Do you see any performance increase on this version? I changed the thread it runs on from .background to .userInitiated which should increase the speed and also fixed some UI choppiness when loading the apps.
Scratch that last update, I think I got the lazy loading working really good now. It's pretty much instant in my testing. Let me know if this works! As a side note, you can switch the sort order by clicking the headers and I also added a menu option in the search bar menu button. Pearcleaner.zip
Pushed v3.7.0 out with this feature. Thanks for the input!
Just updated via homebrew and works perfectly. Thank you so much!
Though it seems calculated size is somewhat off and it looks like only .app
file filesize is counted:
Hi, so this is by design actually. When you click on an app in the sidebar, that's when Pearcleaner performs the actual file search and computes all the values. I didn't want to show the size of the app and all related files in the sidebar for a couple reasons:
Since the sidebar holds the list of apps themselves, I thought it made sense to show the app's own size instead. The detail view on the right side is where all the found files and their sizes are shown. To me, these sizes seemed unrelated compared to the sidebar's function, which is just to show the app list and that's it. I hope this makes sense!
Fair enough :-)
One thing though:
2. Since these app cleaner type apps are never 100% exact on the files they find since they search based on the app name and bundle id, sometimes it finds unrelated files since some apps have similar names. Not very likely usually, but it can. So showing the app size + found files size in the sidebar could actually be incorrect if it finds unrelated files.
Wouldn't this cause issues with the deletion process in itself?
In what way do you mean? The user is presented the list of files/folders the app "thinks" are related to the individual app. The user can either remove all or uncheck what might not be related.
Yes, user is presented but a lot of users probably is not aware that something "may not be related" thus clicking "Delete" without even looking at the list.
I mean, this is possible with any of these app cleaner apps.
I could add a popout warning button on the page, the same way I have on the Leftover files page.
Something like how AppCleaner has as well:
IMHO sounds reasonable :-)
Sweet, I'll add that to the next update :)
How is this? Right next to the delete button:
Looks good! 👍
Is your feature request related to a problem? Please describe.
When I cleanup my machine I often like to remove "big apps" that I may not be using. Having appsize (+option to sort apps by size) would help with that
Describe the solution you'd like
Display app-size in the list next to a version (or instead?) with option to sort by it would be great.