STEP & multi-platforms

STEP aims to run on most platforms:

  • Web
  • Desktop
  • Mobile (connected to the internet)
  • Android (offline use)
  • any others?

Web

Our first platform has been Web. Web is good - it reaches lots of people quickly. However a lot of people suffer from internet connection issues, slower network connections, etc. The Web edition is essentially a 40/60 split between server-side processing and 60% Javascript/HTML/CSS which runs/renders/communicates asynchronously to the server

Desktop

Our next platform will be Desktop. This is due in August 2014 (hopefully). The advantage is that a number of people have specifically asked for this as have limited/flaky internet access. The process is is that we start an embedded Tomcat server on their machine, which hosts STEP and then simply open a browser to the embedded app.

Mobile (connected)

Using Phonegap/Cordova, we hope to make the HTML/CSS/JS downloadable as an app. The app will then communicate with the server-side www.stepbible.org. This will allow us to fine tune the app. However, at all times, the app will need to be able to access the internet.

Mobile (Android)

Android is free, and therefore a lot of cheap smart phones run Android (although we have an eye on WebOS as well). Most people with iPhones have a good internet connection, in comparison to most people with cheap hardware.  Using the work done for "Mobile (connected)" we will write some Phonegap plugins to bridge the AJAX calls. The JS will no longer query a server, but rather query into the phonegap bridge, which will natively call the STEP code (which is pure Java). A main hurdle to this is going to be performance (of Lucene, of the UI, of the XML processing)

Any others

At some point, we'll want to start considering how we can prepare STEP for other platforms, whether that be by porting the Java code, or my coming up with some other mechanism. A number of frameworks are just being started at the moment, which allow you to compile Java code for use on iOS, so we'll be looking to see how mature these get. Another option would be to port some of the Java code to JS but that would have lots of limitations, so we're not considering that at the moment.