I am working on an Android Native project using a couple of libraries (e.g OpenCV) that are not going to be pushed to the repository, mainly due to their size - instead they will be downloaded separately.
I am currently linking them my giving an absolute path in my system, which is clearly not a great thing for anyone else who wants to use the project. Linking them relatively doesn't seem like a great option either, since it's improbable that anyone would use the exact same relative location.
Apart from documenting the project well and indicating where do contributors need to change paths in order to compile the project - what's the best thing to do to ensure my project can be built as out of the box as possible?
Related
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.
I have multiple Android applications, and I've created a common Android library project, and a common Java library project (The Android library project compiles the java one). These libraries are filled with common components that I use for all my Android apps.
I'm using gradle as my build system.
I'm using git for versioning.
What would be the best way to link everything together? Keep in mind things are still being added / changed in the library, and I need a way to propagate changes to all the Android apps. Copy / Paste wouldn't be a great option. I've tried a few things, and they aren't working out very well, so I'd love some input.
EDIT: It's probably also worth mentioning that multiple people are working on these projects. It's not just me.
The current version of Android Studio has a limitation that all of its modules must be under the project's root directory in the filesystem, and this limitation hampers a lot of people in your situation, because frequently they want those common libraries to live someplace else. It seems like this is the case for you as well.
We're in the process of lifting this limitation in Android Studio, and soon you'll be able to have modules outside the project root. I think this might be the best solution for you -- you can pull your common libraries from wherever makes sense in source control, put them wherever makes sense in your filesystem, and link them up into whatever projects need them. However, this isn't available yet, but will show up in v0.5.0, which will hopefully go out this week. I haven't personally tested it in our dev builds and can't vouch for how well it works, but at any rate it should be coming along soon.
Some developers have worked around the limitations by adding script to their settings.gradle files to set different module root directories. They say it works, but I find it a little scary because the IDE just isn't expecting things to work that way, and I don't know for sure if there are problems with it.
If you read other answers to this question on Stack Overflow, they're written before this feature was implemented and will have different advice. If you don't want to wait for 0.5.0 or there are problems in it that prevent you from using it, you can follow that general advice, which is to have your common code compile to libraries that you publish to a Maven repository (which can be local to your machine or common to the developers in your group), and pick up those libraries with Maven-style dependency statements in the projects that need them. This has the disadvantage that you'll need to open up separate projects to edit the code in those libraries, along with a more complex build process, but it will work.
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.
So here is the deal. Let's say I'm developing an app depending on the Facebook SDK and Chris Banes PullToRefreshListView. I import the SDK's to my workspace(which I don't really like since it fills upp the workspace!) and reference it in my app as libraries. I'm making some changes to the PullToRefreshListView, let's say I'm adding a custom font or changing the color of one of the labels.
Now, I'm using Git to version control my project. I would like to be able to put up my project to our Git server and make my colleagues able to pull the project and get to work without having to struggle with getting the same SDK's (of the same versions as I used) setup and referenced in the project. Since I've made some changes to one of the libraries, the project could never be fully restored by another person if I don't provide the code.
How should I act in this situation?
Is it possible to put an uncompiled library in the libs folder or something like that?
If not, what is the right way of accomplishing this?
All I can find when Googling or searching Stack Overflow is how-to's on using compiled .jar files in the libs folder, which is good but not what I'm looking for.
Essentially, I'm looking for a good way of structuring projects using 3rd party libraries.
It sounds like these are android library projects (they contain assets). If that's the case, you can't turn them into JAR files.
The easiest way that comes to mind is to have your root project folder contain your app and all said libraries:
Root
-\Your app
-\src
-\res
-\3rd party lib 1
-\3rd party lib 2
-\3rd party lib 3
This structure would make it pretty simple to push to git and manage in eclipse.
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.