Orgzly-android: Widget/fast action for search

[falematte]

It would be very useful to have a widget or a fast action to search in all the notes.

[MackieLoeffel]

I'm currently using Wunderlist for my Todos and this is one of the two missing features, which hold be back from switching to orgzly, which otherwise looks really great. (the other missing feature are notifications #26 )

Wunderlist has a widget, which looks like this and it would be great for orgzly to have something similar:

More specifically it would be great to have a widget with the following features:

• Ability to select one of multiple different searches
• Plus-Button to add a new note (maybe in the same notebook, where notes from sharing go to)
• a list of notes, which match the search, with the ability to mark notes as done directly

If I find the time, I will also try to implement this.

[MackieLoeffel]

I've started to work on this.

[nevenz]

I've merged #68 (changed design and did few minor things) and also merged reminders, so we can continue on top of all that.

[MackieLoeffel]

Great 👍. Which points would you like me to Work on? The open points from the discussion from the PR?

[nevenz]

Which points would you like me to Work on? The open points from the discussion from the PR?

Whichever you want would be great, thanks.

You might want to check notifyDataChanged in Shelf (just pushed), which should now be a single point of entry to notify about changed data. Probably a place to move notification of a widget.

It's also called when settings are changed -- that's another case when widget should be refreshed -- configuring states for example will affect displayed search results.

[MackieLoeffel]

I implemented to open points from #68 in #75. Let me know, if I missed anything.

One more thing - I think after opening note from the widget, when user is done with it, app should be closed, instead of staying in the notebook. (from #68)

I actually like the current behavior, because it is a nice way to navigate to the note in the notebook and see its context. Maybe it should start a new backstack, but the Book-View should definitly stay there (I would prefer the same behavior for reminders as well, when opening a note is implemented).

[nevenz]

I actually like the current behavior, because it is a nice way to navigate to the note in the notebook and see its context. Maybe it should start a new backstack, but the Book-View should definitly stay there (I would prefer the same behavior for reminders as well, when opening a note is implemented).

When back button is pressed, it feels weird to me still being in the app. I've tried few other apps which had widgets like this and they were all exiting on back press. Not sure if that's specific to this widget, it might be the way Orgzly works with fragments, which is kinda messy currently.

BTW, isn't updating every 15min too slow?

[MackieLoeffel]

The Wunderlist widget, which inspired this widget, has exactly the same behavior as our widget currently has: Click on an item opens the todo, back button goes back to the list of the todo and backbutton again goes back to the homescreen of the Wunderlist app. An alternative would be to add a button in the note view, which goes to the book view, but that could be quite confusing.

15min is the minimum for the interval of an periodic job, see https://github.com/evernote/android-job/blob/master/FAQ.md#why-cant-an-interval-be-smaller-than-15-minutes-for-periodic-jobs.

[nevenz]

The Wunderlist widget, which inspired this widget, has exactly the same behavior as our widget currently has

Seems it's one of the few I tried, although more importantly it looks like it is the correct behavior.

15min is the minimum for the interval of an periodic job

Scheduling could be exact and job rescheduled when it's triggered (reminders are implemented like that). In addition, it could only schedule the update for when it matters. Like right after midnight (which should currently be enough, with limited search operators), or right after full hour to be safe (due to time zones).

[MackieLoeffel]

Seems it's one of the few I tried, although more importantly it looks like it is the correct behavior.

Good find, I didn't know, that this resource existed.

Scheduling could be exact

While I think, that this is a good idea for reminders, because they have a specific time, when they should go off, I don't think it is a good Idea for the update of the widget, because an exact job would wake up the device, but updating the widget is not useful, if the user is not looking at his phone (unlike reminders). Maybe setting the interval to one hour would be a good solution, because then the job would run, when the user looks on his device during this hour (I think so, at least). But you would have a delay of up to an hour for the update. A possibility would be to refresh the widget, whenever the user selects a different (or the same) filter, so that the user could trigger the refresh manually, if he wanted to. What do you think?

[nevenz]

exact job would wake up the device, but updating the widget is not useful, if the user is not looking at his phone

What about using setExecutionWindow, with very low start time (1m ?), and 15min end time? I haven't looked at how that works, so it might not be the right solution for this.

We might want to check some other open-source apps out there and see what they're doing.

A possibility would be to refresh the widget, whenever the user selects a different (or the same) filter, so that the user could trigger the refresh manually, if he wanted to.

I think I'd rather have a button for explicit refresh then. I think it's important that the user is aware that the widget might not be updated. Or it's just a matter of time a new issue about this is opened.

I don't like adding a new icon, but if we can't guarantee that the widget is updated every time the user can be looking at it, I think it's a good workaround.

Or we're just overthinking this way too much and nobody actually cares about widget lagging a bit? 😄

[MackieLoeffel]

What about using setExecutionWindow, with very low start time (1m ?), and 15min end time? I haven't looked at how that works, so it might not be the right solution for this.

I don't know, whether this makes a difference to using a periodic timer with a timeout of 15 min.

I don't like adding a new icon, but if we can't guarantee that the widget is updated every time the user can be looking at it, I think it's a good workaround.

I don't like adding a new icon as well, because space is precious.

Or we're just overthinking this way too much and nobody actually cares about widget lagging a bit? 😄

I don't know, I would say, that we simply leave it as it is at the moment, and if someone opens an issue because the widget updates to slowly or needs too much battery, we can think of a solution.

[mkaito]

Can't you provide hooks to update the widget instead of polling every 15 minutes? Say, when the user saves a note, push an update event. Same after sync. I don't know if android can do that, but it's how I'd handle it on a desktop.

El 13 de mayo de 2017 14:19:46 GMT+01:00, MackieLoeffel [e-mail] escribió:

What about using setExecutionWindow, with very low start time (1m ?),
and 15min end time? I haven't looked at how that works, so it might not
be the right solution for this.

I don't know, whether this makes a difference to using a periodic timer
with a timeout of 15 min.

I don't like adding a new icon, but if we can't guarantee that the
widget is updated every time the user can be looking at it, I think
it's a good workaround.

I don't like adding a new icon as well, because space is precious.

Or we're just overthinking this way too much and nobody actually
cares about widget lagging a bit? 😄

I don't know, I would say, that we simply leave it as it is at the
moment, and if someone opens an issue because the widget updates to
slowly or needs too much battery, we can think of a solution.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[MackieLoeffel]

Yes, theses actions already update the widget. The problem is, that sometimes the widget should update, even if the user doesn't do anything (e.g. on day change).

[nevenz]

Since search result (using current search operators) can only be affected by a day change (I think?), perhaps for now we should just schedule refresh 1s after full hour, every hour?

[MackieLoeffel]

search result (using current search operators) can only be affected by a day change (I think?)

I think so as well.

perhaps for now we should just schedule refresh 1s after full hour, every hour?

I implemented this in https://github.com/orgzly/orgzly-android/pull/82. I had to switch back to using the AlarmManager, because android-job always wakes up the device and doesn't offer similar functionality to setRepeatingInexact.

[nevenz]

The only remaining issue I'm having is that the widget is not always updated then modifying the query of the saved search.

[MackieLoeffel]

I fixed this problem in #105.