Flutter App

[k9withabone]

As discussed in #417, there is interest in creating a Flutter app for audiobookshelf. @keaganhilliard has shared his version that combines usage of audiobookshelf, Emby, and Plex. My current thinking is that we first need to answer some questions:

• Do we create a new standalone audiobookshelf Flutter app or help to improve the linked project?
• Do we create a separate Dart package for interfacing with the audiobookshelf API?
• If making a standalone app, should we attempt to replicate the current design exactly, do something similar but more Material, do something different that is Material (possibly Cupertino on iOS and Mac, possibly Fluent on Windows), or do something else entirely?
• Should we only replicate the existing features of the app or expand on them, including more features from the web version?

[k9withabone]

Here are my personal thoughts on the questions I posed:

Do we create a new standalone audiobookshelf Flutter app or help to improve the linked project?

I am leaning towards creating a standalone app, but I am not opposed to working on a combined project. I don't have an Emby or Plex server and was thinking of going the Jellyfin route instead eventually 🤷‍.

Do we create a separate Dart package for interfacing with the audiobookshelf API?

Yes, this way other projects can make use of it. The linked repo has an audiobookshelf API package in it, however I think it should exist in its own repo. Also, I think it would be good to remove the Flutter dependence if possible so that it can be more portable.

If making a standalone app, should we attempt to replicate the current design exactly, do something similar but more Material, do something different that is Material (possibly Cupertino on iOS and Mac, possibly Fluent on Windows), or do something else entirely?

I am personally most in favor of doing something similar but more Material. But I am somewhat biased as I am an Android and Linux user 🙃.

Should we only replicate the existing features of the app or expand on them, including more features from the web version?

I would like to expand on the features. Adding things such as searching for and downloading new podcasts to the server, uploading from the app, and potentially a podcast playlist/queue.

[Hackmodford]

• Do we create a new standalone audiobookshelf Flutter app or help to improve the linked project?

My vote would be for a standalone app that only works with Audiobookshelf.

• Do we create a separate Dart package for interfacing with the audiobookshelf API?

I'm in favor of this. It fits the open source nature of Audiobookshelf

• If making a standalone app, should we attempt to replicate the current design exactly, do something similar but more Material, do something different that is Material (possibly Cupertino on iOS and Mac, possibly Fluent on Windows), or do something else entirely?

My vote would be to make it look similar to the current Audiobookshelf app but maybe more Material influence. Even though I'm an iOS user, I don't think it's worth trying to match platform styles with Flutter. (.NET MAUI is better for something like that). I like keeping the UI simple and looking the same/similar on all platforms.

• Should we only replicate the existing features of the app or expand on them, including more features from the web version?

I would decide what the core features are, then expand from there.

[keaganhilliard]

The Audiobookshelf api I have now is already structured as a separate package. It does have a flutter dependencies but I think that can be ripped out easily. Happy to throw it in another repo, but it wasn't designed as a library so it would need refactoring. My main focus has been to just feel native to the platform on which the app is running. I'm not sure what the point of rebuilding the app in flutter to look like the current Audiobookshelf UI would be.

As for supporting multiple providers, I never did Jellyfin because audiobook support is even worse there than it is on Emby and Plex. Audiobookly has been my flutter playground for a couple of years so it has been through a lot of refactoring and design/architecture changes. When I started, there was no good server for audiobooks so I took the prologue route and built on top of Plex and later emby. With the advent of Audiobookshelf that kind of went out the window. It solved a lot of the issues that I was working around so it might be worth starting a new project just based on Audiobookshelf, it could remove a lot of the cruft.

That being said if you want just an Audiobookshelf looking flutter app creating another UI implementation is fairly trivial. I built the Mac version in around a week of minimal effort.

[Hackmodford]

Regarding making it look like Audiobookshelf, my issue with the current app is it's built with web technologies and you can tell. There's weird UI glitches where the whole app scrolls instead of just the content inside (because it's essentially scrollable webview).

So I think it really boils down to this.

Do we want to create an "official" alternative to the current app using Flutter? If yes, then it should probably look similar to the website.

[keaganhilliard]

I figured I would address these questions individually rather than in another thread haha

Do we create a new standalone audiobookshelf Flutter app or help to improve the linked project?

I'm fine either way, I won't likely contribute a ton to a separate app, but at least some of the API stuff should be reusable.

Do we create a separate Dart package for interfacing with the audiobookshelf API?

I think this is pretty doable. The API client is already a separate package inside the Audiobookly repo. Shouldn't be a ton of work to split it out and remove any flutter dependencies, which I don't think should be there anyway.

If making a standalone app, should we attempt to replicate the current design exactly, do something similar but more Material, do something different that is Material (possibly Cupertino on iOS and Mac, possibly Fluent on Windows), or do something else entirely?

I actually have been having a lot of fun porting the UI to a more native look and feel in each context. I have historically been a Linux and Android user. Recently switched over to Mac and iPhone and the material app felt really out of place, so I built a cupertino and Mac version. I would advocate for something that feels as native as possible, but that's my preference. I like material on android and to a lesser extent Linux, but it feels very strange on Apple OS's. I wouldn't mind building out a fluent ui. So long as you build out state models for each of the screens the UI for each platform is fairly easy to implement.

Should we only replicate the existing features of the app or expand on them, including more features from the web version?

I really have no preference here. I only listen to Audiobooks from Audiobookshelf and there aren't really any glaring features missing for me. At least not in Audiobookly, there are some missing pages/views in the ABS mobile app. In the ABS mobile app, I have found the downloads to be pretty finicky and it constantly starts books over for me, so I would try to rectify some of those issues.

[k9withabone]

Let me attempt to summarize the general consensus.

• Separate out the audiobookshelf API into its own Dart package.
• Standalone app to act as a replacement for the current app with a similar design but more Material (at least to start with) where it makes sense.
• Start with the core features and expand from there.

That makes sense to everyone?

Initial action items based on that understanding:

• Help to improve the main project's API documentation so that the API package can match it.
• Create the audiobookshelf API Dart package repo with the existing package as a starting point.
• Create the Flutter app's repo.
• Decide on the core features to start with.

Does that sound good?

[k9withabone]

I just meant for where we should put the repos. I wasn't sure if you had any plans to make a general audiobookshelf team or if these 2 new repos should go under your umbrella with us as maintainers.

[gbakeman]

I'm following this as a fan of audiobookshelf, but I feel the need to weigh in as someone who recently took over an abandoned github repo.

There's one repository I've been following and contributing to, where at one point the maintainer disappeared. That's the way things go with open source projects; we all have lives and sometimes life happens. I decided to create a GitHub Organization for the project (I'm guessing what we're referring to in here as a team), naming it in reference to the general subject it addressed.

I feel that GitHub Organizations are better designed with communities in mind. I think if we want to get serious about all things audiobooks (and podcasts), then it may be worth considering moving ABS and associated projects under one organizational umbrella.

[Hackmodford]

I like the idea of having an Audiobookshelf organization for these repos. It would be a good place to store the API repo and flutter_app repo in addition to the more official ones. @advplyr Would you be against that? We could specify in the two extra repos for Flutter that they are community maintained?

For example:
github.com/audiobookshelf/audiobookshelf
github.com/audiobookshelf/audiobookshelf-app
...
github.com/audiobookshelf/flutter-api
github.com/audiobookshelf/flutter-app

[advplyr]

I'll have to think about this some more because I'm not sure. As of now I'm leaning towards keeping all alternative clients completely separate. I think encouraging developers to build alternative clients and tools for abs is important which is why I want to get the API more stable, but grouping them in with the core software doesn't seem right.
It is early though, maybe just get this project off the ground with some users first.

[k9withabone]

Ok, I'll create the audiobookshelf_flutter organization. As I said earlier, we can always transfer ownership of the repos later.

[k9withabone]

I have created repositories for both the Dart API package, and the Flutter app. I have also started a discussion for deciding on the core features.

I added keaganhilliard and Hackmodford as members of the organization. If anyone else would like to be a part of it just let me know.

[sandreas]

I recently started https://github.com/sandreas/ToneAudioPlayer (C# + AvaloniaUI) as a cross platform approach until I stumbled over this discussion - now I'm unsure, that yet another UI is the right way to go. I would prefer the API supporting the OPENAPI instead of having a manually generated documentation and according clients.

I would also like to see a GenericMediaDataSource followed by AudioBookDataSource, MusicDataSource and PodcastDataSource interfaces to use, so that you could implement:

• AudiobookshelfDataSource
• EmbyDataSource
• PlexDataSource
• NavidromeDataSource
• JellyfinMusicDataSource, JellyfinAudioBookDataSource
• etc.

as separate projects / plugins or pull requests.

I also think that ONE SINGLE cross platform solution would be a good way to go to have less technologies and more developers working on the same thing. However, I think it is a MUST to have all the basic features ported - especially the native ones like:

• Lock Screen Menu
• Head Phone remote control

I use the audiobookshelf App on Android 12 every day and I already stumbled over a few rough edges, including:

• crashes even in lockscreen mode and has to be restarted manually
• does not even start on older devices (e.g. Android 7)
• hangs sometimes when streaming content

I also think that audiobookshelf-app UI could be a lot simpler (with the same feature set) and get some polish here and there. Let me know, if I can help you with anything - but be sure to have a developers getting started section in the documentation ;)