briar issueshttps://code.briarproject.org/groups/briar/-/issues2018-06-12T11:32:36Zhttps://code.briarproject.org/briar/briar/-/issues/171Create interface between UI and TransportClient2018-06-12T11:32:36ZakwizgranCreate interface between UI and TransportClientSubtask of #112.Subtask of #112.Milestone Aakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/172Create interface between UI and MessagingClient2018-06-12T11:32:36ZakwizgranCreate interface between UI and MessagingClientSubtask of #112.Subtask of #112.Milestone Aakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/173Create interface between UI and ForumClient2018-06-12T11:32:36ZakwizgranCreate interface between UI and ForumClientSubtask of #112.Subtask of #112.Milestone Aakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/174Rename classes, methods, fields with BSP nomenclature2018-04-16T16:24:37ZakwizgranRename classes, methods, fields with BSP nomenclatureThis is going to touch a lot of code, but shouldn't make any functional changes.
Subtask of #112.This is going to touch a lot of code, but shouldn't make any functional changes.
Subtask of #112.Milestone Aakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/175Sync blocks rather than messages2018-05-11T13:29:53ZakwizgranSync blocks rather than messagesAt this stage we only need to support single-block messages.At this stage we only need to support single-block messages.https://code.briarproject.org/briar/briar/-/issues/180Remove DatabaseCleaner and message expiry logic2018-06-12T11:32:35ZakwizgranRemove DatabaseCleaner and message expiry logicRemove the old message expiry code. Leave the infrastructure for measuring free disk space intact, we'll need it later.
Subtask of #112.Remove the old message expiry code. Leave the infrastructure for measuring free disk space intact, we'll need it later.
Subtask of #112.Milestone Aakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/181Restructure the Dashboard2018-06-12T11:32:35ZErnir ErlingssonRestructure the DashboardRestructure the dashboard with a navigation drawer and use fragmentsRestructure the dashboard with a navigation drawer and use fragmentsMilestone Bhttps://code.briarproject.org/briar/briar/-/issues/182Research Gingerbread ubiquity outside of the Play store2018-06-12T11:32:35ZErnir ErlingssonResearch Gingerbread ubiquity outside of the Play storeTo help us decide where to set the supported OS's lower limit we need a rough estimation of Gingerbread devices outside of Google .
Here is a device/os/screen-size breakdown from the Play store:
http://developer.android.com/about/d...To help us decide where to set the supported OS's lower limit we need a rough estimation of Gingerbread devices outside of Google .
Here is a device/os/screen-size breakdown from the Play store:
http://developer.android.com/about/dashboards/index.htmlMilestone Dakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/183Upgrade to Roboguice 32018-06-12T11:32:35ZakwizgranUpgrade to Roboguice 3https://code.briarproject.org/briar/briar/-/issues/188Inject DbExecutor as an ExecutorService2018-06-12T11:32:35ZakwizgranInject DbExecutor as an ExecutorServiceTransportKeyManager needs to submit database tasks and wait for them to complete, so it needs to see the DbExecutor as an ExecutorService rather than an Executor.
Subtask of #111.TransportKeyManager needs to submit database tasks and wait for them to complete, so it needs to see the DbExecutor as an ExecutorService rather than an Executor.
Subtask of #111.Milestone Aakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/189Implement BLAKE2s2018-06-12T11:32:35Zstr4dImplement BLAKE2sSubtask of #169
Initial implementation will go into briar-core. Once implemented, we should aim to push the implementation upstream into BouncyCastle. We can then drop it from briar-core once it has propagated to BouncyCastly and Spon...Subtask of #169
Initial implementation will go into briar-core. Once implemented, we should aim to push the implementation upstream into BouncyCastle. We can then drop it from briar-core once it has propagated to BouncyCastly and SpongyCastle.Milestone Ahttps://code.briarproject.org/briar/briar/-/issues/194Setup Translation Platform for App2018-06-12T11:32:35ZTorsten GroteSetup Translation Platform for AppCurrently, the app is only available in English. It should be translated into other languages. To make things easier for potential translators, the translation should not happen via editing XML files and doing pull requests on GitLab, bu...Currently, the app is only available in English. It should be translated into other languages. To make things easier for potential translators, the translation should not happen via editing XML files and doing pull requests on GitLab, but rather through a dedicated platform such as [Transifex](http://transifex.com/), [Weblate](https://weblate.org) or a similar service.
This is a precondition for #143.Milestone Ahttps://code.briarproject.org/briar/briar/-/issues/197Improve readability/usability of transport status bar2022-11-18T16:48:47Zstr4dImprove readability/usability of transport status bar* The green text isn't very readable to me. IMHO the text should stay the same primary text color, and only the icon should change to green. The meaning is not altered in the user's eyes.
* "Wi-Fi" should probably be "Local Wi-Fi" to en...* The green text isn't very readable to me. IMHO the text should stay the same primary text color, and only the icon should change to green. The meaning is not altered in the user's eyes.
* "Wi-Fi" should probably be "Local Wi-Fi" to ensure the user understands it refers to reaching other users on the same local network.
* Is "Internet" using the open internet, or Tor? I would have assumed there would be separate entries for each.
Related: #185https://code.briarproject.org/briar/briar/-/issues/198Refactor out pattern of list with empty view and progress wheel2018-06-12T11:32:35ZTorsten GroteRefactor out pattern of list with empty view and progress wheelWe have many lists that need an empty view to be shown when no elements exist and a progress wheel when elements are loaded. This could be re-factored out since it is a common pattern.We have many lists that need an empty view to be shown when no elements exist and a progress wheel when elements are loaded. This could be re-factored out since it is a common pattern.Milestone ATorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/199Use Floating Action Button (FAB) for adding new contact2018-06-12T11:32:35ZTorsten GroteUse Floating Action Button (FAB) for adding new contactCurrently, there's an icon in the action bar for adding new contacts. However, this action is a prime candidate to be implemented with a Floating Action Button (FAB).
There's basically two options for the implementation:
* [Design Su...Currently, there's an icon in the action bar for adding new contacts. However, this action is a prime candidate to be implemented with a Floating Action Button (FAB).
There's basically two options for the implementation:
* [Design Support Library](http://android-developers.blogspot.com.br/2015/05/android-design-support-library.html)
* @str4d's [FloatingActionButton library](https://github.com/str4d/android-floating-action-button)Milestone ATorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/203Remove Tor binaries from repo2018-06-12T11:32:34ZakwizgranRemove Tor binaries from repoThe Tor binaries (and Tor's GeoIP database) need to be updated regularly - this makes the repo enormous. Remove the binaries from the repo and find a convenient way of downloading and verifying them during the build process - possibly gr...The Tor binaries (and Tor's GeoIP database) need to be updated regularly - this makes the repo enormous. Remove the binaries from the repo and find a convenient way of downloading and verifying them during the build process - possibly gradle-witness?
We may want to remove the binaries from the repo's history too, but that will need to be co-ordinated among all developers to avoid git breakage.Milestone Cakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/205Unit tests for KeyManagerImpl and TransportKeyManager2018-06-12T11:32:34ZakwizgranUnit tests for KeyManagerImpl and TransportKeyManagerAn exciting way to become familiar with some core code.An exciting way to become familiar with some core code.Milestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/208Remove ReadPrivateMessageActivity and WritePrivateMessageActivity2018-06-12T11:32:34ZakwizgranRemove ReadPrivateMessageActivity and WritePrivateMessageActivityDo you use them? No, neither does anyone else.Do you use them? No, neither does anyone else.Milestone Aakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/209Ensure clients can reliably respond to contacts being added/removed2018-06-12T11:32:34ZakwizgranEnsure clients can reliably respond to contacts being added/removedAdding or removing a contact may trigger actions by sync clients (such as adding or removing a private group shared with the contact).
If the app crashes immediately after the DB transaction that adds/removes the contact is committed,...Adding or removing a contact may trigger actions by sync clients (such as adding or removing a private group shared with the contact).
If the app crashes immediately after the DB transaction that adds/removes the contact is committed, event handlers registered by clients may not be run.
Possible solutions:
* Clients could check the contact list at startup and perform any actions needed to bring their own state back into step with the contact list.
* Clients could register handlers to be run in the same DB transaction as the add/remove event.Milestone Aakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/213Use @Test annotation to test for exceptions being thrown2018-06-12T11:32:34ZakwizgranUse @Test annotation to test for exceptions being thrownLots of tests currently use this idiom:
```
@Test
public void testFoo() {
try {
foo();
Assert.fail();
} catch (FooException expected) {
// Expected
}
}
```
They should instead use JUnit...Lots of tests currently use this idiom:
```
@Test
public void testFoo() {
try {
foo();
Assert.fail();
} catch (FooException expected) {
// Expected
}
}
```
They should instead use JUnit's support for catching exceptions:
```
@Test(expected = FooException.class)
public void testFoo() throws FooException {
foo();
}
```Milestone ATorsten GroteTorsten Grote