Previous code was:
```
for (i in tabs.indices) {
// ...
if (tabs[i].id == LIST) {
tab.contentDescription = tabs[i].arguments[1]
} else {
tab.setContentDescription(tabs[i].text)
}
// ...
```
When I converted it over, `i` was replaced with `position`, but I misread `tab.contentDescription = tabs[i].arguments[1]` as `tab.contentDescription = tabs[i].arguments[i]`.
Put the `1` back.
Make `tabs` `var` instead of `val` in `MainPagerAdapter` so it can be updated
when tabs change.
Then detach the `tabLayoutMediator`, update the tabs, and call
`notifyItemRangeChanged` in `setupTabs()`.
This fixes a bug (not sure if it's this code, or in ViewPager2) where
assigning a new adapter to the view pager seemed to result in a leak of one
or more fragments. This wasn't user-visible, but it's a leak, and it becomes
user-visible when fragments want to display menus.
This also fixes two other bugs:
1. Be on the left-most tab. Scroll down a bit. Then modify the tabs at
"Account preferences > tabs", but keep the left-most tab as-is.
Then go back to MainActivity. Your reading position in the left-most
tab has been jumped to the top.
2. Be on any non-left-most tab. Then modify the tab list by reordering tabs
(adding/removing tabs is also OK).
Then go back to MainActivity. Your tab selection has been overridden,
and the left-most tab has been selected.
Because the fragments are not destroyed unnecessarily your reading position
is retained. And it remembers the tab you had selected, and as long as that
tab is still present you will be returned to it, even if it's changed
position in the list.
Fixes https://github.com/tuskyapp/Tusky/issues/3251
* Add support for updating media description and focus point when editing statuses
* Don't publish description/focus point updates via the standard api when editing a published post
* Add initial feature for viewing trending graphs. Currently only views hash tag trends.
Contains API additions, tab additions and a set of trending components.
* Add clickable system through a LinkListener. Duplicates a little code from SFragment.
* Add accessibility description.
* The background for the graph should match the background for black theme too.
* Add error handling through a state flow system using existing code as an example.
* Graphing: Use a primary and a secondary line. Remove under line fill. Apply line thickness. Dotted end of line.
* Trending changes: New layout for trending: Cell. Use ViewBinding. Add padding to RecyclerView to stop the FAB from hiding content. Multiple bugs in GraphView resolved. Wide (landscape, for example) will show 4 columns, portrait will show 2. Remove unused base holder class. ViewModel invalidate scoping changed. Some renaming to variables made. For uses and accounts, use longs. These could be big numbers eventually. TagViewHolder renamed to TrendingTagViewHolder.
* Trending changes: Remove old layout. Update cell textsizes and use proper string. Remove bad comment.
* Trending changes: Refresh the main drawer when the tabs are edited. This will allow the trending item to toggle.
* Trending changes: Add a trending activity to be able to view the trending data from the main drawer.
* Trending changes: The title text should be changed to Trending Hashtags.
* Trending changes: Add meta color to draw axis etc. Draw the date boundaries on the graph. Remove dates from each cell and place them in the list as a header. Graphs should be proportional to the highest historical value. Add a new interface to control whether the FAB should be visible (important when switching tabs, the state is lost). Add header to the adapter and viewdata structures. Add QOL extensions for getting the dates from history.
* Trending changes: Refresh FAB through the main activity and FabFragment interface. Trending has no FAB.
* Trending changes: Make graph proportional to the highest usage value. Fixes to the graph ratio calculations.
* Trending changes: KtLintFix
* Trending changes: Remove accidental build gradle change. Remove trending cases. Remove unused progress. Set drawer button addition explicitly to false, leaving the code there for future issue #3010. Remove unnecessary arguments for intent. Remove media preview preferences, there is nothing to preview. No padding between hashtag symbol and text. Do not ellipsize hashtags.
* Trending changes: Use bottomsheet slide in animation helper for opening the hashtag intent. Remove explicit layout height from the XML and apply it to the view holder itself. The height was not being respected in XML.
* Use some platform standards for styling
- Align on an 8dp grid
- Use android:attr for paddingStart and paddingEnd
- Use textAppearanceListItem variants
- Adjust constraints to handle different size containers
* Correct lineWidth calculations
Previous code didn't convert the value to pixels, so it was always displaying
as a hairline stroke, irrespective of the value in the layout file.
While I'm here, rename from lineThickness to lineWidth, to be consistent
with parameters like strokeWidth.
* Does not need to inherit from FabFragment
* Rename to TrendingAdapter
"Paging" in the adapter name is a misnomer here
* Clean up comments, use full class name as tag
* Simplify TrendingViewModel
- Remove unncessary properties
- Fetch tags and map in invalidate()
- emptyList() instead of listOf() for clarity
* Remove line dividers, use X-axis to separate content
Experiment with UI -- instead of dividers between each item, draw an explicit
x-axis for each chart, and add a little more vertical padding, to see if that
provides a cleaner separation between the content
* Adjust date format
- Show day and year
- Use platform attributes for size
* Locale-aware format of numbers
Format numbers < 100,000 by inserting locale-aware separators. Numbers larger
are scaled and have K, M, G, ... etc suffix appended.
* Prevent a crash if viewData is empty
Don't access viewData without first checking if it's empty. This can be the
case if the server returned an empty list for some reason, or the data has
been filtered.
* Filter out tags the user has filtered from their home timeline
Invalidate the list if the user's preferences change, as that may indicate
they've changed their filters.
* Experiment with alternative layout
* Set chart height to 160dp to align to an 8dp grid
* Draw ticks that are 5% the height of the x-axis
* Legend adjustments
- Use tuskyblue for the ticks
- Wrap legend components in a layout so they can have a dedicated background
- Use a 60% transparent background for the legend to retain legibility
if lines go under it
* Bezier curves, shorter cell height
* More tweaks
- List tags in order of popularity, most popular first
- Make it clear that uses/accounts in the legend are totals, not current
- Show current values at end of the chart
* Hide FAB
* Fix crash, it's not always hosted in an ActionButtonActivity
* Arrange totals vertically in landscape layout
* Always add the Trending drawer menu if it's not a tab
* Revert unrelated whitespace changes
* One more whitespace revert
---------
Co-authored-by: Nik Clayton <nik@ngo.org.uk>
* make BlocksAdapter use viewbinding
* remove LoadingFooterViewHolder
* cleanup code
* move accountlist to component packes
* make FollowRequestsHeaderAdapter use viewbinding
* add license to MutesAdapter
* move accountlist to component packages
* use ConstraintLayout in item_blocked_user.xml
* support the bot badge everywhere
* cleanup code
* cleanup xml files
* ktlint
* ktlint
* upgrade AndroidX dependencies
* use new @Upsert in InstanceDao
* fix crash because of new Room nullchecks
* make TimelineStatusEntity.reblogAccount a val as well
* Perform preference schema upgrades at startup
Over time it can be desirable to change how preferences are interpreted.
Preferences might be removed, or renamed. Or the default value for a
preference might be changed.
When this happens it's important that users upgrading from one version to
the next (or jumping from one version to several versions ahead) get a
consistent experience. In particular:
- Preferences that no longer exist should be deleted
- Preferences that have been renamed should have the old preference values
copied over
- If the user used the default value for the preference, and the default has
changed, the previous default value should be explicitly set as their
value for the preference
To support this, store a SCHEMA_VERSION as a preference. This is not exposed
to the user, and corresponds to the app's VERSION_CODE.
If the version code does not match the schema version then this is a newer
version of the app with older preferences that may need to be changed.
Those changes will be implemented in `upgradeSharedPreferences`.
* Translated using Weblate (Hungarian)
Currently translated at 100.0% (552 of 552 strings)
Co-authored-by: Gera, Zoltan <gerazo@manioka.hu>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/hu/
Translation: Tusky/Tusky
* Translated using Weblate (Chinese (Simplified))
Currently translated at 100.0% (552 of 552 strings)
Co-authored-by: Eric <alchemillatruth@purelymail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/zh_Hans/
Translation: Tusky/Tusky
* Translated using Weblate (Ukrainian)
Currently translated at 100.0% (552 of 552 strings)
Co-authored-by: Ihor Hordiichuk <igor_ck@outlook.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/uk/
Translation: Tusky/Tusky
* Translated using Weblate (Vietnamese)
Currently translated at 100.0% (552 of 552 strings)
Co-authored-by: Hồ Nhất Duy <mastoduy@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/vi/
Translation: Tusky/Tusky
* Translated using Weblate (Belarusian)
Currently translated at 100.0% (552 of 552 strings)
Co-authored-by: Mikalai <mikalai.hryb@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/be/
Translation: Tusky/Tusky
* Translated using Weblate (Belarusian)
Currently translated at 100.0% (552 of 552 strings)
Co-authored-by: Andrej Zabavin <andre.zabavin@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/be/
Translation: Tusky/Tusky
* Translated using Weblate (Belarusian)
Currently translated at 100.0% (552 of 552 strings)
Co-authored-by: Mikalai <mikalai.hryb@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/be/
Translation: Tusky/Tusky
* Translated using Weblate (Belarusian)
Currently translated at 100.0% (552 of 552 strings)
Translated using Weblate (Belarusian)
Currently translated at 100.0% (552 of 552 strings)
Co-authored-by: xzFantom <xzfantom@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/be/
Translation: Tusky/Tusky
* Translated using Weblate (Japanese)
Currently translated at 91.3% (504 of 552 strings)
Co-authored-by: TAKAHASHI Shuuji <shuuji3@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/ja/
Translation: Tusky/Tusky
* Translated using Weblate (Icelandic)
Currently translated at 100.0% (552 of 552 strings)
Co-authored-by: Sveinn í Felli <sv1@fellsnet.is>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/is/
Translation: Tusky/Tusky
* Translated using Weblate (Belarusian)
Currently translated at 100.0% (552 of 552 strings)
Co-authored-by: Mikalai <mikalai.hryb@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/be/
Translation: Tusky/Tusky
* Lint
---------
Co-authored-by: Gera, Zoltan <gerazo@manioka.hu>
Co-authored-by: Eric <alchemillatruth@purelymail.com>
Co-authored-by: Ihor Hordiichuk <igor_ck@outlook.com>
Co-authored-by: Hồ Nhất Duy <mastoduy@gmail.com>
Co-authored-by: Mikalai <mikalai.hryb@gmail.com>
Co-authored-by: Andrej Zabavin <andre.zabavin@gmail.com>
Co-authored-by: xzFantom <xzfantom@gmail.com>
Co-authored-by: TAKAHASHI Shuuji <shuuji3@gmail.com>
Co-authored-by: Sveinn í Felli <sv1@fellsnet.is>
Verified by enabling "Pointer Location" in the developer options, and then experimenting to see which angles trigger opens of the nav. drawer, and in a stock "Tabbed Activity" generated in Android Studio (New > Activity > Tabbed Activity) that uses ViewPager2.
* First attempt at user notifications of failure when media upload fails
* Drafts alert displays alert
* ktLint
* Fix defaced 46.json, add 47.json
* Mock draftsNeedUserAlert in MainActivityTest to prevent spurious failure
* Friendlier posts-failed message
* Create DraftsAlert object
* DraftsAlert works
* Not the cleanest, but DraftsAlert works with multiple accounts
* Use plural strings
* KtLint
* Clean up debug prints
* Simplify DraftsAlert per Conny suggestions
* Text change suggested by Conny
* ktLint again
* Back out test changes
* Fix MainActivityTest for new approach
* Tweak debug log
* Do not use GlobalScope for coroutines
* Check for status "type" before casting.
* Update app/src/main/java/com/keylesspalace/tusky/components/viewthread/ViewThreadViewModel.kt
Co-authored-by: Nik Clayton <nik@ngo.org.uk>
* Make sure no placeholder is returned as status
---------
Co-authored-by: Nik Clayton <nik@ngo.org.uk>
* Reinstate optional login via custom browser tab
* Clarify the buttons for the different login options
* Add informative labels for the different login options
* Move "Login with Browser" to the options menu
MIME type detection for files based on extensions (the `getType()` method)
returns incorrect results from DownloadProvider and FileProvider for (at
least) .m4a files.
Investigation details are in https://github.com/tuskyapp/Tusky/issues/3189
Be safe, and use `MediaMetadataRetriever` to sniff the content of the files
to determine the correct type.
Fixes https://github.com/tuskyapp/Tusky/issues/3189
* Handle preference fragments using the framework
The previous code started new preference "screens" as activities, even though
each one hosted a single fragment.
Modify this to use the framework's support for swapping in/out different
preference fragments.
PreferencesActivity:
- Remove the code for launching tab and proxy preferences
- Remove the code for setting titles, each fragment is responsible for that
- Implement OnPreferenceStartFragmentCallback to swap fragments in/out with
the correct animation
PreferencesFragment:
- Use `fragment` property instead of `setOnPreferenceClickListener`
- Set the activity title when resuming
Everything else:
- Set the activity title when resuming
* Implement HTTP proxy summary as a SummaryProvider
Uses the frameworks's support for setting summaries instead of rolling our
own.
Also fix a tiny bug -- the minimum port number to connect to should be 1,
not 0.
* Lint
* Change "Load more" to load oldest statuses first in home timeline
Previous behaviour loaded missing statuses by using "since_id" and "max_id".
This loads the most recent N statuses, looking backwards from "max_id".
Change to load the oldest statuses first, assuming the user is scrolling
up through the timeline and will want to load statuses in reverse
chronological order.
* Scroll to the bottom of new entries added by "Load more"
- Remember the position of the "Load more" placeholder
- Check the position of inserted entries
- If they match, scroll to the bottom
* Change "Load more" to load oldest statuses first in home timeline
Previous behaviour loaded missing statuses by using "since_id" and "max_id".
This loads the most recent N statuses, looking backwards from "max_id".
Change to load the oldest statuses first, assuming the user is scrolling
up through the timeline and will want to load statuses in reverse
chronological order.
* Scroll to the bottom of new entries added by "Load more"
- Remember the position of the "Load more" placeholder
- Check the position of inserted entries
- If they match, scroll to the bottom
* Ensure the user can't have two simultaneous "Load more" coroutines
Having two simultanous coroutines would break the calculation used to figure
out which item in the list to scroll to after a "Load more" in the timeline.
Do this by:
- Creating a TimelineUiState and associated flow that tracks the "Load more"
state
- Updating this in the (Cached|Network)TimelineViewModel
- Listening for changes to it in TimelineFragment, and notifying the adapter
- The adapter will disable any placeholder views while "Load more" is active
* Revert changes that loaded the oldest statuses instead of the newest
* Be more robust about locating the status to scroll to
Weirdness with the PagingData library meant that positionStart could still be
wrong after "Load more" was clicked.
Instead, remember the position of the "Load more" item and the ID of the
status immediately after it.
When new items are added, search for the remembered status at the position of
the "Load more" item. This is quick, testing at most LOAD_AT_ONCE items in
the adapter.
If the remembered status is not visible on screen then scroll to it.
* Lint
* Add a preference to specify the reading order
Default behaviour (oldest first) is for "load more" to load statuses and
stay at the oldest of the new statuses.
Alternative behaviour (if the user is reading from top to bottom) is to
stay at the newest of the new statuses.
* Move ReadingOrder enum construction logic in to the enum
* Jump to top if swipe/refresh while preferring newest-first order
* Show a circular progress spinner during "Load more" operations
Remove a dedicated view, and use an icon on the button instead.
Adjust the placeholder attributes and styles accordingly.
* Remove the "loadMoreActive" property
Complicates the code and doesn't really achieve the desired effect. If the
user wants to tap multiple "Load more" buttons they can.
* Update comments in TimelineFragment
* Respect the user's reading order preference if it changes
* Add developer tools
This is for functionality that makes it easier for developers to interact
with the app, or get it in to a known-state.
These features are for use by users, so are only visible in debug builds.
* Adjust how content is loaded based on preferred reading order
- Add the readingOrder to TimelineViewModel so derived classes can use it.
- Update the homeTimeline API to support the `minId` parameter and update
calls in NetworkTimelineViewModel
In CachedTimelineViewModel:
- Set the bounds of the load to be the status IDs on either side of the
placeholder ID (update TimelineDao with a new query for this)
- Load statuses using either minId or sinceId depending on the reading order
- Is there was no overlap then insert the new placeholder at the start/end
of the list depending on reading order
* Lint
* Rename unused dialog parameter to _
* Update API arguments in tests
* Simplify ReadingOrder preference handling
* Fix bug with Placeholder and the "expanded" property
If a status is a Placeholder the "expanded" propery is used to indicate
whether or not it is loading.
replaceStatusRange() set this property based on the old value, and the user's
alwaysOpenSpoiler preference setting.
This shouldn't have been used if the status is a Placeholder, as it can lead
to incorrect loading states.
Fix this.
While I'm here, introduce an explicit computed property for whether a
TimelineStatusEntity is a placeholder, and use that for code clarity.
* Set the "Load more" button background to transparent
* Fix typo.
* Inline spec, update comment
* Revert 1480c6aa3a
Turns out the behaviour is not desired.
* Remove unnecessary Log call
* Extract function
* Change default to newest first
* Remove rxjava from API calls used by AccountListFragment
* Remove rxjava from API calls used by AccountViewModel::changeRelationship()
The affected API functions are also called from
- ReportViewModel.kt
- SearchViewModel.kt
- AccountListFragment.kt
- SFragment.java
- TimelineCases.kt
so they have also been updated.
This change requires bridging from Java code to Kotlin `suspend` functions,
by creating wrappers for the `mute` and `block` functions that can be
called from Java and create a coroutine scope.
I've deliberately made this fairly ugly so that it sticks out and can be
removed later.
* Use "Throwable" type and name
* Delete 46.json
Not sure where this came from.
* Remove rxjava from the deleteStatus call path
* Emit log messages with the correct tag
* Add another log tag, and lint
* Use TAG in log messages now it's present
* Lint
* Move viewModelScope.launch in to changeRelationshop()
* Use onSuccess/onFailure pair instead of fold
* Return Deferred when deleting statuses
* Improve the actual and perceived speed of thread loading
To improve the actual speed, note that if the user has opened a thread from
their home timeline then the initial status is cached in the database. Other
statuses in the same thread may be cached as well.
So try and load the initial status from the database, falling back to the
network if it's not present (e.g., the user has opened a thread from the
local or federated timelines, or a search).
Introduce a new loading state to deal with this case.
In typical cases this allows the UI to display the initial status immediately
with no need to show a progress indicator.
To improve the perceived speed, delay showing the initial loading circular
progress indicators by 500ms. If loading the initial status completes within
that time no spinner is shown and the user will perceive the action as
close-to-immediate
(https://www.nngroup.com/articles/response-times-3-important-limits/).
Additionally, introduce an extra indeterminate progress indicator.
The new indicator is linear, anchored to the bottom of the screen, and shows
progress loading ancestor/descendant statuses. Like the other indicator is
also delayed 500ms from when ancestor/descendant status information is
fetched, and if the fetch completes in that time it will not be shown.
* Mark `getStatus` as suspend so it doesn't run on the main thread
* Save an allocation, use an isDetailed parameter to TimelineStatusWithAccount.toViewData
Rename Status.toViewData's "detailed" parameter to "isDetailed" for
consistency with other uses.
* Ensure suspend functions run to completion when testing
* Delay-load the status from the network even if it's cached
This speeds up the UI while ensuring it will eventually contain accurate data
from the remote.
* Load the network status before updating the list
Avoids excess animations if the network copy has changes
* Fix UI flicker when loading reblogged statuses
* Lint
* Fixup tests
The intent of the previous code seems to be to show an "X" icon on a hashtag
chip when two or more chips are present.
This didn't work because the icon was not set as visible.
Fix this. In addition, set this as a "cancel" icon, not the chip's regular
icon, so it appears on the right (in LTR locales), as is normal for the
close button on chips.
Tinting the icon did nothing, so remove that.
* Share and copy menu items for account page (first attempt)]
* Always include domain in username in 'handle' copy
* Remove profile copy options, rename 'handle' to 'username'
* Long press on username in profile to copy it to clipboard
* Changes for code review: localUsername not username, Snackbar not Toast
* Do not trust getDomain() when getting full username. This means full-username build has to happen in AccountActivity instead of Account
* Replace != null -> \!\! idiom with more kotlin-y (and more threadsafe) ?.let pattern
* Unnecessary import
* Comment clarifying safety of \!\!
* show status edits part 1
* show status edits part 2 - load status edits
* fix code formatting
* add dialog to show status edits
* small improvements
* use ALIGN_CENTER to position status visibility icon when possible
* rename status_timestamp_info view to status_meta_info
* make dateFormat static
* remove commented-out code
* move edits to dedicated fragment
* Fix saving changes to statuses when editing
With the previous code backing out of a status editing operation where changes
had been made (whether it was editing an existing status, a scheduled status,
or a draft) would prompt the user to save the changes as a new draft.
See https://github.com/tuskyapp/Tusky/issues/2704 and
https://github.com/tuskyapp/Tusky/issues/2705 for more detail.
The fix:
- Create an enum to represent the four different kinds of edits that can
happen
- Editing a new status (i.e., composing it for the first time)
- Editing a posted status
- Editing a draft
- Editing a scheduled status
- Store this in ComposeOptions, and set it appropriately everywhere
ComposeOptions is created.
- Check the edit kind when backing out of ComposeActivity, and use this to
show one of three different dialogs as appropriate so the user can:
- Save as new draft or discard changes
- Continue editing or discard changes
- Update existing draft or discard changes
Also fix ComposeViewModel.didChange(), which erroneously reported false if the
old text started with the new text (e.g., if the old text was "hello, world"
and it was edited to "hello", didChange() would not consider that to be a
change).
Fixes https://github.com/tuskyapp/Tusky/issues/2704,
https://github.com/tuskyapp/Tusky/issues/2705
* Use orEmpty extension function
* Handle preference fragments using the framework
The previous code started new preference "screens" as activities, even though
each one hosted a single fragment.
Modify this to use the framework's support for swapping in/out different
preference fragments.
PreferencesActivity:
- Remove the code for launching tab and proxy preferences
- Remove the code for setting titles, each fragment is responsible for that
- Implement OnPreferenceStartFragmentCallback to swap fragments in/out with
the correct animation
PreferencesFragment:
- Use `fragment` property instead of `setOnPreferenceClickListener`
- Set the activity title when resuming
Everything else:
- Set the activity title when resuming
* Lint
* Use the commit extension function
* Fix off-by-one error in HttpHeaderLink
Link headers with multiple URLs with multiple parameters were being parsed
incorrectly.
Detected by adding unit tests ahead of converting to Kotlin.
* Convert util/HttpHeaderLink from Java to Kotlin
* Convert util/ThemeUtils from Java to Kotlin
* Convert util/TimestampUtils from Java to Kotlin
* Add tests for PairedList
* Convert util/PairedList from Java to Kotlin
* Implement feedback from PR
* Relicense as GPL
These aren't necessary for the app, and are overwritten with the actual style
in `BaseActivity.onCreate()`.
But if they're missing the Android Studio layout preview renderer crashes.
* Leave the "edit scheduled status" button enabled after clicking
If the user submits an edit to the scheduled status then this one will be deleted, the paging source will notice, the adapter will be notified in the normal way, and this binding will be reused.
Or the user backs out of the edit, and this adapter entry is still valid and should remain clickable.
Fixes https://github.com/tuskyapp/Tusky/issues/2705
* Remove unnecessary parameter.
* Remove unnecessary import
* Fix auto play when swiping between attachments
Fixes an issue where attachment doesn't autoplay when swiping left/right from initial attachment.
Fixes#3066
* Fix lint error for wild card imports
* Convert AccountViewHolder from Java to Kotlin
Use view binding in the converted code, which requires small changes in code
that calls constructors.
Pass showBotOverlays as a parameter, rather than having the code reach in to
the shared preferences, fixing a layering violation. This affects callers
and classes derived from AccountAdapter.
* Use 2-arg getString
* Simplify setting bot badge indicator
- Specify the drawable in the XML
- Use visible() to set visibility
- Rename ID to account_bot_badge to make it clearer that this is all it is for
* Use lateinit to avoid needing !! later
Nik Clayton
Levi Bard
David Edwards
Konrad Pozniak
Goooler
mcclure
UlrichKu
Conny Duck
Eric Frohnhoefer