meadl-devel team mailing list archive

[Jorge Silva <jorge.silva@xxxxxxxxxxx>]

Hola,

  I have committed the updated architecture diagram according to Jan's
suggestions. It is available from here: http://tiny.cc/mme1v

  You will notice a "Sensors" block which is meant to implement switch
events coming from input sources other than the Arduino board, (e.g.,
on-screen touch switches for people with fine motor impairments). We
will not be focusing on this for now, but I have included it for
completeness since it is also part of the work we have received funding for.

cheers!
Jorge

On 05/28/2010 05:42 PM, Jorge Silva wrote:
> After discussing this architecture with Jan Richards, my supervisor, he
> suggested to try to exhaust first the possibility of providing built-in
> access to all Android apps as supposed to starting with the separate UI
> as Eric and I had planned, and after doing a bit more research, it
> actually seems it may be way easier to provide full access than we
> originally thought for the following reasons:
> 
> 1. According to:
> http://android-developers.blogspot.com/2009/04/creating-input-method.html
> custom input methods (that provide text to applications) can be defined
> and used as default once installed. We already knew this but the news is
> that:
> 
> 2. According to:
> http://android-developers.blogspot.com/2009/04/updating-applications-for-on-screen.html
> we can explicitly hide & show the input method area (on-screen keyboard)
> even when no text input field is currently selected (e.g., show it on
> any switch change, like a "wake up" kind of feature) and,
> 
> 3. According to:
> http://developer.android.com/reference/android/view/KeyEvent.html
> we can send programatically any hard key event to the system (including
> D-pad events) from the input method window, thus, we can potentially use
> the input method window to translate switch events into D-pad keystrokes
> that allow us to move across the UI.
> 
> Depending on further coding, we could either include the switch event
> provider into this custom input method or keep it as a separate service
> as it is currently planned, however, there would not be any need for a
> separate accessible launcher (UI).
> 
> Let me know what you think... I'll try to come up with some mock-ups so
> you get the idea better.
> 
> cheers!
> Jorge
> 
> On 05/27/2010 05:06 PM, Jorge Silva wrote:
>> Hola,
>>
>>   I committed a diagram for the proposed android app architecture based
>> on our discussion on Tuesday. You can download it from here:
>>
>> http://tiny.cc/yeoef
>>
>> Please let me know if you have any comments, edits, etc...
>>
>> I think this architecture can ensure early success by allowing us to
>> focus on core activities to be performed on the phone (e.g., making a
>> call, sending an email) as supposed to trying to make the whole system
>> accessible at once. Later we may want to consider ways to merge the
>> accessible activity launcher with the accessible input method so that
>> users don't need an intermediary app and 3rd-party applications can be
>> made accessible.
>>
>> As you know, work on the Arduino board and Android switch event provider
>> has already started.
>>
>>  Let me know what you think.
>>
>> cheers!
>> Jorge