larpon
commented
4 years ago We'll have to take this in bite-sized chunks :cake: before I can pull anything in.
Note for curious followers: Ongoing general usability issue discussion is currently in QtFirebase
For this PR:
I do have to note with this PR I did a complete install of Qt/QtCreator/Android-SDK/NDK/JDK and I had some issues (when don't we have issues xD) worth mentioning. This concerns both Android side of things, but also really handy tips on side of Qt and QtFirebase.
Thanks! They'll probably need to go into the documentation somehow - see my comments below.
* Android Studio comes preinstalled with JDK 9, which should <...>
I'm sorry but I can't take on the burden of being first line support on setups using any other setup than command line/QMake. Android Studio (or any other IDE) and whatever tons of weird bugs and inconsistencies that will bring in is none of this projects business. Qt Creator is a little special here as it is my impression that most users will use Qt Creator as it usually comes bundled with Qt (although that might change).
But... Especially issues like login problems with Oracle or any other services, portals etc. is so far from the scope of this project as anything can be. I hate login walls - especially corporate ones - and Qt has recently also introduced this which is a huge mistake IMO. They lock out developers that care about and help their business.
If people choose to use Oracle etc. - it's their problem. I can probably accept to put small general notes in the documentation - but not guidance on how to circumvent logins etc.
* Android minimum target SDK should be around 24/25, build SDK (**compileSdkVersion**) should be at least **28** <...>
Yeah - I'm generally also growing really tired of all these little stupid things. People get confused and report seemingly unrelated issues because of these "numbers". I think they were initially used to keep things easier for backward compatibility - but look at how Google and vendors are dropping support for "older" devices with each release they do. It's a mess. But this probably need to be fixed when we can.
On the QtFirebaseExample side and Qt projects vs Android (at least for Qt 5.14.x):
* *.properties paths hardcoded and not auto-updated: either gitignore, or auto-generate, but dont commit your paths
Fully agreed, I normally don't do this in any of my public facing projects - but like I've stated here ... I initially thought it brought more help than confusion.
I should probably replace them with something like:
systemProp.firebase_cpp_sdk.dir=/path/to/firebase_sdk // NOTE on Windows you might need to escape whitespaces in your path* *.properties paths not escaped on Windows (warning Android Studio only)
I'm not interested in supporting quirks of any IDE - I can accept notes about such oddities in the documentation or in the file itself.
* 'com.google.gms:google-services:4.0.2' due to bug in 4.0.1 (not essential, and I didnt always experience this problem. I dont see a problem in going to a higher version if it works.)
Hmm ok, I see. Again these are a little tough as I can't check for third-party bugs with every release. I normally bump everything to the highest possible working version when "releasing" for versions I know that works. It's impossible (and actually quite time consuming) to find out which versions of the whole software stack works together (preferably on ALL platforms). Again it's a mess, because users want QtFirebase to work with their specific "version chain".
* Manifest changed, libs.xml changed, gradle(w) files updated with newer gradle (we can consider going to version 6.x.x-all.zip even, it works fine)
Yeah - I think you're spot on with the Qt >= 5.14.x thing here. I initially had thoughts about doing a separate branch - but having the solution in master is better. Thank you for introducing this idea. I really wish that we wouldn't have to have so much duplicated code between base and your new android-qt5.14 dir. Can we come up with something smarter? I just know it will bring confusion and issues all the way from contributors to end users. I can feel it :smiley:
* We can massively improve feedback to Developers concerning: paths to SDK, NDK with qmake messages and errors. The build should NOT continue when the paths are wrong or unset, but also I think setting ENVIRONMENT variables is quite unclear: we can make use of a `.qmake.conf` file for _all paths_. Can we write a separate and CLEAR tool for this which is called by qmake? Python/Powershell/Bash script? (I like Powershell, but Python is fine for me. I hate Batch and I think bash is easily breakable. Python is universally available and we can expand it with a clear CLI parser.)
Fully agree, again, you're spot on. We need to make this easier. Let's start out with something in QMake (I'm not very profund with QMake, nor with .qmake.conf) - I dislike bringing in more dependencies like Python/Powershell/Bash - QtFirebase has enough clutter and dependencies as is :sob:
Runtime issues (FCM at least):
* cant find `nulllib***.so`: with the new .aab build, make sure to include your targets platform in the target list. (for me arm64-v8a) and to select .apk/.aab. *If you want the easiest way: build for armeabi-v7a as well and select .aab bundling, so you can upload to PlayStore as easy as possible. This takes longer to compile logically.
Yes I haven't had time to look into .aab support at all. I think it's more important to get sprintf and the v5.14.x+ working first with apk style upload. Again introducing/supporting another output format is equal to confusion. One thing at a time unless unless it's "two for one" solutions.
* We need OpenSSL (libcrypto, libssl)
Fuck.
W libApp_arm64-v8a.so: qt.network.ssl: QSslSocket::connectToHostEncrypted: TLS initialization failed I think this github repo does it perfectly and for all targets. We should definitely include this. This will come in a seperate PR, which is dependent on this PR.
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 will give what you have committed a look though - that much you deserve for all the hard work you've put into this :slightly_smiling_face:
I'll probably not pull this in as is. We need to keep things in clear separate PRs doing one thing at a time. To not confuse any further - let's take the discussion to https://github.com/Larpon/QtFirebase/issues/151.
I really appreciate your efforts and don't mean to sound angry towards what you contribute here.
davidzwa
I do have to note with this PR I did a complete install of Qt/QtCreator/Android-SDK/NDK/JDK and I had some issues (when don't we have issues xD) worth mentioning. This concerns both Android side of things, but also really handy tips on side of Qt and QtFirebase.
On the setup side (on Windows):
On the QtFirebaseExample side and Qt projects vs Android (at least for Qt 5.14.x):
.qmake.conffile for all paths. Can we write a separate and CLEAR tool for this which is called by qmake? Python/Powershell/Bash script? (I like Powershell, but Python is fine for me. I hate Batch and I think bash is easily breakable. Python is universally available and we can expand it with a clear CLI parser.)Runtime issues (FCM at least):
nulllib***.so: with the new .aab build, make sure to include your targets platform in the target list. (for me arm64-v8a) and to select .apk/.aab. *If you want the easiest way: build for armeabi-v7a as well and select .aab bundling, so you can upload to PlayStore as easy as possible. This takes longer to compile logically.