Update dependencies

[archie94]

• replace Picasso's with(Context) with get() after updating to 2.71828

[lukeswitz]

Doing this in the past has broken the signal-cli integration. Have you tested notifications post-update? SSL unverified peer on my end.

[archie94]

@lukeswitz I have not! Thanks! Will verify and update.

[archie94]

The Picasso, fressco and waveform library version updates seem to be the cause. Will remove those version bumps.

[lukeswitz]

I haven’t had much time with work to contribute lately, however it seems updating some dependencies breaks Signal. The problem could be in the haven branch of signal-cli-android.

If you have time to test it for me, here's a version that might fix the issue. It may help, maybe not. There's entirely too much reliance on dependencies we can't control, so combing through them/ creating Haven-specific forks will help future version control. Hoping this is of help, cheers!

https://jitpack.io/#lukeswitz/signal-cli-android2/v0.5.7-beta-05

[archie94]

The exception javax.net.ssl.SSLPeerUnverifiedException seems to occur when we bump Picasso to 2.71828, irrespective of whether we use guardianproject's signal-cli or @lukeswitz 's branch.

Tested keeping fresco:1.8.1 , waveform:library:1.0.3@aar and libphonenumber:8.8.10 version bumps.

Will update once I find anything more.

[lukeswitz]

NanoHTTPD perhaps? I have no problems with multiple signal device linking & 2FA until I use the code with Haven deps.

The beta release I posted above has some glaring issues (commented out key parts, etc.) so I’ll try and remedy that and see where we stand. Thanks for digging deeper into this

[archie94]

I am still not clear why updating Picasso version is causing the issue. :/ Trying to go through this to figure it out. Meanwhile will try to go through your branch and see if I find something. :+1:

[archie94]

Just another heads up. signal-cli lists com.squareup.okhttp3:okhttp:3.8.1 as dependency. Picasso 2.71828 lists com.squareup.okhttp3:okhttp:3.10.0 where as Picasso 2.5.2 lists com.squareup.okhttp3:okhttp:3.8.1. Not sure if this is of any help.

[lukeswitz]

That alone is a good find, and I think it might be the problem- thanks! We should look into handling the media without assistance from libraries ending support for versions of Android < 5 (and for other obvious reasons) as the MIME isn't handled correctly in encoding. Picasso, in turn, fails to display the image/video.

A dependency cleanup is more than in order. I say this because while most developers are phasing out supported devices, this repository needs to do the opposite. I'll update with a clean signal-cli branch to test and work on a more compatible & stable media handler activity. Excited to work with you on this,

Luke

[n8fr8]

Thanks all! I'm going to attempt a release on Monday/Tuesday and would love to integrate some of these improvements. I'm also all for removing dependencies where they are not needed. Picasso is great, as displaying media is important to the UX, but if we can live without it, I am happy to consider.

[lukeswitz]

I have 2FA server and QR TOTP signal device linking to contribute when the media recorder issues are ironed out. Picasso seems to hold this back due to https issues with their updates as archie94 found.

Currently, it burns up my old devices as the monitor activity is trying to do things like create redundant audio/media managers and bind handlers. Memory use went way up, can’t pinpoint it yet.

Other thoughts before a new release: video recording breaks the app altogether as mentioned in issues and there was some valuable feedback from your testing panel that all proved insightful.

I’m all for a new release. I can use that as a base to start work adapting these features and supporting all device cameras. Thanks for all your help and looking forward to what comes next!

[archie94]

@lukeswitz are you talking about #297 when you say media recorder issues? I would like to look into them whenever I get the time.

@n8fr8 I have used Universal Image Loader as image loading library in the past. While it can be a good alternative to Picasso a con is that the project is long dead and we may have to review the library and fix security issues if any. But I feel it will bring less dependencies in our project than Picasso and get our job done.

[fat-tire]

I see picasso was removed. Does that fix this commit?

[archie94]

@fat-tire yes! No javax.net.ssl.SSLPeerUnverifiedException anymore! I should probably squash these commits to one, let me know what you think.