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.
Related
I've been working on a writing a game for Android. Until now I've been using Java instead of the NDK, but I've decided to port my code to C++ (for performance, memory management and industry standards reasons).
Porting my application shouldn't be a problem (I've written my fair share of C++ applications), but I've been using RoboGuice as a dependency injection framework because otherwise my object graph would become too complex rather quickly.
I've been looking around, but I haven't found any resources about using a dependency injection framework in combination with the Android NDK.
Can someone tell me if there any such franeworks available. If so, which one would you recommend?
If you have a C++11 compiler for Android you could use several frameworks (I wrote Infectorpp) but there are others available. You should note that DI is quite limited in C++ due to the lack of reflection so you should make some compromises as not everything you did in RoboGuice would still be possible.
By doing a quick search seems that C++11 is possible on Android. I don't have an Android device and still not needed to emulate it, but if you have any feedback it will be wellcome (private message here or support ticket on google code is enough), the library is headers only so no special build stuff is required for it, apart enabling c++11 on your compiler wich is just one extra option by command line. If that will works good on Android then it will be definitely good also for PC. (Do not misunderstand please, I'm using it heavily, but seems very few people is interested in DI in C++ and so I get very little feedback)
There was also a nice framework cpp-resolver: a little awkard to use because you explicitly register factory functions for injecting ALL parameters, but very scalable, especially for server applications.. (decouple object lifetime management and works with plain old C++).
The most complete framework is probably wallaroo
If you search something really easy to use Infectorpp is a good choice
If you need control over lifetime (mostly servers): Cpp-resolver is perfect
If you need exotic features and configuration files: wallaroo
As side note, run-time configuration is possible also with frameworks that do not explicitly support it:
You just need a Factory that istantiate a different type based on a configuration file you could read through a class that you add as dependency to factories (Probably you don't need to know that since you were already using DI frameworks, but still good to know for occasional readers)
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 am creating an app showing local events for android. I was hoping to use the Eventful API, since that came with its own java-based client library. However, I'm not sure if it's fit for Android, since I know a lot of these java based client libraries use stuff Android doesn't support.
So, does anybody know if it works?
My entire project is available # github if you want to check it out for yourself.
The API is found here.
Android does not have have issues with Java client libraries. It is build on top of standard Java, and can use all of the framework features.
Furthermore, it looks like this API offers a RESTful interface, which is for sure supported by Android.
Bottom line, I do think you can use this API in Android without issue.
I'd say the easiest way is to compile and run an application that embeds the library and tests a few methods.
Typically, you may have issues with the way the networking is handled. There are 2 main ways in android to do HTTP, the Java and the Apache way, I think the Java URL API is fully supported and very close to the actual Java version, but the Apache has some hidden differences.
The main risks you'll have are A/ that it uses classes or packages that are not present on Android. B/ that a class does not behave as expected, which does happen from time to time, as the Android implementation is entirely specific.
Apparently you have already tried to run an android app with the library included? Did you encounter a specific error? If you, can you post the stacktrace?
We have a program that we wish to deploy across multiple devices.
Standalone Captive AIR
Web based flash app
iOS app
Android app
The code other than some UI stuff is identical in a lot of parts. I'm wondering what's the best approach. Should we have a shared library project or should we have one big project with different complier settings controlled through ant or some other method.
Accessing and using Shared Library Project is the best way to be implemented for cross platform Projects. Other than this Approach you can use ant Build.
The answer would ordinarily have a lot to do with the "UI stuff" that's different, but since it sounds like you're Flash/AIR, that's probably not a big concern. If it were me, I would go w/ the "one big project" approach, and get a serious CI/NI and SCM suite that was compatible w/ my IDE. If you're using Eclipse/Aptana, I like Husdon/Surround. (Full disclosure: I used to work # Seapine.) If you're not using Eclipse, you should check out the CI/SCM options that integrate w/ your IDE (and themselves; e.g., Hudson has a Surround module and vice versa). The shared library thing works, but since Flash is Flash darn near everywhere, I don't see the need for the increased division of separate projects. A full-featured CI can manage the compiler differences for you quite effectively.
We're using this combination of approaches for a large scale mobile/web project that currently exists in the IOS AppStore, and will soon be released on Android and the web:
One main project that uses compiler directives to handle specific platform logic and elements
Compiler directives to handle specific platform logic within the main project codebase
A separate project for our video and interactivity engine, which is mostly platform independent, using switch statements for platform specific logic
One shared SWC for graphical assets. Platform specific elements are prefixed with the platform and an underscore. Compiler directives are used to specify which movieclips get displayed on screen
Ant scripts to do the compiling for the various platforms
Native Extensions to interface with hardware specific features
We use some commercial, some open source, and some homemade ANE's for things like AppStore integration, social media features, network monitoring, notifications and inter-app communications.
com.adobe.extension.NetworkInfo.ane
com.milkmangames.extensions.EasyPush.ane
com.milkmangames.extensions.GoViral.ane
com.milkmangames.extensions.StoreKit.ane
(I have no affiliation with milkmangames)
I'm currently writing an Android ANE to handle inter-app communication using Intents. It's a project I'm open sourcing at:
https://github.com/interactivenyc/ANESampleProject.
I'm currently stuck on a problem there and will be posting a question very soon with the details if anyone is interested in following that project. The project setup is fairly well described in the ReadMe file displayed on the front page of the project.
If you use git for versioning take a look at submodules. I used it to keep everything in one project, but versioning each module separately, and it resulted a fine solution.
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