Android App concept

Mobile App
#1

Flipper Android App

After reaching 300k$ goal Flipper support Bluetooth. And…

That means it’s time to make an Android app! (iOS app does not yet, you can join to develop here)

1280×720 24.5 KB

Concept

It is now up to you to determine what functions you would like to see in the application. Write to this topic if you have any ideas about Flipper App features.

I think the app must contain:

  • [MVPv1] Easy to contribute and add Android native module (maybe widget-style?), Bluetooth abstraction
  • [MVPv2] InApp Flipper Zero plugin catalog with one-click install
  • [MVPv3] Control flipper storage (keys, NFC tag and other)
  • [MVPv3] Share and sync (dropbox integration?) keys/NFC tag and other

1280×720 25.8 KB

Now I create some mockup. If you have any idea, send me a concept, please! :slightly_smiling_face:

1280×720 68.5 KB

Technical Features:

  • Clean Architecture with feature layer (View, Presenter, Repository) with Dagger/RxJava/RxBluetooth/Kotlin with multi-module arch
  • Full offline work without auth

Protocol

It’s not clear what protocol to use. It’s not clear yet. Requirements:

  • Small (only 1MB Flash memory)
  • Fast
  • Easy to develop

Now I think is protobuf with nanopb library: https://github.com/nanopb/nanopb
But… Maybe this is the wrong decision?

What do you think about it?
Join to develop here. Flipper needs Android, iOS developer, and designer! :heart:

8 Likes
#2

What’s about Kotlin Multiplatform?

1 Like
#3

This will increase the complexity of the application and will not add benefits. I think the flipper team can find iOS maintainter

1 Like
#4
#5

It’s better to keep iOS development separate, I believe. This will allow to have a nice app which will be a good citizen on Apple platforms, and Android app will become a good citizen on Google’s platform.

Also, SwiftUI has matured enough, allowing for native development on all Apple platforms simultaneously: watchOS, iOS, iPadOS, macOS (and even a tvOS app, should anyone want such an abomination :sweat_smile:).

I’m looking forward to develop an app for Apple platforms.

4 Likes
#6

nanopb quiet good as i think, and have low memory footprint.
Building abstraction wrappers around android bluetooth stack may be not so good, in all cases you will have special bluetooth bound “connection logic” and transfer logic that already abstracted in BluetoothSocket.

1 iteration:
Core features:

  1. Upload plugins to flipper from local computer
  2. Download/upload from local computer RFID, 1wire and all others captured signals, possibly we will have file abstraction for this type of data on Flipper side. So, if we have plugins that produce some data it can be transferred between host and flipper. Or maybe all data that produced by plugins should match predefined type set.
  3. Work with Infra red devices library, synchronize and update.
  4. something other basic use-cases ?

Flipper store:
Implement basic Flipper store, it will be killer feature. May be it will be integrated in bigger “Ffipper picture”, how different modules integrated, builded and deployed. For example if it will use something like Rust crates, we will pull code directly from github and build binary modules.

2 iteration:
Cloud synchronization and data storage, and all other fancy stuff.

#7

I think it would be better if they incorporate it into a pc because they mostly do it on a pc

1 Like
#8

I am hesitant to use cloud stuff. I would rather have the entire environment on my local machine. All the keydumps, backups, and other collected material should be local only first, and shared only by explicit permission to do so. This way I can share what keys, and only what keys I wish. Though, building a library of IR remotes for various devices would be cool!

7 Likes
#9

You can always disable/enable cloud sync. And i think that cloud sync using cloud storage (dropbox/google drive) with master-password archive crypt (like password manager). No one will be able to access your data. Even developers or cloud owners.

2 Likes
#10

I agree that is should be local first, but i don’t see why it would be written cloud first. There are a lot of ways to use local android storage in a unsafe manner. So local storage does not automaticly mean safe tho

1 Like
#11

Now i think about arch:

  1. app module (all base GUI and main application. Biggest module)
  2. core module (api/common debs/utils)
  3. bridge module (communication between android and flipper)
  4. community widget module
    4.1) iButton component
    4.2) NFC card holder
    4…) e.t.c

Technical specs:

  • RxJava
  • View or Fragment for UI. Single-Activity arch

In future we can add dynamic features

#12

This sounds great. I think in addition to the app, core, and bridge modules, it would be great to have support for app bundles to allow other developers to join this project and build the app together.

I have some experience with the RxBle library, and so far it was good for my use cases. It also aligns greatly with kotlin coroutines/flow. Didn’t work with protobuf though.

Is anyone willing to start the GitHub repository and continue the discussion there? We can begin with the mockups proposed by @LionZXY and build UI up from there.

#13

Need your PR review and Issue! :slight_smile:

#14

Have you considered using flutter. It compiles to Native Device code and can be combined with native app development. Things that are the same for both Android and iOS could be done in flutter and the good citizen stuff for each can be added natively.

https://flutter.dev/docs/development/add-to-app/ios/project-setup

#15

As I wrote earlier, it makes sense to keep Apple platforms app native.
At this early stage, it seems like iOS, iPadOS and watchOS app should be designed around iOS Shortcuts, a feature that Android totally lacks, and Android app can be made modular, which doesn’t work at all with Apple App Store.

The architectural difference won’t go well with crossplatform frameworks, and not adapting to respective platforms just means we get worse apps on both.

1 Like
#16

I’m agree at all. Native app for iOS would be better. Of course in such case we need some agreements about communication between devices.

2 Likes
#17

Yeah flutter would be good, have one version build to iOS, Android and Web. The web builds seem to be getting more stable every week.

#18

If there is going to be any desktop integration with this app, could it please include KDE Connect for Linux?

#19

Regarding cloud integration, please include support for Nextcloud.

#20

@LionZXY are you accepting PRs right now? I’d love to get in on this!