search

akaessens / NoFbEventScraper

This app scrapes Facebook event links and adds the event to your calendar.
GNU General Public License v3.0
28 stars 1 forks source link

Option to reprocess previously pasted URLs #35

Open TPS opened 3 years ago

TPS commented 3 years ago

@akaessens I've a few URLs I need to process regularly. Features that'd help:

akaessens commented 3 years ago

Hi @TPS,

Those are some great suggestions, i already thought about a similar functionality but didn't see as far as automatic syncing. The list of URLs could of course be patched somewhere into the existing activity but i think at this point some more sophisticated processing could be considered:

The whole application could become a calendar sync adapter instead of passing single events

This means: We have a list of URLs as you suggested. The scraping of the whole list (or partial?) can then be done manually or automatically. This list of URLs can be modified to include new events / pages. Here it becomes difficult:

(Dis)Advantages i can already see:

(+) Integration into the android sync process (+) Automatic reprocessing (+) Rescheduled events can be moved automatically (-) We do not want every event in the calendar -> hiding / disabling needed (-) Core feature of "paste event link -> add to calendar" would probably become a step more (-) History of pasted events difficult as it's synced all the time (-) Reproducibility of scraping? What if events are modified etc.

I'm looking forward to responses and inspiration

TPS commented 3 years ago

Thanks for your consideration, @akaessens.

The whole application could become a calendar sync adapter instead of passing single events

If possible, I'd like to not lose the initial clean look of the app upon opening, so maybe much of this proposed functionality could be hidden on a secondary tab, & choose default tab via setting?

Here it becomes difficult:

  • shall all events be displayed?

There's currently a setting for how many events scraped. Why shouldn't that be per URL?

  • sorted by scraped most recent as it's done now? but a complete sync will then overwrite this completely

Each URL's events could be displayed behind a <details></details> kind of UI, w/ each section sorted as now.

  • should all events be exported to the sync framework? can they be disabled or invisible so the calendar will not become overloaded?

I'm not even wanting automatic full sync to the calendar, as I think that's too prone to chaos.

(Dis)Advantages i can already see:

(+) Integration into the android sync process

I'm terrified this can't be done w/o a Google dependency, which would automatically dq from F-Droid.

(+) Rescheduled events can be moved automatically

Never even considered this, but I imagine this could get hairy. (E.g., telling between rescheduled vs regularly scheduled.)

(-) Core feature of "paste event link -> add to calendar" would probably become a step more

Only if not made default, as above.

(-) History of pasted events difficult as it's synced all the time

Another reason not to autosync to calendar.

What if events are modified etc.

Does FB have anything that'd flag this to highlight? Else, I'd think that's on end user to notice, no?

I'm looking forward to responses and inspiration.

Thanks again! 🙇🏾‍♂️

TPS commented 3 years ago

Also, I think any background processing shouldn't be full, just enough for app to notify (New events detected) when something's changed. Full processing should happen only when notification/app eventually opened.

akaessens commented 3 years ago

Sorry for the delay. Here are some more thoughts:

The whole application could become a calendar sync adapter instead of passing single events

If possible, I'd like to not lose the initial clean look of the app upon opening, so maybe much of this proposed functionality could be hidden on a secondary tab, & choose default tab via setting?

I think it should be either or - i'm thinking KISS. You're right about the clean look, i would like to keep the initial idea of just paste & add2calendar

Here it becomes difficult: shall all events be displayed?

There's currently a setting for how many events scraped. Why shouldn't that be per URL?

That would be a lot of configuration for a simple tool. In my opinion its not very user friendly and i'm not feeling confident to set a default value that matches everybody's needs.

Each URL's events could be displayed behind a <details></details> kind of UI, w/ each section sorted as now.

I honestly do not want to fiddle with the complete UI again, that's not my favorite challenge. If you have an idea on how to implement that (currently: recycler view) feel free to propose a solution. An expandable list of probably infinite recycler views for probably only one event each seems to heavy effort.

should all events be exported to the sync framework? can they be disabled or invisible so the calendar will not become overloaded?

I'm not even wanting automatic full sync to the calendar, as I think that's too prone to chaos.

It would def. be some chaos in the code as it would mean somewhat rewriting huge parts. The mess in the calendar could also become an issue.

(+) Integration into the android sync process

I'm terrified this can't be done w/o a Google dependency, which would automatically dq from F-Droid.

This is not an issue, e.g. see ICSx5 project.

Thanks again! 🙇🏾‍♂️

appeciate your input :)

Also, I think any background processing shouldn't be full, just enough for app to notify (New events detected) when something's changed. Full processing should happen only when notification/app eventually opened.

I fear that's not an option, a scraping process is needed for that information too. And then why not do the whole process.

TLDR: I will probably stay with the current UI for now. I suggest a drop-down menu of maybe last 5 searches without keeping additional state. What do you think ?

akaessens commented 3 years ago

https://developer.android.com/training/keyboard-input/style#AutoComplete

akaessens commented 3 years ago

This is how it would look like in f569e1f7025933adeb614f7e6946e34049cb16e1 device-2021-08-10-172255

TPS commented 3 years ago

This is how it would look like in f569e1f7025933adeb614f7e6946e34049cb16e1

I think that's a great step. I'd use it regularly.

TPS commented 3 years ago

If you have an idea on how to implement that (currently: recycler view) feel free to propose a solution. An expandable list of probably infinite recycler views for probably only one event each seems to heavy effort.

Perhaps something like FastScroll would be useful?