Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Proposal: Alternate hook-based implementation of Android support

See original GitHub issue

Problem
User @clauderic believes that the approach to implementing Android support should be implemented as a hook and not as a separate `Editable`.

Solution
Will post clauderic’s proposed solution in a separate comment below

Alternatives
The current in progress solution is with this PR #4200

Context
Related to closing this issue #3786

Issue Analytics

State:
Created 2 years ago
Reactions:2
Comments:8

Top GitHub Comments

2reactions

claudericcommented, Apr 23, 2021

Hey @thesunny, I don’t mean to come off as dismissive or condescending, I’m sorry if that’s how some of my messages were perceived. I’ve said this before and will state it again, I’m truly appreciative of all the work you and @wleroux have put into this, and the community should be too.

I’m no stranger to how gruesome and frustrating working on Android reconciliation is, and the work you have both done is heroic and should not be understated. It is because of all those efforts that we’re able to sit here and discuss the merits of one approach over the other.

I mentioned this from the offset, I’m only hoping to spark discussions on the technical merits of one approach over the other in terms of the level of abstraction. I don’t think we necessarily need to ship the perfect abstraction from the get-go, but we should pause and make sure we don’t introduce anything that makes the project harder to maintain or is a decision that’s hard to revert.

Level of abstraction aside, I think there is some work to be done with regards to the actual mutation reconciliation, I’ve summarized some of the issues I’ve found so far. I definitely agree with you that something is better than nothing though.

If there’s buy-in to validate different approaches, I’m happy to put more time aside to invest into the PR I had started a while back to clean it up so we can compare.

1reaction

claudericcommented, Apr 24, 2021

Opened a PR here that implements the described approach, but does not introduce any changes related to mutation observer. That should happen in a separate PR.

Feedback is welcome when you can make time to review the PR https://github.com/ianstormtaylor/slate/pull/4224

The PR lays all the groundwork needed to have swappable composition reconciliation layers.

Top Results From Across the Web

Proposal for Sponsored Open Source Android Support #3786

This is an alternative to the proposal for a Paid Android Plugin ... Proposal: Alternate hook-based implementation of Android support #4223.

Support Library Packages - Android Developers

The Android Support Library contains several library packages that can be included in your application. Each of these libraries supports a specific range...

The Android malware detection systems between hope and ...

The proposed method depends on app decompressing, DEX code extraction, dex code sections identifying and mapping each byte in the code into a ......

A Methodology for Hook-Based Kernel Level Rootkits

In this paper, we propose a scheme that evaluates the hooks by comparing the returned results before hooking and after hooking. If a...

TEEzz: Fuzzing Trusted Applications on COTS Android Devices

We plan to support a further target in the future: Samsung's TEE called TEEGRIS [68]. As far as we know,. TEEGRIS is similar...