Summary
This paper tries to address the concern, whether to develop a mobile web application or a standalone mobile application to provide mobile access to an existing e-learning platform. It discusses the advantages and disadvantages of both solutions for three major mobile platforms – Apple iOS, Google Android, and Microsoft Windows Phone 7.
Keywords: e-learning, m-learning, mobile technology, native applications, web applications
1. Introduction
The latest generation of mobile devices (particularly smartphones and tablets running on Apple iOS, Google Android, or Microsoft Windows Phone 7) allows for the implementation of a variety of services and support for numerous applications. Current mobile devices have large memory capacities, very fast processors, some with multiple cores. They can connect to desktop computers and have vast multimedia capabilities. At the same time, the availability, quality, and speed of mobile data transmission is constantly rising while prices are decreasing. These parameters lead one to believe that it is necessary for the education technology developer to provide proper access for mobile devices to their technology. Education processes supported by mobile devices are called ‘m-learning’. The global trend of technology development is to increase the participation of mobile devices in users’ daily lives. In particular, this trend is now visible in the education and remote education fields, as evidenced (as an example) by the Online Educa Berlin 2010 conference, where one of the main topics was the implementation of e-learning applications for mobile devices. The rationale for the use of m-learning can be found in studies of specific use cases1. Today the question is not whether to deploy m-learning, but how to do it efficiently and how to introduce m-learning to the existing training system of the company or institution2. Some evaluation results of m-learning courses can also be found3. Those confirm the effectiveness of such training and the high acceptance rate of those with students.
1[16]. 2 [17]. 3
The report on mobile-learning stated that “[t]he industry […] has not decided whether to develop proprietary ‘smart client’ applications or to rely on online Web-based wireless applications to deliver mobile-learning”4. This paper tries to address that concern. There are two possible solutions for delivering functionality to mobile devices, and neither of them is better. The first is to create a web application and to trust the mobile browser to render the content correctly and to provide additional functionality e.g. JavaScript. The other way is to embrace the trademarked Apple motto “There’s and app for that” and to create a standalone (native) application.
To decide how to provide the end user with mobile access to an existing e-learning platform, we formulated the following criteria:
1. Preparation cost – what hardware, software and additional knowledge is necessary. 2. Development cost – how long it will take to prepare a working solution.
3. Implementation and maintenance cost – how difficult is to distribute this solution and then to keep end users updated.
4. Amount of necessary data exchange – how much will it cost the end user.
5. End user experiences and habits – what does he expect and what can the solution deliver. 6. Other known issues – are there any known problems or limitations of the chosen
technology.
This paper has taken into consideration three major mobile platforms – Apple iOS, Google Android and Microsoft Windows Phone 7. Other mobile operating systems, especially RIM BlackBerry, Nokia Symbian and Samsung bada are to be addressed in further research. As Figure 1 shows, mobile operating systems designed for touch screens are in steady growth (this report was presented in November 2010, before release of Windows Phone 7).
Figure 1. Worldwide Smartphone Sales to End Users by Operating System in 3Q09 and 3Q10 Source: Cozza, R. et al., Competitive Landscape: Mobile Devices, Worldwide, 3Q10, Gartner
Research, Stamford, 2010.
4 [18].
2. Functions of the e-learning platform
The main concern of this research was to provide mobile access to an existing web application, i.e. e-learning platform, learning management system. That enforces boundary conditions different than in case of creating the new application from scratch. All business logic processes are already implemented, and there is no need to add any functionality. The web interface of the e-learning platform provides rich user experience and all essential functions. Should the mobile application offer the same variety of options? Not necessarily.
In the early stages of designing the mobile front-end for the e-learning platform, we divided the functions into the following groups:
1. Accessing lists – available courses, user groups, registration forms, etc. 2. Manipulating lists – enrolling for new courses, joining, or leaving user groups.
3. Accessing object metadata – checking course details, group information, also inspecting course results.
4. Accessing objects – running a course.
5. Editing objects – manipulating existing data, uploading new courses, deleting groups. According to the philosophy “each program should do one thing and do it well”, not all of those groups are to be implemented in a mobile solution.
As available options are different for different user roles, the important question is, “Who is the end user of the mobile application?” The platform has several roles:
1. Anonymous – can run some publicly available courses and can create a user account to become a student.
2. Student – the majority of users fall here, as a student can register for and run courses, join user groups, comment on content, take tests and perform exercises, report their progress, and perform other essential tasks.
3. Teacher – can manage their own groups, edit object metadata like start and end dates, check students’ progress.
4. Coordinator – can edit objects, upload courses, and appoint teachers. 5. Administrator – can assign other roles to other users.
Some functions are just not practical for mobiles, like uploading a course from a smartphone, which is a big package of data to transfer via a wireless network, not to mention the scarcity of authoring tools for mobile phones necessary to create that package. As a vast majority of users are students (consumers of the e-learning content) mobile applications should be directed mostly toward them. All additional functionality, apart from that available to the student role, should be pruned back, or at least postponed for later releases.
With all essential functions of the mobile front-end outlined, the next step is to compare two possible techniques of implementation to deliver those functions to the end user. They are the web application, a module of the existing server application run entirely in the device browser, and the standalone application, decoupled from the main server and run independently on the mobile device.
3. Web application
With an existing (web-based) e-learning platform, the first approach seems more natural. It has the usual benefits of the ease of deployment and maintenance and also a vast reach, as almost every mobile, even an older model outside of the Apple-Google-Microsoft ecosystem, has an Internet browser. Upon closer inspection, this approach has both great advantages and some serious disadvantages.
Mobile browsers, just like their desktop counterparts, have different rendering engines, different standards interpretation, JavaScript engines, etc. According to StatCounter Global Stats statistics of mobile browsers market share5, the top mobile browsers are Opera (Mini and Mobile), iPhone’s Safari, Nokia browsers, and Android browsers. Nokia and Android browsers are additionally fragmented and often differ from device model to device model6. Our research shows that a web application not optimized for mobile access runs smoothly on all contemporary mobile browsers, but that lack of optimization results in some visual artefacts and sometimes strange, if not particularly faulty, behaviour. Additionally, a user interface designed for larger screens without touch capabilities is awkward and often difficult to use.
Providing mobile access to the already existing web application involves redesigning the user interface for a smartphone and tablet display. That means at least two more different perspectives for application – the smaller one for phones and the bigger one for tablets (taking into consideration portrait and landscape modes of those devices). All those perspectives have to be equipped with the standard means to overcome rendering differences between mobile browsers.
Preparation cost of this approach, assuming that this means the extending existing web-based platform, is minimal. Hardware, software, and knowledge needed for developing web applications designed for mobiles are basically the same as other web applications. The development cost consists mostly of designing and testing the new user interface, as there are no new business processes or functionalities. Implementation and maintenance costs are also low – the client part exists in the browser, so a new version is delivered to the end user each time he visits the site, and there’s no other distribution process involved.
Also, there is no control over the distribution process – web applications usually cannot be sold like standalone applications in app stores dedicated to a particular platform. To sell the web application, it is necessary to implement one’s own checkout system. The data exchange is huge – all additional resources (images, scripts, styles, etc.) have to be downloaded, and every user action causes some kind of request and response to be transferred to and from the web server. Exchanged messages are mostly HTML, and there is no easy way to influence those outside of standard compression to somehow shrink the size. Finally, online studies7 show that 73% of users expect a standalone application to be easier to use than a web page, and 76% think that brands should have mobile applications to make interaction with them easier.
Furthermore, mobile browsers have one limitation that is rarely present in their desktop counterparts. Additional technologies available as plugins for desktop browsers are virtually not supported with mobile browsers. Adobe Flash, a very popular web technology, is available only
5[19]. 6[12]. 7
for newer versions of Android. A similar Microsoft solution, Silverlight, is available only for Microsoft Phone 7. Java applets are not recognized by any mobile browser. Parts of the web application that utilise such technologies have to be refactored into HTML, JavaScript, or others understandable by mobile device technology.
In addition, an application launched with a browser does not benefit from all features of the host system, e.g. access to a camera, microphone, or accelerometer. This might not be the case in the future, as some browsers already can access the location information of the handheld device, so this process can be generalized and more access might be granted. Also, for a mobile version of an existing e-learning platform (with no new functionalities) it is not an issue.
4. Standalone application
The second approach can result in more predictable rendering and behaviour, as it is designed for the operating system and not for the browser. Just like the former, this solution also has its advantages and disadvantages.
Preparation cost of a standalone application is much higher than a web application. Every mobile operating system has its own technology, developer tools, programing language, distribution channels (with various fees), and in some cases, even necessary hardware. The development cost is also high; the development team have to familiarise themselves with new technology, as implementing native applications for mobile phones is different than programming web applications, and in some rare cases when similar-looking technology is used, there are some key differences.
Implementation and maintenance costs are also higher than with the web application. Distribution channels vary from operating system to operating system. Some of them allow the user to install any application on their device, regardless of the source; others, on the other hand, have strict regulations on application distribution. Delivering updates via a controlled environment (“market”, “store”, or similar application source) is easier than updating the application acquired by some other means, but nonetheless there is a possibility that the end user will interact with an outdated application.
The end user benefits, however, are huge. The amount of data traffic is limited to only necessary data, with all additional resources (images, styles, and functionality itself) already present on the client device. The user expectations are met – they get a tangible object they can interact with, with clearly defined functionality, placement, and permissions, with an icon to identify. Also, the native application has full access to all features available on the target device – including the microphone, camera, and other hardware.
As Table 1 shows, the decision on the implementation approach is not easy. It is necessary to introduce some weights to the presented criteria. As first three points can be labelled as “developer’s comfort”; the fourth and fifth point can be labelled as “user’s comfort”. Depending on what is more important to the technology provider that option should be taken into consideration. In our case, it was decided that the end user should get the priority, so the choice was made to introduce a native application as means of mobile access to the e-learning platform.
Table 1. Summary of arguments for and against both approaches
Web application Standalone application
Preparation cost 9 Low 8 High
Development cost 9 Low 8 High
Implementation and maintenance cost 9 Low 8 Medium
Amount of necessary data exchange 8 High 9 Low
End user experiences and habits 8 Does not meet 9 Meets
Other known issues 8 Technology
barrier 9 None
Source: own.
5. Data plans – REST/SOAP/JSON/XML
While adapting a web application for mobile access there is always an issue with transferring data to and from the Internet. As with browser applications, end users are always expecting some data traffic, but with standalone applications, they might not be really prepared for it, despite the application clearly requesting user permission for an Internet connection. While WiFi networks are popular and hotspots are easy to find, they should not be taken for granted, and not all cellular networks offer unlimited data plans and some, if not most, users are on limited or expensive data plans. E-learning applications can generate heavy data traffic, so measures to restrict end user costs should be taken.
Communication between the server and the application can be implemented in many ways. In our implementation, we focused on web services, as they were already used in the web application. There are two major types of web services – SOAP and REST. Simple Object Access Protocol (SOAP) is a strongly typed, easy to consume, and powerful protocol. It is an independent form transfer medium and allows for stateful connections. Also, it requires a great amount of expensive data exchange between the server and client. Representational State Transfer (REST) web services are possible on http protocol only, are weakly typed, should be stateless, and the messages are human readable. The amount of data to exchange is greatly reduced (actual numbers depending on objects construction). Moreover, it is possible to reduce the traffic even further by switching from XML messages to JSON (JavaScript Object Notation), which is impossible to do using SOAP. JSON messages are easy to create and consume, but they lack strong typing and other advanced features of SOAP XMLs. However, the need of those advanced features can be avoided, their functionality replaced, and the overall profit in reducing the amount of exchanged data makes the REST/JSON combination a better solution for mobile applications. Actual numbers can be found in Table 2, where the experimental results are presented.
Table 2. Comparison of the amount of data exchanged. In all three cases, the service in question returned the list of users of an existing instance of the e-learning platform. JSON over REST has the least amount of data transported. Examples of messages being passed can be found in Figure
2, Figure 3, and Figure 4.
Headers Body Sum
SOAP WebService execution data
Bytes Sent: 103 0 103
Bytes Received: 246 22,951 23,197
REST WebService execution data (default content type – XML)
Bytes Sent: 67 0 67
Bytes Received: 242 13,238 13,480
REST WebService execution data (content type – JSON)
Bytes Sent: 93 0 93
Bytes Received: 242 7,715 7,957
Source: own.
Figure 2. Example of a REST JSON message used in the experiment Source: own.
Figure 3. (left) Example of SOAP message used in the experiment Figure 4. (right) Example of REST XML message used in the experiment Source: own.
In addition to general concerns and differences between web and native applications, all considered mobile platforms have their own features and need the specific approach. Regardless of the actual choice between web and native application, all those aspects should be taken into account.
6. Developing for Apple iOS
6.1. Web application for iOS
All devices with iOS on board (like the iPhone and iPad) are provided with the built-in Safari Mobile browser. That does not mean the user will use just that one browser as several more have been released recently. An interesting alternative for the bundled WebKit-based Safari browser is the Presto based Opera Mini, which is available for free. It delivers a compressed version of the web page that is routed through external servers. On the other hand, the SkyFire browser debuted with a lot of hype because it is the first iPhone browser that can play Flash video. It works by
translating Flash videos to HTML5 via external servers. There are also other browsers which vary in speed, features, standard compliance, and price.
The screen resolution of devices working on the iOS platform is not precisely defined. It could vary even for a different version of a particular device – the earlier version of the iPhone had a 320×480 resolution, but the newest iPhone 4 has a 640x960 resolution. Moreover, there is also the iPad – a very popular device with a 1024x768 resolution. While developing the user interface, the designer should at least consider those two devices and the aforementioned different rendering engines.
6.2. Standalone application for Apple iOS
Creating native applications for iOS requires substantial investments, as development tools are available only for an Intel-based Apple computer. The IDE for iOS, Xcode, is currently available in two forms. Version 3.2.6 is available from the Apple developer’s portal free of charge, but the most recent version (4.0) is free only for members of the iOS Developer Program (subscription is annual and costs $99). The iOS Developer Program membership is also necessary to install applications on real devices and not just simulators. Moreover, it is required to publish applications in the App Store8. The programming language of iOS is Objective C, which is not as widespread as C#, Java or C++, so the development team have to learn that technology. Furthermore, it is necessary to become acquainted with Cocoa Touch, a set of frameworks for developing mobile software. Cocoa Touch contains, amongst others, frameworks for user interface – UIKit, for network support, sound playback, and a few others9. Fortunately, Apple supplies great documentation ranging from Cocoa reference to newbie step-by-step guides.
6.3. Human Interface Guidelines
Apple’s company tries to ensure that all applications for iOS should look and behave in a similar way by publishing iOS Human Interface Guidelines10. This very detailed document can be divided into two parts. The first part consists of the sociological aspects of interface design. It helps to create an interface based on the human way of thinking and behaviours. The second part describes how to use common features such as keyboards and input, copy/ paste, gestures, multitasking, and a few others; it is also a guide to available UI elements. This document also states which elements are required for the application to be admitted into the App Store (e.g. application icons). Not meeting the described requirements or deviating too much from the guidelines results in application being rejected, which is a great concern as the Apple App Store is the only way of distributing native applications for Apple devices.
Unfortunately, native JSON support under iOS is not available. It does exist, but it is not public and may be used only by Apple developers. After deciding to use JSON, one has to use
8 [3]. 9 [1]. 10
a third-party solution. The fastest one is thought to be JSONKit11, which is used, for example, by Twitter APIs.
7. Developing for Google Android
7.1. Web application for Android
The stock browser of the Google platform is based on a customised WebKit engine, but there are alternatives available, including, but not limited to, Gecko-based Firefox and Presto-based Opera Mini/Mobile. Just like their desktop versions, those browsers vary in speed, features, and standards compliance. Large parts of HTML5 specifications are supported (but it varies with the browser). Moreover, there is an Adobe Flash support for the latest versions of the Android OS (2.2 and more), so the developer has many tools for building a new mobile interface in the browser.
The Android operating system allows a variety of screen resolutions and pixel densities, and the browser actively scales the web pages to preserve the same perceivable size as a medium-density screen12. There are ways to influence this process with custom-built style sheets and meta-directives. Just like with web applications for desktop browsers, the interface designer has to consider many different device and engine combinations.
7.2. Native application for Android
The standalone application for Android shares the same system specifications as a web application, namely various screen sizes and pixel densities (generalised into four sizes: low, medium, high, and extra high). The programming language is JAVA. Standard Android packages differ in some points from official JAVA packages, having some functionality not feasible for mobile devices removed. Developer tools are provided by Google free of charge, including a plugin to a popular IDE platform named Eclipse.
The official way to distribute Android applications is via the Android Market, a service from Google. There is one time fee of $25 for a developer to be able to publish applications there to reach a global audience13. However, a specialized application like a mobile client to an e-learning platform doesn’t really need a global reach as it has to connect to the existing e-learning platform (e.g. owned by one particular university). It is acceptable to have that application available for download from that particular platform’s page. With Android, it is possible to install applications outside of market distribution, i.e. downloaded from the web, what is a preferred delivery method in this case.
What is also important, the support of JSON standard in Android is very good. There is a JAVA package included in the core packages for parsing, generating, and consuming JSON tables. Free of charge packages are also available for creating JAVA objects from JSON strings.
11 [5]. 12 [9]. 13
There is also a possibility of third-party market services, but at the time of writing, the only alternative market was Amazon Appstore for Android and that service was unavailable outside the US.
7.3. Human Interface Guidelines
Interface design guidelines for Android concentrate on emphasising the concept of activity stack and multitasking. In Android, every application or part of an application (activity) that the user interacts with is placed on the activity stack. Bottom of the activity stack is always the Home application (Android desktop analogue). Activities in the stack are never rearranged, only pushed and popped from the stack – pushed onto the stack when started by the current activity and popped off when the user leaves it using the back key14. Pressing the back button navigates to the previous activity on the stack; pressing the home button sends the application (and its activity stack) to the background and interacting with the application icon or a notification brings it forward with the activity stack intact.
Another important issue discussed is the design of the application icon. With quite rigid design guidelines15, most existing program icons have to be redesigned:
• Android Launcher icons are...
o Modern, minimal, matte, tactile, and textured
o Forward-facing and top-lit, whole, limited in colour palette • Android Launcher icons are not...
o Antique, over-complicated, glossy, flat vector o Rotated, cropped, over-saturated
Moreover, Android suffers from market fragmentation, as some devices are not capable of running the most recent operating system. Apart from the necessity of testing the application against more system versions, older Android versions had different interface design guidelines, which should be taken into consideration.
8. Developing for Microsoft Windows Phone 7
8.1. Web application for Windows Phone 7
Providing a web application for Windows Phone 7, one must deal with many limitations. The only mobile browser which is delivered with the platform is Microsoft Internet Explorer Mobile. At the time of writing, there is no version of any other popular browser adapted to work with a Windows Phone system. For now, the mobile developer must deal with the stock mobile browser based on the Trident layout engine – the current version is based on a hybrid of rendering engines of Internet Explorer 7 and Internet Explorer 8 desktop editions. So far, the support for the HTML5 standard is minimal. The web application has to be adapted to the current rendering engine version. However, the web application can be deployed using Silverlight technology, but just like Flash technology, it is supported only by some versions of Android system; this technology is supported only by a Windows Phone platform. Moreover, all mobile phones with Windows Phone 7 on board have WVGA screens with an 800x480 pixel resolution, no matter the screen size. This will result in a customized Cascade Style Sheets file.
14
[10].
At the end, one must prepare or at least adapt the web application to correctly render on the Windows Phone platform, but there is only one resolution and browser engine combination to consider.
8.2. Native application for Windows Phone 7
When the developer has to provide a custom-tailored interface of the web version of service, why not just implement a standalone application? They will have to learn how to build applications using the Silverlight for Phone framework. In case they are already acquainted with Silverlight technology used in web applications, they must confront this knowledge with the version of that framework designed particularly for mobile devices, which differ in some key parts, including system libraries.
Microsoft delivers all the software needed for developing standalone applications for Windows Phone platform for free. However, in the development process there is always the moment when it is necessary to install the software onto a physical mobile device, and unfortunately it is necessary to buy a subscription on the AppHub portal even to upload the solution to one physical device for testing purposes. This subscription allows the developer to upload multiple applications on the Windows Phone Marketplace – the service that allows users to browse and download applications that have been developed by third-parties. There is no way to avoid expenses even when developing applications for personal needs.
The support of JSON standard in Windows Phone is very good. There are mechanisms built into the .NET framework dedicated for the Windows Phone, which allows object serialization to and from JSON. There is also an open source framework called Json.NET available that includes a possibility to convert .NET objects to JSON and back again, convert JSON to and from XML and mechanisms for the easy reading and writing JSON strings (called LINQ to JSON).
8.3. Human Interface Guidelines
The guidelines to design user interface in Windows Phone Applications were precisely defined by Microsoft. Applications should embody the three Red Threads of Windows Phone 716:
• personal – your day, your way; • relevant – your people, your location; • connected – your stuff, your peace of mind.
Applications designed for Windows Phone should connect to at least one of these threads; so developers should consider which of those threads should be matched by their application and carefully design their project.
The Windows Phone OS 7 User Interface is based on a design that is internally named Metro and echoes the visual language of airport and metro system signage in its design and typeface17. It was developed using the five following principles:
• clean, light, open, and fast – contains ample white space, reduces clutter, and elevates typography as a key design element;
• content, not chrome – accentuates focus on the content that the user mostly cares
16
[14].
about;
• integrated hardware and software – hardware and software blend into each other and create a seamless user experience;
• world-class motion – touch and gesture experiences on capacitive screens are consistent with Windows 7 on the desktop and include hardware-accelerated animations and transitions;
• soulful and alive – a personalized view into the information that matters most to the user is enabled and fully integrated with the Zune software.
Applications should adapt to that kind of user interface. It should be provided with UI elements from the framework adapted to actual needs and not with that made entirely by developers. The developer should also adapt to built-in platform navigation, especially hardware buttons and an application bar available on the bottom of the mobile screen, which are used to navigate between applications and application screens.
9. Application Life Cycle
Beside differences in hardware and software needed for development process, there are also differences between each one of the operating systems. Developing one solution and just refactoring it for different platforms would be preferable, but unfortunately that can’t be done. Particular mobile operating systems vary in multiple points; in particular they have various ways to manage the application life cycle. This makes it much harder to provide a general project of an application which would fit all platforms that should be supported.
The iOS application life cycle is complicated because it differs from version to version – multitasking is supported since the launch of iOS 418. Application life begins with the user tapping its icon on the home screen when it is being loaded and it then becomes active. When the home button is used, the application is not terminated, but it is being sent to the background and later suspended. While it is in this state, all of the core application objects remain in the memory. Moving to the background may also occur after receiving an interruption like a phone call or an SMS (text message) when the user decides to respond to it. If resources begin to run low, the system will begin purging suspended applications without any warning. If a device is running a system prior to Version 4, no multitasking is available; hence there is no background and suspended state: instead the application is just being terminated.
Android is a multitasking system which allows multiple applications to run simultaneously. At any time any running activity (independent application screen) can be paused and sent to the background because of the user action or an incoming call. Such paused activity can be brought forward (and it should restore its state), or it can be killed by the system if another application cannot fit in the phone memory. The foreground-background transitions are very frequent because each dialog box or another screen of the same application pauses the activity. As such, the developer has little control over when their application or activity stops or exits. Moreover, from seven lifecycle events of each activity, three of them are marked “killable after”; that means that “the system can kill the process hosting the activity at any time after the method returns without
18
executing another line of the activity's code”19. In other words, the OnPause event, as the first of that three, is the only reliable event to fire before activity termination.
The Windows Phone operating system allows only one application to run at a time, therefore it does not allow any third-party applications to run in the background (it is possible for some stock applications like the Media Player to do so). The reasons for that are to preserve battery life and to ensure a consistent and responsive user experience. When the user navigates away from the application, the operating system deactivates the application (this process is called tombstoning). The application can become deactivated in the following cases:
• a phone call is received (reactivation occurs when the phone call ends); • the phone goes to sleep (reactivation occurs when the user wakes the phone);
• the user presses the Start or Search button or responds to a notification (reactivation occurs when the user returns to the application by pressing the Back button);
• the application invokes an external task (reactivation occurs when the task completes).
When the tombstoned application is activated again, it should look the same as it looked before tombstoning. For example, if the user spent some time filling out a large form, he definitely does not want to see all his work disappear. To achieve this, when the application becomes deactivated, the operating system maintains state information of the application in memory and uses that information to restore the application when it is reactivated. What is important is that the application must complete all of the actions accounted for the deactivated event in less than 10 seconds, and if it takes longer it will be force-terminated and will no longer be accessible via the Back button20.
10. Summary
This paper summarized the advantages and disadvantages of two possible solutions for delivering an existing functionality of a web application to mobile devices based on the example of the e-learning platform. It discussed three major mobile platforms – Apple iOS, Google Android, and Microsoft Windows Phone 7, as other mobile operating systems, especially RIM BlackBerry, Nokia Symbian, and Samsung bada were left for further research. Assuming an existing web application and the amount of necessary resource investments is less with the mobile web application approach, the end user expectations and future profits are better addressed with native application.
19 [7]. 20
Bibliography
[1] Apple Inc., Cocoa Fundamentals Guide, Apple Inc., Cupertino, 2010.
[2] Apple Inc., iOS Application Programming Guide, Apple Inc., Cupertino, 2011. [3] Apple Inc., iOS Development Guide, Apple Inc., Cupertino, 2010.
[4] Apple Inc., iOS Human Interface Guidelines, Apple Inc., Cupertino, 2011. [5] Cocoanetics, JSON versus PLIST, the Ultimate Showdown, 2011.
[6] Cozza, R. et al., Competitive Landscape: Mobile Devices, Worldwide, 3Q10, Gartner Research, Stamford, 2010.
[7] Google Inc., Activities, Google Inc., 2011. (available online at: http://developer.android.com/ guide/ topics/ fundamentals/ activities.html.)
[8] Google Inc., Launcher Icons, Google Inc, 2011. (available online at: http://developer.android.com/ guide/ practices/ ui_guidelines/ icon_design_launcher.html.). [9] Google Inc., Targeting Screens from Web Apps, Google Inc., 2011. (available online at:
http://developer.android.com/ guide/ webapps/ targeting.html.).
[10] Google Inc., Tasks and Back Stack, Google Inc., 2011. (available online at: http://developer.android.com/ guide/ topics/ fundamentals/ tasks-and-back-stack.html.) [11] Harris Interactive for EffectiveUI, Mobile Application Users Preferences, Harris
Interactive, New York, 2010.
[12] Koch, P., Smartphone Browser Landscape, A List Apart, 2010.
[13] Microsoft Corporation, Running your App in the Background (Tombstoning), Microsoft Corporation, 2011. (available online at: http://create.msdn.com/ en-US/ education/ quickstarts/ Running_your_App_in_the_Background_(Tombstoning).).
[14] Microsoft Corporation, UI Design and Interaction Guide for Windows Phone 7, 2010. [15] Motiwalla, L.F., Mobile learning: A framework and evaluation, Computers & Education,
Elsevier, 2007.
[16] Norman, N., Mobile Learning for the NHS: Research Report: Summary, Epic, Brighton, 2011.
[17] Stead, G., Moving mobile into the mainstream, Tribal Education: CTAD, 2005.
[18] Woodill, G., Cunningham-Reid, A., Mobile-learning: The Essential. Sunnyvale, Brandon Hall Research, 2008.
[19] http://gs.statcounter.com/#mobile_browser-ww-monthly-201010-201103 StatCounter Global Stats. April 2011. (accessed April 2011).
PORZUCAJĄC PRZEGLĄDARKĉ – DOSTĉP MOBILNY DO ISTNIEJĄCEJ APLIKACJI SIECIOWEJ NA PRZYKŁADZIE PLATFORMY E-LEARNINGOWEJ
Streszczenie
Niniejszy artykuł podejmuje próbĊ odpowiedzi na pytanie, czy budowaü dedykowane aplikacje sieci web, czy teĪ raczej samodzielne natywne aplikacje, celem umoĪliwienia dostĊpu do istniejącej platformy e-learningowej z wykorzystaniem urządzeĔ mobilnych. W artykule rozwaĪane są wady i zalety obu rozwiązaĔ dla trzech popularnych Ğrodowisk mobilnych – Apple iOS, Google Android oraz Microsoft Windows Phone 7
Słowa kluczowe: e-learning, m-learning, technologie mobilne, samodzielne aplikacje, aplikacje sieciowe
Monika Biskupska Wioleta Borysewicz Tomasz Marciniak
Institute of Mathematical Machines Information Systems Department
ul. Ludwika Krzywickiego 34, 02-078 Warsaw, Poland e-mail: m.biskupska@imm.org.pl
w.borysewicz@imm.org.pl t.marciniak@imm.org.pl
