> We built an Android app in Haskell because Python was too hard for loading shared objects.

Can you elaborate the process? The only reference I could only find this: https://wiki.haskell.org/Android.

How did you end up developing/deploying your UI?

We used reflex-frp, so our app was a webview that worked on localhost and Android. The docs say it also works on iOS but we don't have an iPhone.

The process was learning Functional Reactive Programming, then learning reflex-frp, then getting a contract with obsidian (creators of reflex) for one hour a week where we could ask questions.

( https://github.com/reflex-frp/reflex-platform )

We had a grant requirement to create a phone client for Tahoe-LAFS, a Python application with a bunch of dependencies, including ZFEC, a forward error correction library.

( https://tahoe-lafs.readthedocs.io/ )

( https://github.com/tahoe-lafs/zfec/ )

We needed bug for bug compatibility with the Python codebase, so I ran Tahoe on localhost and tested the Haskell client against the Python server. We used servant to build the API, since it builds both client and server side from the same description.

( https://hackage.haskell.org/package/servant )

Thanks for your notes. Any chance your app is on the Play store so that I can check it out?

I just checked, it hasn't been approved yet.

Should be named "private storage" when it does show up in the app store.

Even so, it won't be useful until you have a Tahoe-LAFS shared magic folder.

Hopefully we'll get funding to make a default shared folder for getting started!

I don't know if it's been approved yet, but it's open source: https://whetstone.private.storage/privatestorage/privatestor...

I wrote a blog post https://shapr.github.io/posts/2023-07-25-android-app-in-hask...

I hope this helps

From my personal viewpoint the most beneficial things we did:

1. mostly pair programming, so we all knew the current state of the codebase and the path forward

2. When we didn't understand something, we wrote a separate small prototype of that feature / library / reference to teach ourselves how it worked. ( async, monad transformers, lenses, many reflex features )

3. We paid Obsidian for a one hour a week meeting to help us when we couldn't figure it out by ourselves. ( https://obsidian.systems/ )

4. nix for cross compilation and build / dev automation

5. Several hours a week of explicit teaching each other what we knew. This might should go first in the list, as the culture of being open and teaching was a massive benefit. We had one hour a week where the nixpert taught nix, one hour a week where I taught beginning Haskell, another hour a week where I taught Advanced Haskell (things I was learning that might help). We also had two hours a week where we all got together and worked on the stickiest problem along the path to shipping.

Most software dev jobs I've had want me to "do the thing" and have zero time left over for teaching / training others. I wanted to take the opposite approach and this paid off far more than my already wild hopes.

I would personally keep "pair programming" at the top of the list, this _really_ helps everyone learn.

Even more importantly, it tightens the loop between "write code, review code, change code, merge it finally" since you're basically doing all of that "at once" in the best case.

That sounds amazing, can you discuss your dev/prod environments please? Link to product?

Thanks!

The whole thing is open source, pretty sure this is accessible without login:

https://whetstone.private.storage/privatestorage/privatestor...

Dev environment was our laptops, obsidian's "ob run" is friendly and helpful (but doesn't work well with haskell-language-server).

Dev environment was also our Android phones.

We used nix for cross compilation and build automation, lucky for me the other main dev is really good at nix.

Ah nix! Ok thank you very much

Why not Kotlin then?

We don't know Kotlin. We both have some prior Java experience, but it's not our preference.

Since the original codebase is in Python, I would have used that if possible, but I spent eight weeks failing to load a shared object into a Python interpreter on Android. That got us to this past January.

I have had a Haskell job before, though I was entirely unfamiliar with Android dev.

In two days I was able to load a shared object into a Haskell interpreter on Android, so we tried that route.

I see, given the pain of using the NDK, and having to make use of JNI for any meanigful Android API, that approach seemed quite strange, when only having to target Android, hence the question.