Again, as in implementation of SCORM for mobile devices, we encountered some interesting issues in its implementation for Blackberry.

Find our experience on the same.

Target Platform:

After a good amount of R&D and feasibility study on available device software for Blackberry devices, we selected device software 5.0+ as our target platform. Device software 5.0 has good inbuilt browser support (some of the features are from HTML 5.0) and, also has Widget SDK, which is used to create native applications in HTML.

Implementation:

1. Development tools required:

• Normal J2EE development environment like Eclipse and Java SDK.
• Blackberry Widget SDK: You can get more information about Widget SDK here.

We created a Blackberry Widget, which is a combination of two parts:

• Actual Widget
• Custom JavaScript Extension

• Actual Widget
  • The complete UI of solution is defined (in HTML and JavaScript) in the Actual Widget.

• Custom JavaScript Extension
  • A JavaScript Extension is Java code that is built into a BlackBerry Widget, and can be accessed through JavaScript. This capability allows you to extend the functionality of your BlackBerry Widget application to include native BlackBerry functionality.
  • We used it as a backend of our solution to communicate with online database/LMS.

2. Solution:

• We implemented SCORM standard in JavaScript files. These files were then included in the widget.
• As mentioned before, this was an offline solution hence course content was residing in the device itself. We built JavaScript extension to download the actual course content.
• After launching the SCORM complaint course content, the communication took place with JavaScript files, as it would happen in a normal desktop browser.
• We used Google Gears API to store the tracking information of the user. Google Gears API provides ability to create database/tables which greatly simplify storing of tracking data. It uses the open source SQLite database system. (Note: Recently Google has decided to drop Gears in support of HTML 5 database and Blackberry has also decided to use Google backed webkit in their new device OS 6). To sync tracking data back to online LMS, you can use normal browser based method or you can use JavaScript extension built in Java.
• The widget name, icon image, start file etc. were defined in the config.xml file of the widget.
• The final solution was built using command line (bbwp.exe). Alternatively, you can use Eclipse to build the solution.

3. Problems encountered while trying to implement SCORM for Device software 4.6:

• Online mode:
• There was no problem in running SCORM complaint mobile LMS in Blackberry browser.

• Offline mode:
  • Device software 4.6 doesn’t have widget support, so we had to create everything in native Java language including invoking the browser instance for running the courses.
  • While running the courses we had to manually tell the browser which type of file it is rendering like HTML or JavaScript.
  • Till this point everything seemed fine, but we got stuck at a point where actual SCORM communication occurs, using frameset or iframe. We were not able to make API calls or normal JavaScript calls from one frame to another frame.
  • As yet, we haven’t been able to find any solution to this problem nor do we know if the problem lies with Blackberry.(Blackberry  browser has had a very bad reputation until Device software 5.0)

I hope our experience helps you in implementing SCORM for Blackberry devices. Have you followed some different approach? Or implemented it for Device software 4.6? We would like to hear your experience too.

The post SCORM Implementation For Blackberry first appeared on The Upside Learning Blog.

What does it mean for elearning (or should I say mlearning) industry?
Flash is the favorite delivery platform (development tool) for eLearning courses due to its huge install-base and ability to produce engaging content. However, that’s not the case with mlearning. Mobile device platforms are diversified – from screen sizes to the operating-systems driving the devices. Due to this (and some other reasons like processor capability, device features, etc), not all devices support Flash – neither within the web-browser nor outside of it. So if you do some mlearning development the solution would most probably limit its access to the targeted device only. However the advent of AIR for mobile provides an alternative here:

– It opens up possibilities of porting same solution across all supporting devices with some minor tweaks (like changing routines for accessing some device specific features).
– Mobile developers won’t need to learn specialized code each time to port their solutions on different devices
– You can use existing Flash development skills to provide engaging elearning apps for handheld devices.
– You can even implement SCORM LMS tracking methods within the apps itself
– You can develop eLearning content that can run on desktops, laptops, netbooks, and smartphones.

Apart from AIR app, the same code and assets in any AIR app can further be used to deliver a mobile browser version using Flash Player 10.1. Note that all the major smartphones (except iPhone) will support Flash, including Android, BlackBerry, Symbian, Palm’s webOS, and Windows Mobile. It will now also be available on LiMo devices, an independent and open smartphone platform with a Linux-based operating system at its core.

Checkout the video demonstrating some Adobe AIR apps on Motorola Droid –

And here’s a video demonstrating Flash running on Dell Mini 5 through mobile browser –

Apple’s decision of excluding Flash on their devices has resulted in some disappointment within our team and many others around the world. Nonetheless, Adobe has already announced a workaround using the packager for iPhone. So a solution developed for other devices, can possibly be ported for the iPhone using this packager. I assume the same packager would be made capable to publish apps for iPad too as the iPad uses the same underlying technology as iPhone.

At some point one would justify Apple’s standoff against Flash on their handheld devices, and advocate open-web culture of HTML5 or alike. The reality, however, is that the new HTML5-enabled web will take many years to become a standard. In the meantime the world wants to deliver and access content across all devices and that’s where Adobe is pitching. Their goal is to have every platform supporting native Flash and AIR (including iPhone).

As an eLearning developer, we will certainly benefit from the Adobe Flash runtime, AIR and Flash player 10.1 made available for handheld devices.

The post Adobe AIR & Flash Player 10.1– How it Can Benefit Mobile Learning first appeared on The Upside Learning Blog.