I know that new versions both support NDK for android applications.
But many plugins doesnt work with gradle-experimental.
What is gradle?
Gradle is an advanced build system as well as an advanced build toolkit allowing to create custom build logic through plugins.
What is gradle-experimental?
The new experimental plugin is based on Gradle’s new component model mechanism, which allows significant reduction in configuration time. It also includes NDK integration for building JNI applications. This user guides provides details on how to use it and highlights the difference between the new plugin and the original plugin.
WARNING: Note that this is plugin is at the experimental stage. The Gradle API for the new component model is not final, which means it’ll only work with a specific version of Gradle until the APIs are final.
Additionally, the DSL is likely change significantly, as APIs to create the DSL are finalized.
This is a very early preview of the plugin for feedback on performance and NDK integration.
Essentially, gradle-experimental is a work in progress (as stated above this plugin is at the experimental stage) of what gradle itself should become in the future.
An analogy:
A house was built some years ago and has been through alot of improvement. Everything is in place, and it appears done. Today, it is a place where you know you'll be safe if you live in it.
Another house is being built at this very moment, because the owners of the house above have plans to move. Some rooms have been constructed, some haven't. Some doors and windows are already in place, some have not even been ordered yet. Some areas they don't even know yet what they are going to do with. Some rooms might appear done, but they may very well be refurnished at any point in time. The ceiling may collapse, the floor may disappear, you'd only know about it when it has already happened. This house is not currently safe to live in.
Gradle is the first house.
Gradle-experimental is the second house.
I don't think there is much use in comparing them at this stage. If you don't absolutely need to use gradle-experimental for whatever reason, just stick with the current and stable gradle.
Related
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'm having trouble building an Android project at the company I am working for. Currently, I get a whole bunch of errors when I try to build my project due to the specified versions of the dependencies defined in the .gradle file not matching the current version of kotlin.
So, to rectify this I have updated the highlighted dependency versions in the project to match the current version of kotlin I am using.
My big question is whether I have to do this every time I want to develop on Android? I'm assuming the answers a big fat NO, but as someone completely new to this, I definitely need some help from the community if possible.
Just to explain me, we have limited development resources, hence the question on here. I'm going to be taking over the Android side of things and should probably sign up for a one-week taster course (or something like that) but for now, I have our whole Android app on our hands with minimal comments, tests or instructions.
I also posted this question to Reddit and the best advice I was given was to add a '+' to the dependencies in build.gradle instead of version numbers. I've since tried this and feel like it might not be the solution I need. This is because I feel that the live application wouldn't be working if this were the issue.
In short, I feel like my local version of the application might not be working because I have some settings in Kotlin/Android studio somewhere that I need to change.....Any suggestions you can provide RE what these settings may be would be a huge help!
The error from your comment isn't related to Kotlin. Make sure that all versions of the support library are the same, currently you're using 26.0.0-alpha1 for customtabs and 25.3.1 for cardview-v7. You should probably use version 25.3.1 for customtabs as well.
Also, avoid using +, as this makes your build always use the latest version of the dependency, which makes specific builds unreproducable.
I learned android development on eclipse a long time ago. Recently I have some free time. So I decided to catch up on it again.
When checking for eclipse, I saw that it is not supported now and android studio is the new way.
My questions are...
Can I use the old eclipse's android SDK with android studio?
What are the most important changes I need to know?( basics)
Can android studio run on my old computer screen? With a resolution of 1024x800. Because it says on the site that it needs 1280*1024 at least.
Thanks in advance .
Yes it is possible to point Android Studio at pre installed SDK/NDK, but now they have really improved the packaging and downloading of this stuff, so I would say burn it all down and start fresh. Let Android Studio manage the SDK and it will be much easier.
Otherwise, its an IDE, pretty standard stuff. You'll have to learn gradle now to manage your project, which is the main change since Eclipse was using ant. And do get a better monitor :)
Yes, you just need to change the path specified in Studio to your old Sdk that you were using with eclipse and it should work
Apart from different key mappings for shortcuts (you can use eclipse shortcuts in Studio too, by changing editor settings). Except that nothing special, but you got lot more ammo now. You will learn gradually about tests and different configurations in Gradle build System
AFAIK, that shouldnt be a problem, just that it might looked a bit crammed up
Agree with yano, ditch the Eclipse SDKs if possible. The SDK manager is pretty hassle free on Android Studio.
Secondly, the biggest changes for me were the introduction of Gradle and a more rigid project architecture. In Eclipse I was pretty used to putting elements all over the place in which ever folder or package I wanted. Android Studio is a move toward convention over configuration, so projects in Android Studio tend to have similar structures. I think this is great because it requires less configuration (and understanding of unique configurations) by me. Also, Gradle is great. It takes some getting used to (it seems very abstract in the beginning) but having the ability to add packages with a line of configuration beats manually adding libraries to my project. Beyond that, I'd say AndroidManifest is at least now partially configured by your project and that Android Studios object creation wizards handle a lot more of the boiler plate code needed to create new entities. All in all a better - more Android-centric - platform. Took me about a month to become comfortable with the switch. Wouldn't move back (even if that was advisable)
As for the min-resolution I'm pretty sure it will work. I have heard of people running below the min requirements. But it will feel cramped. All the drawers are collapsible, but I personally find Android Studio a bit more cluttered with buttons and panels than Eclipse (others may disagree). Should work, but may not be comfortable
I have a piece software that should delivered to many customers.
Each build should get a customized set of assets (icons , splash screen etc. ) and a bunch of config files, but also a different app id (eg. com.myself.myapp.customer1 ; com.myself.myapp.customer2 etc... )
Also I need builds for different OSes like Android, iOS , PlayBook.
The way I handled this up to now was:
I created a new Application.mxml for each customer, which opened the right locations and passed the files to the MainController.
This leaves it to me to pick the right assets, certificates and iOS-provisioning files to be packaged each time I need to compile, and I had to repeat this steps for each customer, which is very error-prone and , especially in case of iOS, extremely time-consuming.
So I need to get into automated building quickly...
I already downloaded and installed gradle/gradleFX, but I don't find the documentation very friendly to beginners in this subject.
Now the questions:
How do I have to convert the (Flash Builder- ) given project structure to conform the gradle conventions? Are there FB-plugins or tools I could use?
Can I use gradleFX to build for debug sessions as well? FB 4.7 has a lot of issues with that I really like to circumvent.
Can an ipa be "signed" and packaged with assets after it's principle compilation, so I don't have to wait 15 mins for each compile?
Many thanks
How do I have to convert the (Flash Builder- ) given project structure
to conform the gradle conventions? Are there FB-plugins or tools I
could use?
There is nothing to convert. Unless your project structure is extremely exotic, you should be able to configure GradleFx to work with it.
Note that by default GradleFx uses some Maven-style conventions: for instance, the default source folder will be src/main/actionscript. If you want to configure a typical FlashBuilder project you'll have to explicitly declare the source folder:
srcDirs = ['src']
As for FB plugins: there are none. But you can use an "external build tool" instead of FB's built-in configuration. IntelliJ IDEA has Gradle support, but nothing specifically for GradleFx. GradleFx itself has a flashbuilder plugin, but its purpose is to generate an FB-compatible project from a build script - I don't think that's what you're looking for.
Can I use gradleFX to build for debug sessions as well? FB 4.7 has a
lot of issues with that I really like to circumvent.
You can build a debug-enabled version of your application simply by setting the debug flag to true (as described in Adobe's mxmlc docs). GradleFx does not expose all compiler options in its API (there's just too many of them), however you can use the additionalCompilerOptions to define whatever additional compiler flags you require:
additionalCompilerOptions = ['-debug=true']
I don't know how you should tell FlashBuilder to hook up to the compiled swf for its debug session though :( Perhaps through the "external build tool" configuration.
Can an ipa be "signed" and packaged with assets after it's principle
compilation, so I don't have to wait 15 mins for each compile?
I know too little of mobile support to give you a meaningful answer here, but I can tell you that a major upgrade in this area is in the works right now and will be released soon. Perhaps you should ask this question on http://support.gradlefx.org/; #Slevinbe is very helpful and quick to answer.
I don't find the documentation very friendly to beginners in this
subject
If the docs don't work for you, perhaps the example projects might be more helpful. That said, you could help us make the docs better for beginners by telling us how we could improve them. Just start a discussion on support.gradlefx.org
Multiple outputs
One more thing: your main issue seems to be that you need to create multiple outputs from a single code base. This is one thing that GradleFx doesn't provide out-of-the-box (yet). However, there's a fairly unobtrusive workaround that I've described on my blog. If you find the basic concepts difficult to grasp, then I suggest you don't start with this part, but rather concentrate on getting a single project building first.
I've been doing a lot of research to try to set up my development environment to produce highly maintainable code, essentially. I've found many tools for Java/Android around, and the more I research or try to use more it seems that I end up running around in circles. Is there anyone that can give me solid advice on these things? A lot of my search results are out of date, and/or partial. They at best get me one piece of the set up, but don't work well with each other.
Tools I've tried to integrate into my development:
Code Coverage
TDD
Build tools
Dependency Injection
Compatibility libraries
Continuous Integration
I wanted to have a nice MVC structure to my project, with proper scoping of objects, so I discovered Roboguice/Guice and using interfaces/abstract classes to expose the API of the underlying implementation. This I got to work fine for me so far, though not for testing yet. I need an older-SDK compatible Action Bar, so I was lead to ActionBarSherlock in the Android Office Hours. I can add the Android Library Project fine it seems.
Then I discovered (at least for the current stable version) you have to do some maneuvering to get it to work with Roboguice because of the compatibility library. The solution pointed to using Maven to handle the dependencies. So I look into converting my Android project to a Maven Android project (it's something I was considering doing anyways for the cleaner project dependency management). Now I believe I have Maven, Android, and Eclipse (yes, I forgot, Eclipse is another variable in this equation) to work together. But now I'm having issues using the ActionBarSherlock library when importing it through an apklib-type dependency as the guide mentions. Can't "find symbol: class FragmentActivity" for example. I try to make a new Android Library Project with the "target/unpack/apklibs/" Maven produces, but can only get empty Android projects missing an AndroidManifest.xml.
Then I try to find how I could add code coverage for my testing suite, and I find Emma, EclEmma, and Robotium. It seems that those only "work" with Ant builds, in particularly, I've only read things for Emma that seem to require major modifications of the default Android files and build script to support the code coverage reporting. I'm now hesitant to move forward on those because I don't want to destroy my Android development base pursuing old advice, and it requires Ant not Maven, but my earlier work needs Maven.
I'm hesitant to ask such a question because it seems broad, but they are important tools for developing production code so people must be using them, and I can't seem to figure out how to get a nice subset of them working simultaneously. Is there any experienced advice for this issue?
This is more of a side note. All tools you are mentioning are wonderful but please remember that all of them come at the cost of adding bulk to your app. My rule of thumb is: no more than 150-200K of added weight. So I have a tendency to use simple and built-in packages. I get much more mileage on good reusability of my code and I'm really picky about any code repetition. So, refactor, refactor and refactor. Eclipse provides wonderful facilities for that