boswelja / nasdroid Goto Github PK

View Code? Open in Web Editor NEW

35.0 4.0 4.0 1.43 MB

NASdroid is an unofficial Android client for TrueNAS server management

License: GNU General Public License v3.0

Kotlin 100.00%

android compose unofficial-client kotlin material3 truenas

nasdroid's Introduction

NASdroid

NASdroid is an unofficial Android client for TrueNAS server management.

Releases

You can get nightly builds from our CI runs. Stay tuned for alpha, beta and stable releases!

Screenshots

Screenshots coming soon.

State of Development

Features correspond to the menu items you see in the TrueNAS SCALE web interface.

Feature	Status
Dashboard	Available
Storage	In progress
Apps	In progress
Reporting	In progress
Datasets	Not yet started
Shares	Not yet started
Data Protection	Not yet started
Network	Not yet started
Credentials	Not yet started
Virtualization	Not yet started
System Settings	Not yet started

Libraries

Networking: Ktor Client
User Interface: Jetpack Compose
Dependency Injection: Koin

Dependency versions (and artifact coordinates) are strictly managed via Version Catalogs, with the one exception of the Android settings plugin located in settings.gradle.kts. Take a look at our libs.versions.toml to see exact versions and a full list of libraries used.

Architecture

At a high level the application is split into 3 levels, detailed below.

Core

Core is a collection of modules that serve as "foundational" components. Most, if not all of these are planned to be moved to separate libraries in the near future.

Features

The "meat" of NASdroid lives here. This is a collection of modules that build every feature within the app, which are further separated into a maximum of 3 modules per feature.

Data

If a feature requires its own data source (local repositories, APIs not found in the TrueNAS API, etc), its abstraction and implementation will be here. This is the only optional module in the set of modules for any given feature.

Logic

NASdroid adopts the "use case" pattern, where business logic (Create a pool, delete an application, etc) are all extracted and broken down into single-responsibility classes.

UI

All UI for any particular feature lives here. This includes screens, navigation graphs, ViewModels, etc.

App

This is the application module. It's what depends on all the features before it, and puts it all together into a usable app for your phone.

Other Stuff

What

TrueNAS is an open-source NAS operating system. NASdroid is a native Android app that will (eventually) give you the same level of control over your TrueNAS install as the website.

Why

Have you ever tried to use the TrueNAS website (or any reasonably complex management interface) on your phone? It's not much fun, so let's set out to fix that.

nasdroid's People

Contributors

Stargazers

Watchers

Forkers

saroj-maharjan imashnake0 philipk99 gmh5225

nasdroid's Issues

Allow browsing available application

TrueNAS allows users to browse catalogs for applications that can be installed. We should support this too.

Set up screen to display items
Fix deserialize issues when retrieving items from job output
Improve resiliency of fetching available apps

Only run tests against modules that have changed

As of #276 we run existing unit tests against pull requests. As we write more unit tests, this step is going to become more resource intensive. To avoid wasting significant resources, we should only run tests against modules that have changed.

Dashboard - System Information card

Create empty Dashboard module

This will act as an entrypoint for the Dashboard feature

Dashboard - Storage card

Display ZFS & Services memory utilisation in Dashboard

TrueNAS web shows a chart with a breakdown of memory usage by ZFS cache, services, and free memory. Example:

This data is provided to us via the API, but currently we only display used and free memory. It'd be cool if we showed what was used by what.

Sometimes the "Register Server" screen closes without completing successfully

Sometimes when attempting to register a new server, the "Register Server" screen just disappears, and the user is returned to the splash screen.
This appears to be caused by an exception being swallowed somewhere, so the coroutine running the work gets cancelled.

Dashboard - CPU card

Vico API does not play nice with our app architecture

Vico's new API does not play nice with our architecture. Implementations are relatively messy and hard to streamline because of this.

We should either rethink our UI architecture, or move away from Vico.

This doesn't affect many areas of the app (dashboard and reporting, so far), so not a huge priority.

Navigation architecture is fundamentally incompatible with predictive back & split views

Our current nav architecture looks something like

NavigationScaffold(
  topBar = {},
  sideBar = {},
  bottomBar = {}
) {
  NavHost {
    // All our destinations configured here
  }
}

This has worked well for a while for a couple of reasons

Feature screens are completely unaware, and thus isolated, from navigation-related components
Navigation UI is always a reflection of our one-and-only NavHost

There are some pretty major problems creeping up on us now though

Predictive back doesn't feel right when the top app bar (and in some cases, the bottom & side navigation components) don't animate with the rest of the content
Screens that would benefit from a custom title cannot (easily) do so
Introducing a second NavHost causes problems with the navigation UI
- This is most notably for split views, such as a list/detail view

We need to solve this, preferably before creating any new screens to avoid increase in scope (it will affect every single screen, more screens = more work).
I think due to the nature of the change we will lose the "Feature screens are completely unaware, and thus isolated, from navigation-related components" benefit, but we should still try to keep navigation state a reflection of our NavHost as much as possible.