I decided to make an application on jetpack compose but when I download the Android Studio canary version 2021.1.1.1 and I try to write some code to see the changes on the preview at the right the preview tab says the preview is not up to date (or something like this) and requires a full project re-build to let me see my code changes
As of May 2022, There is no solution. Sorry!
Perhaps someday this will change. Until then, if you use jetpack compose, you'll have to do a rebuild your entire project to see the tiniest change in layout.
Furthermore, the requirement that you essentially have to write all your composable functions twice to preview them doubles the amount of boilerplate code you have to write and nearly guarantees that there will be code differences between the preview and actual behavior. Can you say, "Extremely easy to introduce bugs"? I thought you could.
For now, I recommend sticking with the old xml layouts. At least your work flow will be a lot faster. jetpack compose is simply not ready yet.
Related
I am recently back on an older Xamarin Android native project and VS has updated a few years/times since I last touched it. I was using Xameridea which created a parallel project to allow Android studio to be used for all layouts. I see VS2022 has updated their AXML editor but it is pretty poor compared to Android Studio. Xameridea is no more, as of 2019. This link talks about a way to do it via sourcesets:
However, most layouts are broken with errors regarding namespaces and lots of ANdroid studio level issues. So, I am wondering, how are you all maintaining your Xamarin android in vs 2022 in 2023?
I'm not sure what your problem is, but there is no problem using Android Studio Electric Eel and previous versions of AS to design your xml layouts for use in VS 2022. I've been using AS for my layouts for at least the last 3 or 4 years for both Xamarin.Android and now net7-android. As far as I'm aware, the Xamarin.Android designer hasn't been updated in that time period and is pretty much useless. All you need to do is create your layout in AS and then create a new layout in VS with the same name, and copy/paste the layout from AS overwriting whatever is in the Xamarin.Android designer, save it, build it and you are done.
As for maintenance, it does mean you have an AS project that mimics your VS project as far as layouts. I'd suggest, unless you have something better, using something like Beyond Compare to be able to open both XML layouts at the same time and that when editing a layout you always push changes from the AS project to the VS project, not vice versa. You get the added benefit of using a superb layout editor using AS along with their Layout Validation tool. I really can't imagine how anyone would be able to build a complex ConstraintLayout using VS 2022's designer.
VS has handled xml as compared to axml files for years now. I also don't understand your problem re namespaces - could you explain further with an example?
I can point you to shared examples where all the layouts were designed in AS if you need to see examples.
I just looked at the link you shared, and that suggestion also looks viable. Since it is an old link it may need to be modified to suit Electric Eel.
I have been during the last couple of months playing and building a full app in compose. My project has grow, and now with Kodein and other libraries that work already with compose I'm starting to realize how slow sometimes the IDE build the app just to show a simple preview. It was great on a new project to change code, compile in 3-5s and see the result.
But now, it's taking between 30-60s even if the change in the code was minimal.
Is there any way presently to improve the building speed performance for the previews and compose projects?
Try to put all UI components in a structured way, for example, do not put all functions in one file by doing this all functions with preview annotation will run at the same time and will result in slow rendering.
The Bad News
Under the hood, Compose works by performing annotation processing to turn your declarative #Compose functions into imperative rendering code. This annotation processing is done at build-time, which means it adds an extra step in the build process.
With XML and the View system, the UI wrangling is done at runtime. XML layouts are inflated at runtime, with no annotation processing necessary. This means that writing UI with Compose will always increase your build time compared to writing UI imperatively (with XML and the View system).
The Good News
Once you've accepted that you'll never reach the same build performance you had with the View system, you can start optimising. There are things you can do to take advantage of the gradle build cache, so that you only need to rebuild parts of the codebase since the last build. The official Gradle performance guide is here: https://docs.gradle.org/current/userguide/performance.html
A big potential gain is making use of gradle modules:
gradle can build independent modules in parallel
gradle can rebuild only the modules that have been updated
By splitting your codebase into modules, in particular extracting your Compose code to a dedicated UI module, you could see considerable build time improvements. I think this article explains this setup pretty well: https://proandroiddev.com/modular-architecture-for-faster-build-time-d58397cb7bfe
The Future
The Android Studio team seem to be focused on making Compose Previews render more quickly.
In the Artic Fox update, they added support for Live Edit of Literals. It works well in very specific circumstances.
In the Electric Eel update, they added Immediate Updates to Previews. Note that despite the name, updates are far from immediate. There are also many cases where a manual refresh of the Preview is still necessary.
In the Flamingo update, they added experimental support for Live Edit. Again, with a long list of exceptions.
Right now this tooling is not all there. But it is certainly getting better every update, and that makes me hopeful for the future!
I can't seem to find a clear answer to this in Google, and all the documentation and samples I've seen for Jetpack seem to refer to and use Kotlin.
But do you HAVE to use Kotlin in order to use Jetpack? Or can Jetpack be used with traditional Java programs?
I was looking at Kotlin but it adds almost a MB to your app size. And seeing as my entire app is only about 200KB currently, I don't think Kotlin is worth increasing the size of my app by 500%!
Jetpack is a collection of libraries plus guidance on how Google recommends building Android applications. These libraries all have Java APIs, so you don't need to move to Kotlin to use any of them. Both languages are still completely supported for Android development.
As for the APK size consideration, it's true that Kotlin will definitely increase it. It's hard to tell how much larger it'll be, but Proguard should strip out a lot of the standard library that you end up not using, so it could be much less than an entire MB. Here's an article that compared Java and Kotlin APK sizes of an essentially empty Hello world app that found the increase to be just 11 KBs, for example. So unless you're in a market where this is extremely important, you could probably get away with using Kotlin.
More importantly though, switching to Kotlin is more than just pulling in a library - it's a new language to learn, which means you have to put some effort into it, and it can change a lot about how you write your applications. You should look into the language more and see if you like what it offers.
You just get more syntactic sugar when you use kotlin instead of java, but they have same functionality and you can even use them hybird.
Also android Jetpack is great, it shouldn't be limited by language. Although android-sunflower - the official demonstrate app of Android Jetpack wrote in Kotlin, it can still implement by java. In order to support Android Jetpack, I translated all kotlin implementations to Java, and added [app-java] module as the Java version of android-sunflower app, please check out android-sunflower-java.
Quoting Android documentation
Jetpack is a collection of Android software components to make it easier for you to develop great Android apps. These components help you follow best practices, free you from writing boilerplate code, and simplify complex tasks, so you can focus on the code you care about.
Jetpack comprises the androidx.* package libraries, unbundled from the platform APIs. This means that it offers backward compatibility and is updated more frequently than the Android platform, making sure you always have access to the latest and greatest versions of the Jetpack components.
Nowhere in the docs you'll find something saying that using Kotlin is required for Jetpack development. Also, if you open Android Studio 3.2 (Currently beta 5), in the New Project Dialog, you'll see the option to add Kotlin support just like the previous version of Android Studio, so you'll be completely fine going with Java without checking this box.
The fact that Flutter heavily uses the word widget makes it difficult to find documentation on this topic.
On Android (I believe this isn't possible on iOS), we can add widgets on our home dashboard, allowing us to see app-related information or to trigger one-click actions without needing to open the app in question.
Is it possible to build such "widgets" in Dart & Flutter? Or should I do that in java and somehow plug it with my flutter app?
Can you share an example of a resource containing one?
EDIT: I have no android development experience, but it sounds like using a drawable canvas might do the trick.
I could find some canvas flutter code, but I can't connect the dots yet.
EDIT 2: From this Github issue, it looks like writing android home widgets in flutter is a no go since Flutter has its own rendering engine. I'm keen on learning kotlin to get this done, but if someone knew of nice tutorials to help me with that, that would be immensely helpful.
As the OP mentioned in an edit, this isn't currently possible because Flutter uses a custom rendering engine.
Widgets are quite limited in what they can render; the documentation explains that only certain layouts may be used. You could theoretically use Flutter's software renderer to render to an image in a seperate instance from the main one and display that, but that would be very technical, likely not very performant, and not straightforward at all!
Here is a quite detailed tutorial for widgets that guides you through creating a few examples although in Java. The same logic applies with just a few syntactical changes for Kotlin as the classes are pretty much interchangeable. However, realistically, most of the work is in the layout with some wiring in android; if you're already familiar with Android & Java, keep in mind that Kotlin does add a bit to your app size (The Kotlin runtime adds about 7,000 methods and ~1MB to your debug APK from the kotlin on android FAQ) and since most of your logic should be in flutter you probably won't have all that much Kotlin/Java code if this is all you're using it for (although if you're new to both Java & Kotlin, Kotlin is arguably more friendly in some ways).
Also, to be able to communicate between your flutter app and the java/kotlin backend, you'll need to use platform channels as described in the flutter documentation.
I wanted to create my own tool for android where i will change xml and that should reflect android ui side by side likewise what android studio and eclipse does.
Can someone tell me what android studio and eclipse uses to render ui from xml as shown in screenshot.
First off: it is not really clear what you want to achieve so I think I should ask some questions first.
- Do you want to create an add-on for an existing IDE?
- Do you want to create an Android Application?
- Do you want to create an IDE similar to Android Studio/ Eclipse?
Answer: If you want to create your own IDE then you need to implement the parsers and preview using 2D drawing. The tools AndroidStudio or Eclipse use to display the XML Views are part of the IDE. As far as I know there is no tool that will display your XML preview as they do. Follow the next instructions in order to implement that part.
But regardless of the answer to any of the questions above, here are some directions.
Since you need to know what kind of content you're using, you should start with an xml parser. How to do that can be found here.
Next step would be to actually draw the Views hierarchy somewhere. For that you need a basic 2D drawing knowledge, and you can start here
Access the resources for different platform and draw them to your window, using processed xml information and Android specific images. You can access the Android specific resources (images) for different platform, through the AOSP here
I hope i managed to point out some directions.
This is a complex thing to do:
One and only solution , Making the compiler for XML, If there are openSource XML parser for java Use them.
If there are not any I am afraid you have to make your own.
unity can do it for you its funny but you can do it with unity you can make android native views like button and ... in as objects in unity and load xml for adding views in right place,its so hard but possible and intresting