spaRSS icon indicating copy to clipboard operation
spaRSS copied to clipboard

[feature request] export starred items to /sdcard/sparss/starred

Open markstinson opened this issue 8 years ago • 7 comments

It would super awesome if spaRSS either:

  • kept its starred items on the /storage/external_SD || /sdcard mount point under .../sparss/starred (unlikely due to redundancy, speed, overhead, etc.)

OR

  • allowed for an export of starred items to the /storage/external_SD || /sdcard mount point under .../sparss/starred . Possibly with the option to delete starred items after export.

This would allow us feed hunger users to clear possibly hundreds (or more) starred feeds. Some of us used to rely on Google Reader for this, but Phone apps don't have infinite storage. We also know SQLite database can get sluggish after awhile if burdened with lots of articles.

Thanks in advance. Cheers. M.

markstinson avatar Mar 31 '16 17:03 markstinson

May a simple backup app solve your needs?

ildar avatar Apr 02 '16 13:04 ildar

I thought of that at first.

  1. To properly backup the SQLite database used by the app in its /data/data directory, my phone (like most) has to be rooted. [ I always root my tablets, never my phone. A phone is less obnoxious to read news feeds on & can be explained as a "text message".] Then I would have a copy of the SQLite database, not files for reading, so more post-processing off the phone would be required. Then the articles wouldn't necessarily be on the phone's 32/64GB sdcard which has tons of space. The whole point of the export is that a lot of android phones come with 4/8GB of internal storage for OS/Apps/etc and changing phones & provider is not an option while finding another Reader is.
  2. A proper export wouldn't necessarily export the starred entries to new SQLite database file on the sdcard storage. It would likely create usable files something like:
for each starred entry:
if filename exists, enumerate name being used (in case of same name postings)
open a new txt/html file on the sdcard
write entry data to file
close file
optionally mark entry as successfully exported for optional post-export deletion

Now what it writes, would be up to Etuldan. I myself choose to include

  • the post's permalink (which obviously has the site's name in it)
  • the contents displayed in spaRSS (preferably the fully fetched article if it was retrieved)
  • date-time
  • and maybe other pertinent metadata

As to the naming of the of the filename, maybe something like: postsdatetime-part_of_title[-optional_enumeration].ext OR site.com-postsdatetime-part_of_title[-optional_enumeration].ext OR flip the post's date-time to just before the extension. Possibly truncating the filename.ext at max length of 32 or 48 characters - cause who doesn't hate unnecessarily long filenames.

Prefixing the filename with the post's date/time would give it a natural sort. Conversely, if post's date/time was just before extension and the file was 'touch'ed with its posted date time, then it could be sorted by alpha, "modified"/posting date time, etc.

Easy peasy.

markstinson avatar Apr 02 '16 17:04 markstinson

+1: It would be nice to create a full text archive from starred feeds as described by @markstinson above in paragraph 2.

oligond avatar Oct 30 '16 00:10 oligond

+1 if at least a database file copy could be put in a non-root accessible directory, that would be a great first step. Up to me/to us to process this database file via another process (another project a spaRSS user could work on?)

Best regards and greetings from France! 🎄

VLNTNO avatar Dec 11 '16 10:12 VLNTNO

Yes they would be great especially if we could export feeds and settings ourselves or to Google drive.

toyotabedzrock avatar Dec 24 '16 06:12 toyotabedzrock

Also better text search would be great.

toyotabedzrock avatar Dec 24 '16 06:12 toyotabedzrock

Hi @Etuldan, I've just implemented an export feature for spaRSS writing the list of starred entries to an HTML file and another option to reset the starred entries (e.g. after having exported them). It's working as a PoC, but still has some raw edges and is not tested thoroughly yet. As I'm new to Android development, I could use some guidance on my preparing the code for a proper PR. Would you be willing (and able) to help with a quick and dirty review of my changes in order to tell me where improvements are needed to reach "acceptable" quality or what kind of testing you require for contributions to the codebase. If so, please let me know, and I will commit the changes to my personal spaRSS fork for review. Cheers, Alco!

oligond avatar Feb 27 '17 17:02 oligond