Bundle of improvements

[davidzwa]

I have some ideas to improve QtFirebase, concerning the 'hard to use side', but it is best to prioritize them. I am willing to execute the steps, as I have some time.
First look at the PR I made for QtFirebaseExample on the total set of bumps in the road of setting up Qt, Android NDK,SDK, JDK 1.8.

I think the following things could make this wrapper library even more awesome:

• Provide more examples (f.e. to show different qt versions at work)
• Put the examples in the same repo. People need the platform files especially it to get started. Make a different 'barebone' example as well, which leaves qml/c++ integration as simple and basic as possible, so just a hello-world for checking 'does my app even qmake/make/deploy succesfully'.
• Document what is required in the Android files, but also what can be skipped/replaced with new Qt Android Template stuff. This way we relieve ourselves of the responsibility to explain all of the gradle setup (Qt do this much better than we can). One way is to provide a build.gradle.template file with only the required additions with some comments as to why they are needed. This way people can merge them with any Qt Android/iOS template as they so desire. We could go even further and auto-generate certain parts of files (but not overwrite) purely for QtFirebase. This is optional and should be discussed.

// BEGIN OF QTFIREBASE AUTOGENERATED SECTION
gradle stuff here
// END OF QTFIREBASE AUTOGENERATED SECTION

• Same for AndroidManifest.xml (you only need services to make Firebase Messaging to work, right?)
• Make the qmake step provide essential feedback on whether the androiddeployqt (or ios deploy) is gonna fail or not. Qmake is fast, build and deploy often not. (also refer to a previous GUI suggestion, aIthough personally I'd prefer a CLI as is more common these days)
• Dont hardcode FIREBASE_CPP_SDK in environment variables, although you might be tempted to. This is a very weak method for other build pipelines like CI/docker environments as it is not used by gradle. We have multiple viable alternatives: the previously discussed GUI/CLI + autogenerated sections, .qmake.conf in platform folder or QMAKE define + python script => local.properties, or a mix of both. This way the developer is in control by adjusting one file, and this is preferrably their own (.pro/.pri file).
• Include openSSL Qt for android
• Reduce required SDK files of firebase, or fork/integrate/cooperate with it (maybe integrate reduced download of SDK into QtFirebase repo, or provide downloader/extractor tool? Maybe split them up per target? Less MB's to download, more certainty of working version. "If it ain't broken, don't touch it" approach.)

[larpon]

@davidzwa - thank you for taking your time to do this!
This is a gazillion times more useful than all the previous "QtFirebase is hard to setup" issues I've had to deal with over the years 😄

Now bear with me as your contribution is on the complete opposite end of the scale (which is cool - but a big chunk to deal with all at once) 😄

I'm just back from writing a reply to your other efforts - thanks for caring and contributing.

To address your points:

• Provide more examples (f.e. to show different qt versions at work)

Yes, that would indeed help - although, if not done right, it could bring even more confusion and even more issues. My time with this project is extremely limited as I personally don't have any use for it currently. So for me to keep QtFirebase afloat I need more help and more time 😄

• Put the examples in the same repo. People need the platform files especially it to get started. Make a different 'barebone' example as well, which leaves qml/c++ integration as simple and basic as possible, so just a hello-world for checking 'does my app even qmake/make/deploy succesfully'.

If you merge QtFirebaseExample with this repository I think you'll get confusion - not clearance. The biggest problem is the huge tech stack.

I fully see where you're coming from - we need a project you could do git clone ... && qmake && make && deploy in one go so people can see it work without fuzz. The problem, as I see it, is that QtFirebaseExample is a hello world example. All features of QtFirebase is already tested and shown in QtFirebaseExample - nothing more nothing less (except the recent break with my testing endpoint).

There's "just" these irritating things like path resolving and paths to dependencies that's hard to set automatically - I'm hoping for someone to bring some qmake "magic" to the table. Using bash/python/powershell is not ideal and won't work on all setups (== more project issues and support work).

My problem the whole time has been to make the setup of QtFirebaseExample simpler without putting more work on my shoulders, that's why I'm really glad to see your comments and efforts here.

Let say I introduced another example that would work out of the box; we'd need to bundle fixed versions of Firebase C++ SDK, Android SDK/NDK, Java for Linux, macOS & Windows (can Java even be bundled?), Gradle, Firebase iOS SDK on top of just QtFirebase... This would be what... 30GB? Ouch. On top of this I'd have a whole new very big project to support on my hands 😅

Maybe we should look into Docker examples instead? I'm not good with Docker but could probably manage to get something going.

• Document what is required in the Android files, but also what can be skipped/replaced with new Qt Android Template stuff. This way we relieve ourselves of the responsibility to explain all of the gradle setup (Qt do this much better than we can). One way is to provide a build.gradle.template file with only the required additions with some comments as to why they are needed. This way people can merge them with any Qt Android/iOS template as they so desire. We could go even further and auto-generate certain parts of files (but not overwrite) purely for QtFirebase. This is optional and should be discussed.

Yes this has been on my personal TODO. Get things commented and described better in the platform files/docs. I need time and/or help with this

BTW: Does Qt has specific Android Template stuff now? (didn't know - or is it that dreadful qmake *.in file kind-of templating?).

Same for AndroidManifest.xml (you only need services to make Firebase Messaging to work, right?)

Yes

Make the qmake step provide essential feedback on whether the androiddeployqt (or ios deploy) is gonna fail or not. Qmake is fast, build and deploy often not. (also refer to a previous GUI suggestion, aIthough personally I'd prefer a CLI as is more common these days)

Good idea - I've leaned away from the GUI idea - it's too error prone.

Dont hardcode FIREBASE_CPP_SDK in environment variables, although you might be tempted to. This is a very weak method for other build pipelines like CI/docker environments as it is not used by gradle. We have multiple viable alternatives: the previously discussed GUI/CLI + autogenerated sections, .qmake.conf in platform folder or QMAKE define + python script => local.properties, or a mix of both. This way the developer is in control by adjusting one file, and this is preferrably their own (.pro/.pri file).

Also good idea - accepted. Just need to understand the alternatives if I am to implement any of it - or get it in with bite-sized PRs 😄

Include openSSL Qt for android

I'll repeat myself: Fuck.

Besides being a huge dependency - it's also a giant painful mess in regards to both Qt and Android.

Bringing this in will be like gate crashing a party in a hornet nest with a smoking pole.
It's a big steaming pile I really don't want to touch.

Again we have enough problems as things are currently.

I'll have to investigate what to do here.

Reduce required SDK files of firebase, or fork/integrate/cooperate with it (maybe integrate reduced download of SDK into QtFirebase repo, or provide downloader/extractor tool? Maybe split them up per target? Less MB's to download, more certainty of working version. "If it ain't broken, don't touch it" approach.)

Yes with the recent open sourcing we probably could pull this off somehow. I'm still researching 🧐

Thanks for taking your time, let me know what you think about all this so far.

[davidzwa]

So same thing here: really grateful for the thorough feedback. That's motivating.

Little bit of context, my company develops quite a complex suite of apps with Qt, so we got the experience with SSL.

• Linux: easy apt/snap install
• Windows: custom built (yep I did that xD)
• Android: the referred openssl repo fixes a lot of headache. Git submodule and should be actually quite fine! You dont have nothing to maintain that way 🥇
• iOS/mac: ehhh?

Now about smaller tasks. I got three ideas:

• dockerize (I am quite the docker pro, if I say so myself) we already have a lot running in docker + Linux/Android build, I can freely share. We could start hammering away on a Github Action quite easily.
• document Android example build in bite-size manner for Qt 5.14 + Messaging
• CLI / environment validator for qmake... that's something we gotta think through carefully: I see only options, but it's a matter of where we can make ends meet. I'll make a smaller separate issue for that.

What would have your priority?

[larpon]

Well if we some ready made SSL solutions it's fine.
I just don't like to bring it in for any platform - because it leaves me with a potential support for it. Even Qt tries to push it to be some thirdparty stuff you need? (From what I can see in Qt Creator and the forums/issues etc.)

You're a brave warrior to have built it for Windows! 😅

Yes, providing docker files would probably help a lot, showing different configurations.
(I'm already experimenting with GitHub actions - but they're failing for Android right now because of some gradle download failing, need time to fix it)

document Android example build in bite-size manner for Qt 5.14 + Messaging

Can we get away with some 5.14 notes in the existing docs?

CLI / environment validator for qmake <...>

Accepted - the issue should probably be moved to this repository - as it's not just a tool for the example app?

EDIT Moved to #153