Android Studio / Gradle support
by Marc Sluiter
(next try, sorry again)
Hi all,
some time ago there was already a discussion about using Android Studio / Gradle
[1], but as far as I can see nothing happened afterwards.
So I was curious if I can get the cookbook application running with Android's
new build system, and want to share what I found out so far:
My first approach was to migrate the cookbook first, and using the library as
dependency only. But that didn't work out, because the Androd dependencies in
the pom.xml of the lib could not be found. I really didn't want to install them
with the maven-android-sdk-deployer, because that's not needed anymore with the
new build system, it accesses directly the installed Android SDK.
So I migrated the lib first. The first issue was: how do I get the aar into my
local maven repository? Solution: the Gradle Android Maven plugin [2]. After
some configuration I could install the lib into my local maven repo with
"gradlew clean install". Nice.
Then I looked how I can run the Robolectric tests in the lib. That seems to be a
problem, because the Android Gradle plugin team seems to be focused on running
tests in AVDs or on real devices only [3]. Then I found another Gradle plugin to
the rescue... at least I thought: the Robolectric team itself maintains the
Gradle Android Unit Testing plugin [4], which should run JUnit and Robolectric
tests, but unfortunatly it was broken by the latest Android Gradle plugin
update... [5]. So I prepared running the tests, but had to comment out the
plugin for the moment.
So back to the cookbook: here I had to use a workaround now for accessing my
local maven repo, because the official and easy way is broken in Gradle itself
atm [6]. But with the workaround I could run the cookbook app on my device with
"gradle clean installDebug"... finally (And with the OpenShift Push Server it
was easy to test the push functionality, great!)
So my resume of this adventure:
before that I liked Android Studio very much, I used it for some little private
fun apps already, and had only few problems. It has features (e.g. product
flavors) which were more difficult to handle with maven. But I tested only by
deploying and using the apps on my own devices (shame on me, I know...), so
missing JUnit/Robolectric support was not an issue for me. And my library
project was part of the app's project (works nice with Gradle!), so no local
maven issues.
But now I think that there is still some work to do with Android Studio and the
Android Gradle plugin. Some gaps can be filled with 3rd party plugins, but the
chance that they get broken by new versions of the build system is not low,
development is very fast.
One point I forgot: I did not have a look into the Travis stuff, because I don't
know it yet.
If you are interested in my results, see here:
https://github.com/slintes/aerogear-android/tree/gradle
https://github.com/slintes/aerogear-android-cookbook/tree/gradle
Kind regards,
Marc
[1]
http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Android-Google-s-G...
[2] https://github.com/dcendents/android-maven-plugin
[3] http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Testing
[4] https://github.com/robolectric/gradle-android-test-plugin
[5] https://github.com/robolectric/gradle-android-test-plugin/issues/8
[6] https://code.google.com/p/android/issues/detail?id=63908
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
12 years
AeroGear.js without jQuery Discussion
by Lucas Holmquist
> I agree that it would be nice to implement AGJS-70 (Investigate removing jQuery requirement). Meanwhile, there is an open source project on GitHub that claims to offer a custom builder for jQuery in order to include only the modules needed [1] [2]. I haven't tried it yet but maybe we could create a custom jQuery build which includes only the parts currently needed in AeroGear. This would mean a smaller size of the jQuery dependency.
The AG lib depends on a few parts of jQuery, the biggest being jQuery.Ajax and the promise implementation.
i know we can make custom builds of jQuery pretty easily( building from source ), but i don't really want to bundle it within our lib.
and i don't think with bower we can do this easily. although they did just add a post install hook, so perhaps that could be something to look at.
Datamanager only uses the promise implementation of jQuery( and some random thing for the filter method, which could probably be updated ). Promises are starting to become available natively in browsers and jQuery doesn't use the Promise/A+ spec, so it could be harder to fallback without a shim of some kind
while i don't really want to reinvent the wheel in terms of Ajax, it might be interesting to take a look. I think in a previous ML thread about what 2.0 looked like, that Pipeline would maybe just be a JSON only thing, with exception for multipart
12 years
automated plugin release
by Erik Jan de Wit
Hi,
Because the release process for cordova plugins has a lot of steps and because it’s a source distribution I would like to suggest an automated process for releasing and testing the plugins.
What I would like to suggest is that we create a gradle script (for instance can be something else) that will execute the tests, merge the development branch create a tag and publish to plugins.cordova.io. I’ve already experimented with it a bit and it seems very doable.
So what do you think?
Cheers,
Erik Jan
12 years
Modularization and Push
by Summers Pittman
Y'all,
So there has been some concerns with the complexity of the build
especially where including the Google GCM (push) libraries are
concerned. Additionally there have been some requests for a separate
"push" module which won't need the full aerogear android library.
The full modularization of the library along with several other
improvements is scheduled for the "2.0" epic.
So my question is a) Should we make a 2.0 which is only the
modularization sooner and iterate on that a few times before we include
our improvements in a 3.0 or b) Should we create a "fork" project which
is only a push module? This new project will get merged back into the
main project when we have our complete modularizations.
--
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.
12 years
Cordova and iOS
by Miguel Lemos
Hi all!
As you know I managed - with a little help from my friends ;-) -to have
the push notifications working on Android. But with iOS, not the same luck
so far. What I've done:
a) I created my development profile at Apple;
b) I uploaded the Certificates.p12 to the AeroGear Server;
c) I installed the devprof profile (the mobile provision file) in Xcode
(which says it's valid);
d) I inserted the variant ID and Secret on my phone code, like this (keys
are not real):
if(device.platform=='iOS'){
varID= "bb66d681-zabc-42cc-87f6-c27185c2389f";
varSec= "e66271f5-dd92-492d-bbac-83736f53e930";
} else if (device.platform=='Android'){
varID= "b438d657-5eef-4301-ba82-28c46cc3466f";
varSec= "150b5f99-z450-4edc-bdad-62dad284af2e";
}
var pushConfig = {
senderID: "278695547260", // not relevant for Android anyway
pushServerURL: "https://aerogear-metalpush.rhcloud.com",
variantID: varID,
variantSecret: varSec,
alias: userid
}
But nevertheless I can't register the device. I get this error:
no valid aps-environment (the message is not in English, so I translate it
freely:"It was not found a valid aps-environment for the app")
What can be wrong?
Thanks
Miguel
12 years
