The Making of an Android App
With the extension to the project we were given the opportunity to expand our audience and make a product that can outlast the project and website. The outcome is the app Lights, Camera, Education! (www.cadarn.ac.uk/lce). This is an open, free learning application that informs and guides you through all the stages of video production.
We started with some base decisions to make, firstly being a single developer team we only had time for one product. The idea of running a dual development of both Android and iOS was considered too much. The market share and device access to students pointed us towards Android.
Source: Business Insider
The app was to be based on the web version of this content, which can be seen by visiting . It was decided that LCE should follow the same basic mechanic of allowing learning and progression without the need for oversight or moderation. This is formed from the steps;
- Read content of a Lesson
- Mark Lesson as read
- Read and complete the Task
- Mark Lesson as complete
- Move on to next Lesson
- When all lessons are complete, the user earns an OpenBadge.
We did initial research looking at what learning apps are like, other similar "archive of knowledge" apps and what Android provides to come to the base design ideas. This was somewhat limited by my basic knowledge of Android and what is possible. I didn’t have the requisite experience during initial design to state what could be achieved from the result. By following the basic Android material design ideas, we put together the simple list of lesson structure with a select one lesson mechanic through to its content showing all that is required in a lesson, the content, progress and comments.
Some sketches after initial research.
At this stage, we decided to cover three screen sizes; phone, midi tablet and large screen tablet. These designs were sketched, then drawn up in a mock-up graphics application to finalise the layouts and components. Some of the areas came about after inital useage, like how to add progress and comments to each lesson, changing from an original idea of all content inline in the page into a pager layout.
The Drupal CMS we use for the website had a simple module created to export the various fields of a content type in both languages into a file structure that is appropriate for use within the Assets folder of the Android App structure. This content had several automated and manual changes to be made before it was ready for use within LCE. The main one of these is the conversion of the images and files to a format and size appropriate to the App and the rewriting of the IMG tags within the HTML so the raw HTML of the Lesson content picks up the local and not external images. The same applies to files that are viewable in lesson.
The website view of a lesson shows all components to be broken into App sections.
The raw HTML content used the website styling to look the way it does. Within the App we are displaying the Lesson content as a HTML file inside a custom WebView. This was built as the steps towards full screen video are much easier when using the HTML5 components within the WebView browser renderer than any VideoView where we would have to build the controls. This also works for our oEmbed content in lessons as handling them is also done via the WebView.
Lesson Content in a Phone layout
Within the content there are three types of "a" tag or links;
- Links to external websites requiring a full web browser
- Links to files that the user needs to view externally of the app
- Links to other lessons within the App.
The first just forces a browser window instead of opening in the App to allow bookmarking and follows similar behaviour in other Android apps. External files are provided by the App to other Apps on the device through the ShareIntent system, offering the choice of how best to view for example a PDF file.
The more difficult one is internal links. We needed to take the code
<a href="/lesson/course-introduction">Introduction</a> and make it open the appropriate lesson not a link in an external browser. The good thing is these links are the only ones that have the internal structure of links, not a fully qualified URL. A simple string check on the lack of
https:// and having
file:///lesson/ is unique enough. We created a "string-array" XML within the app of the URL slugs that represent a Lesson and start a new Intent or Fragment as needed.
One area that we didn't anticipate was the conversion process of the images used for the "header" image of each lesson. This was initially done via an automated PHP script but had unattractive results. I created within IrfanView a pair of settings to one crop and resize to produce the list image and resample to reduce the size of photographs by making each a JPG and sizing to the devices designed for.
The website contains a marking system for a learner to set that they have read the content and then completed the task of each lesson. The status for the is managed via a coloured sidebar, cycling yellow and green upon completion. We replicated this with checkmarks coloured yellow and green in both course list and progress screens. With the most visual component of the list being the image, and to not obscure the list when lessons are at different stages I chose this method of showing completion.
Progress in the Course / Homepage of the App.
Marking Progress in a lesson.
When developing this we had to consider the fact updating progress effects multiple parts of the screen and has different behaviours in tablet and phone layouts. This required the use of interface call backs to enable one class, handling the display of one area of the screen to update itself on another action. The alternative was to rebuild the entire App screen, not a good solution.
Viewing your progress across all lessons.
There is a separate section of the app to see overall progress, something quite visible on a webpage. This screen contains visual representations of the user’s progress through circular progress bars and an image of the reward, that gradually fills itself to full opacity. This was achieved with a layered drawable image type and a filter colour, like layer masks in Photoshop with the lesson completed percentage morphing the mask layer height percentage to gradually show more of the image.
Viewing comments in a lesson
The comments system within Drupal is a robust and simple solution to creating post comments. To cross implement this with the app allowing the same comments on both we implement the embeddable Disqus comments system. This provides us with comments across platforms, with automated filtering and editorial functionality separate from the website if needed in the future.
A side bonus to Disqus was it has some of its standard text labels in Welsh. Although not complete, this was the best and only real choice for this scenario.
One of the main components of the whole project is its video output. The App came about as we wanted a wider audience for the content, including our video content that is currently available on YouTube and our own website. To make this available within the app we made use again of the original HTML output from the CMS. The WebView and WebChromeClient within Android meant we could use YouTube, Vimeo and TED talk embeds as if you were viewing on a desktop browser. When we had to make this available for download however the embeds had to be replaced with HTML5
<video> tags with a on device local URI.
A simple list of the lessons with available downloadable material was created from the content of the lesson exports. These are packaged up as ZIP files and kept on a webserver. Downloading these is done through an AsyncTask in the App and displayed with a simple array adapter pulling from present folders in the file structure for status. If the folder (and contents) of a equivalent lesson number exists it shows as downloaded, this refreshes whenever a download is completed.
The lessons can also read this state and replace the iframe embed tags with local URI on load removing the need for user interaction to go "offline". As the content is not scheduled to change, due to overall project completion, this process is the most appropriate solution in terms of circumstance and development time. It allows us to relocate the content if the website were to change and keep the functional content (the text, images and online videos) available whatever happens to the online content.
The App comes from the CADARN Learning Portal. This entire project has bilingual responsibilities that make the providing of the content in English and Welsh a priority. Android itself has a model of multilingualism where the App can present itself in any language, but to allow language switching as a part of the whole device ecosystem you have to develop only in the supported languages this also includes appearing in the App store in that language as well. This doesn't exist in Welsh, something that is a side effect of the co-official language status within the EU and is dependent on the local government status, hence the fully supported Catalan Google but has limited support for Welsh Google.
Welsh language version of the Course / All Lessons view.
This doesn't mean there aren't ways to present your content in a specific language whilst still making use of the Locale system in an Android App. Locale supports any of the two to five letter combinations of the ISO codes for regions. In this instance Welsh is "cy" sometimes referred to as "cy-gb". Extending the Local and Application class objects to set the App language as something other than the device language at load time means support for any language. This is detailed very succinctly in this Stack Overflow post comment. Here you apply the updateConfig functions in each class you want support and the App loads the Locale content you want enabling multilingual images, text, internal assets and raw code if needed. The language choice for this can be placed in settings configuration or as a simple toggle button within the App. It was a simple change to the loading of the content from the assets folder which had duplicated content in Welsh.