Why does gradle sync happen after creating new Activity?
Any way to stop this unnecessary build (which takes a huge time in big projects) without any impact?
It's not unnecessary. When you create a new activity using the automatic option for it, AS will also add an entry for it in you manifest file. This is most likely why it syncs with Gradle as that will also reload the manifest file (among other things).
It should also be mentioned that a Gradle sync is not a full project build. It can take some time in larger projects sure, but if it's taking an extremely long time (I'dd say more then 5-10s) you might want to have a look at your Gradle setup and see if there are any sore spots in it. If you are using the Kotlin DSL then building your build scripts will naturally take more time and this is one of the draw backs of using them.
Also how often do you create new activities? For me this is not something I do much at all (on average maybe once a week at best). I don't think it would save any time and probably cost more even if you could disable it (which I doubt you can as, like I stated above, it is needed). If it really costs you that much time you have to optimize your Gradle setup, otherwise their will be other spots in your workflow where you can save more time with less effort.
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 building an app with android studio with another developer. Is there any way in which I can make it so that both my partner and I can work on the project at the same time on different computers (both Windows computers)? I know there is a similar question, but I am looking for a more detailed explanation on how to do it.
My suggestion: Use Version Control preferably git.
This will help both of you to develop Apps without any problems of copying & pasting and manually making changes in all files one-by-one.
Note: Want to use git but do not want to open source your code (since Github allows creating private repository but with some Payment), then use Bitbucket, you can create private repositories for FREE!
EDIT: Github now provides unlimited private repositories.
Hope it helps!
Take a look at git. I will help you and your partner to work on the same project on a different computer (Windows, Mac, Linux...).
https://www.atlassian.com/git/tutorials/comparing-workflows
As others have indicated, you should use a version control system like git for this. This will give you the following features (among others):
The ability to share code between people
Essentially keeps a backup of your code on an external server
Keeps a history of revisions to files (so you can "back out" changes if you need) as well as differences between your local file and the version on the server
Allows you to merge changes between you and people working with you
How you do this will depend on which version control system you use, but some version control providers will allow you to also set up what's known as "Continuous Integration" - basically, if you or your partner check code in, it'll immediately start a build. If this is available to you, I strongly recommend using it. The advantage of that is that it'll give you quick feedback if you did something that'll prevent it from building for the other person (e.g. if you forgot to check in a file or something). This'll prevent a lot of frustration and wasted time. (This happens a lot more often than you'd think; you don't want the other person to have to spend half an hour trying to get the app to build again when they download your code only to find out that you forgot to check in a file).
I also strongly recommend integrating your stuff with each other as often as possible as well as practicing regular "re-baselines" (i.e. downloading each others' stuff and merging it with what you have locally). The longer you wait to integrate your stuff with each other the more complicated it'll become, and waiting too long greatly increases the risk of introducing bugs when merging or forcing unnecessary rework.
These are a series of questions for Android Studio programmers who have worked on large projects before. So, before I list the questions let me explain why I'm asking.
I couldn't help but notice it taking 36+ seconds for Gradle to sync and build for me to start programming every time I launch AS. It's not so much a problem now, but how about when the project starts to get over 26,000+ lines of code? So, now my real questions are:
1) Do large projects take significantly longer for Gradle to sync and build than a small one?
2) If it does, are there any levels of refactoring/error catching that I could bypass in the sync/build to make the process faster in the long run?
3) My computer can run any game on full ultra quality. Is a system spec that makes compiling and programming language processing faster than a gaming spec?
Thanks to all who contribute, and you will be acknowledged (with at least a vote) regardless of whether you can answer all the questions or not!
Lucky you. Gradle speeds have increased considerably over the last two years. As of today, even though still a bit slow, I'm pretty satisfied with the speed. Anyhow. Regarding your questions, here's my two cents:
Yes. But it's not a linear "function". I haven't come across any project that takes more than 3 or 4 mins tops when configured correctly, one especially was pretty big.
The only way to "speed up" the process is to allocate more memory. There are two ways here, inside the inner (module) gradle file, you can do this:
dexOptions {
javaMaxHeapSize "5g"
}
Or you can define a field inside the gradle.properties file:
org.gradle.jvmargs=-Xmx5632M
There is no system spec that I know of that will increase performance, but sounds like you got a pretty good system and you will not run into any troubles. A lot of progress has been made in the field.
Enjoy developing.
Yes, larger projects will take longer to sync and build. Lines of code is a contributing factor, as well as dependencies, number of assets, etc. Gradle is also somewhat infamous for being a bit slow.
This is dependent on your individual Gradle configuration. Removing unneeded steps (if you have configured some), such as signing the APK, may also help. 'Instant Run' is very quick for small changes but is somewhat untrustworthy. There's no way to 'skip' steps of compilation - if a recompile is needed, a recompile is needed. Trust that the compiler and IDE will optimise out any unnecessary steps and ensure that you are not asking for any unnecessary extra steps.
Gaming computers generally have fairly beefy processors, which are the main component used to sync and build a project. The disk read speed of your hard drive will also be a factor - SSDs will be much faster than platter drives - but it's comparatively much less important than your processor. Your video card, the other big component in a gaming PC, will not be used at all to build. A solid gaming PC will be more than adequate for development.
There are a few ways to shave time off your Gradle build times (for example) but build times will always be a reality.
I have been developing a much-revamped version of an earlier android application. So many additions and changes to the infrastructure, UI, and general organization were necessary that it was far easier to start from scratch with the new application and transplant some of the guts from the old one rather than trying to understand everything the previous developer wrote and incrementally perform smaller surgeries.
I have the source code from the previous developer, and it contains several activities, fragments, classes, etc. that I know likely are not being used in the final build. To make the transplant process as easy as possible, is there an easy way to find out which of the above components are simply not being used in the app?
A couple ideas that immediately come to mind are:
stepping through everything in a debugger and taking note of which components are used (this seems like a super inefficient and terribly tedious process)
add a log message to each component's onCreate/instantiation code and then run through the entire app (more efficient, but still a pain)
Is there an easy way to do this?
The way I see it, there are a few options using Android Studio:
Add a new module for Android TV, and create a common module to share some of the code, but mainly re-write most of my code for Android TV.
Add one or more Android TV specific packages in my existing application code; add the Leanback manifest intent filter for the Android TV main Activity, and finally do manual checks in code. Some of the existing stuff can be re-used on Android TV, and some areas will need to be re-written.
What do you think is the best option?
I personally think that the second option is the best, as it's significantly easier to do, but it does have a few disadvantages, i.e. a larger APK size.
It really goes down to your project, how it is built, how big it is, and so on. In a general sense, each option has its own advantages and disadvantages.
EXTENDING THE SAME PROJECT
You can decide to share your code base and add some TV-specific classes to your existing project. This allows for a faster bootstrap for sure, since you have all the code you need right there. Plus, to the end user, the Play Store entry will not change, so you will benefit from the same ratings, downloads, visibility and so on. The downside, in this case, is the risk of your app becoming monolithic and thus, harder to handle.
CREATING A NEW MODULE
On the other hand, going for a separate project "forces" you to write common modules, which (to me) sounds like a good thing. You will have a longer bootstrap if your code/project is not modular enough, but in the long term it will pay off. Also, the APK of your TV application will benefit too, since it's going to be smaller. You will have a different Play Store entry, but that could be a downside as well as an upside. Finally, I think it feels refreshing to work on a separate project once in a while, so this is a totally subjective plus :)
In my company, we decided to go for a separate project/module. We wanted to modularize some common components, so it felt like the right time to do so. That alone was a good reason for us, and we did not regret it. Also, we had the chance to experiment with a new project structure, which involved using a bus (Otto) and a job queue (Path's).
All in all, it's up to you and to your project. I will try to add as many other points as I can.