Committing changes to /platforms/android/project.properties - ionic-framework

To fix a recently problem with "com.google.android.gms.license" the recommended solution is to edit platforms/android/project.properties to specific the version of the libraries
old:
cordova.system.library.1=com.google.android.gms:play-services-auth:+
new:
cordova.system.library.1=com.google.android.gms:play-services-auth:11+
However the Ionic scaffolder deliberately out platforms/ into the .gitignore file so these changes will not be committed and shared to other dev. How/where should I make this change so that it persists?

You can use the cordova-android-play-services-gradle-release plugin to align the versions specified by various plugins during the Cordova build process so you don't need to modify/exclude platforms/android/project.properties:
cordova plugin add cordova-android-play-services-gradle-release --variable PLAY_SERVICES_VERSION=11+

Related

Problem with document scanner plugin: extra dependencies add on time of build

I have a problem with the ionic react document scanner, as I build the app in some file extra dependency adds into that file and I have to remove that dependency to make application workable, otherwise, it won’t work.
Here is the path of extra dependency, it's showing file not found:
/Users/ionic/builds/project-0/ios/capacitor-cordova-ios-plugins/sources/CordovaPluginDocumentScanner/src/ios/IRLDocumentScanner.framework/PrivateHeaders/IRLCameraView.h:14:9:
'IRLScannerViewController.h' file not found
Now, important thing is that I am sending the code to the client and he makes build from the ionic hub and he is not able to comment or remove that dependency from the ionic hub as he builds on ionic hub dependency came and he can’t remove it, now I’m not being able to find the solution of this issue from the previous week.
Any help will be appreciated
I changed
#import "IRLScannerViewController.h"
to
#import <IRLDocumentScanner.h/IRLScannerViewController.h>
IRLDocumentScanner.h file

Should I keep symfony.lock in my version control?

I'm starting to use Symfony Flex to bootstrap my project and I realized that running composer install for the first time generates a file named symfony.lock for which I could find no documentation.
What does this file do? Should I keep it in my version control and deploy it or should I .gitignore it?
Yes, officially you must add it to the version control:
Flex keeps tracks of the recipes it installed in the symfony.lock file, which must be committed to your code repository.
https://symfony.com/doc/3.4/setup/flex#how-does-flex-work
Otherwise on staging or production stages it will be generated again by Flex, auto-configuring all installed packages with recipes and triggering bugs like this https://github.com/symfony/flex/issues/192

Gradle Android SDK integration with Unity [duplicate]

My project uses these plugins:
OneSignal
GooglePlayServices
Adjust
Google Analytics
Unity IAP
Facebook SDK
Those plugins are used in almost every project.
But I am over field references count
This is my .aar file list
What should I do to decrease reference count?
So What should i do to decrease reference count ?
You have so many plugins with many functions/fields. There is a limit when building this from Unity's Editor and you have reached that limit.
To decrease reference count, you have to delete some these plugins but I am sure that you need them and deletion may not be the appropriate solution in this case.
The only way to actually get around this and build for Android at this moment is to export the Project as Android Project then build it with Android Studio. This removes the reference limit imposed by Unity's Editor.
EDIT
I forgot to mention that you have to enable multidex after exporting it out. Since many people go through this problem daily, I decided to add a thorough instruction on how to fix this problem by exporting it out and also how to fix it without exporting it.
FIX BY EXPORTING THE PROJECT
1A.Export the Unity Project as Android Project.
1B.Import into Android Studio:
If you get grade error when importing into Android Studio like the one below:
Error:org.gradle.api.internal.tasks.DefaultTaskInputs$TaskInputUnionFileCollection
cannot be cast to
org.gradle.api.internal.file.collections.DefaultConfigurableFileCollection
In the "dependencies" block which is in the "buildscript" block in the build.gradle file, change:
classpath 'com.android.tools.build.gradle.2.1.0'
to
classpath 'com.android.tools.build:gradle:2.2.3'
If you export the Project and still get the-same error, you need to manually enable multidex. Below is a simplified step to follow from Google's doc that will be shown to you in the error:
2.Add android:name="android.support.multidex.MultiDexApplication" > to the
application tag in the AndroidManifest.xml file.
3.Add compile 'com.android.support:multidex:1.0.1' to the "dependencies" block in the build.gradle file.
4.Add multiDexEnabled true to the "defaultConfig" block which is in the "android" block in the build.gradle file.
Build APK and see if it works. If the reference count error is gone, stop here.
5.Getting a GC overhead exception like the one below?
java.lang.OutOfMemoryError: GC overhead limit exceeded
Increase the heap size that will be used when performing dex operation. From this solution, add the following to the "android" block in the build.gradle file:
dexOptions {
javaMaxHeapSize "4g"
}
FIX WITHOUT EXPORTING THE PROJECT
Must have Unity 5.5 and above to do this:
1.Go to <UnityInstallationDirecory>\Editor\Data\PlaybackEngines\AndroidPlayer\Tools\GradleTemplates, Copy the mainTemplate.gradle file to your <ProjectName>Assets\Plugins\Android folder.
2.Go to <UnityInstallationDirecory>\Editor\Data\PlaybackEngines\AndroidPlayer\Apk, Copy the AndroidManifest.xml file to your <ProjectName>Assets\Plugins\Android
3.Open both the mainTemplate.gradle and AndroidManifest.xml file you just copied with Visual Studio then do the modification from the FIX BY EXPORTING THE PROJECT instruction above. Skip/Ignore step #1A and #1B. Just do steps from #2 to #5. That's it.
This is what the final mainTemplate.gradle should look like and this is what the final AndroidManifest.xml should look like. This is only for reference purposes. I suggest you don't use mine but instead follow the copy steps above to create yours because future Unity versions can come with different files. You want to make sure you use the latest one or you may have problems building it.
4.Build APK and see if it works:
--
If the reference count error is gone, stop here:
5.Getting an error like the one below?
Build Failure Release builds have to be signed when using Gradle
Just sign the apk from the Publishing Settings in the Build Settings. You can create new keystore or use an existing one.
6.Another error like below?
Error: Avoid hardcoding the debug mode; leaving it out allows debug
and release builds to automatically assign one [HardcodedDebugMode]
Remove android:debuggable="true"> from the AndroidManifest.xml file.
If this non exporting solution did not work for you then you have to
use the exporting solution.
IMO, The accepted answer isn't correct (or only partly correct). Exporting an Android studio will not "magically" fix this issue. Also, from my experience, the exported Android studio project does not always build right away and you have to fix lots of things before you can actually build it.
You are using lots of plugins and so you faced an Android limitation of not being able to reference more than 64k methods.
There are a few things you can try to solve this:
Delete some of these plugins, if possible (as already suggested in the accepted answer).
Use multidex. In the past this was only possible by exporting the project to Android studio and building it there. Starting with Unity 5.5 you can build your project using Gradle right from Unity. This means you can create a custom gradle file that configures your game to use Multidex. This doesn't reduce the method ref count, but it works around it by splitting your native Java count into multiple dex files.
Use ProGuard - since you can use Gradle from Unity, you can also define ProGuard to run and remove any code that is not used.

ionic-gulp-browserify-typescript: What version of typescript is used?

I created an Ionic project with Typescript as below.
ionic start MyIonic2Project tutorial --v2 --ts
In gulpfile.js which is created automatically, ionic-gulp-browserify-typescript is used to compile Typescript.
My question is what version of typescript is used by ionic-gulp-browserify-typescript.
ionic-gulp-browserify-typescript uses the tsify plugin internally, which maintains it's own TypeScript version. As of right now, this is 1.8.7, but that's likely to change, so you should keep an eye on the package.json or npm page.

how to put to work Ionic generator?

I have an Ionic app running with the basics of Ionic and running it in the browser by doing ionic serve, but I want some new stuff and run it trough the grunt serve command, also has the feature for JSLint, I am already using this scss this: https://github.com/diegonetto/generator-ionic/ and I see that have everything I want, how do I install that in my project?
Take into account that my project is almost done, I have almost 85 % already done.
Is this the part I need to follow up:
Upgrading
Make sure you've committed (or backed up) your local changes and install the latest version of the generator via npm install -g generator-ionic, then go ahead and re-run yo ionic inside your project's directory.
The handsome devil is smart enough to figure out what files he is attempting to overwrite and prompts you to choose how you would like to proceed. Select Y for overwriting your Gruntfile.js and bower.json to stay up-to-date with the latest workflow goodies and front-end packages.
does this will bring some complications ? is there something else I need to know ?
I use the same generator and enjoy using it. With that said, I would not recommend starting to use a generator until you've made a complete backup of your project.
Even then, I'd recommend creating a brand new project using the generator then migrating your existing code into the newly generated project. While migrating, you should be modifying your code to match the generator conventions as you go. This gives you the most control and will make sure that you learn the conventions of the new project structure. Upgrading instructions are really meant for people who already use the generator and are just upgrading to a new version of the generator. They are not applicable to you.