howdy, tunneling!

how can I help you today?

howdE

oh .. i have so many questions .. lol

i was looking at your MergeAdapter build.xml file trying to figure out how to make a jar file

i downloaded your source, but couldn't figure out how to generate the jar

ant jar, probably

yup, that's it

so if I make a build.xml and add it to the build path, shouldn't it run everytime it compiles?

huh?

build.xml is for Ant

ok. let me start over.

i want to have a project in eclipse that ends up in a jar file, and uses the Android api

purely from Eclipse, I do not know how to do that, as I am not an Eclipse expert

I would presume that there is a way

ok

what you see with MergeAdapter is *two* projects

the Android library project

and the demo/ sub-project

yea

what I do is use both in Eclipse

ok

and when I commit/push/tag a change and wish to distribute a new JAR, I run the ant jar command from the command line

oh

I use Eclipse because the world is forcing me to, not by personal preference :-)

what do you prefer?

a simple editor

right now, I use Komodo Edit for non-Android work

ic

i've read that you can add an Ant file to the build path in eclipse

I tried it today, but to no avail.

I would find that somewhat surprising

the build path is supposed to be JARs that go into your project

I have no idea why a build.xml would be found there

but, then again, I am not an Eclipse expert

sorry, Builders

you declare it as a Builder (don't forget, i'm a Novice. especially when it comes to vocabulary)

I have never worked directly with Eclipse builders, so I can't help you there, either

ok

so the big picture is that I'm trying to develop this app that will allow me to drop in jar files. these jar files contain "Drivers" that are written to an API that I am developing.

define "drop in"

oh.. someone writes the Driver, sends it to me and I'll add it to the libs folder in Eclipse, then add it to the Build Path

I'd love to add it to the SD card of a device

that's a massive security hold

er, hole

yea.. i know

that's why i'm not going there

eventually (and hopefully soon), Android library projects will support distributing them in JAR form

that would be nice

that will be the long-term reusable component container for Android

as it will handle resources and such as well

AFAIK, the R17 tools should support this

whenever they are released

yea, it would be really cool if you didn't have to modify the manifest.. will it read the manifest in the library project?

not that I am aware of

that's been discussed

ah

but I do not know if it is an anticipated feature or not

ic

ok, so the next thing I was going to ask you about is really a Java question and it has to do with the ServiceLoader

I guess you haven't played with it much, so I think I am 0 for 2 so far.

I have never used it

it's in the Android SDK, so in theory it might work

yea.. so you have to have this META-INF/services/<fully qualified class name>

that's another reason i'm interested in the jar stuff. since android doesn't like me making this folder, i'd like to be able to insert /services/<full qualified class name> into the apk.

right now i have to make the apk, then open it up, then insert the goodies, then use "adb install .. " to load the apk into the emulator

that's part of the reason why I am skeptical that it will work

so the ServiceLoader will goto this folder, read the <fully qualified class name> file, and get the full qualified class names of the classes that implement the "Service" in my case it would be a "driver"

this is the way that java.sql works.

seems kinda silly to me

lol

if you have to write a file, why not write a Java file instead of an XML file?

it's plain text

big <bleeping> deal

woah

if nothing else, write a script to code-gen the Java from a plain text file

well.. the beauty of it is that the ServiceLoader will "load" all of the service providers (drivers)

so would a Java class

I mean, if this were traditional Java, ServiceLoader is probably a fine solution

but this is Android

as you noted, META-INF/services is problematic

so, why bother?

because I can't think of another way to achieve what I've set out to do

I want my app to load the drivers without having to know what they are

your app has to know what they are for ServiceLoader

or do you think out-of-work Keebler elves are writing that text file?

no.. it only has to know the interface

lol

true

good point

it's actually the Underpants Gnomes that write my text files

that's my point: the incremental value of the text file (vs. a Java class) IMHO isn't worth the pain of dealing with Android's build tools and META-INF/services/

the text file should go in the jar file which is the driver

that wouldn't work

at least, AFAICT

oh, no, wait, that might work

that jar file is in the class path

I'm still dubious of the value

you already indicated that you have to modify the app to have the driver (copy JAR and rebuild)

do you publish these transcripts?

adding a line to a Java class to instantiate your new driver seems like the simplest solution

yes, these transcripts are archived, with the links published to the cw-android Google Group

ok

maybe that's the way I'll have to go

what do these drivers drive?

IOW, is there a reason you are doing integration-by-JAR rather than integration-by-Intents?

i've just run down the path of "i want to build an app that supports plug-ins".. and that's where I ended up

OK, what do the plug-ins do, in general terms?

the drivers will handle sending and receiving commands from a remote source

another approach, therefore, would be for the plug-ins to be distributed as separate APKs, exposing some Intent-based interface for "sending and receiving commands from a remote source"

e.g., to send a command via the plug-in, call startService() to send the command to an IntentService, supplying a PendingIntent for delivering the result

is that aidl?

no, that would be bindService()

that's also an option

i found the aidl section of your book, but haven't read it yet

I personally prefer the command pattern and startService(), but binding has its adherents as well

ok, i need to think about how to implment it. one of my concerns is that there could potentially be many drivers.

how many drivers will a typical user need?

maybe 10

and you are expecting to get 10+ other developers to write drivers for you?

possibly, or I'll write them myself..

that's undetermined

are these other developers independent app authors, or is it something where you will be directing their development work (e.g., they are contractors)?

now, avaliable, there could be hundreds of drivers.. but a typical User may only need about 10

some of them may be app authors, that already have apps that "send and receive commands from a remote source"

i guess deciding how/who writes the drivers will ultimately be a business decision

well, beyond that, there's all sorts of discovery issues and so forth

IMHO, for something like this, you count: 0, 1, 2, 3, 4, 5, 6, 1 million, infinity

so if I go the Intent route, how does the main app locate the ... is that discovery?

there are two types of discovery

1. the user finding what plugins they need

2. the app finding what plugins exist

in your JAR-integration approach, neither of those are an issue, as you are forcing a solution

well.. i think the User would have to install the plugins

then the app find them

oh, that's what you said

if the user is installing the plugins, the only choice is integration-by-Intents, IMHO

right

your JAR approach would not have the user install the plugins, as they would all be baked into the APK

right

exactly

so, if the user is installing plugins, somehow you need to provide them a directory of what plugins exist

then, given that they install some plugins, your app needs to find them

right

the latter would be accomplished mostly via PackageManager

ok

exactly what you use on PackageManager would depend somewhat on what you are using for the integration

you may want to read the Integration and Introspection chapter in _The Busy Coder's Guide to Advanced Android Development_)

(minus the extra closing parenthesis)

ok

in the last update, I just added a section on creating an APK-based plugin mechanism

i'll do that when we are done here

ahh

ok

in that case, it was using RemoteViews passed around via broadcasts

what about security?

I cover some security stuff in the chapter

so, while the RemoteViews-specific stuff probably isn't relevant for you, some of the rest will be

ok

in my next update, due out in a week or two, I will have another section in there on using ContentProviders for a plugin interface

I guess in the main app, I could provide an list of avaliable plugins with links to the market

and that could be driven by, say, a JSON file you download from the mother ship

oh?

sure

or use an RSS feed

whatever floats your boat

ok.. i've seen JSON thrown around, but have no idea what it is

JavaScript Object Notation

or how to use it :)

basically, it's a data structure in text format, a bit lighter-weight than XML

http://en.wikipedia.org/wiki/JSON :-)

but an XML-based format would work as well

JSON is the flavor of the month for this sort of thing, but it's not required

more reading .. i need to quit my day job

regardless, you could download your list of plugins and their Market links in some data format

oh

so i guess the market will supply the data in the JSON format?

no

first, I don't know what "the data" is

second, the Market doesn't have a documented and supported API of any form

oh.. the list of plugins

outside of Market URLs

is the Mother Ship my Mother Ship?

yes

I thought you meant Google = Mother Ship

oh, sorry

gotcha

see, I've been kinda thinking throughout all of this that this was a major project with a large team at a big firm

haha.. it's a major project, but a small team

no offense, but your plugin problem perhaps is less a technical one and more a marketing one

i can develop the plugins

you're going to have to, at least at the outset

yea.

getting developers to support some plugin interface to your app will take some work

i would love to just spill the beans, but I think I have a really unique idea and since this transcript is published it makes me nervous.

we talked before about developing an Open Source "Service with WIFI lock to maintain a persistent connection", maybe we should talk about it offline, but I would like to pursue that.

yeah, that's something worth covering in the books

and it will really help with the plugins ;)

I can work up a sample that uses a Comet-style HTTP long poll, or perhaps MQTT, as the protocol

did you have a particular protocol (plugin-to-remote source) in mind?

umm.. i do, but it requires hardware.

yeah, well, that won't work for my case

yea

anyway, I've added that to my list of things to write up in the March/April timeframew

er, timeframe

basically i connect to a remote source that requires you to talk to it at least once every 5 minutes

(one of these days, I'll figure out why damn near all my typos are on the last words of my sentences)

oh, yeah, that problem

haha

i guess it's a socket timeout

that's very possible

Google had to do a heartbeat every 30 minutes for the stuff behind C2DM

and it took some work to get it as long as every 30 minutes

so the issue is when the "internet" isn't working on an Android device, the "Connection is reset by peer"

right

and since this is hardware, I'm assuming it's gotta be WiFi, not mobile data (e.g., 3G), right?

and if the phone is asleep, and my Connection doesn't know that the connection has been reset, the remote source can't send messages

well, if the phone is asleep, you're screwed either way

yea.. that's what I found.

you will need a WakeLock and a WifiLock

with commensurate pain from a battery standpoint

I have all of these nice Exceptions that notify when the connection is lost, but when the phone goes to sleep.. it seems like the app just stops running.. and the exceptions are never called because my Ping thread is asleep

when the phone goes to sleep, the CPU shuts down

yea

so does it just stop executing code?

yes

while incoming packets on a mobile data connection will wake up the device, that's not trye for WiFi

er, true

perhaps WiFi Direct will change some things in this area

but my outgoing Ping isn't sent, so the Connection is reset by peer and the incoming packets stop coming

so on mobile or wifi, i lose connection

right, though that's more a hardware-specific thing

there isn't something magical about five minutes for, say, a SIP server

anyway, that's a wrap for today's chat

yea, I think it's a unique problem

next one is Tuesday, 4pm Eastern

ok, bye. thanks for everything.

have a pleasant day!