How to start with i-CT Framework

HOW to start a development of new SEN app using the i-CT FRAMEWORK

As noted in other contributions, i-CT FRAMEWORK with its apps (see README files of initial apps in their directories too) stands for OPEN SOURCE PLATFORM for development of apps for SEN (Special Education Needs). Such development should be more automated (it saves your time and resources) and moreover final SEN app should be better usable too.

For introduction to i-CT FRAMEWORK see our contribution at this blog called “The introduction of the i-CT framework tool”

One of the main advantage of this platform is that, i-CT FRAMEWORK offers most of common services which every SEN app should use. Hence a developer of new SEN app does not have to care about a design and an implementation of these services on his side, but just can use these services through communication protocol of i-CT FRAMEWORK. Therefore handling of communication with i-CT FRAMEWORK through this protocol is only one thing which should be implemented on the new app too (of course beside the proper SEN education content).

Generally there are three user profiles (roles) which can be used to login to i-CT Framework and which are further distinguished in handling of communication with i-CT FRAMEWORK:

1. Administrator (full rights),
2. Assistant (e.g. teacher or social worker can edit pupils and app management) and
3. Client (pupil - just uses prepared education app, can not change app setting).

To see how SEN app (interconnected with i-CT Framework) can be created, visit our sources of initial apps in repo. In present time there are following apps as sources (see README files and sources of initial apps in their corresponding directories in repository):

• Yes/No app: simple app for AAC (alt. comm.),
• Daily Planner: simple planner app
• SoundTherapy: app for music therapy
• GestureTranslator: app for hand gesture language translation

The communication of i-CT FRAMEWORK with its SEN app is based on multiplatform solution – URL scheme invocation, which can operate with specific parameters. These communication parameters can be divided into 2 sides:

• Parameters for transition from i-CT FRAMEWORK to SEN app
• Parameters for transition from SEN app back to i-CT FRAMEWORK

To see how these URL scheme parameters can be handled see e.g. Java method parseUrl() which is located e.g. in LifeCycleListenerIMpl.java in directory of sources of SoundTherapy app.

All these parameters were observed based on real studies in special education and therapies to identify necessary data which should be presented in every usable SEN edu. app. Now let us go through predefined communication parameters (to have an idea what should be handled in new SEN app using this i-CT FRAMEWORK):

Parameters for transition from i-CT FRAMEWORK to SEN app:
∙ return - URL scheme for return to i-CT Framework from SEN edu. app
∙ userId – ID of selected user (client)
∙ userLogin – login name of selected user
∙ userName – first name of selected user
∙ userSurname – surname of selected user
∙ userLevel – level of user permission (ADMIN - administrator, ASSISTANT – special educator or social worker, CLIENT – client/pupil)
∙ userManagerId - ID of superordinate user for u selected user (e.g. ID of special educator for his selected pupil)
∙ userLanguage – language preferences
∙ loggedId - ID of logged user to i-CT Framework (e.g. special educator, who left SEN app)
∙ loggedLogin – login name of logged user
∙ loggedGesture - login gesture of logged user (e.g. can be also requested when leaving SEN app and if this option is selected in i-CT Framework for this case, see canEscapeApp parameter below)
∙ loggedName – first name of logged user
∙ loggedSurname – surename of logged user
∙ loggedLevel - level of logged user permission
∙ loggedManagerId - ID of superordinate logged user for u selected user (e.g. ID of special educator for his selected pupil)
∙ loggedLanguage – language preferences of logged user
∙ canEscapeApp – mark whether selected user can leave SEN app without gesture of logged user
∙ allowedTime – set timer which is applied on SEN app, thus SEN app will be running until the timer expires (e.g. value 60 means 60 minutes, -1 stands for no time restriction)
∙ manage – marks whether SEN app will be running in management (edit) mode (e.g. value true is used when spec. educator run SEN app with this parameter to change his pupil educational content there according to his individual needs).

An example of a new SEN app URL invocation from i-CT Framework follows:

myAppScheme://?return=ictframework&userId=3&userLogin=client&userName=Johh&userSurname=Goodboy&userLevel= CLIENT&userManagerId=2&userLanguage=en&loggedId=2&loggedLogin=asistent&loggedGesture= 123&loggedName=Paul&loggedSurname=Teacher&loggedLevel=ASSISTANT&loggedManagerId= 1&loggedLanguage=en&canEscapeApp=false&allowedTime=15

Parameters for transition from SEN app back to i-CT FRAMEWORK:

∙ ictframework://?fromManage=true – used in case when e.g. administrator or spec. educator are going back from SEN app to i-CT FRAMEWORK, in this case they stay still logged in i-CT FRAMEWORK
∙ ictframework://?afterGesture=true – used in case when user needs to use gesture to go back to i-CT FRAMEWORK (e.g. used in cases when spec. educator works with his pupil in his profile and needs to go back to i-CT FRAMEWORK and also needs to stay logged there).
∙ ictframework://?becauseNotInKiosk=true – used in cases when user is going back to to i-CT FRAMEWORK in iOS and the Assistive mode (available in iOS setting) is just switched off.

Registration of new SEN app to i-CT Framework:

Each new SEN app should be also able to register (add its reference) to i-CT Framework as central manager, to let it know about a presence of new app, which can be manageable by i-CT Framework. Such new app is then visible in i-CT Framework, can be launched from this tool, can be linked to any user and can be setup to any user according to his needs. Here is an example of URL registration format which should be sent from new SEN app to i-CT Framework:

ictframework://?action=register&scheme=myAppScheme&name=MyAppName

If necessary more parameters can be added on both sides of this communication protocol. Thus as we can see this communication is open to future changes and extension as necessary.