| … | … | @@ -1,11 +1,20 @@ |
| 1 | 1 | # favela-android — architecture |
| 2 | 2 | |
| 3 | | **Decided 2026-08-07.** favela-android is a **React Native app over a bare-kit worklet**, not a WebView |
| 4 | | around favela-web. favela-web is **reference**, not a dependency of the UI. |
| 5 | | |
| 6 | | > *"favela-android is materially a different rendering surface and should be treated as such."* |
| 7 | | |
| 8 | | ## 0. Why this is not favela-web in a WebView |
| 3 | > ⛔ **REVERSED 2026-08-11. §0 and §2 below are HISTORY, not the design.** favela-android is a **WebView |
| 4 | > over favela-web's own pages**, served by a favela-web running inside this app's worklet. The decision |
| 5 | > recorded here on 2026-08-07 — a hand-written React Native UI, with favela-web as reference only — was |
| 6 | > built (715 lines), shipped, and reversed four days later: the native surface looked nothing like favela |
| 7 | > and could only be brought closer by rebuilding every screen a second time, by hand, to a lower standard. |
| 8 | > |
| 9 | > The reversal lived only in the README for a week. hyper-social #45 called that out — *"leaving it |
| 10 | > guarantees this decision gets re-litigated"* — and it was right: on 2026-08-18 §7 was appended to this |
| 11 | > file while §0 still asserted the opposite, making the document argue with itself. |
| 12 | > |
| 13 | > §0 and §2 are kept rather than deleted because the ARGUMENTS in them are still true — they are why the |
| 14 | > WebView had to earn its place, and what it costs. Read them as "what we believed on 2026-08-07", and |
| 15 | > read §7 and the README for what is actually built. |
| 16 | |
| 17 | ## 0. Why this is not favela-web in a WebView — *(2026-08-07, REVERSED — see the note above)* |
| 9 | 18 | |
| 10 | 19 | The rejected design ran favela-web's SSR HTTP server on `127.0.0.1` inside the app and pointed a WebView |
| 11 | 20 | at it. It would have worked — favela-web already emits `<meta name=viewport>` and carries 9 `@media` |
| … | … | @@ -52,6 +61,12 @@ what makes this a re-render rather than a rewrite. |
| 52 | 61 | └─────────────────────────────────────────────────────────────┘ |
| 53 | 62 | ``` |
| 54 | 63 | |
| 64 | ⛔ **REVERSED — favela-web now runs in-process and DOES bind 127.0.0.1:4041, which is what the WebView |
| 65 | renders.** The paragraph below is the 2026-08-07 reasoning, kept because its objection is real and was |
| 66 | answered rather than ignored: the IPC channel is still used for lifecycle and pairing, and the port |
| 67 | carries only what a browser needs. What changed is that serialising to HTML stopped being waste once the |
| 68 | HTML *was* the product — every screen favela-web gains arrives on the phone without being rebuilt. |
| 69 | |
| 55 | 70 | ⛔ **No HTTP server, and this is the substantive change from the WebView design.** favela-web binds a |
| 56 | 71 | port because a browser needs one. RN does not: it talks to the worklet over the IPC bridge that bare-kit |
| 57 | 72 | already provides (`BareKit.IPC` inside, `IPC` in Kotlin/JS on the RN side). Keeping an HTTP server would |