otto
TextSecure
Our great sponsors
otto | TextSecure | |
---|---|---|
2 | 985 | |
5,215 | 24,890 | |
- | 0.7% | |
0.0 | 9.9 | |
about 6 years ago | 3 days ago | |
Java | Java | |
- | GNU Affero General Public License v3.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
otto
-
Is it a good idea to use Google Guava library for Android development?
I am involved in the development of Android application which is a rather "thick" mobile client for a Web service. It heavily communicates with the server but also has a lot of inner logic too. So, I decided to use some features of Google Guava library to simplify development process. Here is a list of features I'm very interested in: immutable collections, base utils, collection extensions, functional programming sugar and idioms (common.collect and common.base), primitives utilities (common.primitives), hashing utilities (common.hash), concurrent utils (futures and AsyncFunction). Things I don't want to use in Android: common.cache (see question below), common.eventbus (we have better Android specific libs for this, such as Otto), common.io (we can use okio for Android now).
-
EventBus 3.1 with plain Java support
1. I'm happy to see that EventBus has made this change. Let's hope the long overdue AndroidX migration (we're three years into AndroidX, folks) follows close on its heels.
2. Event buses are really, really bad. (At least, this kind of event bus is) The Android community has some battle scars on this, so I'll drop a little history for the broader audience here.
Event buses were an architectural fad that were briefly explored to address the challenges of communicating in the immature application architectures of the era. The maintenance lifetime of Otto, a competing event bus, is a good reference point for when they might have been considered reasonable practice: 2012 through 2015: https://github.com/square/otto/tags
This tool was abandoned by leading edge shops when they saw how rapidly it could make a complete hash of any thoughtfully laid out architecture. Connections made in an EventBus based application tend to be many-to-many, without the sender of an event having a direct reference to its recipient or vice versa. This is incredibly irritating to debug, and breeds communication patterns that are challenging even in a disciplined codebase. In an _undisciplined_ codebase they can be breathtakingly byzantine, even in small scale development.
Instead of using this, many leading edge shops started switching to RxJava at around 2016. RxJava is a powerful tool with sharp edges and a steep learning curve, but the need was so imminent and the failings of the existing EventBus-style tools so clear that it caught on. Indeed, while Google understandably felt it RxJava was too complex to recommend as an introductory tool, their first party LiveData tool released a few years later was essentially RxJava with the edges sanded off.
Of course, we're not even further down the road than that. Kotlin coroutines presents its own paradigm shift to contend with, but it's a clear step up from all the other solutions, and has Google's blessing as well. There's not much reason to start new development on top of anything except coroutines.
So where does that leave EventBus?
EventBus is at this point about as legacy as you can get without going all the way back to AsyncTask. Anytime I'm doing a code audit and see this dependency, red flags immediately go up: not only is it a sign that this code is far behind the times, but it's also a flag that I'm going to find some truly unfortunate and problematic design decisions.
People need what they need, and it's of course good to see critical dependencies for legacy applications get upgrades. But I can't recommend strongly enough to avoid this tool.
TextSecure
-
The xz sshd backdoor rabbithole goes quite a bit deeper
Moxie's reasons for disallowing Signal distribution via F-droid always rang a little flat to me ( https://github.com/signalapp/Signal-Android/issues/127 ). Lots of chatter about the supposedly superior security model of Google Play Store, and as a result fewer eyes independently building and testing the Signal code base. Everyone is entitled to their opinions, but independent and reproducible builds seem like a net positive for everyone. Always struggled to understand releasing code as open source without taking advantage of the community's willingness to build and test. Looking at it in a new light after the XZ backdoor, and Jia Tan's interactions with other FOSS folk.
- WhatsApp forces Pegasus spyware maker to share its secret code
-
Signal: Keep your phone number private with Signal usernames
Signal has documentation on how to reproduce their Play Store builds and compare them with what you've installed locally:
https://github.com/signalapp/Signal-Android/blob/main/reprod...
-
Signal v7.0.0 with phone number privacy
There's nothing on Signal blog as of yet, but Signal's git repository was tagged with v7.0.0 yesterday and we can see from the commit history since the previously tagged version (v6.74.4) that there will be a setting to hide one's phone number [1], as well as disabling the previous default behavior of advertising that one is on Signal to all their contacts already using it [2].
[1] https://github.com/signalapp/Signal-Android/commit/8797236b5... (PNP stands for "Phone Number Privacy")
[2] https://github.com/signalapp/Signal-Android/commit/6097e6c30...
-
What are you shocked people are still doing nowadays?
Signal works the same but without the user tracking from Meta/Facebook. Many people use it as well but I'm surprised that a majority sticks to WhatsApp.
-
Apple has seemingly found a way to block Android’s new iMessage app
Telegram and Signal solve this.
-
Apple Just Confirmed Governments Are Spying on People’s Phones With Push Notifications
Sadly yes: Looks like an open issue 13290 for Signal, sounds like they were/are indeed still interacting through google's push notification service, wat, and per a link at that issue it was a chore for Tutanota to break away once they realised it was a problem some years ago (though at least they thought about it years ago? wtf Signal...)
-
Building end-to-end security for Messenger – Engineering at Meta
Here is one: https://github.com/signalapp/Signal-Android/tree/main/reprod...
- Are Signal Notifications Encrypted ?
-
Facebook & Messenger finally get end-to-end encryption
Rule 1: Posts to r/signal must relate to Signal.
What are some alternatives?
EventBus - Event bus for Android and Java that simplifies communication between Activities, Fragments, Threads, Services, etc. Less code, better quality.
undiscord - Undiscord - Delete all messages in a Discord server / channel or DM (Easy and fast) Bulk delete
RxJava - RxJava – Reactive Extensions for the JVM – a library for composing asynchronous and event-based programs using observable sequences for the Java VM.
Signal-TLS-Proxy
RxAndroid - RxJava bindings for Android
duckduckgo-locales - Translation files for <a href="https://duckduckgo.com"> </a>
tinybus
session-desktop - Session Desktop - Onion routing based messenger
Drekkar - An Android event bus for WebView and JS.
MaterialAudiobookPlayer - Minimalistic audiobook player
LifecycleEvents
Signal-Android - Patches to Signal for Android removing dependencies on closed-source Google Mobile Services and Firebase libraries. In branches whose names include "-FOSS". Uses new "foss" or "gms" flavor dimension: build with "./gradlew assemblePlayFossProdRelease".