CLOSED - WTA : Upgrade Spica di Jakarta

by Rafles Marpaung » Thu, 22 Apr 2010 08:50:47 GMT

Sponsored Links

Ok lah klo beg...beg...begitu....

Ane close yah...

sent from spica-droid by T-sel

bukan di PIM, tapi di Arteri.

Kalau dari arah pondok Indah menuju ke arah Permata Hijau disebelah kiri.
Lokasinya lebih deket ke Pondok Indah daripada ke Permata Hijaunya,,


On Thu, Apr 22, 2010 at 7:05 AM, Rafles Marpaung <>


Other Threads

1. Which version of Java is used in Android?

I've read that Android doesn't use Java; instead, you write in Java
syntax but the code is compiled into a different VM's bytecode
format.  Fine, assuming this is true, but which version of Java
syntax?  I understand that Java 1.5 has generics; 1.6 has annotations
etc - is there a cut-off point? Do I get sensible warnings if I try
and use stuff that's not supported, or will it happy compile but then
fail at runtime?


2. Reusable Android library packaging: interest?

Creating Android JARs is fairly long as all you want to do is
ship Java code. If your Java code needs resources or assets, or offers
up activities or services, then you have to ship a JAR plus a whole
bunch of other stuff. And the person reusing your JAR would need to know
about all that other stuff, find it, download it into the right spots,
etc. The only way that is somewhat convenient for the developers is to
package this stuff into separate APKs...which is inconvenient for the users.

IMHO, that's one of the reasons why we don't have a robust collection of
third-party widgets or other libraries. There are few recipes for
creating such things, no standards or conventions for how to consume
them, and no home for them to live. At least, I am not aware of much in
this area -- please correct me if I've missed something.

I've been working on a solution for all of that, or as good of a
solution as I can create given some of the peculiarities of Android's
build tools. Before I invest much more time, though, I need to know if
anyone really cares.


Suppose you found out about...say...a calendar widget you wanted for
integration in your app. You might have found it from a Web-based
catalog of components, or from a search engine query, or a StackOverflow
answer, or whatever.

To download that calendar widget, you would run:

parcel install <name>

where <name> is the unique identifier for this widget. That would
download the widget to your development machine, plus download any
dependent libraries.

To use that widget in one of your Android projects, you would run:

parcel inject <name>

from the project base directory. This would:

-- copy the JAR file(s) into libs/
-- copy the resource(s) into res/
-- merge in key elements (e.g., activities) into AndroidManifest.xml
-- copy documentation and other stuff into parcels/<name>
-- do all of the above for all dependencies as well

If you write a calendar widget and want to make a parcel for others to
reuse, there would be:

parcel package <name> ...

where you specify the parcel to create and all the stuff that should go
in it (JARs, resources, source code, documentation, etc.). You could
wrap this up in an Ant task or Maven plugin or Eclipse, um, thingy, if
you wished to integrate this as part of a build process.

There's more to it, but this should give you the feel for what I have in
mind. It is modeled loosely after RubyGems and Rails vendor plugins, two
of the more successful examples of this pattern in use today.


If this is something you would like to see, please reply to this
message, or tweet me (@commonsguy), to let me know of your interest. If
I release this, I'll be committing a fair chunk of time to helping to
maintain it, and I don't want to make that commitment until I have a
sense that enough people will care.

I am, of course, certainly open to other ideas, suggestions, Googly
input, etc. :-)

Thanks in advance!

Mark Murphy (a Commons Guy) |


3. Video Player - Progress Bar

4. Is there any changes in crop image activity

5. Which is the faster custom 2D and OpenGL-ES 2D?

6. Proper way of importing contacts to the device/contacts operations are very slow

7. No Network Connectivity in Service/AlarmManager Process.