There are already several classes called Document on the C++ side.
Let's reduce confusion a bit. (Also, we might need to use the
Objective-C Document class from some of the Online C++ code (which is
actually compiled as Objective-C++).)
Change-Id: I34347ba0161c067b14bb125c3410eefd89bbca31
Add two settings: One setting "Template list URL" is a string that
should either be empty (the typical case for a random user of the
app), or contain a https: URL. If this setting is empty, only the
templates bundled in the app are provided.
If the "Template list URL" is non-empty, it should be a https: URL
pointing to a text file (or dynamically generated text resource). That
file is downloaded and read when the app starts. Each line in the file
should either be a comment (starting with a hash '#'), or a https: URL
pointing to a template document, that is of type .ott, .ots, or .otp.
That document is downloaded if it hasn't been downloaded already, or
if its time stamp is newer than that of the already downloaded copy.
Also a thumbnail image for the template, formed by appending ".png" to
its URL, is downloaded, if available.
Any previously downloaded templates that aren't mentioned in the list
file are removed.
The intent is that in some managed mass deployment environment, the
mobile device management software would set up this setting, so that
the end-user devices would see the same templates.
Obviously, this URL does not have to point to a static file on a web
server, but could point to some dynamically generated resource on a
web server, that enumerates the templates available on the server and
returns their URLs as a text document.
Another setting is "Empty tile cache next time". This is a toggle. If
toggled on, the next time a document is opened in the app, the tile
cache is emptied (and the toggle is reset off). This is mostly for
potential problem solving, and might be removd later.
Various refactoring to support the new functionality.
Change-Id: Ie2ebf032acb9e43bb1c6f7ae4d0c449ae66eaa05
It took quite some time for me to understand how to do it. Not sure if
this is The Right Way, but at least it now works better.
The trick was to store the importHandler block as a property of the
TemplateCollectionViewController and call it when the right template
has been selected.
There is no need to call the importHandler already in the
documentBrowser:didRequestDocumentCreationWithHandler: instance method
and it would not be possible anyway as there apparently is no way to
have the presentViewController:animated:completion: method work in a
truly modal way, so that it would not return until the selection has
been done.
Change-Id: Ia229500c181844fcd99f1f099b2e6744c22b5266
When the "Create Document" button in the document browser is pressed,
we scan a set of ODF templates in the Templates subfolder of the app
bundle, and we display that list as a collection view. (So far that
view is not interactive, i.e. once it is displayed, you are stuck
there.)
Eventually, when the user chooses one of the templates, we will open
that and immediately, before the user has done any edits, do a Save As
of it as a real (not template) document in the app's document folder.
What name to use for it is unclear yet. Further saves will thus don't
need any dialog to choose the document name.
More work will be needed on i18n of the template support. Should we
have localised templates? At least localised template names. Etc.
Change-Id: I5675779a5b16bc4c70a943109aa0dd53cf4bd903
It turns out that the view of the DocumentViewController object is
removed from the view hierarchy when the camera is displayed, and
re-added after you choose to use the taken photo. Thus the
viewWillAppear: method is called again at that stage. The Document
object is stil quite intact, though. We should not call the Document
object's openWithCompletionHandler: method again, as that will cause
horrible brokenness.
Change-Id: Ib79bd8f292b01a19866278c4d95a2e816dcd9235
