Declare your activity as abstract class in library and create a new
activity in client apps using that library.
Declare a configuration class with static variables for your library.
Assign resource ids with your local R.ids. If required you can allow
yr client apps can configure required
Thanks, Chenna, for your reply;
but I have some doubts more... Could you better explain me , with
sample code?
You say: Declare your activity as abstract class in library = ok,
in this way (right?)
**
public abstract class
As per my understanding you have two activities in your library. So
you want to provide your library for another apps to use it. You want
to set text resource from your client app to your library activity. If
you want only resource. Create a class Configurator and declare a
static variable
Ok, thanks Chenna, for your help ..
maybe i didn't make my self very clear, I'm very sorry...
Setting the text resource from my client app to library was just an
example.. I was actually trying to modify the Activity library
behavior, overwriting it on the client app that is using the library
Ok I got it.
Make your SecondActivity as abstract class in yr library and create a
clientSecondActivity class and extend SecondActivity
OverRide onCreate() method and add required views.
thanks
Chenna
On Oct 26, 7:47 pm, Francesco nolano...@gmail.com wrote:
Ok, thanks Chenna, for your help
It gives error on xml resource reference in application
AndroidManifest.xml.
After copy med_widget.xml from library project to application project,
it works good.
I haven't try, can i add widget configuration in application
AndroidManifest without refer to widget xml?
Thanks,
regards.
On 26
For example, for android default resource you can use @android:anim/
cycle_interpolator
And for resource in library project?
On 26 Nov, 15:37, Premier a.grum...@gmail.com wrote:
Hello,
i'm using Android Project Library (http://goo.gl/7vvxI). In Android
docs, it copys all items from android
Resource from library project are packaged with the application
(that's the whole point of library projects), so you don't need to
change any @type references.
The only thing you need to update are the classes (like Activity,
Service, etc...) that are declared relative to the library package in
I'm having this exact problem right now. Did you figure it out?
On Jul 7, 11:58 am, Vladimir Lebedev-Schmidthof dair@gmail.com
wrote:
Hello Mark,
I faced the same problem with attrs.xml in Library Project. Have you
finally found the solution?
On 23 май, 23:22, Mark Carter
this is good news, do you know when next ver of ADT will be available
through Eclipse update?
On Jul 9, 2:36 pm, Xavier Ducrohet x...@android.com wrote:
Just to give an update to anyone still reading this thread.
The next version of ADT will include fixes for:
- Issue with the library needing
I was having similar problems to the others in this thread.
Removing the '-' character in my library project name (it was called
project-library) made the library instantly appear in the non library
project,
On Jul 9, 1:36 pm, Xavier Ducrohet x...@android.com wrote:
Just to give an update to
Here is another issue.
Import works but auto complete doesn't. If I have a class called
MyClass then normally I will type
MyC and press ctrl+space to autocomplete the type. This does not work
when trying to use classes in the library.
I have to type out MyClass in full and then do the import.
On
Actually it breaks auto complete entirely.
I hope that's fixed in the update - until then its useless :(
On Jul 21, 12:44 am, samspade79 samspad...@gmail.com wrote:
Here is another issue.
Import works but auto complete doesn't. If I have a class called
MyClass then normally I will type
MyC
Hello Mark,
I faced the same problem with attrs.xml in Library Project. Have you
finally found the solution?
On 23 май, 23:22, Mark Carter mjc1...@googlemail.com wrote:
I'm sure that thelibrary.apk file error was because I had added
thelibraryprojectto my appprojectbuild path.
The other
Thanks for your reply! Don't worry, I will try to solve the problem ;)
I have not error in my progect, but when I run my application, in LogCat
file, I obtain:
*tag *
dalvikvm
*Message *
Could not find class 'org.apache.axis.client.
Service', referenced from ...
Regards,
Deborah
--
You
On 7 July 2010 20:58, Vladimir Lebedev-Schmidthof dair@gmail.comwrote:
Hello Mark,
I faced the same problem with attrs.xml in Library Project. Have you
finally found the solution?
Sorry Vladimir - I stopped using the Library Project system I while ago -
and never found a solution to
Just to give an update to anyone still reading this thread.
The next version of ADT will include fixes for:
- Issue with the library needing to have a single source folder called
src. Any number of source folder, of any name, even under other
folder (src/java).
- Issue with project name
I've lost whole day restarting eclipse, cleaning and rebuilding
projects just in order to make errors reporting missing class
references disappear. Without any success.
As I have projects divided in several working sets, I have a wild
guess that these working sets might cause problems as well.
Hi Xavier and all,
There is clearly some problems with project naming.
I usually name my projects with '-' (e.g. Project-Lib) but that
doesn't work for my library unless I rename them (to ProjectLib) and
restart my Eclipse. I also noticed that to create a link to a library
project, the library
On 5 June 2010 22:56, Xavier Ducrohet x...@android.com wrote:
How does your library project depend on the (standard?) java project?
Just a standard project dependency in the Java Build Path of the main
Android project. It works fine when I'm not using Android Library projects.
I've been using
I reported this the bug to do with the src directories:
http://code.google.com/p/android/issues/detail?id=8502
I was looking at fixing it myself but I failed to get the eclipse
plugin to compile so I gave up, admittedly without putting much effort
in.
Andrew
On 12 June 2010 12:50, Ratamovic
I just noticed the issue with '-' char.
The issue is that linked folder in Eclipse cannot be named with a -
char and we use the name of the project to make up the name of the
linked project.
I've fixed it for the next version to have the name of the linked
folder drop any '-' char from the
I am also having problem with using library projects. I refactored
two of my apps to use a shared project. Both apps work well after
refactoring. However they now show 2 icons each in the app view when
I click ^ button. It happens on both my Droid running 2.1 and G1
running 1.6. Anybody has
How does your library project depend on the (standard?) java project?
From the refactoring feature point of view, both projects are Java
project (a library project, like normal Android project, is both Java
and Android projects), so I'm not sure how it's the fault of the
library feature?
(Now,
I had to abandon the Library Project approach in the end because I was
running into so many eclipse errors it was really slowing me down. This is
particularly true when refactoring - which, I suppose, is the first thing
people do when changing their code to use libraries.
For example, if your
Xavier,
I was just in front of the same problem.
If you could just add a note about restarting eclipse in the following
page it could help a lot :
http://developer.android.com/guide/developing/eclipse-adt.html
Thanks in advance,
Didier
On May 23, 9:06 pm, Xavier Ducrohet x...@android.com wrote:
On 26 May 2010 19:58, Mark Carter mjc1...@googlemail.com wrote:
On 26 May 2010 20:33, Xavier Ducrohet x...@android.com wrote:
The problem is not so much generating the R class, it's making sure
the library project is compiled with this composite R class made of
all the projects (main + libs).
Its got positives and negatives.
Bear in mind that the resources in android.R are not overridable.
There was an example given earlier where things get messy (when library
nesting is allowed):
If library A depends on library B. Project C depends on both A and B then
things get a little confusing
I guess you've probably looked into this already, but is there any way
to make this work by adding the Android project to the build path (as
opposed to making it a library project and then adding it as a
library)?
From a developer's perspective this would be more intuitive because
projects would
On Wed, May 26, 2010 at 3:16 AM, Mark Carter mjc1...@googlemail.com wrote:
I guess you've probably looked into this already, but is there any way
to make this work by adding the Android project to the build path (as
opposed to making it a library project and then adding it as a
library)?
On 26 May 2010 20:33, Xavier Ducrohet x...@android.com wrote:
The problem is not so much generating the R class, it's making sure
the library project is compiled with this composite R class made of
all the projects (main + libs).
Is it essential for the library project to be compiled with
It's essential because It's impossible to have each library handle its
resources independently.
Currently there's no way to have each library packages its resources
(and give them resources IDs) in a way that doesn't conflict with
other resources.
This means if we compile resources for 2
My heavens, you mean you need a resource linker? :)
Mike
On 05/26/2010 01:46 PM, Xavier Ducrohet wrote:
It's essential because It's impossible to have each library handle its
resources independently.
Currently there's no way to have each library packages its resources
(and give them resources
Thank you for explaining.
With regards to the conflicting resource IDs, couldn't you just make
whatever assigns those IDs keep them unique across different projects?
On 26 May 2010 22:46, Xavier Ducrohet x...@android.com wrote:
It's essential because It's impossible to have each library handle
It's hard to keep them unique.
- One possibility is to make aapt (which is what compile them into
R.java and packages them into the apk) be given a different starting
value for each library. The problem is that you can have any combo of
library so which starting point do you use when compiling
With regards to the first possibility...
Rather than giving the aapt a starting value why not let it work it out for
itself? Nothing else is generating those ids, so it can be sure that it
doesn't give the same id to a different project.
This, of course, assumes that the aapt has some way to
well if you let aapt work it out for itself it will need to know about
the other libraries used by the project. So you're back to exporting
the library in the scope of the main project.
On Wed, May 26, 2010 at 2:13 PM, Mark Carter mjc1...@googlemail.com wrote:
With regards to the first
It wouldn't need to know about anything else specifically in the app
project. When asked to generate ids for some library it just needs to make
sure it doesn't use any IDs given before.
On 26 May 2010 23:34, Xavier Ducrohet x...@android.com wrote:
well if you let aapt work it out for itself it
For me, the biggest problem with the Android Library Project feature,
is that library source files are showing up multiple times (once for
the library project and then once for each project that uses that
library project) in:
1. The main source view
2. Call Hierarchy
3. Compiler warnings/errors
Yes, this is not great.
The problem is our need to compile the library code as part of the
main project, and Eclipse only really gives us access to linked source
folder (it's so much easier in Ant because we control the input to
javac). I'm not sure there are other ways, except than replacing the
One thing that makes things slightly easier is to uncheck the Builders -
Java Builder of the Library project. This means that compiler
errors/warnings will not be duplicated. You still need to be sure you are
editing the code from MyApp/MyLibrary rather than MyLibrary.
This doesn't help the call
Thanks Xavier.
MyLibrary is the name of my library project. I don't explicitly create
or intend to create the APK. The console shows that something is
expecting to find it.
Here's my guess:
I had to add the MyLibrary project as a dependency to MyApp project
because otherwise MyApp could not
Hmmm - please ignore - seems Google Groups is doing some strange
delayed postings.
On May 22, 10:21 pm, Mark Carter mjc1...@googlemail.com wrote:
Thanks Xavier.
MyLibrary is the name of my library project. I don't explicitly create
or intend to create the APK. The console shows that something
I'm seeing exactly the same problem as Mark Carter.
I've followed the instructions on the reference pages exactly (at
least as far as I can make out). The app project compiles fine and is
able to use and inherit classes in the library project, but trying to
run the (non-library) project in the
On May 22, 11:48 pm, Mark Carter mjc1...@googlemail.com wrote:
I think the bug mentioned in my second post was due to (additionally)
specifying the library as a project in the build path of MyApp.
Something was expecting MyLibrary.apk to exist because of that (and
because MyLibrary is an
The only time I've seen that Could not find otherproject.apk
warning was in the same situation as mentioned above, when the project
being run used an Eclipse, Java Build Path, Project dependency on the
other project.
If you want to double check that you don't have that, right click on
the project
Yes - I realize that. It just doesn't work in my setup. :-(
I can see the R.java file from the library gets included in the
generated content, but i don't get access to the classes in the
library project. Very frustrating.
Regards,
Michael A.
On May 23, 7:24 pm, Lance Nanek lna...@gmail.com
Just to note that I am fully up to date with both the SDK and Eclipse
plugins, so that does not appear to be the problem.
On May 23, 8:45 pm, Michael A. michael.aki...@gmail.com wrote:
Yes - I realize that. It just doesn't work in my setup. :-(
I can see the R.java file from the library gets
When you do the link between the main project and the library (as
shown here:
http://developer.android.com/images/developing/adt-props-libRef.png),
try to simply restart Eclipse (I know it's annoying) and the link
should happen.
The library source folder will appear in your main project as a new
I'm sure that the library.apk file error was because I had added the
library project to my app project build path.
The other problem, where app project classes could not see library
project classes was due to something else.
For some strange reason, even when the android library compiles by
Hi,
I figured out (after fiddling around with the TTT examples) that the
problem was that the source folder is not being added to the build
path as it was in the TTT example.
Restarting eclipse after having added the library worked, though.
Thanks.
Regards,
Michael A.
On May 23, 9:06 pm,
Typo: I mean to write as a Source Folder on the Java Build Path
view.
Unfortunately, it is very hit and miss how well this works. In some
cases, restarting Eclipse works to show the code as a new source
folder, in other cases not. And it's not very obvious (to me), why it
works for one test
I'm not sure why subversion would impact it, but that's not impossible.
I've done a lot of link/unlink of library projects when we develop it
and never had a problem.
I just tried it at home and it failed to link it correctly (but
restarting eclipse made it work). I guess I'm going to have to go
On some occasions, the debugger gets a bit mixed up and can't decide
whether the source code lives at MyApp/MyLibrary or MyLibrary. So, if
I set a breakpoint in the source code of the MyLibrary project, it
might be ignored completely, or the breakpoint is reached and, when it
does, a
Right. I may have managed to stumble upon the cause of the problems I
experienced.
I tend to name my projects using dot notation; e.g. domain.project.
It seems as if this naming might have caused problems. Once I renamed
the non-functioning library project to domain_project, the library
hmm interesting point about the period in the project name. I'll check
it out tomorrow at work.
What's the build path error you get when you refactor a class from the
main project to the library? This really shouldn't happen!
Xav
On Sun, May 23, 2010 at 3:15 PM, Michael A.
FWIW, I don't use periods in project names.
As for my comment about breakpoints - it seems the workaround is to access
the (and set breakpoints on) library source code in MyApp/MyLibrary rather
than MyLibrary (i.e. top level).
If you set a breakpoint in a class of the top level project then the
Ah that may be a problem with Eclipse and how it deals with linked
source folder.
I'll see if we can override the behavior, but it's unlikely.
Xav
On Sun, May 23, 2010 at 3:35 PM, Mark Carter mjc1...@googlemail.com wrote:
FWIW, I don't use periods in project names.
As for my comment about
@Xav - about the conflicting resource naming problem in multi-level library
hierarchy... Would it not be simplest to just not allow sibling libraries to
define the same resource? Just fail the compilation.
All these libraries are in-house so we've got enough control over this.
So imagine a
On May 24, 12:24 am, Xavier Ducrohet x...@android.com wrote:
What's the build path error you get when you refactor a class from the
main project to the library? This really shouldn't happen!
Non-obvious (of course).
I just get a The project cannot be built until build path errors are
resolved
When trying to launch an activity, the console gives:
Uploading MyApp.apk onto device 'emulator-5554'
Installing MyApp.apk...
Success!
Could not find MyLibrary.apk!
Starting activity com.mycompany.MyActivity on device
ActivityManager: Starting: Intent { act=android.intent.action.MAIN
There is something very strange here.
What is MyLibrary.apk?
I think you may be a bit confused with what libraries are.
Library projects are handled at compilation time. They are *NOT* meant
to be export as APK (I don't even know how you managed to create
MyLibrary.apk because the tools don't
On May 22, 10:12 pm, Xavier Ducrohet x...@android.com wrote:
The manifest for the library is not used besides looking at the
package name for the library.
So, for now, the packageName is the only important thing in the
library manifest?
The question is what happens when a project depends on
On Sat, May 22, 2010 at 2:48 PM, Mark Carter mjc1...@googlemail.com wrote:
On May 22, 10:12 pm, Xavier Ducrohet x...@android.com wrote:
The manifest for the library is not used besides looking at the
package name for the library.
So, for now, the packageName is the only important thing in the
64 matches
Mail list logo
