I have an "older" machine which is more than adequate for developing my first Android marketplace application BUT only with Java!
I recently tried Kawa and Scala (I switch to functional programming about six years ago with LISP/Scheme and I've absorbed Erlang and Haskell since then) and I must say that I really love Scalas conciseness and Kawa is still fantastic (used it a long time ago for a project).
However... the build time when "dexing" on my machine is into the minutes(!) when the 'dx' program works on the kawa.jar file.
Does anybody know if it is possible to "cache" or "pre-build" a Jar file so that the desxing process only does what has changed. It is just a little irritating and sad to see it dexing the jar files I've used even though they are the same as last time.
I could buy a faster new machine but I don't have the spare dosh right now so I want to know what optimisations I could make...
:(
Thanks.
This article might help - Custom Class Loading in Dalvik. You would have to use multiple pre-compiled dex files and perform some of the class loading yourself as required.
Maybe you could preinstall kawa.jar on your (rooted) android device, see here: http://zegoggl.es/2011/07/how-to-preinstall-scala-on-your-android-phone.html
Related
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.
For a project, I am changing certain ContentProvider-files in the Application Framework Layer of the Android System. As I am trying different things, I was wondering if it is necessary to build the Android Source for every change I make, or if there is a way to somehow emulate the system without the build?
I am not entirely sure what "building" means, as I cannot find a proper definition including Android as a context. I assume it is some kind of compiling?
Converting the source code into an executable program? In that case I do not think there is another way, is there?
But do I understand building correct in the first place? In that case, I would believe there is no other way than building the system every time and then see how it works out.
So I might have the solution right here, but I was hoping someone could assure me that it is right or maybe tell me why it is not?!
Any help is very much appreciated!
Building in this context means that all Android source files are re-compiled by the java compiler and a massive .jar file is produced. This is the Android.jar file that we see in the library dependencies of an Android application project.
Unfortunately, the short answer is that there is no way out for you except to re-compile the entire blob of the Android framework files each time you make a change. What I can advise you is to plan all your changes beforehand so you don't end up wasting a lot of time.
we all know that google is shifting from Dalvik to ART ( 4.4.2 has even experimental support too) for obvious reason, A very basic question is arising in my mind after i recently started working on mdifying the generated smali files for some purpose. Here is my question:
After expanding any apk file we see dalvik executable and various smali file containing dalvik opcodes and other related things. So i was surprised if this structure inside the apk file will be containing the similar things going forward once Google forces to use ART i.e. I am not clear if modifying the smali file will be valid once ART takes over.
This may be very basic question for many but is my first question in this forum so please excuse me for my limited knowledge on this topic.
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 am newer to android development. I have a couple apps I've made with appinventor. I would like to be able to take a completed and packaged .apk that is saved on my computer that was made with appinventor and open to edit it in eclipse. Mainly I want to see how a working app Ive made is actually written. This is for my own educational purposes only, no pirating or other illegal uses.
generally it is not possible to convert an App Inventor project into Java. However there are projects which have this goal, see the App Inventor-Java translation project and the Java Bridge project.
Check the android-apktool. I have no experience with the tool and as I see it will not show you the sources but it seems to be the best way to 'unpack' apk files.
I doubt this is possible, how are you going to bring the dex code back to your java code, even then, AppInventor makes for horrible APKs, two apps that do the exact same thing will differ greatly in size if made with the SDK vs AppInventor.
You should just read a couple of books, or search for information online, instead of trying to unpack an APK.
It's absolutely possible using dex2jar which involves a little time to set up and run but it give you a .jar that you can open with a java decompiler. As for getting the source files into eclipse, there are probably some decompilers that do this but probably cost money. You can use the one listed to copy/paste the code out but it will not provide you with an eclipse project.