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>
as non-native mipmap resolutions don't get stripped from the apk (as
drawables would), but launchers and similar might still want to show the
higher-res version instead. Google Play store now enforces this.
Also rename to the common name for it ("ic_launcher" instead of "main")
Change-Id: I97318287f05556f5db0afaa0b23c0d8c9628465e
Reviewed-on: https://gerrit.libreoffice.org/31204
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
and account for the libreofficekit changes
This reverts commit 50e9065cbbb2c62fa925cf5b561a85c715a0eb1e.
that did in turn revert 4ae8c3c20bd4a10ba141a32f01e23ac63636f9c3.
Change-Id: Ie02d8743b3608120ed63bfe2a014fa4139577b01
the linux build / libreofficekit also uses those and needs to be told
about this change as well.
This reverts commit 4ae8c3c20bd4a10ba141a32f01e23ac63636f9c3.
If we draw a black graphic handle manually, then it's possible to color
it later, this isn't easy if a bitmap is painted.
Change-Id: Ib4456fd5155862d52e3ffa79ee49c7bfd16fb742
Reviewed-on: https://gerrit.libreoffice.org/26860
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.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>
Duplicate <include layout="@layout/toolbar"/> statement found.
Problem could be caused by either
1) a differing xml reading mechanism across android versions
2) toolbar being accessed in a different way across android versions
Duplicate element removed, and linearlayout shifted below first toolbar.
Change-Id: I084b6498745bc72988f3a8eed12f7a72d261e267
Reviewed-on: https://gerrit.libreoffice.org/20422
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
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
