54 lines
1.8 KiB
Plaintext
54 lines
1.8 KiB
Plaintext
Generation 2 of the iOS app:
|
|
|
|
Goal:
|
|
|
|
- Simplified plumbing and largely reduced risk of things going
|
|
horribly wrong.
|
|
|
|
Ideas:
|
|
|
|
- No more FakeSockets.
|
|
|
|
- No more large number of threads emulating the processes and threads
|
|
in web-based Online.
|
|
|
|
- Still based on WebView, though, and the same Online JavaScript still
|
|
used.
|
|
|
|
- The completely unrelated "FakeWebSocket" thing in our JavaScript is
|
|
not going away.
|
|
|
|
- Just handle incoming messages from JavaScript and callbacks from LO
|
|
core as received. Either directly or by scheduling a block to be
|
|
executed. Do not pretend that there is a bunch of processes that
|
|
need to use sockets for IPC as in web-based Online. Do not pass
|
|
messages between threads using FakeSockets.
|
|
|
|
- Reduce and simplify the use of the Online C++ code.
|
|
|
|
Steps:
|
|
|
|
- Re-factorings that don't affect any working of current Online or
|
|
apps, but which will make the iOS app re-plumbing easier.
|
|
|
|
- ...
|
|
|
|
Problems:
|
|
|
|
Clearly this change can't be done in one step, and is not necessarily
|
|
of high priority, but has to be done over a period of several months.
|
|
How to make sure other changes done to Online at the same time don't
|
|
interfere? If kept in a branch, changes from the master branch must be
|
|
merged in on an almost daily basis.
|
|
|
|
When some of the functionality in Online C++ can/should be re-used
|
|
after all (probably things like the basic handling of messages, where
|
|
one might guess that large chunks of code is re-usable), separate out
|
|
such functionality into a class of its own in the master branch first,
|
|
and use that then in the gen2 branch.
|
|
|
|
What about the Android app? There hardy is interest to make similar
|
|
changes to it, if it works fine already, and there is no need to make
|
|
it handle multiple open documents in the same app process. Need to
|
|
keep the FakeSocket code for it, etc.
|