Since some days, you need to run the configure script in a tree where
you are going to build the iOS app anyway (to set the app's
user-visible name). Use the configure script to set up a couple of
symbolic links pointing to the LibreOffice core source and build
directories and the Poco installation. Use those symbolic links in the
project file.
Also, now a vendor-specific app icon set can be given with the
--with-iosapp-appicon option.
Change-Id: Ib936388a4cc680bd97ca6ef95a91e3296ab04d18
I got a crash report from SwDocShell::Edit. Let's see if adding those
source files to the Xcode project (but not to be compiled by Xcode)
means that Xcode will be able to show the actual crash location based
on such a report. (At least for crashes in the code that Xcode itself
compiles, I assume it works perfectly. But LibreOffice core code is
not built by Xcode.)
Change-Id: I1b6bf34e35a0e5652081a6dca40ba04312fbe20b
Added it to UTImportedTypeDeclarations, seemed to work. Not sure what
document types should be in UTImportedTypeDeclarations and what in
UTExportedTypeDeclarations. The documentation for document type
association is sadly rather vague.
I remember that some month ago I had horrible problems with this stuff
(see 26323fb92b), but now adding xlsx
went without a hitch. Not sure if I was just lucky, or whether iOS
12.1 has some bug fix related to this...
Change-Id: I75483719bd20496e8b44f935c788455148655a88
(Such a crash is intentionally caused by the system, in case an app
attempts to access the photo library or the camera without explicitly
declaring that intent in the Info.plist.)
The photo doesn't show up in the document, though, in fact the UI
kinda freezes... but that is another problem.
Change-Id: Ib998bdc2c2c3708f69f066522ade54c36dd5f551
Take the user-visible name of the iOS app as a configure parameter
--with-iosapp-name. The only purpose of running the configure script
in this case is to get that expanded into the Info.plist file.
You need autofoo to build LibreOffice core for iOS anyway, so this
doesn't really add any new hurdles for a potential developer who wants
to build the iOS app
Bypass some checks that aren't relevant (and would fail) in this case.
Could bypass a lot more of configure.ac in the ENABLE_IOSAPP case.
Change-Id: Ia0cb82ad552da1bb597411748f0cd74f825774fa
Using an optimised build of Poco seems to cause some code to work
incorrectly, sigh. No time to investigate deeper now.
Change-Id: I47e1809d380226d489db35bf4fc97d0f731fd887
In the JS, send the special "BYE" message to the app code.
In the iOS app code, handle that message by closing the fake socket
connection to the Online code, which eventually will cause the
corresponding thread to exit etc, and the app to return to displaying
the DocumentBrowserViewController. (Currently it causes the whole app
to exit which is wrong of course; an iOS should never exit
intentionally.)
Sadly we can't use the so-called user-defined LOSRCDIR and LOBUILDDIR
variables from the Build Settings in the pathnames to files. We have
to use relative pathnames, so if attempting to build this you need to
fix them all (instead of just editing the LOSRCDIR and LOBUILDDIR
values), most easily by editing the project.pbxproj manually.
Anyway, for me now I don't see any "red" (not found) referenced files
any more in Xcode.
Use the same discovery.xml and the ClientRequestDispatcher::
InitStaticFileContentCache() call as in Online, even if as such we
aren't serving any "static files" (like discovery.xml) to a WOPI
server in the mobile app case.
This stuff is a bit fragile, and the presence of other apps on the
device that claim to support "our" file types might, or might not,
affect how it works. Also, upgrading to iOS 12 seemed to have an
effect. Anyway, now it is back to working as I need.
Re-think the plumbing between the different parts of the C++ Online
code. Do try to have it work more like in real Online on all but the
lowest socket level. Except that we don't have multiple processes, but
threads inside the same process. And instead of using actual system
sockets for WebSocket traffic between the threads, we use our own
FakeSocket things, with no WebSocket framing of messages.
Reduce the amount of #ifdef MOBILEAPP a bit also by compiling in the
UnitFoo things. Hardcode that so that no unit testing is ever
attempted, though. We don't try to dlopen any library.
Corresponding changes in the app Objective-C code. Plus fixes and
functionality improvements.
Now it gets so far that the JavaScript code thinks it has the document
tiles presented, and doesn't crash. But it hangs occasionally. And all
tiles show up blank.
Anyway, progress.
Change-Id: I769497c9a46ddb74984bc7af36d132b7b43895d4
It's easier to either call the function to set the logging callback,
or not, in one place in client code, than to comment in and out all
the logging lines in FakeSocket.cpp as needed.
Change-Id: Id17f7e461c7df817440b47cb3124fcece13b189b
As we use #ifdefs at all call sites anyway (because we don't dare use
the generic overrides of close() etc), we can leave out the parameters
related to actual BSD sockets that we ignore anyway.
"Real" Online always uses non-blocking sockets. We don't need to take
flags for that or check it. We can hardcode such behaviour always.
(Assuing that is what we want; let's see once something works.)
Change-Id: I6863907d71c5599b00ce1f8305a44d41bbaf7bee
That is how Online uses the sockets for communication between the
processes anyway: It send and receives complete WebSocket frames.
Sure, in the mobile case there is just one process, but (I think) we
want to keep the same basic structure anyway, even if "wsd" and "kit"
are just threads. (We probably also want to drop the WebSocket framing
of the messages.)
Change-Id: I2397f321029c1cbbbc448a9b2403ad185a51cf14
Intended as a replacement for the real sockets used for WebSocket IPC
in Online on Linux. The idea is that in a mobile app we don't want to
bother with any actual sockets or WebSocket protocol (because we are
running as a single process after all), but keep much of the code that
thinks it is using such mostly unmodified. Just an idea so far, let's
see how this turns out.
Change-Id: I7878b0db99d9cbf70650227186c1fec9677fa74b
The app is unimaginatively called "Mobile" for now.
Runs but crashes pretty quickly after loading the document by the LO
core. Will need some heavy changes to get a ClientSession object
created in there, too, to handle the (emulated) WebSocket messages
from the JavaScript. It would then handle some of these messages
itself, and forwards some to the ChildSession, which in this case is
in the same process. Now the messsages from the JavaScript go to a
ChildSession, which is wrong. As the assertion says, "Tile traffic
should go through the DocumentBroker-LoKit WS"
