On Tue, Jun 23, 2009 at 9:51 PM, Mike Hearn<mh.in.engl...@gmail.com> wrote:
>
> it's a bit hard to figure out what you want from this email, I assume
> you're talking about this:
>
>
> http://www.google.com/codesearch/p?hl=en&sa=N&cd=1&ct=rc#3aMARKchqsQ/trunk/AndroidTTS/src/android/tts/Tts.java&q=TTS%20android
Yes, that's it.
> I agree this API is a bit questionable, but I don't see the problem.
> You can't block inside the function you pasted if it's run from the
> main thread, that'll make your service ANR.
Yes, I realise it will ANR - that's what I am trying to avoid. The tts
api itself does what I want - it's the underlying framework that
stymies me.
> BTW there are very sound reasons to not make RPCs pump the event loop
> - Windows RPC does this and it resulted in massive confusion and
> horrible, hard to find bugs to do with unexpected re-entrancy. I can
> elaborate in excessive detail if you want.
Yes, I remember vividly the debugging session when I first discovered
that an incoming COM call was reentering my code and stomping over my
carefully mutex protected data. That was certainly confusing; I
therefore agree with that design decision :)
Ok, so I'm going to try to elucidate my problem as best I can:
Let's say I had a fully completed application (non-trivial, lots of
code, lots of complex interactions). One of the features of this app
uses an event from the AlarmManager to wake up every hour, do some
work, and play a short sound using the MediaPlayer. This code thus
needs to be in a Service so that the BroadcastReceiver can return. One
day I think to myself "it would be cool if the sound played by the
service could read out the current time". So I find some aidl which
allows me to pass in the current time, and get out a wav file. This
should be easy...
Extending my original example you get this:
class MyService extends Service {
public void onStart(Intent intent, int startId) {
soSomethingWithIntent(intent);
String t = TuneChooser.getTunePath();
playTune(t);
}
}
class TuneChooser {
static public String getTune() {
if(normalOperation)
return "/sdcard/someAudioFilePath.mp3"
//**** new code here *****
if(fancyNewSpeakTheTimeFeature)
return generateAudioFromText(new Date().toString())
}
static public String generateAudioFromText(String text) {
TTS tts = new TTS(...);
...
//wait for TTS service to start up...doh!!!
...
tts.synthesizeToFile(text, ...);
return newWavFilePath;
}
}
So I was hoping to add a few lines of code to extend my app using a
thirdpary service, but it seems it's not that easy. Now, I suppose I
could re-architect the code to somehow work with this asynchronous
requirement, but it will be probably be major surgery, and it just
doesn't feel right. Sorry to return to the train-wreck that was COM
again, but at least with it I could create an out-of-proc object (i.e.
start up a com server in another process; and in fact I didn't care if
it was in-proc, out-of-proc, or even on another machine) and make a
method call on it, all synchronously.
I understand how the service connection callback works, and have used
it successfully in GUI code, and also in code that "eagerly" connects
to services and then holds references for future use, but in this use
case, it just seems unworkable.
I guess I just don't understand why there was no provision for
synchronous start-up of services.
Aside: all of this is possibly moot for me if future api versions will
have inbuilt library support for tts, but the issue at hand still
stands.
I hope you now understand where I'm coming from. I know it's difficult
to envisage what it is going on in another programmer's head. And
overall, I think the framework rocks!
cheers,
Craig
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"android-framework" group.
To post to this group, send email to android-framework@googlegroups.com
To unsubscribe from this group, send email to
android-framework+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-framework?hl=en
-~----------~----~----~----~------~----~------~--~---
