I am using smack API with openfire server to make an android app. I am trying to implement a MessageEventManager and MessageEventProvider to my app so it will tell me if the message was delivered or not though when i try to declare it a MessageEventManager, it is not compiling and tells me to create that class, What can i do? i have the following dependencies in my gradle:
dependencies {
compile fileTree(include: ['*.jar'], dir: 'libs')
compile 'com.android.support:appcompat-v7:22.1.1'
compile 'org.igniterealtime.smack:smack-android:4.1.0-rc1'
compile 'org.igniterealtime.smack:smack-tcp:4.1.0-rc1'
compile 'org.igniterealtime.smack:smack-im:4.1.0-rc1'
compile 'org.igniterealtime.smack:smack-extensions:4.1.0-rc1'
compile 'org.igniterealtime.smack:smack-android-extensions:4.1.0-rc1'
}
Do i need an extra for it? I would appreciate any help Thanks.
IMG:
Well, I might be wrong, but it seems it's not included in Smack4.1, I can't tell if it's deprecated or not since I haven't seen it on the deprecated lists, and the documentation exists here and here for the parent class.
But... what I did find is this SO answer by the Author of Smack, that clearly states that
Message events in SMACK are done via the now obsolete XEP-22. There is a good chance that the other side does not implement this out-dated mechanism.
Since this is dated 3 years back, it might be a good idea to look for another solution, or (depending on your needs, might not be recommended) use an older version Smack or aSmack.
Message event manager (XEP-22) are obsolete now, but smack team still maintain it. You can use smack legacy library throgh gradle
compile "org.igniterealtime.smack:smack-legacy:4.1.3"
Related
I've been getting an error when syncing Gradle:
Could not find method compile() for arguments [com.android.support:support-core-utils:28.0.0] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.
Please install the Android Support Repository from the Android SDK Manager.
I've found solutions for previous versions but I've been developing for v28, and I'm not even sure if my compile "com.android.support:support-core-utils:28.0.0" line is correct. This is for a firebase chat app and I'm following a 2016 tutorial. I did end up installing the support thing from the manager but same error.
You can not use compile in version 4.4 of Gradle and instead reduce it by using implementation method
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'com.android.support:appcompat-v7:27.1.1'
androidTestImplementation 'com.android.support.test:runner:1.0.2'
androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
testImplementation 'junit:junit:4.12'
I have also completed a quite similar tutorial - creating the "Flashchat" app.
I ran into the same problem - apparently they updated the keyword used in the gradle files:
build.gradle (Module: app) - you will find dependencies at the bottom.
There you will be able to add the firebase libary as well as other ones. Example:
implementation "com.android.support:support-core-utils:28.0.0"
Unfortunately, the tutorial from 2016 is outdated so you might find several of those little changes later on. For example creating the firebase database will be a little different because they introduced a Real Time Database. (You can still use the old one for your chat app but you will have to change the ruleset for read and write access.)
For further questions you might run into, I recommend searching for "Flashchat" on GitHub. Many people have followed that tutorial and have uploaded their results. This might solve upcoming questions by just comparing the code and then looking up the documentation to understand what has changed. Link to GitHub
I am learning midtrans (payment gateway). I get this documentation. There is writen compile 'com.midtrans:uikit:$VERSION-SANDBOX'. What should i write in $VERSION-SANDBOX? I've search on google and ask people but no result. I try to write compile 'com.midtrans:uikit:100' but not work :D.
You can see the latest Version of midtrans here. So it will be compile 'com.midtrans:uikit:1.5.1'
Android Studio 2.2.2
Compile SDK Android 7.1.1
Build Tools: 25.0.0
Gradle version: 2.14.1
Min SDK: 19
Target SDK: 25
I encountered an issue with jackson-dataformat-xml-2.8.5.jar when attempting to execute this:
JacksonXmlModule module = new JacksonXmlModule();
ObjectMapper xmlMapper = new XmlMapper(); //This line
throws the following exception
E/AndroidRuntime: FATAL EXCEPTION: Thread-418
Process: cb.myAppName, PID: 29744
java.lang.VerifyError: com/fasterxml/jackson/dataformat/xml/XmlFactory
at com.fasterxml.jackson.dataformat.xml.XmlMapper.<init>(XmlMapper.java:49)
at cb.myAppName.Core.GenerateReturnXMLFile(Core.java:863)
at cb.myAppName.RouteScreenActivity$4.run(RouteScreenActivity.java:305)
at java.lang.Thread.run(Thread.java:841)
From what I researched, it has to do with a binary incompatibility that was introduced in Jackson 1.3. As stated by Tatu Saloranta in his old blog which sadly is no longer online.
I have always valued compatibility quite highly, at least for any "non
beta" release (1.0 and above). As a result, the idea has been that any
1.x release would be simple plug-and-play over previous one. This does work for patch releases; but it turns out that not all minor releases
have worked this way. For example, versions 1.2 and 1.3 have some
unexpected incompatibilities.
Problem is this: although most commonly binary compatibility is a
harder goal than source compatibility -- that is, if you break source
compatibility, you are almost guaranteed to break binary compatibility
-- it is not strictly so. Specifically, it is quite possible to make certain changes that are source compatible, but that are NOT binary
compatible.
Specific case in point is that of changing a method that returns
nothing ("void method") into method that returns something does not
break compilation. But it does actually break binary compatibility.
UGH.
And this is exactly what happened when I decided that it would be nice
to make ObjectMapper follow "fluent" pattern, to allow for chaining of
configuration method calls. This would be nice, if it was not this
"hidden" API change...
Not quite sure how to correct this though since i'm fairly new to android development.
I already made sure to use same version of Jackson across the board as you can see in my list of dependencies from the app/build.gradle, is there something else I may be missing?
dependencies {
compile fileTree(include: ['*.jar'], exclude: ['com.symbol.emdk.jar'], dir: 'libs')
compile files('../libs/json-20151123.jar')
provided files('../libs/com.symbol.emdk.jar')
compile files('../libs/slf4j-api-1.7.6.jar')
compile files('../libs/logback-android-1.1.1-4.jar')
compile files('../libs/sun.misc.BASE64Decoder.jar')
compile files('../libs/ZSDK_ANDROID_API.jar')
compile 'com.android.support:appcompat-v7:22.2.1'
compile 'com.android.support:support-v7:22.2.0'
compile 'com.google.code.ksoap2-android:ksoap2-android:3.6.0'
compile 'com.google.code.gson:gson:2.4'
compile 'org.apache.directory.studio:org.apache.commons.io:2.4'
compile 'org.joda:joda-money:0.11'
compile 'org.apache.directory.studio:org.apache.commons.lang:2.6'
compile 'com.google.android.gms:play-services-appindexing:9.8.0'
compile 'org.greenrobot:eventbus:3.0.0'
compile 'com.fasterxml.jackson.core:jackson-core:2.8.5'
compile 'com.fasterxml.jackson.core:jackson-databind:2.8.5'
compile 'com.fasterxml.jackson.datatype:jackson-datatype-joda:2.8.5'
compile 'com.fasterxml.jackson.dataformat:jackson-dataformat-xml:2.8.5'
compile 'com.github.gcacace:signature-pad:1.2.0'
}
As per the official FasterXML Jackson github page, the extension i'm using should be supported...
XML: supports XML; provides both streaming and databind
implementations. Similar to JAXB' "code-first" mode (no support for
"XML Schema first", but can use JAXB beans)
https://github.com/FasterXML/jackson-dataformat-xml
This issue was also reported on the project's github page but no real solution was reached. -- github.com/FasterXML/jackson-dataformat-xml/issues/116
UPDATE: I used jarjar on the following dependencies:
compile files('../libs/cb-joda-time-2.9.6.jar')
compile files('../libs/cb-joda-money-0.12.jar')
compile files('../libs/cb-jackson-dataformat-xml-2.8.5.jar')
compile files('../libs/cb-jackson-datatype-joda-2.8.5.jar')
compile files('../libs/cb-java-json-0.13.0.jar')
compile files('../libs/cb-json-20160212.jar')
Also upgraded every single dependency to latest version as well as my appcompat and support api.
The error continues -
java.lang.VerifyError: cb/com/fasterxml/jackson/dataformat/xml/XmlFactory
at cb.com.fasterxml.jackson.dataformat.xml.XmlMapper.<init>(XmlMapper.java:49)
Hopefully someone can shine some light on this, not sure what is causing this...
After some research and tips from user aha I was able to further identify how to correct this. I haven't had time to test it since I ended up taking a different route and using SimpleXML library instead which works great for what I needed to do.
I will update this answer with more details when I do get around to testing it but here are some ways to attempt and correct this:
Include Stax as a dependency: github.com/FasterXML/jackson-dataformat-xml#android-quirks
Execute gradle dependencies. Gradle will then display the actual dependency tree that it has used to compile and package your app. The generated dependency tree might be different than the dependencies you'd declared, e.g. because of transitive dependencies. -Thanks aha
This is the original issue at github: github.com/FasterXML/jackson-dataformat-xml/issues/116
I'm currently implementing two Twilio SDKs:
Programmable Video
IP Messaging Client
I'm realizing that one dependency affects the other, or at least so I believe, since I first implemented the IP Messaging Client and it worked flawlessly, and now that I've added the dependency for Programmable Video, when I try to run the project, it says it cannot find 3 of the used classes for IP Messaging Client in the package com.twilio.common, but those for Programmable Video are found. Here's part of the gradle (Module):
dependencies {
compile 'com.koushikdutta.ion:ion:2.1.7'
compile 'com.twilio:ip-messaging-android:0.8.1'
compile 'com.twilio:conversations-android:0.12.2'
compile 'com.android.support:appcompat-v7:23.1.1'
compile 'com.android.support:design:23.1.1'
}
Also the classes that I have the conflict with of IP Messaging Client (they aren't in the package, the other clases are):
import com.twilio.common.TwilioAccessManager;
import com.twilio.common.TwilioAccessManagerFactory;
import com.twilio.common.TwilioAccessManagerListener;
And the classes of Programmable Video that I'm using:
import com.twilio.common.AccessManager;
import com.twilio.conversations.IncomingInvite;
import com.twilio.conversations.LogLevel;
import com.twilio.conversations.TwilioConversationsClient;
import com.twilio.conversations.TwilioConversationsException;
Note that class AccessManager from Programmable Video is the same and it's at the same level that class TwilioAccessManager used for IP Messaging Client, which in theory work equally. But the other classes can't be found.
I'm hoping anyone can help me! Regards!
Twilio Developer Evangelist here.
We had a dependency conflict with com.twilio:ip-messaging-android:0.8.1, but have now fixed that and the fact that they use two different AccessManagers in 0.9.0. this should solve the problem you're encountering.
So please update your gradle file to be:
dependencies {
compile 'com.koushikdutta.ion:ion:2.1.7'
compile 'com.twilio:ip-messaging-android:0.9.0'
compile 'com.twilio:conversations-android:0.12.2'
compile 'com.android.support:appcompat-v7:23.1.1'
compile 'com.android.support:design:23.1.1'
}
More information about this update can be found here. Hope this helps you
I've heard that using incremental dependency in Gradle is bad.
like this
dependencies {
compile fileTree(include: ['*.jar'], dir: 'libs')
compile 'com.android.support:appcompat-v7:22.+'
}
Is that so? Why?
There are two primary issues with using wildcard dependency versions:
First, you lose control over when you update. This means that you could potentially get a bad version of the library, or pull down a good version that introduces breaking changes before you are ready to address those changes.
Second, your builds are no longer reproducible. If in a few months you decide you need to build the exact version of the app that you had on May 28th, 2015, you will find that task much more difficult because you don't know what the precise version of the library you were using on that date. If you simply check out the code from that date, you are receiving whatever version is currently the latest instead of what the latest version was on that date.