There should be no major rearchitecting required; just put the long-running operation in another thread. Using AsyncTask makes this extremely easy.
On Tue, Jun 23, 2009 at 9:27 PM, Craig <supkic...@gmail.com> wrote: > > 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 > > > > -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
