Provide a pure-floss build flavor

ghost commented 9 years ago

Crashlytics is a non-free buildtime dependency, could you add a gradle build flavor that works around it? Maybe you might want to have a look at acra.ch as a free alternative.

Also: Are the jar files still used?

ratan12 commented 9 years ago

The picasso and Retrofit .jar files not. Yes, crashlytics isn't really handy when developing but I honestly do not mind. It works pretty decent and I am kinda happy with it.

Currently I am working on a cleanup which is finished and an ORM implantation (dbflow) but I got stuck due some problems with saving arrays in the db because RecordStub$Table could not be resolved :/

Edit: I will drop the ORM idea and just improve the DB

srvrguy commented 9 years ago

I'll leave this open for now, but the application doesn't depend on Crashlytics. Feel free to remove the dependency and build it yourself until we get around to making a special flavor for purists.

As for ACRA, I'm personally not too interested in supporting it at this time. Unlike Crashlytics, the official backend requires either paying a provider or setting it up yourself. I currently run the MAL API server out of generosity, and I don't want to add more things to maintain on my own time that will use up resources on my personal server. If that happens, the official builds may start having to display ads or find other ways to monetize to pay for the resource usage, the server usage, and my time. I do not want that to happen.

aphirst commented 9 years ago

It's definitely a shame that the most recent build in F-Droid is 1.4.x. I mean, it's great that we nonetheless have builds up on github... but there's definitely an interest in having it in the FOSS repos that extends beyond myself. I'll follow this with keen interest, and remark with the fact that I'm sure that many would be willing to provide support in ways other than having to have such unsightly things bundled into official builds...

srvrguy commented 9 years ago

I left the issue open because I'm not opposed to this, there's just no time available for any of the current core contributors to do the work. We have plenty of other things that we consider more pressing. As it is, I barely have enough free time to track down all the changes MAL does and fix our API code, let alone do lower-priority work on the Android application.

If you want a build flavor that doesn't require Crashlytics, please do the work and submit a pull request. If you can't do this, it'll have to wait until someone has time to do it. Posting about it on this issue will not give us more free time to do the work.

aphirst commented 9 years ago

Of course I appreciate the situation. Sadly I don't have the applicable knowledge to be able to do it, but at least in my own experience, those who do and who stumble upon such open issues are often more likely to decide to invest their own if they know there are lots of other people who'd appreciate seeing it done. Of course there's always a fine line between "keen" and "demanding", and no-one wants to appease people with self-entitlement issues.

Anyway, from this point I'll just sit tight and stay subscribed to the thread. :smile:

aphirst commented 9 years ago

Actually, I do have a suggestion that might be a stop-gap for a lot of people, myself included, assuming you were to consider it a viable option: Even without a "fully FOSS" version in the official F-Droid Repository, have you considered running your own F-Droid Repo containing the .apk Builds that you otherwise simply have available for Direct Download from your github Releases pages?

ratan12 commented 9 years ago

I am not against it but running a repo would mean putting it on the server.

aphirst commented 8 years ago

Has there been any further consideration to the possibility of running an F-Droid server for the official .apk releases, as other projects (e.g. Öffi, LibreSignal) do?