Moved LOKitThread back to LibreOfficeMainActivity, so that it could
use the context in the constructor. Once the Context became available
in LOKitThread, it was simply a matter of replacing static references
with the one passed in the constructor.
Also changed access levels of some methods in LOKitThread.
Change-Id: I0cc2c846c67b90907cbf3dce363666f9ab02d887
Reviewed-on: https://gerrit.libreoffice.org/33546
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Removed references to static context, replaced them with the context
object already available in the class, and changed access levels on
some methods in LOKitTileProvider.
Change-Id: Ib52d325650377b77ec166ddbfb760f74c19067ff
Reviewed-on: https://gerrit.libreoffice.org/33554
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
This makes the dialog more modular, and it takes no parameters
instead of two. This is in the preparation of making
the classes more independent on each-other's states, which is very
important. Also, this follows the Android way of workflow better,
since there is no "wrapper" class around the dialog, but instead
the dialog is called directly.
Change-Id: I7571480a040efaf202fae3929cfe76d65c19653e
Reviewed-on: https://gerrit.libreoffice.org/33086
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Aleksandar Stefanović <theonewithideas@gmail.com>
Replaced empty spinner with the document title in the Main (viewer)
activity. Had to edit the themes to not disable title, and edit the
manifest to make the desired activities use that theme. If the theme
is set in the "application" tag, it will apply the theme globablly.
Also cleaned up and tightened the ToolbarController.
Change-Id: I5099860787b5f84d01c98c5e53ade519c2f89cc4
Reviewed-on: https://gerrit.libreoffice.org/33306
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Aleksandar Stefanović <theonewithideas@gmail.com>
Huge refactoring of the methods to use the passed instance of the
Context object instead of using the static one. I couldn't completely
remove the static object, because it requires restructuring of the
workflow so that it originates from the activity, and not from some
other random place. The way it was refactored is:
1. Find a place where the static object
(LibreOfficeMainActivity.mAppContext) is used.
2. Add a LibreOfficeMainActivity object to the method signature.
3. Repeat the process with a method that calls it, and repeat until
the LibreOfficeMainActivity object isn't available, so that it can be
passed through all the methods, to the place where the static object
was used.
4. Replace that static object with the parameter of the function.
The commit looks pretty huge, but it's basically just the simple
refactoring explained above. The memory leak isn't completely gone,
but this a progress towards it. Also moved the "global" objects of
Handler and LOKitThread from an Activity to an Application, which
is the correct place for "global" variables. Can someone explain why
Handler and LOKitThread are used? They seem to mostly do nothing, but
steeply increasing the complexity of the application.
Change-Id: Ib2be77fa3adea94d6b7849d0e2afa90bf318d68b
Reviewed-on: https://gerrit.libreoffice.org/33073
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Aleksandar Stefanović <theonewithideas@gmail.com>
It was coded pretty badly, so I cleaned it up. Most notably, it used
a static instance of the Activity, which is a huge no-no which
creates memory leaks. The irony is, it already had a reference to the
Activity used correctly in the constructor. One memory-leak fixed,
29 more to go (LibreOfficeMainActivity holds that static Activity
object which needs fixing). Also, simplified the "bottom toolbar"
in preparation for the CoordinatorLayout implementation which will
allow the activity to have fancy animations and smart interactions.
Change-Id: I31aa117f6179910db73a5256b0a287357e1dec83
Reviewed-on: https://gerrit.libreoffice.org/33010
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
Because RecyclerView is more optimized, especially if there are lot
of items. This way, we don't have to recreate ListView and GridView
each time we switch view modes. Changed list adapter to appropriate
RecyclerView adapter, and created new grid adapter inline, next to
the list adapter, while deleting the older grid adapter file. Since
these adapters are almost identical in content, maybe we could:
a) Make them extend the same "base" adapter, to avoid duplicate code
b) Unite them into one adapter which would display appropriate views
at appropriate times.
Change-Id: I1545c2c245ca642a689dee584bffb15f90aac4a6
Reviewed-on: https://gerrit.libreoffice.org/32976
Reviewed-by: jan iversen <jani@documentfoundation.org>
Tested-by: jan iversen <jani@documentfoundation.org>
Replaced the custom implementation of the drawer with the support library one.
This one inherently follows Material Design guidelines, and is much easier to
maintain. This implementation also allows for header in the drawer, and so
we could put something useful there to make the drawer even better. Also kept
the original way of programatically adding the menu items, although I find this
practice somewhat unelegant. Maybe we could have static list of items, and then
grey-out the ones that aren't currently available? Also added appropriate icons
to the menu items (which are vector drawables, of course), but I only covered
the providers that appeared on my device (I can't confirm that there are no
other providers), so if the provider is covered, it will have an icon, but if
I didn't cover it, it will appear just fine, but without an icon. Maybe we
could move the settings and sorting to the navigation drawer, also? It would
be cleaner and more elegant, IMO.
Change-Id: I02a051f0b75c6d4e16f518aa19fb9c6eef00f5e4
Reviewed-on: https://gerrit.libreoffice.org/32881
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
Replaced old and busted icon design, with Google's generic app icon.
It is now a vector drawable, which means it will be sharp at any resolution,
while we only need to keep one tiny xml file for it. No folder thumbnail
support, but this a welcomed change nontheless.
Change-Id: Ie6e38a6ac8e6cf1bc2d22247c11b5de0bd0d8478
Reviewed-on: https://gerrit.libreoffice.org/32498
Reviewed-by: jan iversen <jani@documentfoundation.org>
Tested-by: jan iversen <jani@documentfoundation.org>
Lowered all-caps navigation labels to something more professional.
Added a Spinner to the Toolbar in XML.
Reworked many lines of LibreOfficeUIActivity to remove possible NPE's, and also
removed redundant lines, which were mostly deprecated, as well as switching to
a newer implementation of a toolbar-spinner navigation pattern. There are more
deprecated methods, but I wanted them in a separate commit.
Change-Id: I15d5365ed7c00880873bf7874bc794008436bb99
Reviewed-on: https://gerrit.libreoffice.org/32497
Reviewed-by: jan iversen <jani@documentfoundation.org>
Tested-by: jan iversen <jani@documentfoundation.org>
Background:
External SD cards are only partially supported by the Android system,
with a great deal of fragmentation on implementation across manufacturers
and android versions. There is no official support for OTG devices.
This commit adds:
1) External SD card support
2) OTG device support
Caveats:
1) Not tested on Android 6. Emulator crashes when opening
files on Android 6, using an unmodified build of the master branch.
2) OTG support currently works only if there is write access
to the OTG directory. The user must be aware of exact OTG directory
path or be able to navigate to it as well.
3) External SD card provider currently lacks file filtering.
Approach:
-----
Added new document providers.
External SD cards:
There are 2 different document providers external sd cards,
one for Android 4.4 and above, and the other for older versions.
1) New
Android 4.4 and above require usage of the DocumentFile wrapper class
to access files in external storage. Actual file paths are no longer
obtainable. As such, the underlying file will be cloned in a cache,
allowing us to get an actual file path and use LOK.
Some differences exist between 4.4 & 5+. The document provider handles
each case separately.
2) Legacy
Android 4.3 and below do not support the DocumentFile wrapper.
File object can be used in these versions, allowing actual file paths
to be obtained. The document provider guesses the root directory of
the SD card. If the guessing fails, the user is to navigate to
this directory himself.
OTG:
The OTG document provider resembles the legacy external SD card
document provider, requiring the user to locate the directory himself.
The document provider does not guess the root directory of the OTG
device as the location varies with manufacturer implementation.
-----
Supplementary Notes:
Attempting to use the internal app cache as the file cache like in
the ownCloud document provider did not work. Using the external app
cache works fine though. It could be because initializing LOK wipes
the internal app cache.
Would be good to test the ownCloud document provider to confirm if it
works.
Change-Id: Ie727cca265107bc49ca7e7b57130470f7fc52e06
Reviewed-on: https://gerrit.libreoffice.org/20738
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
LOKit supports searching, but this was not implemented yet in the
Android GUI. This adds a bottom search toolbar where you can type
a search string + up/down search handles to search for the string
from the current cursor position.
Change-Id: Ia7461d2c6399c23201d2ea81f0b44c38533939a1
The bottom formatting toolbar now shows the formatting options
previously located in the main toolbar as a menu entry (bold,
italic, ...). In addition alignment options and selection of fonts
and sizes have been added.
Bottom formatting toolbar is not shown by default - it enables when
hitting the icon in main toolbar. Also soft keyboard and formatting
toolbar should not be shown at the same time.
Change-Id: I5f6cf8a9fcbdb4d154ae7504a65f9a226c99d694
We need to know the client's view level to correctly handle the mouse
events in calc. PaintTile() set a zoom level that corresponds to the
requested tiles and previously postMouseEvent would call SetZoom(1,1).
Now we can make use of knowing the client's view level and call
SetZoom() with the correct parameters
Change-Id: I34b5afcdcc06a671a8ac92c03e87404e42adf4cd
Conflicts:
sc/source/ui/unoobj/docuno.cxx
I forgot about this when I enabled other Calc file types in
07997cba7745997d7e2ed908a8764ba1f0777f1e (android: adapt doc browser to
updated manifest that accepts Calc documents, 2015-01-19).
Change-Id: Iabacffbfc09d806f09bc7e0f9307830bda8ebbe1
using AssetsManager in both java as well as native parts allows to
handle files both with and without compression transparently
Change-Id: If02f1159c498be7ea965fd9c217410722f2dca1f
