I am working on a Kotlin Multiplatform project for Android and Desktop using Compose and have the Compose Multiplatform IDE Support plugin installed.
What I am trying to do is add the #Preview annotation so I can get a preview of the composables that I'm working on. I tried following this guide to implement that:
https://developer.android.com/jetpack/compose/tooling/studio
I want to have my shared Compose classes in the module shared-ui, so I added the following dependencies to the build.gradle.kts in that module:
dependencies {
debugImplementation("androidx.compose.ui:ui-tooling:1.3.2")
implementation("androidx.compose.ui:ui-tooling-preview:1.3.2")
}
However, even after a synchronization, when I try to use or import the #Preview annotation in my class (shared-ui/src/commonMain/kotlin/.../MyScreen.kt), I get this error:
Unresolved reference: preview
That happens twice: Once in the import statement, where the final word Preview is in red, and once in the annotation, where it is also the word Preview that is in red:
[...]
import androidx.compose.ui.tooling.preview.Preview
[...]
#Preview
#Composable
[...]
Incidentally, I also tried the quick fix option that Android Studio offered me there: "Add dependency on androidx.compose.ui.ui-tooling-preview and import". What that does is add the dependencies exactly where I added them (provided I remove them first, otherwise it does nothing), which apparently means that Android Studio agrees with me that this is where the dependencies should go.
Which brings me to my ultimate question: Why does this not work? What am I doing wrong? Based on my understanding, this should work. But it doesn't. Am I missing something?
Related
I stumbled into an issue where all my unit test classes fail to run, providing the following error:
java.lang.IllegalStateException: Failed to transform class with name <my class name>. Reason: toPrettyPrint (Ljava/lang/String;)Ljava/lang/String; in <my class name>: inconsistent stack height -1
One user commented on the following github thread for powermock, that the same error first happened to them after updating their kotlin plugin:
https://github.com/powermock/powermock/issues/779
After reading this, I have checked with my colleagues to see maybe they have a different kotlin version, and saw that their kotlin plugin version is
203.1.6.0-release-798-AS7717.8, whereas mine is 1.4.32-release-Studio4.1-1.
What I find peculiar abbout this, is that these versions dont follow the same conventions, they look more like two completely different sofware. Is there any way for me to get the same version for my kotlin plugin ?
Any help or clarification is much appreciated, thanks!
They probably just changed the naming scheme for the plugin. Looks like you have one that is about one and a half years out of date.
Anyway, go to File -> Settings -> Languages & Frameworks -> Kotlin and click the Install button.
I'm using Android studio 4.0, coding in Kotlin and I'm still really new at Android development.I need to integrate the Xzing barcode libray. I've copied some code from the tutorial at [https://tutorialwing.com/implement-android-qr-code-scanner-using-zxing-library-in-kotlin/][1]. The tutorial uses the following import statement:
import android.app.Fragment
I've modified a fragment that was generated with the Navigation Drawer Activity template. It uses the androidx fragment import statment:
import androidx.fragment.app.Fragment
The errors it occurs on the following line with the "this" reference:
qrScanIntegrator = IntentIntegrator.forFragment(this)
The error is:
Type mismatch: Required Fragment! found HomeFragment
Changing my import to the older version to the older version is not recommended and if I do I get a lot of other errors.
What can I do to get zxing to work with the androidx fragment?
Thanks
The ZXing library is no longer maintained, and that particular class (IntentIntegrator) only supports android.app.Fragment which is the deprecated Android framework version of the AndroidX Fragment class.
You have a few possible options here:
Fork the ZXing library, and change the android.app.Fragment import to use the androidx.fragment.app.Fragment version instead.
Delegate the IntentIntegrator calls to your Activity instead, and have the results forwarded to your Fragment.
Simply duplicate the Intent initialization code from IntentIntegrator to a helper class of your own. The IntentIntegrator methods are just convenience methods to build an Intent and call startActivityForResult(). You'll still be able to use the IntentIntegrator.parseActivityResult method to interpret the result that comes back.
I would recommend going with option #3.
As a longer term alternative, you may also want to consider looking into Firebase ML Kit since ZXing is no longer maintained.
I read the article about AndroidX Refactoring Support at https://android-developers.googleblog.com/2018/09/android-studio-32.html.
To my understanding AndroidX will work instead of android.support.v4 and android.support.v7, right?
So in my new project, I don't need to import android.support.v4 and android.support.v7 again, right?
If you go to android.com's page Migrating to AndroidX, it has a list of which AndroidX package replaces each legacy package. It also has a list of which namespace a particular class has been moved to. To convert to using the AndroidX version, you have to replace the appropriate 'artifact' in your gradle dependencies, and you have to change your import statement to whatever namespace the class is in now.
For example, android.support.v4.app.FragmentManager is now called androidx.fragment.app.FragmentManager. So you'll need to change your import statement, and you'll need to add the relevant AndroidX library to dependencies in your build.gradle file:
implementation 'androidx.legacy:legacy-support-v4:1.0.0'
So yes, you don't have to reference android.support.v4, you have to reference the appropriate new library.
So, I have been trying to migrate the development of a multi-project (eclipse projects that is) app to Android Studio (v1.1).
Importing via File > Import Project was really easy and went without incident.
However, when I tried Make/Rebuild project I encountered numerous surprises. The first, not Proguard-related, had to do with source file encoding (originally in Windows-1252), but I quickly found a solution using this Windows-1252 > Reload > UTF-8 > Convert answer.
Then, "error: cannot find symbol class" for a com.comp.mod.X class of mine. I then solved it by going to the module (Android Studio module that is, previously an Eclipse project) that contains that class and added to its proguard.cfg the following:
-keep public class com.comp.mod.X
Which left me with an "error: cannot find symbol variable" for a const BB defined in the aforementioned class. I solved this by adding to the same proguard.cfg the following:
-keepclassmembers class com.comp.mod.X {
public static final boolean BB;
}
That left me with only one "error: cannot find symbol method getPreferenceX()". I solve this by adding to the same -keepclassmembers that method, so that the above now looks:
-keepclassmembers class com.comp.mod.X {
public static final boolean BB;
public static java.lang.String getPreferenceX();
}
I thought I was done, but to my dismay, when I attempted to rebuild the project, I received numerous additional errors from other modules in the project, all of the type to "error: cannot find symbol class/variable/method" and related to some proguard.cfg.
I could have continued butchering the proguard.cfg files for each and every module but at this point I am beginning to suspect that I am doing something fundamentally wrong, because those proguard.cfg files work perfectly under Eclipse. So,
Why all of a sudden these are no longer good for Android Studio?
If ProGuard runs only when you build your application in release mode, why is the Android Studio based build complaining about "cannot find symbol" due to Proguard's obfuscation?
What am I missing?
Note: I have not attempted "Generate Signed APK". All I do is "Rebuild Project".
Currently (as of 2015-04-24), minifyEnabled's default value of false for all build types is incorrect for multi-module projects, in which some modules (app included) are dependent on other modules. This is due to bug #52962 that causes build types to not propagate to libraries -- they are always built as RELEASE.
Suggestions to work around this bug or notifications of its fix are most welcome.
I have IntelliJ 12 and some groovy code (along with a pile of java code) in a project.
In intelliJ, i can see class A's import of some groovy code, and i have also included the library that has that code.
However, while the package itself is in one colour (for the import), the actual class being imported is in red, which implies an issue of some sort. Hovering the mouse over it reveals no issue though.
When i run a "make" or a "rebuild project" is where the problems start - i get
Groovyc: unable to resolve class com.blah.blah.blah.A
How can i resolve this?
Currently, my project setup is like so:
Under "Libraries" in (Project Structure -> Project Settings -> Libraries) I have:
the jar file with all the groovy code
the src jar file with all the groovy code
In the "Modules" section i have the - well, i don't know what to call it, the column isn't labelled - the library name from the libraries section associated with the src and class files, and the little "export" button beside it is ticked.
Incidentally, opening the class in intelliJ never shows the source code, which given the source is included struck me as weird.
Is there anything else I should need to do?
I've worked this one out, but if anybody knows why groovy cannot be in the "Resource Patterns" list and wants an upvote, do chime in
Oh, right.
I removed the !?*.groovy entry from the list of, um, entries in the File : Settings -> Compiler -> Resource Patterns thingy.
It doesn't seem to matter if "use external build" is on or off for this, but the !?*.groovy; entry cannot be there.
I wonder if anybody knows why?
I had the same problem and had to Add Framework Support and add Groovy to the project to get round this problem.
I created the project using gradle.
I just got your question in my Google results as I had a similar issue. My problem was that I was able to get the groovy code in my IntelliJ 12 project to compile ok, but it wasn't getting wired in properly when I tried to run unit tests within the IDE.
After some investigation, I uncovered that groovy and logback libraries were all set up in the project to be available in the runtime stage of the Maven build of the project, but that resulted in them not being available in the test stage. To fix this, I ended up manually updating the groovy-all and the logback libraries scope from runtime to provided under File->Project Structure->Modules->Dependencies. This allowed me to both compile and test within the IDE while including the Groovy modules as well as the Java modules.
Perhaps you had something similar going on in your project?
Six years later, I also just got this question near the top of my search results.
In my project my Unable to load class 'groovy.text.SimpleTemplateEngine' problem was actually due to a codenarc issue. I was able to resolve the issue by adding the following to build.gradle:
// codenarc version issue work-around
configurations.codenarc {
resolutionStrategy.eachDependency { DependencyResolveDetails d ->
if (d.requested.group == 'org.codehaus.groovy') {
d.useVersion '2.4.7'
}
}
}