briar issueshttps://code.briarproject.org/groups/briar/-/issues2021-07-06T10:01:35Zhttps://code.briarproject.org/briar/briar/-/issues/1961Implement UI of "Connect via Bluetooth" feature2021-07-06T10:01:35ZTorsten GroteImplement UI of "Connect via Bluetooth" featureImplement the design of #1960
Sub-task of #1821Implement the design of #1960
Sub-task of #1821Adapt to changes in the Android platformIvanaIvana2021-04-30https://code.briarproject.org/briar/briar/-/issues/1960Design "Connect via Bluetooth" feature2021-04-26T12:52:47ZTorsten GroteDesign "Connect via Bluetooth" featureSub-task of #1821Sub-task of #1821Adapt to changes in the Android platformTorsten GroteTorsten Grote2021-04-30https://code.briarproject.org/briar/briar/-/issues/1957All conversation messages are marked as read via messaging manager2021-05-05T16:08:47ZakwizgranAll conversation messages are marked as read via messaging managerThe setReadFlag() method is declared in the ConversationClient interface, but only MessagingManagerImpl's implementation of the method is used (except for one integration test).
If clients don't need their own implementations, the metho...The setReadFlag() method is declared in the ConversationClient interface, but only MessagingManagerImpl's implementation of the method is used (except for one integration test).
If clients don't need their own implementations, the method could be moved to the MessagingManager or ConversationManager interface, and the unused implementation in ConversationClientImpl could be removed.
On the other hand, if clients *do* need their own implementations then the implementation in ConversationClientImpl should be updated and we should make sure that ConversationViewModel and (eventually) MessagingControllerImpl call the right client for each message.
Test instructions:
* repeat tests from !1389Self-destructing messagesIvanaIvana2021-01-31https://code.briarproject.org/briar/briar-gtk/-/issues/99React on ConversationMessagesDeletedEvents2021-03-02T12:19:12ZNicoReact on ConversationMessagesDeletedEventsPointed out by @grote in https://code.briarproject.org/briar/briar/-/merge_requests/1384#note_47198. Once https://code.briarproject.org/briar/briar-gtk/-/issues/80 is there this will be really easy.Pointed out by @grote in https://code.briarproject.org/briar/briar/-/merge_requests/1384#note_47198. Once https://code.briarproject.org/briar/briar-gtk/-/issues/80 is there this will be really easy.GTK 0.2.0-beta1https://code.briarproject.org/briar/briar/-/issues/1951Exclude files from D2D backups2021-03-15T13:29:35ZTorsten GroteExclude files from D2D backupsWhen targeting API 30: When using device-to-device backup our `allowBackup=false` will be ignored and our app data will get backed up, if we don't explicitly exclude files from backup.
Subtask of #1827When targeting API 30: When using device-to-device backup our `allowBackup=false` will be ignored and our app data will get backed up, if we don't explicitly exclude files from backup.
Subtask of #1827Adapt to changes in the Android platformTorsten GroteTorsten Grote2021-04-30https://code.briarproject.org/briar/briar/-/issues/1930Show actual auto-delete timer duration in UI2021-03-01T17:05:35ZTorsten GroteShow actual auto-delete timer duration in UISince we only support a fixed timer for disappearing messages, the UI currently shows a static text (one week) for the duration.
However, to make changing the timer possible in the future without client version upgraded, we should alrea...Since we only support a fixed timer for disappearing messages, the UI currently shows a static text (one week) for the duration.
However, to make changing the timer possible in the future without client version upgraded, we should already show the actual timer that is being used, so that old clients can show the actual duration used by future clients.Self-destructing messagesakwizgranakwizgran2021-01-31https://code.briarproject.org/briar/briar/-/issues/1922Upgrade Tor to 0.3.5.132021-02-17T17:19:27ZakwizgranUpgrade Tor to 0.3.5.13Tor 0.3.5.13 includes the following bugfix that should improve v3 hidden service reachability:
> Major bugfixes (onion service v3, backport from 0.4.5.3-rc):
> - Stop requiring a live consensus for v3 clients and services, and
> allow...Tor 0.3.5.13 includes the following bugfix that should improve v3 hidden service reachability:
> Major bugfixes (onion service v3, backport from 0.4.5.3-rc):
> - Stop requiring a live consensus for v3 clients and services, and
> allow a "reasonably live" consensus instead. This allows v3 onion
> services to work even if the authorities fail to generate a
> consensus for more than 2 hours in a row. Fixes bug 40237; bugfix
> on 0.3.5.1-alpha.Android 1.2IvanaIvanahttps://code.briarproject.org/briar/briar/-/issues/1921PluginViewModel should wait for DB to open before loading settings2021-04-21T11:29:10ZakwizgranPluginViewModel should wait for DB to open before loading settingsWhile testing something unrelated on the 1.2.12 release I noticed this exception in the log:
```
02-03 16:15:52.017 2925-2952/org.briarproject.briar.android.debug W/PluginViewModel: org.briarproject.bramble.api.db.DbClosedException
...While testing something unrelated on the 1.2.12 release I noticed this exception in the log:
```
02-03 16:15:52.017 2925-2952/org.briarproject.briar.android.debug W/PluginViewModel: org.briarproject.bramble.api.db.DbClosedException
org.briarproject.bramble.api.db.DbClosedException
at org.briarproject.bramble.db.H2Database.createConnection(H2Database.java:97)
at org.briarproject.bramble.db.JdbcDatabase.startTransaction(JdbcDatabase.java:554)
at org.briarproject.bramble.db.JdbcDatabase.startTransaction(JdbcDatabase.java:97)
at org.briarproject.bramble.db.DatabaseComponentImpl.startTransaction(DatabaseComponentImpl.java:161)
at org.briarproject.bramble.db.DatabaseComponentImpl.transactionWithResult(DatabaseComponentImpl.java:208)
at org.briarproject.bramble.settings.SettingsManagerImpl.getSettings(SettingsManagerImpl.java:26)
at org.briarproject.briar.android.navdrawer.PluginViewModel.isPluginEnabled(PluginViewModel.java:204)
at org.briarproject.briar.android.navdrawer.PluginViewModel.lambda$loadSettings$0$PluginViewModel(PluginViewModel.java:187)
at org.briarproject.briar.android.navdrawer.-$$Lambda$PluginViewModel$HPPDOnjY7Hk6kE7RpR2no4vHis8.run(lambda)
at org.briarproject.bramble.TimeLoggingExecutor.lambda$execute$0$TimeLoggingExecutor(TimeLoggingExecutor.java:36)
at org.briarproject.bramble.-$$Lambda$TimeLoggingExecutor$Bqrtbsq_8LcRPoTWBOef6xh7gJg.run(lambda)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
at java.lang.Thread.run(Thread.java:818)
```
This happens at startup when NavDrawerActivity is created before signing in, as PluginViewModel tries to load the plugin settings.
This is currently harmless because a new NavDrawerActivity instance is created after signing in, with a new view model instance that successfully loads the settings. But that's just a lucky accident. To avoid depending on that, perhaps it would be better to refactor PluginViewModel to use DbViewModel#runOnDbThread()?Adapt to changes in the Android platformSebastianSebastian2021-04-30https://code.briarproject.org/briar/briar/-/issues/1916Remove locking from MessageTreeImpl and mark the interface @UiThread2021-04-30T13:35:41ZakwizgranRemove locking from MessageTreeImpl and mark the interface @UiThreadSubtask of #1823.Subtask of #1823.https://code.briarproject.org/briar/briar/-/issues/1915Optimise ConnectionRegistry calls in SharingControllerImpl2021-04-30T13:35:47ZakwizgranOptimise ConnectionRegistry calls in SharingControllerImplSubtask of #1823.Subtask of #1823.https://code.briarproject.org/briar/briar/-/issues/1914Create ViewModels immediately after injection2021-04-26T12:11:53ZakwizgranCreate ViewModels immediately after injectionVarious activities and fragments are creating their view models at different points in their lifecycles. To avoid subtle lifecycle bugs let's standardise this and create view models immediately after injection.
Subtask of #1823.
Test i...Various activities and fragments are creating their view models at different points in their lifecycles. To avoid subtle lifecycle bugs let's standardise this and create view models immediately after injection.
Subtask of #1823.
Test instructions:
This set of changes doesn't introduce new features, it only rearranges some code and is supposed not to break anything. It makes sense to test that the workflows and actions for which code has been touched. These include:
* Creating a new account on a fresh install
* Adding contacts via QR codes and make sure it works
* Add a contact remotely and before that finishes (by only completing the dialog on one of the devices first), check that the screen with the "pending contacts" works as expected
* Changing the alias for a contact
* Changing the account password
* Sending an image and opening that image full screen on both the sender and receiver device
* Opening the transports screen (by opening the navigation drawer on the left, tapping any of the connection modes at the bottom) and check that changing anything there persists (i.e. is still changed when navigating away and back to that screen)Adapt to changes in the Android platformSebastianSebastian2021-04-30https://code.briarproject.org/briar/briar/-/issues/1905Use ContactListViewModel in ContactChooserFragment and IntroductionActivity2021-04-26T12:51:23ZSebastianUse ContactListViewModel in ContactChooserFragment and IntroductionActivity!1341 introduced the ContactListViewModel which should be reusable by ContactChooserFragment and IntroductionActivity!1341 introduced the ContactListViewModel which should be reusable by ContactChooserFragment and IntroductionActivityAdapt to changes in the Android platformSebastianSebastian2021-04-30https://code.briarproject.org/briar/briar/-/issues/1895Introduce ViewModel for WriteBlogPostActivity2021-05-11T15:06:42ZTorsten GroteIntroduce ViewModel for WriteBlogPostActivityThe `WriteBlogPostActivity` could either be turned into a fragment and re-use BlogViewModel or have its own ViewModel.
Subtask of #1823
Depends on #1866The `WriteBlogPostActivity` could either be turned into a fragment and re-use BlogViewModel or have its own ViewModel.
Subtask of #1823
Depends on #1866https://code.briarproject.org/briar/briar/-/issues/1894Introduce ViewModel for RssFeed*Activity2021-05-05T16:08:09ZTorsten GroteIntroduce ViewModel for RssFeed*ActivityThere's `RssFeedManageActivity` and `RssFeedImportActivity`. Maybe one of them or both can be turned into a fragment and share the same ViewModel.
Subtask of #1823.There's `RssFeedManageActivity` and `RssFeedImportActivity`. Maybe one of them or both can be turned into a fragment and share the same ViewModel.
Subtask of #1823.Adapt to changes in the Android platformDaniel LublinDaniel Lublin2021-04-30https://code.briarproject.org/briar/briar/-/issues/1893Provide explanation when self-destruct timer gets changed2021-03-11T12:26:30ZTorsten GroteProvide explanation when self-destruct timer gets changedWhen self-destruct timer gets changed initially and later, we should provide a way to get more information about this feature for users that don't understand it, yet.
This could be as simple as making the timer changed message bubble ta...When self-destruct timer gets changed initially and later, we should provide a way to get more information about this feature for users that don't understand it, yet.
This could be as simple as making the timer changed message bubble tapable "Tap here to change" and bring the user to the settings screen for self-destructing messages that has further explanation #1837Self-destructing messagesIvanaIvana2021-01-31https://code.briarproject.org/briar/briar/-/issues/1891Migrate SharingController to ViewModel2021-04-26T12:53:15ZTorsten GroteMigrate SharingController to ViewModelUsed by blogs and forums.Used by blogs and forums.Adapt to changes in the Android platformTorsten GroteTorsten Grote2021-04-30https://code.briarproject.org/briar/briar-gtk/-/issues/88Revise contributing guide2021-02-04T09:28:42ZNicoRevise contributing guideThere's at least an error with the `component` thing in merge requests. Might have other issues, too.There's at least an error with the `component` thing in merge requests. Might have other issues, too.GTK 0.1.0-beta3NicoNicohttps://code.briarproject.org/briar/briar/-/issues/1883Prepare for Resource IDs becoming non-final in Android Gradle Plugin version 5.02021-04-26T12:12:21ZTorsten GrotePrepare for Resource IDs becoming non-final in Android Gradle Plugin version 5.0Adapt to changes in the Android platformSebastianSebastian2021-04-30https://code.briarproject.org/briar/briar/-/issues/1882Get rid of legacy code after ViewModel migration2021-04-30T13:35:56ZTorsten GroteGet rid of legacy code after ViewModel migrationA list of things we might not need anymore after the ViewModel migration is complete:
* [ ] `ActivityComponent`
* [ ] `BaseEventFragment`
* [ ] most of `BaseFragment`
* [ ] part of `BaseFragmentListener`
* [ ] `BriarActivity#runOnDbThre...A list of things we might not need anymore after the ViewModel migration is complete:
* [ ] `ActivityComponent`
* [ ] `BaseEventFragment`
* [ ] most of `BaseFragment`
* [ ] part of `BaseFragmentListener`
* [ ] `BriarActivity#runOnDbThread()`
* [ ] `BriarActivity#finishOnUiThread()`
* [ ] `VersionedAdapter` and its implementationhttps://code.briarproject.org/briar/briar/-/issues/1881Migrate ThreadListController to ViewModel2021-04-06T12:40:00ZTorsten GroteMigrate ThreadListController to ViewModelSubtask of #1800Subtask of #1800Adapt to changes in the Android platformTorsten GroteTorsten Grote2021-04-30