Better post sorting method

[RadarNyan]

What's wrong with current sorting method

I've no idea how the current sorting system works, I mean when I set it to sort as score, it may very well return a post scored 247 as well as a post scored as 89.

So I guess it just grabs the top 100 posts and pick one randomly? This could be work for some popular tags, but definitely not the best solution.

And we miss the ability to not use any "sort" or "order" tag in queue string (which is sort by upload time)

I got a better one (still not the perfect solution)

1. Create a local database from search result everyday / week / month make database update frequency an option so it would suit common users who would like their wallpaper changes once or twice a day as well as some crazy users who what change their wallpaper every 15 minutes Let's call the search result List_result
2. Always show the first post in List_result, and remove the post after shown By doing this, we can avoid seeing duplicate posts in a time period. Unless we have no new posts to show (in that case, we will have to update List_result)

This method would be working best with no sorting order (which is sort by update time) since we will be always getting the latest posts and barely see any duplicates if not updating posts very frequently.

And it would be better than current method while choose score as sorting method (well, just my guess) since not every top 100 of score sorted tags will return good results.

But this method may also lead to a problem that will be seeing duplicate posts since new posts will not make itself into the top 100 of score list in a short time.

---

Haven't get my hands on codes yet since I don't have Android Studio and can't get ADT to make a working build and I don't really know the java language very much anyway... so all I can do for now is providing some ideas and hope you good luck with achieving them :)

[Flat]

Current Sorting Method

The current way images are sorted is a request is sent to the server for 100 images with the tags and sort method, the server returns the information for those 100 images (The API does not support more) Out of those 100 images one is chosen randomly.

Reasoning

The reason why a random image is chosen instead of going through the images one by one is that it highly reduces the chances of repeating images. If it wasn't chosen randomly every time you put in the same tag you'd get the same exact images in the same order (unless you change the sort order) every time. By choosing a random image you're more likely to get something different.

Example

Random Method

Tags: hatsune_miku returns image 1 2 3 4 5 etc randomly 4 is chosen, that image is set as wallpaper.

Tags: hatsune_miku vocaloid is chosen images returned are 5 6 3 1 2 image 6 is randomly chosen and set as wallpaper

I set the tags back to hatsune_miku server gives me 1 2 3 4 again. randomly image 3 is chosen and set as wallpaper.

Without Random

tags set to hatsune_miku server returns 1 2 3 4 image 1 is set to wallpaper

tags are changed to something else and set back to hatsune_miku image 1 is again set as wallaper (the same as last time)

Using databases as a solution

While using databases would be a good way to keep track of which images were already set as wallpapers and can change the sort order; the drawback to this is that every combination of tags and sort orders and explicit rating would have to have a separate table/database. This information at 100 sets of information each time can add up to a large amount of space over time.

Why this is a problem

Google has made it very difficult to use external storage on phones. Each database needs to be kept track of in a database so we know what tag sets users have made.

Why this isn't a problem

Most internal storage on older phones is small, luckily we don't have to support older phones as we target 4.2+, most internal storage on newer phones is fairly large, however is shared with every other app on the phone.

While I do see your point, I believe it would need a lot of planning and more thought into the project, as it would not be a trivial change.

[RadarNyan]

Well, the other reason I recommend to use a database is that we don't really need to get 100 results from API on every update (or is there already some kind of cache?) It's better off for both client side and server side right?

And I don't understand why it could be a problem, I mean it's all plain text, how big can it be? I mean it can't be bigger than this app right? So I believe it won't be a problem to store it using internal storage.

And what about not using a database at all, I mean what if we just cache the search result in raw format (which would be json) as a file and read from it, delete used entry from it, if empty then update it?

In the meantime, would you please add none (latest) sorting method in the next release? This is a missing (yet important) feature.

[Flat]

In the next couple days I will try to create a cache-like database for md5 hashes of images used, and time stamps with a user selectable timeout. So if an image md5 is in the database it will not be used and the next image will be, it will also check the timeout peroid and if it is past that remove the md5 from the database. I have also added the option for no in the last commit. Should be on play store shortly.

[RadarNyan]

Err... I see the update 1.2.0 on Play Store, I see the change log, and I see your commit as well, but nothing seems really changed on the new version? The download notification is old style (only start and complete) and there's no new sort method, what's wrong?

[Flat]

Should be fixed now