I want to develop Chat Application on Xamarin Cross Platform using Firebase Cloud Messaging. But Xamarin.Forms 2.3.3.180 has dependency to Xamarin.Android.Support.v4 23.3.0 and Xamarin.GooglePlayServices.Basement 32.961 has a dependency to Xamarin.Android.Support.v4 24.2.1.
How can this be resolved?
Or
Is there another way to do it?
This can be resolved in a couple of ways
Use a version of Firebase that has the same Android Support dependency
Go to Xamarin.Forms github, check out the repository and upgrade this dependency. Then build your own version or make a Pull Request and wait for it to be released
Don't use Firebase directly in your App, but use your own backend, which in turn talks to Firebase.
Wait for the Xamarin.Forms team to fix this dependency
Which one you pick is entirely up to you. It is your task to weigh the pros and cons about these approaches. Some take more time than others.
I personally think, either 1. or 2. might be your best options. Xamarin.Forms is open source and you can do whatever you want with the source. Including upgrading dependencies etc. Of course Pull Requests for the project are welcome and I encourage you to make one if you have a fix that benefits all others. Make sure to talk to the Xamarin.Forms team before you start a big task, so you don't waste your time doing something that they don't want or is not on the roadmap.
The options from Cheesebaron are a good summary. I'm assuming you're using Xamarin.Firebase.Messaging.
If you want to go with option #1, the Xamarin.Firebase.Messaging component version 32.940.0-beta3 is the most recent one whose dependencies still allow the various Xamarin.Android.Support 23.3.0 libraries that Xamarin.Forms needs. In order to see the 32.940.0-beta3 version, you'll have to enable "Prerelease" versions.
While it is marked as a beta release, it has worked for me, and hopefully Forms will allow upgrading the Android support libraries soon...
Related
In my React Native apps, I've had bugs where the solution was to either upgrade Gradle or the Android Gradle Plugin. Is there a best practice on when to upgrade them? For example, should you keep an eye out for new versions of both of them and always keep them up-to-date? Or only when you upgrade react-native versions? Or something else?
Personally, I haven't had to upgrade Gradle often, but it's a good thing to try if you're app isn't building. Gradle is a build tool, if building isn't working, Gradle being out of date might be part of the problem.
I basically see two ideologies. 1. Always update, 2. Update when you have to. Always keeping your dependencies up to date can help with troubleshooting and keeping with best practices, but can also open you up to bugs and can take a lot of extra work. Updating when you have to is good for mission critical apps that require stability over new features. It also cuts down on development work.
Gradle also adds a potential breaking changes section to their update documentation.
I have an android system app that is currently being built with the android build system. The SDK in use is system_current as it uses some system apis.
For external dependency reasons, ease of development, debugging etc, it would be nice to move this app to Android Studio and use Gradle to build.
Converting the sources to build with Gradle is straight forward enough. However, at build time, the system APIs are not found as those are not available in the normal SDK. I thought that by generating the SDK from the AOSP sources I'd get an SDK I could use, but that target output seems to also not have the System APIs available.
How would I change my gradle build to be able to use the System SDK to compile against?
There are two ways depending if you are only trying to use current non-public APIs, or of you've added custom ones yourselves and are trying to access those.
If you're only trying to use current system-level APIs, you can use android.jar from this repository https://github.com/anggrayudi/android-hidden-api
If you have added some new method that isn't part of standard AOSP, then it's a but more work.
The reason that all methods don't show as part of Android SDK is that in AOSP code they are annotated with #hide. This means that when SDK is generated, they are exlcuded.
You'll need to remove that annotation for the methods that you want to use. Then you'l need
Run make update-api to update the public API of the project.
Make the Android SDK from code by following: https://android.googlesource.com/platform/sdk/+/master/docs/howto_build_SDK.txt
Change the Android SDK path in Android Studio to use the custom one you build.
There's also the possibility of accessing methods via reflection on runtime without SDK generation. It's slower and messier to code though.
Not sure I understand exactly what you mean by normal SDK etc.
From https://developer.android.com/studio/build
The key part is to have a
apply plugin: 'com.android.library'
...
android {
...
}
If on the other hand you wanted to build with a desktop JDK but compile against java APIs you could add a dependency on robolectric and you can get a jar you can import into another Android project.
implementation "org.robolectric:android-all:11-robolectric-6757853"
Android Studio isn't really designed to work with System APIs. Even if you make Gradle build your platform app, you will also need to sign it with the same certificate as your AOSP build (so that you could run it). As you noticed, if you decide to use Roboelectric you would also need to modify it yourself to match your current AOSP version (System APIs are not as stable as Public APIs and Roboelectric needs to constantly chase all the changes).
I would suggest to keep using the AOSP build system but optimize our workflow.
Ease of development
Doing a full build/flash for every change in your component must be a pain. But if you are just modifying a single app, you can get away with just building that single component:
~/aosp/ $ m -j -- do a full build first
flash a clean image (with your platform certificate)
~/aosp/path/to/your/app/ $ mma -j -- build your app with all dependencies after you made changes
$ adb root && adb remount && adb sync
Basically, adb sync works great if you don't touch any APIs or parts of Android Framework (which would cause a rebuild of thousands other objects). If you see adb sync updating more than handful of files, you'll likely end up with a bad system and need to do a full flash.
Debugging
While Android Studio is a to-go solution for regular apps, framework and the platform apps go with InteliJ (you can probably use Android Studio, but there won't be much of use of Android plugins on top InteliJ) plus some configuration (see idegen.sh - example).
I am very confused about using Azure Java SDK.
Firstly, I found and started using https://mvnrepository.com/artifact/com.microsoft.azure/azure version 1.31.1.
I have been using this for a while but today my CI software failed to build my project:
Failed to collect dependencies at com.microsoft.azure:azure:jar:1.31.1 -> com.microsoft.azure:azure-client-authentication:jar:1.7.0 -> com.microsoft.azure:adal4j:jar:1.6.4 -> com.nimbusds:oauth2-oidc-sdk:jar:6.5 -> net.minidev:json-smart:jar:2.3-SNAPSHOT: Failed to read artifact descriptor for net.minidev:json-smart:jar:2.3-SNAPSHOT: Could not find artifact net.minidev:minidev-parent:pom:2.3-20170326.024654-2 in jfrog (http://url/maven-public) -> [Help 1]
Now, I can't find net.minidev:minidev-parent:pom:2.3-20170326.024654-2 anywhere, and why would thesdk have a SNAPSHOT dependency?
Then I followed https://azure.github.io/azure-sdk/releases/2020-03/java.html and saw a whole lot of different libraries.
What's the deal with Azure SDK for Java? How should I actually use it?
This is well explained in its Github page
1. Management Libraries
Libraries which enable you to provision specific resources. They are responsible for directly mirroring and consuming Azure service's REST endpoints. Management library directories contain -mgmt-, e.g. azure-mgmt-keyvault.
2. Client: GA March 2020 Releases
New wave of packages that were released in March 2020 client library as General Availability (GA) and several others that were released in beta. These libraries follow the Azure SDK Design Guidelines for Java and share a number of core features such as HTTP retries, logging, transport protocols, authentication protocols, etc, so that once you learn how to use these features in one client library, you will know how to use them in other client libraries. You can learn about these shared features here.
These libraries can be easily identified by sdk/ folder, package, and namespaces names starting with azure-, e.g. azure-keyvault.
3. Client: Previous Versions
Last stable versions of packages that have been provided for usage with Azure and are production-ready. These libraries provide similar functionalities to the preview libraries, as they allow you to use and consume existing resources and interact with them, for example: upload a blob. Stable library directories start with microsoft-azure-, e.g. microsoft-azure-keyvault. They might not implement the guidelines or have the same feature set as the GA releases. They do however offer wider coverage of services.
Suggestion
If you want to manage Azure resources, use Management Libraries which contain -mgmt-.
If you want to utilize Azure resources, use the new-version GA Client Libraries for new features and better support. The most official documentation has turned to use new GA version now.
The question seems easy, but according to my research, the maven repository http://repo.maven.apache.org/maven2/org/primefaces/primefaces/ has only major releases 5.2,5.3,...,6,2
what I want exactly is to use the version 5.2.9 in order to correct the problem of the reCAPTCHA by implementing its v2, the use of the version 5.3 will have much impact on the developed application.
X.Y.Z releases are only available for paying customers as an elite release. You can then download the jar in a portal and put it in your own maven repo. They are not available in any public repository.
What you could try to do is to compare the sources of the 5.2 and 5.3 release regarding the captcha and just backport those. Still, really upgrading (to 6.2) is a better choice
If you have luck, maybe 5.3.RC1, which implements reCAPTCHA v2, is close to 5.2.9. You can get 5.3.RC1 via primefaces repo: https://repository.primefaces.org/org/primefaces/primefaces/5.3.RC1/
I'm looking at configuring SwiftyJSON. The docs state you can configure the library using any of these methods:
CocoaPods
Carthage
Swift Package Manager
Manual
What are the pros and cons of these approaches when configuring external libraries?
Here is some points about each of them
1. CocoaPods
Pros
Most widely used dependency manager.
Almost every popular libraries, framework vendors provide pod for their library/framework.
You can try the library and its usage without manually downloading it manually. pod try command
Cons
You should manage your project with a workspace.
If any vendor is not adding or updating their library's pod spec, it will be difficult to maintain.
2. Carthage
Pros
No need to keep the project in a workspace.
It's not a centralized system, that is no need to wait for the vendor to update/add the library to any centralized repo.
Cons
Need to add your frameworks to project for the first time.
3. Swift Package Manager
Pros
Product from creators/maintainers of swift itself.
No extra workspace created.
Super easy to integrate.
Cons
Not very popular.
Still, need to be adopted by the developer community.
4. Manual
Pros
You have full control.
You can edit(if the license allows to..).
Cons
Need manual work to add dependencies.
Difficult to update libraries.
Not sure whether we can add Objective-C libs to project using Swift Package Manager.
I would suggest using CocoaPods because its very simple to use and will get enough help and resources from the internet.
In WWDC 2019, Apple introduced Xcode 11 with the built-in feature to use SPM. So it would be easy to use SPM as Cocoapods.