Create fragments appropriately in main view.
The approach to creating fragments in the constructor of the `AppListFragmentPagerAdapter`
was incorrect. Fragments are a special kind of magic, so this commit uses the approach
documented at http://stackoverflow.com/a/15261142 to make sure that the correct
fragment instances are always retrieved.
Fixes#521.
See merge request !190
Translators:
Ajeje Brazorf Sardinian
Alberto Moshpirit Spanish
hrskrs Albanian
Kalle Lampila Finnish
Mladen Pejaković Serbian
Persian: fix format strings Daniel Martí
Tobias Bannert German
Someone introduced lots of %I and and other weird format issues like %!.
Fixed all of them.
We normally catch these via Android's lint, but it appears that %I went
under its radar.
Fixes#530.
The approach to creating fragments in the constructor of the `AppListFragmentPagerAdapter`
was incorrect. Fragments are a special kind of magic, so this commit uses the approach
documented at http://stackoverflow.com/a/15261142 to make sure that the correct
fragment instances are always retrieved.
Fixes#521.
Translators:
Adrià García-Alzórriz Catalan
ageru French
Ajeje Brazorf Sardinian
Allan Nordhøy Norwegian Bokmål
Enol Puente Asturian
Erwin Scheuch-Heilig German
Karola Marky Japanese
Ldm Public French
Marcelo Santana Portuguese (Brazil)
Massimiliano Caniparoli Italian
naofum Japanese
Reiner Herrmann German
riotism Chinese (Hong Kong)
Tobias Bannert German
ultrapeer Turkish
Use custom layout for ACRA report dialog, not default one.
Styling the default dialog was difficult and it doesn't obey some
of the guidelines provided by the Android design docs:
https://www.google.com/design/spec/components/dialogs.html#dialogs-specs
(see "Content Guidelines")
This change introduces a custom dialog extending the base ACRA reporting
activity. Specifically, it introduces a padding of 24dp around the dialog
contents.
I couldn't find design specs on the specific spacing between different elements _within_ the dialog, so I used the same spacing of 20dp suggested to use between the title and the main body of the dialog.
At the very least, this change should make it easier to update styles in the future if somebody suggests improvements to the layout of the dialog.
### Before
### After
See merge request !186
Partially revert f2212e33. Make some constructors public again.
There is some code in the Android SDK using reflection to find the constructor
of one of our custom views. As such, a previous change in f2212e33 broke this
code because it made constructors package local. This partially reverts the bit
of f2212e33 which pertains to the constructors accessed using reflection.
Fixes#519.
See merge request !187
There is some code in the Android SDK using reflection to find the constructor
of one of our custom views. As such, a previous change in f2212e33 broke this
code because it made constructors package local. This partially reverts the bit
of f2212e33 which pertains to the constructors accessed using reflection.
Styling the default dialog was difficult and it doesn't obey some
of the guidelines provided by the Android design docs:
https://www.google.com/design/spec/components/dialogs.html#dialogs-specs
(see "Content Guidelines")
This change introduces a custom dialog extending the base ACRA reporting
activity. Specifically, it introduces a padding of 24dp around the dialog
contents.
This is thinking of the future, when new AFs are added and the installed
client doens't know about them yet. Showing the name is better than not
showing anything at all.
Translators:
Adrià García-Alzórriz Catalan
Ajeje Brazorf Sardinian
Alberto Moshpirit Spanish
Allan Nordhøy Norwegian Bokmål
Enol Puente Asturian
Kalle Lampila Finnish
Marcelo Santana Portuguese (Brazil)
Mladen Pejaković Serbian
naofum Japanese
Tobias Bannert German
Андрій Бандура Ukrainian
Саша Петровић Serbian
Add opt-in crash reporting via ACRA
Fixes#398.
Screenshot: https://imgur.com/E3uNIBY
E-mails to team@, so the reports are somewhat private yet still available to developers.
Using e-mail over POST has two advantages:
* Doesn't require a specific server handling the form submits
* Makes interaction with users who reported issues easy (we can just reply to the e-mail to ask for more info, etc)
It also has a disadvantage, though:
* It requires an e-mail app to be present and set up in the device
Most phones are already logged in to user's Google accounts, though, and a large part of those have the gmail app or the stock mail app installed. Those who don't have Google installed are probably technical enough to have set up a mail client like K9 on their own.
See merge request !185
Renaming id -> packageName in local variables/method args/comments/etc.
Building on the previous MR. This finishes renaming "id" in the Java code to "package name" where appropriate. It still leaves the database symbols as "id" because they are not worth the effort to rename at this point in time.
See merge request !184
Rename id to package name
As suggested in issue #37, "id" is not the correct terminology to use in the code base. Instead, it should use "package name". I'm doing this now before I begin work on #511, where it is helpful to recoup the "id" name, as "rowid" in sqlite refers to a row's integer primary key.
This changes the following Java symbols:
* `Apk.id` -> `Apk.packageName`
* `App.id` -> `App.packageName`
* `ApkProvider.DataColumns.ID` -> `ApkProvider.DataColumns.PACKAGE_NAME`
* `AppProvider.DataColumns.ID` -> `AppProvider.DataColumns.PACKAGE_NAME`
* A small number of comments referring to `id`.
It does _not_ change (and likely will not benefit from changing):
* Any database columns, these are all still `id`.
* Anything pertaining to the index, which still uses `id`.
It does _not_ change (but future MR's will change):
* Local variables referring to `id`
* Method names referring to `id`
By not changing any string literals, only changing the name of variables and constants, and ensuring that the original variables/constants are no longer present, then in theory if this compiles is should be good to merge.
See merge request !183
relan