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
Related
Background
For the past few weeks, I've been on a mad quest to build a native Android client for an AWIPS2-EDEX server based on the open-source code for their Eclipse-framework-based Java client.
The specific repo of interest: https://github.com/unidata/awips2-core (and its dependencies, https://github.com/unidata/awips2-core-foss).
The Problem
I finally managed to get enough of awips2-core to build in Android Studio as a Gradle-based module (see my github fork at https://github.com/jskubick/awips2core-android ). After I finished celebrating my victory at getting it to build, I set out to actually make use of it in an actual Android app... then watched the build fail because awips2-core has dependencies on JAXB, which has been exhaustively documented elsewhere as being fundamentally incompatible with Android(*).
I'm now attempting to eliminate the module's dependencies on JAXB, but it got me thinking... how many MORE unexploded mines are out there waiting in the code for me to trip over... things that compile fine as "straight Java", but will blow up the moment something Android-specific references them?
Is there any tool that can scrape through library .jar files, and identify any dependencies within them that can't be satisfied by Android?
Update: my attempted project to use awips2-core directly with Android is dead. Upon further investigation, the implications of awips2-core's extensive use of Apache Camel sank in, and I realized that attempting to use awips2-core directly by Android in its present form is hopeless. As I understand it, Camel dynamically builds and compiles its own classes at runtime... which is completely impossible under Android, but allowed by "regular" Java.
This doesn't mean I've given up on my goal of writing an Android awips2-EDEX client, but it does look like my goal of reusing the existing code in awips2-core to write an Android client for EDEX is a lost cause & I'm going to have to write my own Android EDEX client from scratch.
(*) By "fundamentally incompatible", I mean that there's no known way to build it in a way that allows it to work with unmodified JAXB-using generic Java code built for Android. This is due to at least two problems:
Namespace problems. Think: BouncyCastle-vs-SpongyCastle. Apparently, Android hijacked SOME of JAXB's namespace for its own purposes, and Dalvik/ART's classloader won't allow you to override it with your own code using the same namespace.
Limits to Dalvik/ART's introspection capabilities. Basically, "real" Java has runtime introspection capabilities related to annotations that Dalvik/ART not-really-Java doesn't support... and some functionality with JAXB depends upon it.
From what I've read, various individuals over the past ~7 years have found partial work-arounds for 1 or 2, but the collective one-two punch of both has ultimately led to everyone who's tried to find a solution to either throw in the towel and write off the problem as intractable & hopeless, or hack it just enough to make it work for whatever they originally needed it for & call it a day.
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 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.
In my recently started internship (I'm studying computer science), I have to port a somewhat big existing Project to Android. It is a Visual C/C++ Project which in the end should run on Android using of course the NDK. The problem is that I don't know a thing about porting software, since this is not covered in my studies...
I had a few days to get to know the project I will be working with a little.
A few words about the complexity:
It is a Visual Studio solution which consists of 28 projects of which most are kind of big...
And now I need to develop a concept for porting it to Android, and this is why I'm writing this. I have absolutely no idea know where to start, also I don't know how to get to a concept for porting it. I tried searching online for some stuff or for some books covering this, but I found nothing.
Of course I know, that basically I have to remove everything that is Visual/Windows specific and replace it with appropriate Android/Linux functions or implement something new if there is nothing corresponding on Android.
But since this project is somewhat huge, I can't just try to compile it with the correct compiler and work through the error messages, this will lead to nowhere, I guess...
So now my actual question:
Is anybody experienced about this or something similar and can give some tips how to start with it? As I said, I first need a concept. Something more general about how to start and deal with porting a software project of this size is also very welcome, since I don't know nothing about it...
I think that you're approaching the whole matter in the wrong way. There are several tools that will allow you to compile C# and visual C++ and other visual languages from their respected IDEs to the android platform. For example there is mono for android . Mono is a plugin for visual studio which helps you create android projects using visual studio and .net technologies. I think you should focus your research on tools like this because changing all of the code manually is nearly impossible and too time consuming. Here is a page that will help you get started with mono for android. Good luck.
See this answer Android NDK with Visual Studio.
Personally I don't use this, but It seems to be a nice solution to your problem.
Like you, in the past, we had to port a big Visual C++ library project to Android, we proceeded in this way:
Try to compile the main library interface (by creating the relative Android.mk)
By using linking errors, you should guess other projects to be compiled and create the mks for them
Cycle until you have no more linking errors.
You didn't tell about the source code size of the project (how many thousands of lines of source code).
If the code size is big enough (e.g. at least 100 KLOC), you could consider customizing the GCC compiler (assuming a recent 4.6 or 4.7 version), perhaps using MELT (a high level domain specific language to extend GCC), or painfully coding in C a GCC plugin. This GCC customizing approach is worthwhile only for large code bases (you'll need several days to master GCC internals).
On the other hand, many well designed applications may have packaged their operating system functions inside a well defined interface and library. You might consider porting your application to Qt or some other cross-platform library.
We need more details about your project to help you more.