Mobile programming

From Wikipedia, the free encyclopedia

Jump to: navigation, search

Programming for mobile phones is its own discipline. A J2ME programming project has more in common with a BREW project then it does with a Java server side project.

The differences lies in the limitations common to most mobile programming languages and mobile environments. Resources are constrained, including screen size, memory, CPU, storage, and input method.

The expectations of the end user of a mobile product are also very different from the average web browser, or brick and mortar customer.

There are also different performance expectations from the hardware, and the API's used by the handset. Users and developers are both prepared for a certain degree of faults, especially in prototype or hard to acquire models.

See also

• Mobile Development
• Multiplayer Mobile games

Mobile Environments

• Feature phone and better:
  • J2ME|
  • Brew

• Smart phone and better:
  • Symbian
  • RIM
  • Palm
  • Windows Mobile

This wireless-related article is a stub. You can help Wikipedia by expanding it.

Java Platform, Standard Edition - J2SE

Java Platform, Standard Edition

From Wikipedia, the free encyclopedia

Java Platforms

Micro Edition (ME)

Standard Edition (SE)

Enterprise Edition (EE)

Java Platform, Standard Edition or Java SE (formerly known up to version 5.0 as Java 2 Platform, Standard Edition or J2SE), is a collection of Java programming language APIs useful to many Java platform programs. The Java Platform, Enterprise Edition includes all of the classes in the Java SE, plus a number which are more useful to programs running on servers than on workstations.

Starting with the J2SE 1.4 version (Merlin), the Java SE platform has been developed under the Java Community Process. JSR 59 was the umbrella specification for J2SE 1.4 and JSR 176 specified J2SE 5.0 (Tiger). As of 2006, Java SE 6 (Mustang) is being developed under JSR 270.

The following are descriptions of some of the primary Java SE packages. For a complete list of packages see the J2SE 5.0 API Javadocs.

Contents 1 General purpose packages 1.1 java.lang 1.1.1 java.lang.ref 1.1.2 java.lang.reflect 1.1.2.1 Discovery 1.1.2.2 Use by name 1.1.2.3 Arrays and proxies 1.2 java.io 1.2.1 Streams 1.2.2 Random access 1.2.3 File system 1.3 java.nio 1.4 java.math 1.5 java.net 1.6 java.text 1.7 java.util 2 Special purpose packages 2.1 java.applet 2.2 java.beans 2.3 java.awt 2.4 java.rmi 2.5 java.security 2.6 java.sql 2.7 javax.rmi 2.8 org.omg.CORBA 2.9 javax.swing 2.10 javax.swing.text.html.parser 3 External links

General purpose packages

java.lang

The Java package java.lang contains fundamental classes and interfaces closely tied to the language and runtime system. This includes the root classes that form the class hierarchy, types tied to the language definition, basic exceptions, math functions, threading, security functions, as well as some information on the underlying native system.

The main classes in java.lang are:

• Object – the class that is the root of every class hierarchy. (See also Java syntax#Methods in the Object class.)
• Enum – the base class for enumeration classes (as of J2SE 5.0).
• Class – the class that is the root of the Java reflection system.
• Throwable – the class that is the base class of the exception class hierarchy.
• Error, Exception, and RuntimeException – the base classes for each exception type.
• Thread – the class that allows operations on threads.
• String – the class for strings and string literals.
• StringBuffer and StringBuilder – classes for performing string manipulation (StringBuilder as of J2SE 5.0).
• Comparable – the interface that allows generic comparison and ordering of objects (as of J2SE 1.2).
• Iterable – the interface that allows generic iteration using the enhanced for loop (as of J2SE 5.0).
• ClassLoader, Process, Runtime,SecurityManager, and System – classes that provide "system operations" that manage the dynamic loading of classes, creation of external processes, host environment inquiries such as the time of day, and enforcement of security policies.
• Math and StrictMath – classes that provide basic math functions such as sine, cosine, and square root (StrictMath as of J2SE 1.3).
• The primitive wrapper classes that encapsulate primitive types as objects.
• The basic exception classes thrown for language-level and other common exceptions.

Classes in java.lang are automatically imported into every source file.

java.lang.ref

The java.lang.ref package provides more flexible types of references than are otherwise available, permitting limited interaction between the application and the Java Virtual Machine (JVM) garbage collector. It is an important package, central enough to the language for the language designers to give it a name that starts with "java.lang", but it is somewhat special-purpose and not used by a lot of developers. This package was added in J2SE 1.2.

Java has a more expressive system of reference than most other garbage-collected programming languages, which allows for special behavior for garbage collection. A normal reference in Java is known as a strong reference. The java.lang.ref package defines three other types of references—soft, weak, and phantom references. Each type of reference is designed for a specific use.

A SoftReference can be used to implement a cache. An object that is not reachable by a strong reference (that is, not strongly reachable), but is referenced by a soft reference is called softly reachable. A softly reachable object may be garbage collected at the discretion of the garbage collector. This generally means that softly reachable objects will only be garbage collected when free memory is low, but again, it is at the discretion of the garbage collector. Semantically, a soft reference means "keep this object unless the memory is needed."

A WeakReference is used to implement weak maps. An object that is not strongly or softly reachable, but is referenced by a weak reference is called weakly reachable. A weakly reachable object will be garbage collected during the next collection cycle. This behavior is used in the class java.util.WeakHashMap. A weak map allows the programmer to put key/value pairs in the map and not worry about the objects taking up memory when the key is no longer reachable anywhere else. Another possible application of weak references is the string intern pool. Semantically, a weak reference means "get rid of this object when nothing else references it."

A PhantomReference is used to reference objects that have been marked for garbage collection and have been finalized, but have not yet been reclaimed. An object that is not strongly, softly or weakly reachable, but is referenced by a phantom reference is called phantom reachable. This allows for more flexible cleanup than is possible with the finalization mechanism alone. Semantically, a phantom reference means "this object is no longer needed and has been finalized in preparation for being collected."

Each of these reference types extends the Reference class which provides the get() method to return a strong reference to the referent object (or null if the reference has been cleared or if the reference type is phantom), and the clear() method to clear the reference.

The java.lang.ref also defines the class ReferenceQueue, which can be used in each of the applications discussed above to keep track of objects that have changed reference type. When a Reference is created it is optionally registered with a reference queue. The application polls the reference queue to get references that have changed reachability state.

See "Reference Objects and Garbage Collection" for a more thorough description of using reference types and reference queues.

java.lang.reflect

Reflection is a constituent of the Java API which enables Java code to examine and "reflect" upon Java components at runtime and to use the reflected members. Classes in this package, along with java.lang.Class and java.lang.Package accommodate applications such as debuggers, interpreters, object inspectors, class browsers, and services such as object serialization and JavaBeans that need access to either the public members of a target object (based on its runtime class) or the members declared by a given class. This package was added in JDK 1.1.

Reflection is used to instantiate classes and invoke methods using their names, a concept that allows for dynamic programming. Classes, interfaces, methods, fields, and constructors can all be discovered and used at runtime. Reflection is supported by metadata that the JVM has about the program. There are two basic techniques involved in reflection:

1. Discovery involves taking an object or class and discovering the members, superclasses, implemented interfaces, and then possibly using the discovered elements.
2. Use by name involves starting with the symbolic name of an element and using the named element.

[edit] Discovery

Discovery typically starts with an object and calling the Object.getClass() method to get the object's Class. The Class object has several methods for discovering the contents of the class, for example:

• getMethods() – returns an array of Method objects representing all the public methods of the class or interface
• getConstructors() – returns an array of Constructor objects representing all the public constructors of the class
• getFields() – returns an array of Field objects representing all the public fields of the class or interface
• getClasses() – returns an array of Class objects representing all the public classes and interfaces that are members (e.g. inner classes) of the class or interface
• getSuperclass() – return the Class object representing the superclass of the class or interface (null is returned for interfaces)
• getInterfaces() – returns an array of Class objects representing all the interfaces that are implemented by the class or interface

Use by name

The Class object can be obtained either through discovery, by using the class literal (e.g. MyClass.class) or by using the name of the class (e.g. Class.forName("mypackage.MyClass")). With a Class object, member Method, Constructor, or Field objects can be obtained using the symbolic name of the member. For example:

• getMethod("methodName", Class...) – returns the Method object representing the public method with the name "methodName" of the class or interface that accepts the parameters specified by the Class... parameters.
• getConstructor(Class...) – returns the Constructor object representing the public constructor of the class that accepts the parameters specified by the Class... parameters.
• getField("fieldName") – returns the Field object representing the public field with the name "fieldName" of the class or interface.

Method, Constructor, and Field objects can be used to dynamically access the represented member of the class. For example:

• Field.get(Object) – returns an Object containing the value of the field from the instance of the object passed to get(). (If the Field object represents a static field then the Object parameter is ignored and may be null.)
• Method.invoke(Object, Object...) – returns an Object containing the result of invoking the method for the instance of the first Object parameter passed to invoke(). The remaining Object... parameters are passed to the method. (If the Method object represents a static method then the first Object parameter is ignored and may be null.)
• Constructor.newInstance(Object...) – returns the new Object instance from invoking the constructor. The Object... parameters are passed to the constructor. (Note that the parameterless constructor for a class can also be invoked by calling newInstance().)

Arrays and proxies

The java.lang.reflect package also provides an Array class that contains static methods for creating and manipulating array objects, and since J2SE 1.3, a Proxy class that supports dynamic creation of proxy classes that implement specified interfaces.

The implementation of a Proxy class is provided by a supplied object that implements the InvocationHandler interface. The InvocationHandler's []) invoke(Object, Method, Object[]) method is called for each method invoked on the proxy object—the first parameter is the proxy object, the second parameter is the Method object representing the method from the interface implemented by the proxy, and the third parameter is the array of parameters passed to the interface method. The invoke() method returns an Object result that contains the result returned to the code that called the proxy interface method.

java.io

The java.io package contains classes that support input and output. The classes in the package are primarily stream-oriented; however, a class for random access files is also provided. The central classes in the package are InputStream and OutputStream which are abstract base classes for reading from and writing to byte streams, respectively. The related classes Reader and Writer are abstract base classes for reading from and writing to character streams, respectively. The package also has a few miscellaneous classes to support interactions with the host file system.

Streams

The stream classes follow the decorator pattern by extending the base subclass to add features to the stream classes. Subclasses of the base stream classes are typically named for one of the following attributes:

• the source/destination of the stream data
• the type of data written to/read from the stream
• additional processing or filtering performed on the stream data

The stream subclasses are named using the naming pattern XxxStreamType where Xxx is the name describing the feature and StreamType is one of InputStream, OutputStream, Reader, or Writer.

The following table shows the sources/destinations supported directly by the java.io package:

Source/Destination	Name	Stream types	In/Out	Classes
byte array (byte[])	ByteArray	byte	in, out	ByteArrayInputStream, ByteArrayOutputStream
char array (char[])	CharArray	char	in, out	CharArrayReader, CharArrayWriter
file	File	byte, char	in, out	FileInputStream, FileOutputStream, FileReader, FileWriter
string (StringBuffer)	String	char	in, out	StringReader, StringWriter
thread (Thread)	Piped	byte, char	in, out	PipedInputStream, PipedOutputStream, PipedReader, PipedWriter

Other standard library packages provide stream implementations for other destinations, such as the InputStream returned by the java.net.Socket.getInputStream() method or the Java EE javax.servlet.ServletOutputStream class.

Data type handling and processing or filtering of stream data is accomplished through stream filters. The filter classes all accept another compatible stream object as a parameter to the constructor and decorate the enclosed stream with addional features. Filters are created by extending one of the base filter classes FilterInputStream, FilterOutputStream, FilterReader, or FilterWriter.

The Reader and Writer classes are really just byte streams with additional processing performed on the data stream to convert the bytes to characters. They use the default character encoding for the platform, which as of J2SE 5.0 is represented by the Charset returned by the java.nio.charset.Charset.defaultCharset() static method. The InputStreamReader class converts an InputStream to a Reader and the OutputStreamWriter class converts an OutputStream to a Writer. Both these classes have constructors that allow the character encoding to use to be specified—if no encoding is specified then the default encoding for the platform is used.

The following table shows the other processes and filters supported directly by the java.io package. All of these classes extend the corresponding Filter class.

Operation	Name	Stream types	In/Out	Classes
buffering	Buffered	byte, char	in, out	BufferedInputStream, BufferedOutputStream, BufferedReader, BufferedWriter
"push back" last value read	Pushback	byte, char	in	PushbackInputStream, PushbackReader
read/write primitive types	Data	byte	in, out	DataInputStream, DataOutputStream
object serialization (read/write objects)	Object	byte	in, out	ObjectInputStream, ObjectOutputStream

Random access

The RandomAccessFile class supports random access reading and writing of files. The class uses a file pointer that represents a byte-offset within the file for the next read or write operation. The file pointer is moved implicitly by reading or writing and explicitly by calling the seek(long) or skipBytes(int) methods. The current position of the file pointer is returned by the getFilePointer() method.

File system

The File class represents a file or directory path in a file system. File objects support the creation, deletion and renaming of files and directories and the manipulation of file attributes such as read-only and last modified timestamp. File objects that represent directories can be used to get a list of all of the contained files and directories.

The FileDescriptor class is a file descriptor that represents a source or sink (destination) of bytes. Typically this is a file, but can also be a console or network socket. FileDescriptor objects are used to create File streams. They are obtained from File streams and java.net sockets and datagram sockets.

java.nio

In J2SE 1.4, the package java.nio (NIO or New I/O) was added to support memory-mapped I/O, facilitating IO operations closer to the underlying hardware with sometimes dramatically better performance. The java.nio package provides support for a number of buffer types. The subpackage java.nio.charset provides support for different character encodings for character data. The subpackage java.nio.channels provides support for channels, which represent connections to entities that are capable of performing I/O operations, such as files and sockets. The java.nio.channels package also provides support for fine-grained locking of files.

java.math

The java.math package supports multiprecision arithmetic (including modular arithmetic operations) and provides multiprecision prime number generators used for cryptographic key generation. The main classes of the package are:

• BigDecimal – provides arbitrary-precision signed decimal numbers. BigDecimal gives the user control over rounding behavior through RoundingMode.
• BigInteger – provides arbitrary-precision integers. Operations on BigInteger do not overflow or lose precision. In addition to standard arithmetic operations, it provides modular arithmetic, GCD calculation, primality testing, prime number generation, bit manipulation, and other miscellaneous operations.
• MathContext – encapsulate the context settings which describe certain rules for numerical operators.
• RoundingMode – an enumeration that provides eight rounding behaviors.

java.net

The java.net package provides special IO routines for networks, allowing HTTP requests, as well as other common transactions.

java.text

The java.text package implements parsing routines for strings and supports various human-readable languages and locale-specific parsing.

java.util

Data structures that aggregate objects are the focus of the java.util package. Included in the package is the Collections API, an organized data structure hierarchy influenced heavily by the design patterns considerations.

Special purpose packages

java.applet

Created to support Java applet creation, the java.applet package allows applications to be downloaded over a network and run within a guarded sandbox. Security restrictions are easily imposed on the sandbox. A developer, for example, may apply a digital signature to an applet, thereby labeling it as safe. Doing so allows the user to grant the applet permission to perform restricted operations (such as accessing the local hard drive), and removes some or all of the sandbox restrictions. Digital certificates are issued by such agencies as Thawte or Entrust.

java.beans

Included in the java.beans package are various classes for developing and manipulating beans, reusable components defined by the JavaBeans architecture. The architecture provides mechanisms for manipulating properties of components and firing events when those properties change.

Most of the APIs in java.beans are intended for use by a bean editing tool, in which beans can be combined, customized and manipulated. One type of bean editor is a GUI designer in an integrated development environment.

java.awt

The Abstract Windowing Toolkit contains routines to support basic GUI operations and uses basic windows from the underlying native system. Many independent implementations of the Java API (such as GNU's libgcj) implement everything but AWT, which is not used by most server-side applications. This package also contains the Java2D graphics API.

java.rmi

The java.rmi package provides Java remote method invocation to support remote procedure calls between two java applications running in different JVMs.

java.security

Support for security, including the message digest algorithm, is included in the java.security package.

java.sql

An implementation of the JDBC API (used to access SQL databases) is grouped into the java.sql package.

javax.rmi

Provides the support for the remote communication between applications, using the RMI over IIOP protocol. This protocol combines RMI and CORBA features.

org.omg.CORBA

Provides the support for the remote communication between applications using general inter ORB protocol and supports other features of the common object request broker architecture. Same as RMI and RMI-IIOP, this package is for calling remote methods of objects on other virtual machines (usually via network). From all communication possibilities CORBA is the most portable between various languages. However it is also rather difficult to understand.

javax.swing

Swing is a collection of routines that build on java.awt to provide a platform independent widget toolkit. Swing uses the 2D drawing routines to render the user interface components instead of relying on the underlying native operating system GUI support.

Swing is a very rich system in its own right, supporting pluggable looks and feels (PLAFs) so that widgets in the GUI can imitate those from the underlying native system. Design patterns permeate the system, especially a modification of the model-view-controller pattern, which loosens the coupling between function and appearance. One inconsistency is that (as of J2SE 1.3) fonts are drawn by the underlying native system, and not by Java, limiting text portability. Workarounds, such as using bitmap fonts, do exist. In general, layouts are used and keep elements within an aesthetically consistent GUI across platforms.

javax.swing.text.html.parser

Provides the error tolerant HTML parser that is used for writing various web browsers and web bots.

Java Platform, Micro Edition - J2ME

Java Platform, Micro Edition

From Wikipedia, the free encyclopedia

(Redirected from J2me)

Jump to: navigation, search

Java Platforms

Micro Edition (ME)

Standard Edition (SE)

Enterprise Edition (EE)

Java Platform, Micro Edition or Java ME (also referred to as Java 2 Platform, Micro Edition or J2ME), is a collection of Java APIs for the development of software for resource-constrained devices such as PDAs, cell phones and other consumer appliances. Java ME is formally a specification, although the term is frequently used to also refer to the runtime implementations of the specification. Java ME was developed under the Java Community Process as JSR 68. The evolution of the platform has abandoned the umbrella Java Specification Request in favor of separate JSRs for the different flavors of Java ME.

Java ME was designed by Sun Microsystems and is a replacement for a similar technology, PersonalJava. Note that Sun only provides a reference implementation and that most work targeting a non-Intel-based small device will require a vendor-supplied JVM to be available on the device.

Java ME has become a popular option for creating games for cell phones, as they can be emulated on a PC during the development stage and easily uploaded to the phone. This contrasts with the difficulty of developing, testing, and loading games for other special gaming platforms such as those made by Nintendo, Sony, and others, as expensive system-specific hardware and kits are required.

Sun Microsystems has tended not to provide free binary implementations of its Java ME runtime environment for mobile devices, rather relying on third parties to provide their own, in stark contrast to the numerous binary implementations it provides for the full Java platform standard on server and workstation machines. One of the notable omissions is for Microsoft Windows Mobile (Pocket PC) based devices, despite an open letter campaign to Sun to release a rumoured complete project "Captain America" which is such an implementation.

Contents [hide] 1 Configurations and Profiles 1.1 Connected Limited Device Configuration 1.1.1 Mobile Information Device Profile 1.1.2 Information Module Profile 1.2 Connected Device Configuration 1.2.1 Foundation Profile 1.2.2 Personal Basis Profile 1.2.3 Personal Profile 2 See also 3 External links

[edit] Configurations and Profiles

Java ME devices implement a profile. The most common of these are the Mobile Information Device Profile aimed at mobile devices, such as cell phones, and the Personal Profile aimed at consumer products and embedded devices like Set-top boxes and PDAs.

A profile is a superset of a configuration, of which there are currently two: Connected Limited Device Configuration and Connected Device Configuration.

[edit] Connected Limited Device Configuration

The CLDC contains a strict subset of the Java class libraries, and is the minimal needed for a Java virtual machine to operate. CLDC is basically used to classify myriad devices into a fixed configuration.

[edit] Mobile Information Device Profile

Designed for cell phones, MIDP boasts an LCD-oriented GUI API, and MIDP 2.0 includes a basic 2D gaming API. Applications written for this profile are called MIDlets. Almost all new cell phones come with a MIDP implementation, and it is now the de facto standard for downloadable cell phone games. However, many cellphones can run only those MIDlets that have been approved by the carrier, especially in North America.

[edit] Information Module Profile

The Information Module Profile (IMP) is a Java ME profile for embedded, "headless" devices such as vending machines, industrial embedded applications, security systems, and similar devices with either simple or no display and with some limited network connectivity.

Originally introduced by Siemens Mobile and Nokia as JSR-195, IMP 1.0 is a strict subset of MIDP 1.0 except that it doesn't include user interface APIs — in other words, it doesn't include support for the Java package javax.microedition.lcdui. JSR-228, also known as IMP-NG, is IMP's next generation that is based on MIDP 2.0, leveraging MIDP 2.0's new security and networking types and APIs, and other APIs such as PushRegistry and platformRequest(), but again it doesn't include UI APIs, nor the game API.

IMP applications are called IMlets, but in reality they are MIDlets. They subclass MIDlet, and follow the same packaging, deployment, security and life-cycle as MIDlets.

[edit] Connected Device Configuration

CDC is a subset of Java SE, containing almost all the libraries that are not GUI related. It is richer than CLDC.

[edit] Foundation Profile

A headless version of Java SE.

[edit] Personal Basis Profile

Extends the Foundation Profile to include lightweight GUI support in the form of an AWT subset.

[edit] Personal Profile

This extension of Personal Basis Profile includes a more comprehensive AWT subset and adds applet support.

[edit] See also

• Smartphone
• platform
• Mobile development — How J2ME stacks up against the alternatives on mobile platforms
• Multiplayer Mobile games
• SavaJe
• JBlend
• Doja

[edit] External links

Wikibooks Programming has more about this subject:

J2ME

• The Source for Java ME Developers (Java ME Homepage)
• Open source Mobile & Embedded Community
• The most active unofficial J2ME forum
• Unofficial j2me wiki, phone specifications included
• JSR 68
• Java ME Technical Tips
• Java ME Tips
• Search Engine for J2ME Developers
• Russian articles for J2ME developers

M-learning

M-learning
From Wikipedia, the free encyclopedia
Jump to: navigation, search

'M-learning' is the follow up of E-learning which for its part originates from D-learning (distance education). M-learning is the delivery of learning to students who are not keeping a fixed location or through the use of mobile or portable technology. The rapid growth of information and communication technologies (ICT) makes it possible to develop new forms of this education. (Georgiev, T., E.Georgieva, A.Smrikarov. M-Learning - A New Stage of E-Learning, http://ecet.ecs.ru.acad.bg/cst04/Docs/sIV/428.pdf)
Contents
[hide]

* 1 Definition
* 2 Differences between M-Learning and E-Learning
* 3 Challenges with m-learning
* 4 Organizing the content
* 5 Different communication methods
* 6 Different program languages
* 7 References
* 8 External links

[edit] Definition

M-learning is the term given to the delivery of training by means of mobile devices such as Mobile Phones, PDAs and digital audio players, as well as digital cameras and voice recorders, pen scanners etc. M-learners are seeking lessons in small, manageable formats that they can undertake when it suits them.

[edit] Differences between M-Learning and E-Learning

If e-learning took learning away from the classroom or campus, then m-learning is taking learning away from a fixed point. Where e-learning is an alternative to classroom learning (actually eLearning should/can be complementary to classroom learning) - m-learning is a complementary activity to both e-learning and traditional learning. M-learning respects that a user would like to interact with educational resources whilst away from their normal place of learning - classroom or computer.

In one sense m-learning has been around for longer than e-learning, with the paperback book and other portable resources, but technology is what shapes today's usage of m-learning. Technology now allows us to carry vast resources in our pockets and access these wherever we find convenient. Technology also allows us to interact with our peers instaneously and work together remotely in ways never before possible.

While the opportunties that m-learning devices present us with are new - the challenges are quite old, smaller screen sizes, limited processing power, reduced input capabilities. These challenges mean that adapting existing e-learning services and content to m-learning is not a trivial task.

m-Learning has been gaining appeal among younger generations who have grown up using portable video game devices and wireless technology. In this sense, mLearning appeals not only to those who need learning portable, but to those who have grown up with a cognitive disposition towards using mobile devices- whether or not they have the need for true portability in their learning.

[edit] Challenges with m-learning

The connectivity is one of the main differences if we compare a mobile device with the PC (the usual medium for delivering e-learning). Nowadays mobile devices might be connected to ‘The Net’ via many technologies – WAP, GPRS, UMTS, Bluetooth, WiFi, etc. Although it is predictable that in the future the ‘always on’ will be wide spread still it is not the case. Mobile devices often have periods of disconnection, either intentionally (when the connection is too expensive) or not (when no infrastructure is provided).

Devices’ hardware and software characteristics have a big impact on what content is possible and meaningful to be delivered. Usually the web content is designed for desktop PCs, thus unpleasant and even rarely useful from a small-screened device. Nowadays mobile phones are rapidly becoming increasingly powerful (both from hardware and software point of view) however their screens will remain comparatively small. Often also the navigation is hard. Equipped with a small phone-style keyboard or a touch-screen (for the PDAs) the users might lose more time in searching where on the page the information they need is than in reading it. We can imagine alternative ways of navigation, for example voice commands. The memory available on a mobile device is also relatively small. It is possible to use extension packs on some devices like PDAs, which reduces some of the restrictions.

Devices such as the Nintendo DS raise the bar even higher by providing collaborative gaming. The Nokia N-Gage brings an expandable platform of gaming and mobile communications to the forefront.

mp3 players and other portable media devices have also come into the forefront of the mLearning trend with companies using these devices to deploy education to their 'road warrior' sales teams through podcasts or videocasts.

Location is a new thing to be considered. Although up to now we are talking only about limitations confronting m-learning and e-learning, there are also advantages. The small size of the device and the wireless connections make them available anytime and anywhere. The mobility opens variety of new scenarios. Services involving location-discovery are, for example, receiving directions on how to get to a certain room, or alerts for seminars/lectures that can be triggered while taking into consideration the current place and the time to get to the needed destination; location-aware printing of the learning content, etc.

Source: Copied rather too directly from Trifonova A., Ronchetti M. (2004). "A General Architecture to Support Mobility in Learning". Proc. of ICALT 2004 [IEEE Computer Society Press 2004, ISBN 0-7695-2181-9]. pp. 26-30 [1]

[edit] Organizing the content
To meet Wikipedia's quality standards, this section may require cleanup.
Please discuss this issue on the talk page, and/or replace this tag with a more specific message. Editing help is available.
This section has been tagged since May 2006.

* For whom do we develop a M-learning environment?
* What is the educational information we need to provide?
* How do we develop the structure?
* For which mobile devices do we develop?
* Which tools / software do we use? For creating? To present?

for instance the software cannt be edited from the mobiles

[edit] Different communication methods

* Text Message / SMS
* WAP Wireless Application Protocol
* GPRS
* Bluetooth
* WLAN / Wifi
* IrDA

[edit] Different program languages

* C++
* Java (J2ME)
* Flash Lite
* .NET Framework
* HTML
* WAP (WML, XML)
* Python
* LMA

[edit] References

* L Low & M O'Connell, Learner-Centric Design of Digital Mobile Learning, Queensland University of Technology, 2006.
* Sharma, S., F.Kitchens. Web Services Architecture for M-Learning, Electronic Journal on e-Learning, Vol.2, Issue 1, 2004.
* T Georgiev, E Georgieva, A Smrikarov - Proceedings of the 5th international conference on Computer Systems and Technologies - CompSysTech'2004. http://ecet.ecs.ru.acad.bg/cst04/Docs/sIV/428.pdf
* A Trifonova, M Ronchetti. A General Architecture to Support Mobility in Learning. Proc. of the 4th IEEE ICALT 2004
* B Sanregret, Hot Lava Software, MLearning Basics 2005
* T Toth. Technology for Trainers, ASTD Press 2003
* D. McPhee and N. Thomas, "Evaluating the effectiveness of m-Learning in the teaching of multi-media to first year university students”, iJET International Journal of Emerging Technologies in Learning" Vol 1. 2006

[edit] External links

* EU project: Incorporating Mobile Learning Into Mainstream Education
* EU project: Mobile Learning: The Next Generation Of Learning
* Zimbio's mLearning group Wiki
* mLearning devices
* M-learning : home
* MOBIlearn : home
* mLearning World
* M-Learning News Latest developments in mobile learning
* M-learning and video streaming
* m-Learning project in Sweden- Academic
* PocketEd M-learning program at Coastline College Associate Degree PocketEd Program for military personnel
* Portal de m-learning en Español
* The Math4Mobile Project Mathematics for Mobile Phones
* Mobile Education Center of Excellence Mobile Learning Project at the University of Hagen / Germany

Symbian OS

From Wikipedia, the free encyclopedia

Jump to: navigation, search

Symbian OS

Website:	http://www.symbian.com
Company/ developer:	Symbian Ltd.
Source model:	Shared
Supported platforms:	ARM, x86
Kernel type:	Real time
Default user interface:	Series 60, UIQ
Working state:	Current

Symbian OS is an operating system, designed for mobile devices, with associated libraries, user interface frameworks and reference implementations of common tools, produced by Symbian Ltd. It is a descendant of Psion's EPOC and runs exclusively on ARM processors.

Symbian is currently owned by Ericsson (15.6%), Nokia (47.9%), Panasonic (10.5%), Samsung (4.5%), Siemens AG (8.4%), and Sony Ericsson (13.1%). Whilst BenQ has acquired the mobile phone subsidiary of Siemens AG the Siemens AG stake in Symbian does not automatically pass to BenQ - this will need the approval of the Symbian Supervisory Board.

Contents [hide] 1 Design 2 Competition 3 Structure 4 History 5 Open Source Software for Symbian 9.1 6 Security and Malware 7 Openness 8 Devices that have used the Symbian OS 9 Developing on Symbian OS 10 See also 11 Notes 12 Sources 13 External links

[edit] Design

Symbian OS, with its roots in Psion Software's EPOC is structured like many desktop operating systems, with pre-emptive multitasking, multithreading, and memory protection.

Symbian OS's major advantage is the fact that it was built for handheld devices, with limited resources, that may be running for months or years. There is a strong emphasis on conserving memory, using Symbian-specific programming idioms such as descriptors and a cleanup stack. Together with other techniques, these keep memory usage low and memory leaks rare. There are similar techniques for conserving disk space (though the disks on Symbian devices are usually flash memory). Furthermore, all Symbian OS programming is event-based, and the CPU is switched off when applications are not directly dealing with an event. This is achieved through a programming idiom called active objects. Correct use of these techniques helps ensure longer battery life.

All of this makes Symbian OS's flavour of C++^{[citation needed]} very specialised, with a gradual learning curve^{[citation needed]}. However, many Symbian OS devices can also be programmed in OPL, Python, Visual Basic, Simkin, and Perl - together with the Java ME and PersonalJava flavours of Java.

There are a number of smartphone user interface platforms based on Symbian OS, including open platforms UIQ, Nokia's Series 60, Series 80 and Series 90 and closed platforms such as that developed for NTT DoCoMo's FOMA handsets. This adaptability allows Symbian OS to be used on smartphones with a variety of form factors (e.g. clam-shell or "monoblock"/"candybar", keypad- or pen-driven).

[edit] Competition

The neutrality of this article is disputed. Please see the discussion on the talk page.

Symbian OS is often seen as competing with other mobile operating systems, such as Windows Mobile, Palm OS, and Linux. It primarily competes with the embedded operating systems^{[citation needed]} used on lower-end phones, such as NOS and OSE, which tend to be maintained by the phone companies themselves. SymbianOS, like its smartphone competition, has long been encumbered by the need for two processor cores in order that it can ensure separation between the mobile network and the user's applications. This means that SymbianOS phones have tended to be larger, heavier, more expensive and less power-efficient^{[citation needed]} than featurephones with similar capabilities. Symbian OS' major advantage over the embedded operating systems used in featurephones is its modularity - there is runtime linking between dynamically linked shared libraries (DLLs, see dynamic linking) on the device, and an emphasis on plug-in architectures. This makes complex phones quicker to develop^{[citation needed]}, though this is sometimes offset by the complexity of Symbian OS C++ and the awkwardness of going to another company for an OS (instead of doing it in-house).

The advantages over other OS's such as Linux or Windows Mobile are more debatable. Phone vendors and network operators like the customisability of Symbian OS relative to Windows^{[citation needed]}. This customisability, though, makes integrating a Symbian OS phone more difficult. It's possible that Linux goes too far in the other direction^{[citation needed]}, and is simply too hard to make a phone from at the moment (a fact that may change with Trolltech's introduction of the Greenphone). Symbian OS's ground-up design for mobile devices should make it more power-and memory-efficient^{[citation needed]}, as well as being flexible.

SymbianOS EKA2 also supports hard enough real-time operation that it is possible to build a single-core phone around it- that is, a phone in which a single processor core executes both the user applications and the signalling stack. This is not a feature that is available from Linux or Windows CE. This has allowed SymbianOS EKA2 phones to become smaller, cheaper and more power efficient.

Recently published statistics show that Symbian OS has a 67% share of the 'smart mobile device' market, with Microsoft having 15% and RIM having 6%. ^[1]

[edit] Structure

At its lowest level sit the base components of Symbian OS. This includes the kernel (EKA1 or EKA2 - see the 'History' section), along with the user library which allows user-side applications to request things of the kernel. Symbian OS has a microkernel architecture, which means that the minimum necessary is within the kernel. It contains a scheduler and memory management, but no networking or filesystem support. These things are provided by user-side servers. The base layer includes the file server, which provides a fairly DOS-like view of the filesystems on the device (each drive has a drive letter, and backslashes are used as the directory delimiter). Symbian OS supports various filesystem types including FAT32 and Symbian OS-specific NOR flash filing systems. The filesystem is generally not exposed to the user through the phone user interface.

Immediately above base are a selection of system libraries. These take all shapes and sizes, including for example character set conversion, a DBMS database, and resource file handling.

Further up, the software is not so readily arranged into a stack.

This article or section is not written in the formal tone expected of an encyclopedia article.
Please improve it or discuss changes on the talk page. See Wikipedia's guide to writing better articles for suggestions.

There is a large networking and communication subsystem, which has three main servers - ETEL (EPOC telephony), ESOCK (EPOC sockets) and C32 (responsible for serial communication). Each of these has a plug-in scheme. For example ESOCK allows different ".PRT" protocol modules, implementing different types of networking protocol scheme. There's lots of stuff relating to short-range communication links too, such as Bluetooth, IrDA and USB.

There's also a large amount of user interface code. Even though the user interfaces themselves are maintained by other parties, the base classes and substructure ("UIKON") for all UIs are present in Symbian OS, along with certain related servers (for example, a view server which controls transitions between different phone user interface screens). There's a lot of related graphics code too - such as a window server and a font and bitmap server.

An application architecture provides for standard application types, embedding, and file and data recognition. There is also a selection of application engines for popular smartphone applications such as calendars, address books, and task lists. A typical Symbian OS application is split up into an engine DLL and a graphical application - the application being a thin wrapper over the engine DLL. Symbian OS provides some of these engine DLLs.

There are, of course, many other things that don't yet fit into this model - for example, SyncML, Java ME providing another set of APIs on top of most of the OS and multimedia. Quite a few of these things are frameworks, and vendors are expected to supply plug-ins to these frameworks from third parties (for example, Helix player for multimedia codecs). This has the advantage that the APIs to such areas of functionality are the same on many phone models, and that vendors get a lot of flexibility, but means that phone vendors need to do a great deal of integration work to make a Symbian OS phone.

Symbian OS device manufacturers also get supplied with an example user interface layer called TechView. This is very similar to the user interface from a Psion Series 5 personal organiser, so isn't particularly similar to any given phone user interface, but provides a basis to start customisation. It is also the environment in which a lot of Symbian OS test code and example code runs.

[edit] History

In 1980, Psion was founded by David Potter.

EPOC16. Psion released several Series 3 devices from 1991 to 1998 which used the EPOC16 OS, also known as SIBO.

EPOC OS Releases 1–3. The Series 5 device, released in 1997, used the first iterations of the EPOC32 OS.

EPOC Release 4. Oregon Osaris and Geofox 1 were released using ER4.

In 1998, Symbian Ltd. was formed as a partnership between Ericsson, Nokia, Motorola and Psion, to explore the convergence between PDAs and mobile phones.

EPOC Release 5 a.k.a. Symbian OS v5. Psion Series 5mx, Series 7, Psion Revo, Psion Netbook, netPad, Ericsson MC218 were released in 1999 using ER5.

ER5u a.k.a. Symbian OS v5.1. u = Unicode. The first phone, the Ericsson R380 was released using ER5u in 2000. It was not an 'open' phone - software could not be installed. Notably, a number of never released Psion prototypes for next generation PDAs, including a Bluetooth Revo successor codenamed Conan were using ER5u.

Symbian OS v6.0 and v6.1. Sometimes called ER6. The first 'open' Symbian OS phone, the Nokia 9210, was released on 6.0.

Symbian OS v7.0 and v7.0s. First shipped in 2003. This is an important Symbian release which appeared with all contemporary user interfaces including UIQ (Sony Ericsson P800, P900, P910, Motorola A925, A1000), Series 80 (Nokia 9300, 9500), Series 90 (Nokia 7710), Series 60 (Nokia 6600, 7310) as well as several FOMA phones in Japan.

In 2004, Psion sold its stake in Symbian.

Also in 2004, the first worm for mobile phones using Symbian OS, Cabir, was developed, which used Bluetooth to spread itself to nearby phones. See Cabir and Symbian OS threats.

Symbian OS v8.0. First shipped in 2004, one of its advantages would have been a choice of two different kernels (EKA1 or EKA2). However, the EKA2 kernel version did not ship until SymbianOS v8.1b. The kernels behave more or less identically from user-side, but are internally very different. EKA1 was chosen by some manufacturers to maintain compatibility with old device drivers, whilst EKA2 offered advantages such as a hard real-time capability. v8.0b was deproductized in 2003.

Symbian OS v8.1. Basically a cleaned-up version of 8.0, this was available in 8.1a and 8.1b versions, with EKA1 and EKA2 kernels respectively. The 8.1b version, with EKA2's single-chip phone support but no additional security layer, was popular among Japanese phone companies desiring the realtime support but not allowing open application installation.

Symbian OS v9.0. This version was used for internal Symbian purposes only. It was deproductised in 2004. v9.0 marked the end of the road for EKA1. v8.1a is the final EKA1 version of SymbianOS.

Symbian OS has generally maintained reasonable binary compatibility. In theory the OS was BC from ER1-ER5, then from 6.0 to 8.1b. Substantial changes were needed for 9.0, related to tools and security, but this should be a one-off event. The move from requiring ARMv4 to requiring ARMv5 did not break backwards compatibility.

A Symbian developer proclaims that porting from Symbian 8.x to Symbian 9.x is a more daunting process than Symbian says. ^[2]

Symbian OS v9.1 released early 2005. It includes many new security related features, particularly a controversial platform security module facilitating mandatory code signing. Symbian argues that applications and content, and therefore a developers investment, are better protected than ever, however others contend that the requirement that every application be signed (and thus approved) violates the rights of the end-user, the owner of the phone, and limits the amount of free software available. The new ARM EABI binary model means developers need to retool and the security changes mean they may have to recode. S60 3rd Edition phones have Symbian OS 9.1. Sony Ericsson is shipping the M600i based on Symbian OS 9.1 and should ship the P990 in Q3 2006. The earlier versions had a fatal defect where the phone hangs temporarily after the owner sent hundreds of SMSes. However, on 13 September 2006, Nokia releases a small program to fix this defect^[3].

Symbian OS v9.2 released Q1 2006. Support for Bluetooth 2.0 (was 1.2) and OMA Device Management 1.2 (was 1.1.2). S60 3rd Edition Feature Pack 1 phones have Symbian OS 9.2.

Symbian OS v9.3 released on 12 July 2006. Upgrades include native support for Wifi 802.11, HSDPA, Vietnamese language support.

On November 16, 2006, the 100 millionth smartphone running the OS was shipped. ^[4]

[edit] Open Source Software for Symbian 9.1

The following Open Source software has been rewritten for Symbian 9.1:

• Utilities:
  • PuTTY
  • Internet Radio
  • Ruby Programming Language
  • SymTorrent
  • Symella
  • Python interpreter
  • Apache HTTP Server

• Game emulation:
  • ScummVM (Currently only a very early port is available)

[edit] Security and Malware

Symbian OS has been subject to a variety of viruses, the best known of which is Cabir. Usually these send themselves from phone to phone by Bluetooth. So far, none have taken advantage of any flaws in Symbian OS - instead, they have all asked the user whether they would like to install the software, with somewhat prominent warnings that it can't be trusted.

However, of course, the average mobile phone user shouldn't have to worry about such things, so Symbian OS 9 is adopting a capability model. Installed software will theoretically be unable to do damaging things (such as costing the user money by sending network data) without being digitally signed - thus making it traceable. Developers can apply to have their software signed via the Symbian Signed program. Developers also have the option of self-signing their programs.

Some other hostile programs are listed below, but all of them still require the input of the user to run.

• Drever.A is a malicious SIS file trojan that attempts to disable the automatic startup from Simworks and Kaspersky Symbian Anti-Virus applications.

• Locknut.B is a malicious SIS file trojan that pretends to be patch for Symbian Series 60 mobile phones. When installed, it drops a binary that will crash a critical system service component. This will prevent any application from being launched in the phone.

• Mabir.A is basically Cabir with added MMS functionality. The two are written by the same author, and the code shares many similarities. It spreads using Bluetooth via the same routine as early variants of Cabir. As Mabir.A activates it will search for the first phone it finds, and starts sending copies of itself to that phone.

• Frontal.A is a SIS file trojan that installs a corrupted file which causes the phone to fail at reboot. If the user tries to reboot the infected phone, it will be permanently stuck on the reboot, and cannot be used without disinfectation - that is, the use of the reformat key combination which causes the phone to lose all data. Being a trojan, Frontal.A cannot spread by itself - the most likely way for the user to get infected would be to acquire the file from untrusted sources, and then install it to the phone, inadvertently or otherwise.

[edit] Openness

A common question is whether Symbian OS is "open". It is not open in the sense of Open Source software - the source code is not publicly available. However, nearly all the source code is provided to Symbian OS phone manufacturers and many other partners. Moreover, the APIs are publicly documented and anyone can develop software for Symbian OS. This contrasts with traditional embedded phone operating systems, which typically cannot accept any aftermarket software with the exception of Java applications.

Symbian is also open in terms of the Open Standards it supports.

[edit] Devices that have used the Symbian OS

• Ericsson R380 (2000) was the first commercially available phone based on Symbian OS. As with the modern "FOMA" phones, this device was closed, and the user could not install new C++ applications. Unlike those, however, the R380 could not even run Java applications, and for this reason, some have questioned whether it can properly be termed a 'smartphone'.
• Nokia 9210 Communicator smartphone (32-bit 66 MHz ARM9-based RISC CPU) (2001), 9300 Communicator (2004), 9500 Communicator (2004) using the Nokia Series 80 interface
• UIQ interface:
  • Used for PDAs such as Sony Ericsson P800 (2002), P900 (2003), P910 (2004), P990, W950, M600, Motorola A920, A925, A1000, DoCoMo M1000, BenQ P30, P31 and Nokia 6708 using this interface.
• Nokia S60 (2002)
  • Nokia Series 60 is used in various phones, the first being the Nokia 7650, then the Nokia 3650, followed by the Nokia 3620/3660, Nokia 6600, Nokia 7610, Nokia 6670 and Nokia 3230. The Nokia N-Gage and Nokia N-Gage QD gaming/smartphone combos are also Series 60 platform devices. It was also used on other manufacturers' phones such as the Siemens SX1, Sendo X, Panasonic X700, Panasonic X800, Samsung SGH-D730, SGH-D720 and the Samsung SGH-Z600. Recent, more advanced devices using Series 60 include the Nokia 6620, Nokia 6630, the Nokia 6680, Nokia 6681 and Nokia 6682, a next generation N series, including the Nokia N70, Nokia N80, Nokia N90, Nokia N91, Nokia N92 and Nokia N93, and the enterprise (ie business) model E series, including the Nokia E60, Nokia E61, and Nokia E70. For an up to date list, refer to the Symbian Series 60 website.^[5]
• Nokia 7710 (2004) using the Nokia Series 90 interface.
• Fujitsu, Mitsubishi, Sony Ericsson and Sharp phones for NTT DoCoMo in Japan, using an interface developed specifically for DoCoMo's FOMA "Freedom of Mobile Access" network brand. This UI platform is called MOAP "Mobile Orientated Applications Platform" and is based on the UI from earlier Fujitsu FOMA models.

[edit] Developing on Symbian OS

There are multiple platforms, based upon Symbian OS, that provide an SDK for application developers wishing to target a Symbian OS device - the main ones being UIQ, Series 60, etc. Individual phone products, or families, often have SDKs or SDK extensions downloadable from the manufacturer's website too. The SDKs contain documentation, the header files and library files required to build Symbian OS software, and a Windows-based emulator ("WINS"). Up until Symbian OS version 8, the SDKs also included a version of the GCC compiler (a cross-compiler) required to build software to work on the device.

Symbian OS 9 uses a new ABI and so requires a new compiler - a choice of compilers is available including a new version of GCC (see external links below). In terms of SDKs, UIQ Technology now provides a simplified framework so that the single UIQ SDK forms the basis for developing on all UIQ 3 devices, such as the Sony Ericsson P990 and Sony Ericsson M600.

Symbian C++ programming is commonly done with a commercial IDE. For current versions of Symbian OS, CodeWarrior for Symbian OS is favoured. The CodeWarrior tools will be replaced during 2006 by Carbide.c++, an Eclipse-based IDE developed by Nokia. It is expected that Carbide.c++ will be offered in different versions: a free version may allow users to prototype software on the emulator for the first time in a free product.

Visual Basic, VB.NET, and C# development for Symbian can be accomplished through AppForge Crossfire, a plugin for Microsoft Visual Studio.

There's also a version of a Borland IDE for Symbian OS. Symbian OS development is also possible on Linux and Mac OS X using tools and techniques developed by the community, partly enabled by Symbian releasing the source code for key tools. A plugin that allows development of Symbian OS applications in Apple's Xcode IDE for Mac OS X is available. ^[6]

Once developed, Symbian OS applications need to find a route to customers' mobile phones. They are packaged in SIS files which may be installed over-the-air, via PC connect or in some cases via Bluetooth or memory cards. An alternative is to partner with a phone manufacturer to have the software included on the phone itself. The SIS file route will be a little more difficult from Symbian OS 9, because any application wishing to have any capabilities beyond the bare minimum must be signed via the Symbian Signed^[7] program.

Java ME applications for Symbian OS are developed using standard techniques and tools such as the Sun Java Wireless Toolkit (formerly the J2ME Wireless Toolkit). They are packaged as JAR (and possibly JAD) files. Both CLDC and CDC applications can be created with NetBeans. Other tools include SuperWaba, which can be used to build Symbian 7.0 and 7.0s programs using Java.

Nokia Series 60 phones can also run python scripts when the interpeter is installed, with a custom made API that allows for Bluetooth support and such. There is also an interactive console to allow the user to write python scripts directly from the phone.

[edit] See also

• Smartphone
• Smartmovie - A Symbian App to Watch DIVX/Xvid on your Phone
• Operating System Embedded (OSE)
• Multiplayer Mobile games
• Nokia OS (NOS)
• Palm OS
• Windows Mobile
• S60 Platform

[edit] Notes

1. ^ http://www.canalys.com/pr/2006/r2006071.htm
2. ^ Symbian developer reports on porting from 8.x to 9.x
3. ^ Solution to Nokia Slow SMS / Hang Problem
4. ^ http://www.thesmartpda.com/50226711/six_years_of_symbian_produces_100_models_and_100_million_shipments.php
5. ^ Symbian series 60 phones
6. ^ Tom Sutcliffe and Jason Barrie Morley Xcode Symbian support
7. ^ Symbian Signed

[edit] Sources

• History of OPL
• History of Symbian, 1980-2004
• Symbian Software,Ringtone, Themes

[edit] External links

• Symbian official sites
  • Symbian Company Website including release history
  • Symbian Signed, an application signing and verification process
• DMOZ directory of Symbian software
• DMOZ directory of Symbian sites
  • All About Symbian News and information site for Symbian OS powered phones with active forum
  • SymbianOne.com An active Community portal for mobile developers, device makers, and carriers interested in symbian devices
  • My-Symbian Symbian OS Communicators and Smartphones Info Center, with active discussion forum
  • Symbian OS OpenSource Community Center, This site is dedicated to the development of Open Source programs for SymbianOS.
• Symbian Example A collection of compilable code examples for the Symbian OS
• Symbian OS Unit An open-source unit testing framework for Symbian OS devleopment.
• NewLC A Symbian C++ developer portal with news, forums, tutorials and more
• Symbware Directory of freeware and open source software for Symbian OS.
• Symbian Freak Website for smartphone users, with a smart phone discussion forum
• Symbian Watch Symbian blog.
• Symbian Wiki
• Nokia Symbian Mobile Softwares and Themes
• Carbide.c++ is an Eclipse-based IDE for Symbian C++ development, developed by Nokia. Available in 2006
• Python for Series 60
• Mobilab.ru - Russian site about Symbian C++ development