Separate app windows when opening notes

[John117XC]

Is your feature request related to a problem? Please describe.

The new separate app window when opening a note bothers me. Especially because it doesn't close the process when exiting that note.

Also there is no multi tabbing, which would allow to open multiple notes at once which would only make sense in this combination.

Describe the solution you'd like

Maybe you could insert an option to toggle this behavior.

Describe alternatives you've considered

No response

Additional context

No response

[larena1]

That feature is completely useless and annoying. Never saw it in another notes app and barely any app at all spawns activities in a separate task. No idea who thought that'd be an improvement.

#2018

The issue was introduced in this commit by setting launchMode. I'm not an Android expert but I suppose that because EditNoteActivity also has a dedicated launchMode, they'll run in separate tasks.

@JonasMayerDev can you look into this maybe and restore the old behavior?

[larena1]

@JonasMayerDev

https://medium.com/android-news/android-activity-launch-mode-e0df1aa72242

singleInstance

This is very special launch mode and only used in the applications that has only one activity. It is similar to singleTask except that no other activities will be created in the same task. Any other activity started from here will create in a new task.

Are you really sure it needs this launchMode? The choice seems a bit odd, given that the app has more than one activity but @ZetaTom approved it also.

As I understand the docs linked in your PR, you could also just set taskAffinity to an empty string at application level, which will then be inherited by all activities, mitigating possible task hijacking attempts.

[JonasMayerDev]

@larena1 thanks for mentioning me. I will have a look 👍

[larena1]

@JonasMayerDev do you think you are able to fix this or do you need @AndyScherzinger or @tobiasKaminsky to help you maybe?

[JonasMayerDev]

@larena1 you might be right that the launchMode is not needed, but this new behavior is introduced by the taskAffinity="".
At least in my testing, reverting the general launchMode changed nothing in that new behavior. As far as I can tell, the Issue is related to the launch mode of the EditNoteActivity which changes behavior when the taskAffinity is set to ""...

[JonasMayerDev]

Removing the Launchmode from EditNoteActivity solves the issue when editing a file but now, when opening a file via android share (select text somewhere in android -> click share -> click create new note) it again creates a new window. I guess this would be better than the old behavior because I guess this interaction is less common, but it is not really a solution. In addition to that idk. what else is affected when removing the launchmode from the EditNoteActivity...

[larena1]

@JonasMayerDev I don't use the app from the share sheet so can't comment on that but in my build I removed launchMode from the main and edit activity and that fixed it. But can't you just set taskAffinity for the whole app instead of activity to an empty string and then remove launchMode? That's at least what the docs suggest.

[JonasMayerDev]

@larena1 yes I agree, it seems like setting taskAffinity to "" for the whole app seems to be enough security wise. But I am not sure if we change important behavior in the App if remove launchmode from the EditNoteActivity. I would suggest I create PR for it, and we test it carefully and collect issues. Then we can see what version is better?

[JonasMayerDev]

#2163 please take a look and help to test to make sure we don't introduce another significant issue with that fix.

[Ronkn]

One thing that irritating is my wife and I use this app in part, to have a grocery list note that we can both edit. We always have to be sure to back out of a note when done editing so the changes sync so we don't have a conflict of unsynced edits. Now with this new feature, we also have to ensure we go to recent apps and close the window for that note since hitting the back button only returns you to the main note screen where you select a note file, and does NOT close the note that was being edited. As a result we've had more sync conflicts lately.

[larena1]

I'm afraid we have to live with this behavior for now but it's for a good cause.

Reason is that @alperozturk96 recently discovered a vulnerability dating back to 2015 affecting devices running Android 8 or earlier. In order to protect possible enterprise and other customers using devices from more than 6 years ago, measures had to be taken to provide them with an at least half secure notes app, as the other version of the vulnerability can only be mitigated on OS and not app level.

Maybe we can have one half secure app with the current second task flow and another version with the regular single task flow known from basically every other app for devices running Android 9 or newer. @jancborchardt do you think that could be an option?

[Ronkn]

I'm afraid we have to live with this behavior for now but it's for a good cause.

Reason is that @alperozturk96 recently discovered a vulnerability dating back to 2015 affecting devices running Android 8 or earlier. In order to protect possible enterprise and other customers using devices from more than 6 years ago, measures had to be taken to provide them with an at least half secure notes app, as the other version of the vulnerability can only be mitigated on OS and not app level.

Maybe we can have one half secure app with the current second task flow and another version with the regular single task flow known from basically every other app for devices running Android 9 or newer. @jancborchardt do you think that could be an option?

Is android 8 even secure anymore? Does that still receive security updates? This seems odd to support incredibly old devices for the sake of security when they're running a potentially unsecured android version anyway. Calyx and grapheneos for example will only support devices a few years old from the current date at best, due to Android becoming unsupported by Google after 4 years or so.

I appreciate this app and will support whatever the decision is, but this seems like an odd reason to not fix the bug.

[alperozturk96]

Unfortunately, singleInstance launchMode affects the UX in a bad way. My previous findings were to indicate a low-probability vulnerability and to be sure before making a change. For now, we have to choose between a low probability vulnerability and a better UX.

In the light of your feedback and with the decision we will take within the team, we will solve this problem. Most likely, we will prefer a better UX experience.

In the long run, we are planning a more secure, more performant and better navigated application with single activity pattern. So there will be only fragments in the application and no more exported activities, so we will have a safer app and better UX.

Thank you for your messages and interest.