At least in Fire, I’m not seeing any way of adding an android library project that isn’t just a .jar file.
Depending on how it’s stored, it’s either an .aar file or a directory with \lib; \res; etc in it. For the directory: Just reference the libraries in lib\ and it will deal with res\ relative to that automatically. If it’s an .AAR, extract the file (it’s a zip) and do the same as the directory. We’re working on automatic aar support.
1 Like
Hi @ck, I would like to know about the state of automatic aar support since I can not get how to use any android support library. When I extract the .aar file the document structure is like the picture below:
I can not get what you mean by referencing libraries in /lib folder because I can only see the /libs folder and it’s empty.
latest builds should just support referencing an AAR file directly, just point to the aar file.
@ck The Add Reference window only lists the .jar files. I think it’d be good if it also lists the .aar files in the list. From what I understand .jar files most of the times are only source and doc files.
Moreover, adding the .aar file leads to this error in the output:
: error JE20: Could not load referenced Java archive "recyclerview-v7-25.0.1": Invalid referenceI got the error by adding the file below as a reference to my project:
~/Library/Android/sdk/extras/android/m2repository/com/android/support/recyclerview-v7/25.1.0/recyclerview-v7-25.1.0.arr
What folder is the .aar file in that you are looking for? the System page only shows references found in a couple specific system folders (that said, there might still be a bug that it doesn’t include .aar files, we’ll need to see)
As for the Invalid Reference: what version of Fire are did you use to add it (i assume via browse, or by dragging the file into the project)? can you check the .elements file to see if the Include="" tag includes the .aar file extension in the name, and if not, add it. (iirc Fire was fixed to include it, but maybe after the version you have).
thanx!
marc
@mh as I mentioned the file path is:
~/Library/Android/sdk/extras/android/m2repository/com/android/support/recyclerview-v7/25.1.0/recyclerview-v7-25.1.0.arr
In the containing folder there are two .jar files that are shown in the System Page so I belive there must be a bug.
Fire version that I’m using is 9.0.97.2071 and I added the .aar file using Browse button.
<Reference Include="recyclerview-v7-25.0.1">
<HintPath>../../Library/Android/sdk/extras/android/m2repository/com/android/support/recyclerview-v7/25.0.1/recyclerview-v7-25.0.1.aar</HintPath>
<Private>True</Private>
</Reference>
above is the original form of the file, but after I changed the <Reference Include="recyclerview-v7-25.0.1"> to <Reference Include="recyclerview-v7-25.0.1.aar"> compiler expects to find the .aar file in the root of the project. I think it expects the complete path for the library file in the Include="" attribute.
i see. those arendt meant to be added directly, so they are t supposed to shop up in Add References. these are meant be referenced via gradle. but i’ll look at improving the UX for that, and i’ll also check why the extension gets dropped, that one is a bug.
I didn’t know gradle is supported. I think for the sake of UX it would be nice if you add “Add new file…” to context menu opened by right-clicking on the folders in the project.
@mh now the problem is that by using gradle script, it ignores the .arr libraries and just looks for .jar and .pom . this the the error I get:
FAILURE: Build failed with an exception.
* What went wrong:
Could not resolve all dependencies for configuration ':compile'.
> Could not find com.android.support:cardview-v7:*.
Searched in the following locations:
file:/Users/ali/Library/Android/sdk/extras/android/m2repository/com/android/support/cardview-v7/*/cardview-v7-*.pom
file:/Users/ali/Library/Android/sdk/extras/android/m2repository/com/android/support/cardview-v7/*/cardview-v7-*.jar
file:/Users/ali/Library/Android/sdk/extras/google/m2repository/com/android/support/cardview-v7/*/cardview-v7-*.pom
file:/Users/ali/Library/Android/sdk/extras/google/m2repository/com/android/support/cardview-v7/*/cardview-v7-*.jar
https://jcenter.bintray.com/com/android/support/cardview-v7/*/cardview-v7-*.pom
https://jcenter.bintray.com/com/android/support/cardview-v7/*/cardview-v7-*.jar
https://repo1.maven.org/maven2/com/android/support/cardview-v7/*/cardview-v7-*.pom
https://repo1.maven.org/maven2/com/android/support/cardview-v7/*/cardview-v7-*.jar
Required by:
project :It does, but it’s a bit tentative. I’m planning teamwork it drastically for Elements 10 when we switch to EBuild (and will probably bypass gradle altogether and implementing resolving references from gradle repositories internally), and i was just going to reply that i’m hesitant to make major changes to this to improve it, beforehand (because it will be double work, and this kind of stuff is messy to do in MSBuild), but i just had an idea how to actually make the way i want tis to work in EBuild functional with MSBuild as well, so i’ll be looking at doing that now (includes improvements to the build chain and changing how grad; le references will be handled in there Fire IDE — ore like regular references.
good idea, i’ll add that. i’m so used to Cmd-N, that i never missed having a context menu item. should be a quick fix, and will do for next weeks beta,.
What does your gradle script look like? this works for me, straight from one of my projects
dependencies {
compile 'com.android.support:appcompat-v7:23.4.0'
compile 'com.android.support:cardview-v7:23.2.1'
compile 'com.android.support:customtabs:23.2.1'
//compile 'com.google.android.gms:play-services:9.2.1'
compile 'com.google.android.gms:play-services-location:9.2.1'
compile 'com.google.android.gms:play-services-maps:9.2.1'
compile 'com.google.android.gms:play-services-gcm:9.2.1'
//compile 'com.facebook.android:facebook-android-sdk:[4,5)'
compile('com.amazonaws:aws-android-sdk-core:2.2.18')
compile('com.amazonaws:aws-android-sdk-cognito:2.2.18')
compile('com.amazonaws:aws-android-sdk-s3:2.2.18')
compile('com.amazonaws:aws-android-sdk-mobileanalytics:2.2.18')
compile('com.amazonaws:aws-android-sdk-sns:2.2.18')
//compile 'com.facebook.android:facebook-android-sdk:4.6.0'
}
1 Like
Next Fire beta:
where this is what the project looks like:
<ItemGroup>
<Reference Include="swift">
<Private>True</Private>
</Reference>
<Reference Include="cooper">
<Private>True</Private>
</Reference>
<Reference Include="android" />
<Reference Include="sugar">
<Private>True</Private>
<HintPath>\Users\mh\Code\Sugar\Sugar\bin\Android\sugar.jar</HintPath>
</Reference>
<Reference Include="References/facebook-android-sdk-4.14.0.aar">
<HintPath>References/facebook-android-sdk-4.14.0.aar</HintPath>
<Private>True</Private>
</Reference>
<GradleReference Include="com.android.support:appcompat-v7:23.4.0" />
<GradleReference Include="com.android.support:cardview-v7:23.2.1" />
<GradleReference Include="com.android.support:customtabs:23.2.1" />
<GradleReference Include="com.google.android.gms:play-services-location:9.2.1" />
<GradleReference Include="com.google.android.gms:play-services-maps:9.2.1" />
<GradleReference Include="com.google.android.gms:play-services-gcm:9.2.1" />
<GradleReference Include="com.amazonaws:aws-android-sdk-core:2.2.18" />
<GradleReference Include="com.amazonaws:aws-android-sdk-cognito:2.2.18" />
<GradleReference Include="com.amazonaws:aws-android-sdk-s3:2.2.18" />
<GradleReference Include="com.amazonaws:aws-android-sdk-mobileanalytics:2.2.18" />
<GradleReference Include="com.amazonaws:aws-android-sdk-sns:2.2.18" />
</ItemGroup>
(and i’ll be working on UI to add those references easily as well, ofc)
1 Like
I am looking forward to playing with Elements 10. Elements is an excellent and advanced project. The only things that are mising are details and features that seem trivial for you, but maybe it’s necessary for other beginner users. I’m trying to fill the absence of that beginner user by sharing my feedbacks.
this was the gradle file I was using:
dependencies {
compile 'com.android.support:cardview-v7:*'
compile 'com.android.support:recyclerview-v7:*'
}
and this is the build output i’m getting:
Odd. i can reproduce this. a concrete version works, but * fails for me too. can you try specifying a concrete version, i.e.
dependencies {
compile 'com.android.support:cardview-v7:23.4.0'
compile 'com.android.support:recyclerview-v7:23.4.0'
}
does work for me. i don’t see why * fails, given we just pass tis thru to gradle as is, but i’ll investigate more
FWIW, much appreciated, both the kind words and the feedback. We do want to make this as easy as possible; one of the main goals for the upcoming 9.1 release is “a better toolchain for Android that Android Studio”, so any such feedback is greatly appreciated.
as for feedback:
-
I think the top bar in the current version is better than the new one because the new one uses more real estate. The more space for code the better developer experience. Or you can just save that space for adding a status bar on the bottom. Much useful information can be shown on status bar like the details of selected word in the code that now appear on the same line. Showing those in the same line have many problems, for instance, it can be trimmed due to lack of space, besides having that on the status bar makes it possible to update the info not just by selecting word but also by hovering it.
-
for the reference window I think having a simple search function would be great for lists as long as these and maybe a checkbox for filtering the latest available packages.
-
I recall that you said in the next version dependencies going to be resolved internally. Since the users of Fire are developers, using less “magic” and instead more industry standard tools is more effective.
-
“check for update” menu always asks my user credential and after that … Nothing happens. If it’s because I had the latest version, It can just show a message that indicates there is no new update available.
-
Fire is the most right-click enemy IDE I have ever seen. Right clicking on code editor pane doesn’t open ANYTHING… I think many of the Edit Menu should be available in a context menu opened by right-clicking on words in the editor.
-
One crazy idea just came to my mind. One of the Fire’s features is to convert files from one language to another and then add them to the project. Besides, I believe copying a code snippet from StackOverflow and then changing the syntax to the working language is a common scenario. It would be nice to have a context menu option to convert the selected source code inline.
Can you elaborate on what you mean why this? the toolbar hasn’t changed since v1. Fire it optimized for maximum screen real estate dedicated to the code editor, I’m full screen view — with the side and drug panel collapsed, the only pixels now showing code are the ~20pt at the top for the jump bar. That was the case in 1.0 and is still the case in the current beta. in windowed mode, we have the titlebar and toolbar as well (always had), but you can hide the latter via the View menu, if you prefer)
Agreed. Fire was conceived on a 11" MacBook Air. and even though i “upgraded” my screen and use the 12" MacBook now for my own work, screen real estate and maximum code view is still a priority for myself as well.
Good idea, i’ll add a search/filter box. and of corse i’ll add versioning for the Gradle references; already have an idea how to do this UI wise, but its a bit more work than o had time for yesterday 
We always try to strike a balance between using standards, and using or own stuff. For example, the above dialog would not be possible w.o me implementing my own Gradle/Maven repository client. Similarly, it’d be easy to debug why resolving the “*” references doesn’t workforce you if it was m code — but now while we’re using Gradle to resolve these, thats a black box, and we have to use what Gradle gives us.
Doing this resolving ourselves gives us the best of both worlds: control over how its done and what level of detail and error feedback we can provide, wile still using the standards (ie the same repository, with all the available;abke references everyone else sees, as well.
Curious. i assume you are logged in? are you using 9.0 RTM or the beta? can you send me your ~/Library/Application Support/RemObjects Software/Everwood folder (via PM, not publicly here)?
Agreed, Fire is too focused on keyboard shortcuts, we need toads more context menus, and expand the existing ones. One for the editor is high on my list of oft-requested features.
You can already do this via the Edit|Paste menu, but yes, when we add a context menu to the editor, this will be available there, as well.
thanx!
marc
I’m sending it to you in a minute
I’m sure next version of Fire is going to be awesome!!
oh. that’s based in screen size. on small screens (i.e. 11" air) i merge toolbar a s title bar, on larger ones i don’t. that hasn’t changed. what’s your screen?
mine is 13" macbook pro retina