Hola Jorge!
Sorry for the delay, I'm well impressed by the profusion of emails,
and clearly I have a lot of catching up to do! However, trying to keep
things separate and deal with each one in turn...
On 17 February 2011 15:01, Jorge Silva<jsilva@xxxxxxx> wrote:
Hola Alan,
I think I had a bit of a simplistic idea of how this would work, your
suggestions are definitely more comprehensive. I simply imagined adding to
Tekla an IME preference for text entry that would only be shown if Dasher
(or any other compatible IMEs) were detected on the system. It would just be
a drop-down or radio button list including only Tekla and Dasher initially.
Ok, fair enough! The idea of allowing switching between multiple IMEs,
according to the input field's content type, very much stems from the
Dasher end of things, I think. However, I suspect many of the issues
will be the same - specifically, both IMEs need to have some common
idea of what arrangement the user wants, even tho exactly one can be
the active IME at a time...
Thus, a "simple" Tekla-for-navigation, other-IME-for-text-entry,
scheme might make a good first prototype :-)....and who knows, maybe
we'll come up with even more requirements if we start thinking about
yet other input methods! :)
What you suggest is a bit more granular than that, so we could break up
the text-entry preference I had imagined into the various types of entry
available and let users select an alternative for each (with the default
being our respective IMEs). So this is a lot like your second suggestion and
the only real challenge, as you mentioned, would be to sync the preferences
between the two or more compatible IMEs so users don't have to set their
preferences on all of them.
Just read this again, and I was just saying pretty much the same
thing. So yes, quite :)
Your first idea seems reasonable too, but I don't think the system works
that way. Once a new IME is called, it effectively becomes the primary IME
(regardless of the time it stays in that role), so the idea of "secondary
IME" would be a bit awkward, me thinks...
Correct - the system doesn't support this - so the "secondary" status
would have to be something our own IMEs knew about& implemented
themselves: you'd have a per-session flag, "transfer control back
again when session ends", that'd be set before transferring control,
and cleared at the end of the session. (Definition of session
depending a bit upon whether we're changing IME per input field or
not, I guess). If you're not keen on this then fair enough, methinks,
let's not go that way!...
On a related note, as you know, the Tekla Switch Event Provider (SEP) is
currently sending broadcasts, but I think client applications should instead
bind to it because it really doesn't make sense to let more than one app
process switch events at the same time.
Mostly agreed. There are possible exceptions, in that I can see a lot
of switch-event-processing apps doing several of the same functions
upon receiving an event: unlocking the screen, signalling user
activity so the screen doesn't become locked again, perhaps also
beeping or vibrating the phone to flag the switch was pressed. But
yes, these are small things, and may not always be appropriate to all
apps...
Instead, client applications should
request a lease to SEP events and release the lease when the user is done
with the app so others can take it.
Hmm, I see. AIDL, you mean. Okay...so I've not looked at this before,
so please correct me as I go along, but: the client app binds to the
service (using some kind of Intent that identifies the SEP) with a
ServiceConnection, to which the OS gives a Binder representing the
client's channel to communicate the service. It then...performs some
operation on that Binder, passing (to the service) it's own object,
implementing some AIDL interface with a method something like
switchPressed(...), which the service uses to make callbacks when the
switch is pressed. Then...when the client no longer wants to receive
switch events, it calls unbindService, and the SEP waits for the next
client.
Hmmm. I can see that the arrangement is in many ways cleaner than
using broadcasts, but I can also see a couple of downsides. Firstly, I
think anything using AIDL looks more complicated (!), with the
connection, binders, etc., whereas the broadcast system is nothing if
not simple :-). (Ok, perhaps simplistic...). Secondly, and more to the
point, I'm thinking there's much more scope for misbehaving client
apps to mess up the system and the SEP. If a client which binds the
service, _doesn't_ call unbindService, what happens - the user could
be locked out until the client is shut down. What if the client's
switchPressed() callback doesn't return (quickly) - presumably the SEP
gets blocked too? What happens if there are further switch events
whilst switchPressed() is executing? You could define the interface
such that any concurrent switch events are lost, and the client had
better make sure switchPressed() returns quickly (!)...or does the SEP
manage a thread pool, and spawn threads to make callbacks? Maybe we
could fix all this sort of thing, but the simplicity of broadcasts is
appealing... (I guess the deciding factor there might be performance,
do we have any figures on that?)
That would also help with the transition between Dasher and Tekla while using a Shield.
Not sure what you mean here, can you explain a bit further? I mean,
we'd still have to tell the input method manager to set the active
input method, and then use the binding/etc mechanism to transfer as
well. Ah - you mean, that the candidate input methods, would all
register a callback handler initially, and then the SEP could choose
which one to send it to, or something like that? Mmmm....maybe if we
worked out some more details....:)
I keep thinking some apps
like switch-accessible games would want to keep an exclusive channel for
receiving switch events without having to show any IME to the user. What do
you think? Do you know how apps can bind to services?
Same way as IMEs, I think - using the bindService and unbindService in
android.context.Context. (Both Activities, i.e. apps, and Services,
such as IMEs, extend Context)....???
So in conclusion:
1. I think your second suggestion makes the most sense so we need to come
up with a way to create a common preference framework
Right. So actually a "common preference" might be another way of doing
this: android.context.Context has a method getSharedPreferences(String
name,int), and apparently, "Only one instance of the SharedPreferences
object is returned to any callers for the same name". IOW, we might be
able to have _one_ set of preferences, i.e. preference data stored on
disk, shared between all the IMEs (but each IME might have to have its
own _GUI_ for setting them) - certainly, this seems to be what the
documentation for getSharedPreferences says. However,
android.content.SharedPreferences says (in the class description),
"Note: currently this class does not support use across multiple
processes. This will be added later." - so we might have to
investigate and try to figure out whether this actually works or not
(and on what Android OS versions!)...
Maybe that's not what you meant tho :), and maybe the simpler plan is
to send (broadcast?) intents whenever the prefs are changed: so yes,
firstly we need to figure out what the prefs are, I think something
like one String (identifying an IME, as per the list in
InputMethodManager) per type of input field...but the tricky bit is
the latter, I'm looking at android.text.InputType, and it's not nearly
as simple as I'd like!! Secondly, is how to transmit the changes -
i.e. a broadcast intent - and I think the easiest thing maybe to
broadcast the whole set of prefs, as the editing app thinks they are,
so all the other apps can then update to match.
Mmmm. Problem, tho, is that if an IME isn't loaded, it's not going to
pick up the intent telling it to change its own preferences, so it'll
have to try and figure out what all the other IMEs think is going on,
when it loads. Ugh :(...maybe the idea of a common set of
SharedPreferences is better, and we'd better hope that that works?!?!
2. I would like you to help me move from a broadcasting to a leasing/binding
SEP if you think the change makes sense.
Hmmm, ok. Well: as I say, I think anything using AIDL is gonna be more
complicated, but I'm happy to start trying to figure out how that side
of it works, if we think it's a good plan. But I'm not yet convinced
whether the change does make sense, so maybe I should ask you to
consider a bit more, and if you still think it's a good idea, to try
to justify why& persuade me. How's that?! :)
Yikes, this is where it gets interesting, methinks. But, OTOH, that's
what engineering a good system is all about :)
[Good work on the Tekla update w/ extra events, sounds great, will
have a test tomorrow!]
Cheers!
Alan
