Native Apps - Dr. Feda A. AlShahwan

Download Report

Transcript Native Apps - Dr. Feda A. AlShahwan

Selected Topics in Computer
Engineering
ENC-360
Dr. Feda AlShahwan
Computer Section
Electronic Engineering Department
College of Technological Studies
Public Authority for Applied Education and Training
@Feda AlShahwan
1
Chapter 2
Mobile Applications
Mobile Applications:
• Computer programs that are designed and developed to run on small
wireless mobile devices
Mobile Apps Development:
• Developing apps for mobile devices requires considering the constraints and
demands of the devices and also taking advantage of the capabilities and
features of these devices. Mobile devices run on battery, have limited
storage capacity and have less powerful processors than personal
computers and also have more features such as location detection and
cameras. . Moreover, a gaming app, for example, might take advantage of
the iPhone's accelerometer.
• Developers also have to consider a wide array of screen sizes, hardware
specifications and configurations because of intense competition in mobile
software and changes within each of the platforms.
• Mobile application development requires use of specialized integrated
development environments.
• Mobile apps are first tested within the development environment using
emulators and later subjected to field testing. Emulators provide an
inexpensive way to test applications on mobile phones to which developers
may not have physical access.
2
Chapter 2
Mobile Applications
Mobile User Interface Development:
• As part of the development process, Mobile User Interface (UI) Design is
also an essential in the creation of mobile apps. Mobile UI considers
constraints & contexts, screen, input and mobility as outlines for design. The
user is often the focus of interaction with their device, and the interface
entails components of both hardware and software. User input allows for
the users to manipulate a system, and device's output allows the system to
indicate the effects of the users' manipulation. Mobile UI design constraints
include limited form factors, such as a mobile device's screen size for a
user's hand(s). Mobile UI contexts signal cues from user activity, such as
location and scheduling that can be shown from user interactions within a
mobile application. Overall, mobile UI design's goal is primarily for an
understandable, user-friendly interface. The UI of mobile apps should:
consider users' limited form factor, minimize keystrokes, and be taskoriented with a minimum set of functions.
3
Chapter 2
Types of Mobile Applications
Types of Mobile Applications:
Mobile apps are categorized to : Web-based, native apps or hybrid apps.
Native Apps:
•
•
•
•
•
•
•
A native application (native app) is an application program that has been
developed for use on a particular platform or device.
The term "native app" is often mentioned in the context of mobile computing
because mobile applications have traditionally been written to work on a specific
device platform (Apple’s iOS, Google’s Android, Windows Phone or (decreasingly)
BlackBerry OS). A native app is installed directly on a mobile device and
developers create a separate app version for each mobile device.
The native app may be stored on the mobile device out of the box, or it can be
downloaded from an online store or marketplace such as the App Store or
Android Apps on Google Play and installed on the mobile device. Data associated
with the native app is also stored on the device, although data can be stored
remotely and accessed by the native app.
Depending on the nature of the native app, Internet connectivity may not be
required.
Examples of native apps are Camera+ for iOS devices and KeePassDroid for
Android devices.
Ingress is an example of native apps, which is available only in the Google Play
Store, it uses multiple hardware functions on your device, and its interface exists
independently from a web browser.
Another good example of a native app would be Instagram. Although this app is
available on both Android and iOS operating
systems, each variant is unique to its
@Feda AlShahwan
OS, and incompatible with any other system.
Chapter 2
Types of Mobile Applications
Native Apps:
•
There are different programming languages and developing tools for each
platform
– If building for Apple’s iOS, your developer will need to use the Objective-C
language—one of the hardest programming languages to master, even for
professionals with experience. The good news is that Apple provides its
developer community with very good tools. The main one, Xcode, is the tool your
developer will use to create your native app.
– Building for Android requires Java. Java is a more common language than
Objective-C and has less of a learning curve, so it’s not as challenging to find
proven developers. However, the tools available to create apps for Android—
including the most popular tool, Eclipse—aren’t as good as Xcode; but a new tool
called Android Studio could eventually deliver the same quality of development
support as Apple’s tool.
– Windows Phone, while still more popular than BlackBerry, is back in third place.
However, it’s strongly supported by Microsoft and is particularly worth
considering if building an enterprise app. Apps for Windows Phone are made
using the C# or VB.NET languages. Microsoft’s Visual Studio is a great tool for
building an app—it’s probably the most developer-friendly of the three main
platforms.
@Feda AlShahwan
Chapter 2
Types of Mobile Applications
•
•
•
•
•
If a computer application program is compiled to run with a particular processor
and its set of instructions, the result can be referred to as native code . If the
same program is run on a computer with a different processor, software can be
provided so that the computer emulates the old processor. In this case, the same
application runs in "emulation mode" and almost certainly more slowly than in
native mode on the original processor. (The application can be rewritten and
recompiled so that it runs on the new processor in native mode.)
Minimal computational overhead and additional components.
Because native apps are written for a specific platform, they can interact with
and take advantage of operating system features and other software that is
typically installed on that platform.
Because a native app is built for a particular device and its operating system, it
has the ability to use device-specific hardware and software, meaning that native
apps can take advantage of the latest technology available on mobile devices
such as a global positioning system (GPS) and camera. This can be construed as
an advantage for native apps over Web apps or mobile cloud apps.
The principal advantage of a native app is that it is fast and the app will operate
more quickly because native app requires compilation, which is faster than
interpretation. Moreover, it is developed for a specific platform.
@Feda AlShahwan
Chapter 2
What is Interpreted Software:
•
•
•
An interpreted language is a programming language for which most of
its implementations execute instructions directly, without previously
compiling a program into machine-language instructions. The
interpreter executes the program directly, translating each statement
into a sequence of one or more subroutines already compiled into
machine code.
Does not produce native binary code; at least not in general. Instead, an
interpreter converts a program to an intermediate representation,
usually a tree, and uses an algorithm to traverse this tree emulating the
semantics of each of its nodes.
With interpreted languages, the code is saved in the same format that
you entered.
@Feda AlShahwan
Chapter 2
Native vs Interpreted Software
• Native software need to be compiled to run in a mobile system
– Often relies on APIs defined in the system
– Compiled programs generally run faster than interpreted ones because
interpreted programs must be reduced to machine instructions at
runtime.
– … Therefore well-suited in situations when developing the system on
top of well-formalized and documented platform?
• Interpreted software requires an interpreter that executes a
downloaded program
– Often requires APIs defined in language standard
– Can modify themselves by adding or changing functions at runtime. It is
also usually easier to develop applications in an interpreted
environment because you do not have to recompile your application
each time you want to test a small section.
– … Therefore well-suited in situations where software downloading
support is added to a proprietary system that does not have a clean
architecture, static APIs, memory protection, etc.
@Feda AlShahwan
Chapter 2
Types of Mobile Applications
Web Apps:
•
A Web application (Web app) is an application program that is stored on a
remote server and delivered over the Internet through a browser interface.
• Web applications are generalized for multiple platforms and not installed locally
but made available over the Internet through a browser.
• They require internet connectivity.
• Mobile web apps are Internet-enabled apps that have specific functionality for
mobile devices. They are accessed through the mobile device’s web browser (i.e.
on the iPhone, this is Safari by default) and they do not need to be downloaded
and installed on the device.
Hybrid Apps:
• Hybrid application is one that combines elements of both native and Web
applications.
• Most applications could be considered hybrid apps. Web apps, such as online
banking services, typically store some content locally; The iOS Facebook app is a
hybrid, it uses Three20 as the core UI along with the Facebook SDK but HTML5
for feeds.
• There are actually three types of web apps: traditional, responsive and adaptive.
• Traditional web apps include any website.
• A responsive web app takes on a different design when it’s opened on a mobile
device (i.e. phone or tablet), altering its design to suit the device it is viewed on.
• An adaptive web app, in contrast, doesn’t change its design. It will display the
same design, but will adjust it to fit the different screen size of a mobile device.
@Feda AlShahwan
Chapter 2
Types of Mobile Applications
Hybrid Apps:
• A ready example of a responsive web app is the oDesk
blog. Below, you can see the tablet view on the left
and the mobile view on the right.
@Feda AlShahwan
Chapter 2
Types of Mobile Applications
Hybrid application features:
• The biggest benefit of web apps is that they are built using the
most popular programming languages—so developer talent is
readily available.
• Can function whether or not the device is connected.
• Faster and easier to develop.
• Easier to maintain and you can change platforms.
• The app itself will not be as fast as a native app as it still depends
on the browser speed.
• Integration with a device’s file system.
• Integration with Web-based services.
• An embedded browser to improve access to dynamic online
content.
However, a responsive web app has two principal drawbacks:
• It can not use any hardware on a device (i.e. an iPhone’s camera)
• Its “discoverability” will be reduced because it will not be in any
app stores.
@Feda AlShahwan
Chapter 2
Comparison between Web-based and
Native Mobile Apps
Comparison of Native App vs. Mobile Web App
Comparison Factors:
• User interface
• Development
• Capabilities
• Method of delivery
• Versioning of the app
• Strengths
• Weaknesses
@Feda AlShahwan
Chapter 2
Comparison between Web-based and
Native Mobile Apps
User Interface
• Some companies choose to develop both a native app and a mobile
web app. Here’s a side-by-side look at Facebook’s native app and mobile
web app:
•
Notice that, in terms of the general look-and-feel, there’s little
difference between the two, making for a consistent user experience.
@Feda AlShahwan
Chapter 2
Comparison between Web-based and
Native Mobile Apps
Development
Native Apps
Web Apps
Each mobile application
development platform (e.g. iOS,
Android) requires its own
development process
Runs in the mobile device’s web
browser and each may have its
own features
Each mobile application
development platform has its own
native programming language:
Java (Android), Objective-C (iOS),
and Visual C++ (Windows Mobile),
etc.
Mobile web apps are written in
HTML5, CSS3, JavaScript and
server-side languages or web
application frameworks of the
developer’s choice (e.g. PHP, Rails,
Python)
Standardized software
development kits (SDKs),
development tools and common
user interface elements (buttons,
text input fields, etc.) are often
provided by the manufacturer of
the platform
There are no standard software
development kits (SDKs) that
developers are required to use to
make a mobile web app
@Feda AlShahwan
Chapter 2
Comparison between Web-based and
Native Mobile Apps
Method of Delivery
Native Apps
Web Apps
Downloaded onto a mobile device
Accessed through a mobile
device’s web browser
Installed and runs as a standalone
application (no web browser
needed)
No need to install new software
Users must manually download
and install app updates
Updates are made to the web
server without user intervention
There are stores and marketplaces
to help users find your app
Since there is no app store for the
Mobile Web, it can be harder for
users to find your app
@Feda AlShahwan
Versioning of the app
Chapter 2
Comparison between Web-based and
Native Mobile Apps
Native Apps
Web Apps
Some users may choose to ignore
an update, resulting in different
users running different versions of
the app
All users are on the same version
Strengths
Native Apps
Web Apps
Typically perform faster than
mobile web apps
Have a common code base across
all platforms
App stores and marketplaces help
users find native apps
Users do not have to go to a store
or marketplace, download the app
and install the app
App store approval processes can
help assure users of the quality
and safety of the app
Can be released in any form and
any time as there is not an app
store that has to approve the app
@Feda AlShahwan
Chapter 2
Comparison between Web-based and Native
Mobile Apps
Weakness
Native Apps
Web Apps
Are typically more expensive to
develop, especially if you’re supporting
multiple mobile devices
Mobile web apps can’t access all of the
device’s features (yet)
Supporting multiple platforms requires
maintaining multiple code bases and
can result in higher costs in
development, maintenance, pushing
out updates, etc.
Supporting multiple mobile web
browsers can result in higher costs in
development and maintenance, etc.
Users can be on different versions and
can make your app harder to maintain
and provide support for
Users can be on different mobile
browsers and can make your app
harder to maintain and provide support
for
App store approval processes can delay
the launch of the app or prevent the
release of the app
For users, it may be harder to find a
mobile web app because of the lack of
a centralized app store (though listings
do exist such as Apple’s Web apps and
you can request to be listed in them)
@Feda AlShahwan
Chapter 2
Symbian
• Backed by Nokia, Sony Ericsson, Motorola, Panasonic,
Psion, Siemens, many more
• C++
• Runs on ARM
• OO design, well-established architectural principles,
programming style aiming at easing mobile systems
development
• Event driven, micro-kernel design
• Pre-emptive multi-tasking system
• Good power management
• Runs from ROM
• Rich middleware
@Feda AlShahwan
Symbian overview
Application
Protocols
Application
Application
Engines
Engines
Application Services
Application
Framework
MIDP
WAP
Browser
Messaging
WAP
Stack
Narrow
Band
Protocols
Multimedia
JavaPhone
Java
Infrared
Bluetooth
Networking
Comms Infrastructure
Base
Graphics
Security
Serial Comms
Telephony
19
Chapter 2
Platform
Java:
• Interpreted byte code
• Virtual machine, Configuration (CLDC 1.0>CLDC 1.1), Profile (MIDP 1.0->2.0)
• Intended as an add-on
• Enables sandbox security, MIDP 2.0 also
introducing digital signatures and rights
categories
@Feda AlShahwan
Chapter 2
Platform
• Small size, fits in low-end mobile phones
• An important add-on to many systems that
have other main programming support
• SavaJe – an all-Java mobile platform
• Further info: www.sun.com/java
@Feda AlShahwan

Servers

Java™ 2 Platform
Desktop
machines
Optional
Packages
Optional
Packages
Java 2
Enterprise
Edition
(J2EE)
Java 2
Standard
Edition
(J2SE)

High-end
consumer
devices

Low-end
consumer
devices
Smartcards
Personal Profile
Foundation Profile
CDC
Java Virtual Machine

MIDP
CLDC
Java
Card
APIs
KVM
CardVM
Java 2 Micro Edition (J2ME)
22
Chapter 2
Introduction
Palm:
• Palm 4.1 based on AMX kernel
– Programs are basically event handling loops
– Single threaded
– Motorola DragonBall (68000 series)
• Palm 5.0 true multitasking
– ARM
• C, C++, Java
• Open and modular architecture
– Introduction of 3rd party SW
– Introduction of 3rd party HW accessed by related SW -> Easy
development of add-on modules
• Further info: www.palm.com
l
@Feda AlShahwan
Palm Reference
Architecture
24
Chapter 2
Introduction
Brew:
• Aims to be the mobile platform for CDMA phones
– … but claims to be extendable to GSM as well
– Marginal (if any) interest in Europe
• Controlled distribution: “Before your application can
be certified for distribution, you must provide certain
information that will allow you to become an
authenticated BREW application developer”
– QualComm and its clients (e.g. Operators) may find this
convenient, whereas developers may not like vendorenforced restrictions
• C, C++, Java
• Further info: www.qualcomm.com/brew
@Feda AlShahwan
Brew Reference Architecture
26
Chapter 2
Introduction
Microsoft CE:
• On and off interest in mobile systems
• Market leader in PCs, not dominant in PDA/handheld
computers
• Windows CE can be installed to different reference
hardware
– Pocket PC 2002
– SmartPhone 2002
• Compatibility to PC world is an obvious advantage
• C, C++, Windows-like APIs
• Further info: www.microsoft.com/mobile
@Feda AlShahwan
Microsoft Smartphone 2002
28
Chapter 2
Platform
Linux:
• Three levels of systems
– Minimal system environment
• One process, deeply embedded
– Intermediate system environment
•
•
•
•
Mass memory
I/O
Dynamic linking
File system interfaces
– Full system environment
• ”Almost” full Linux
• Released systems from e.g. Motorola
• Monta Vista Software/Consumer Electronics Edition for
core, application framework also needed
• More info: www.embedded-linux.org
@Feda AlShahwan
Chapter 2
Platform
• Do it Your Self
• Own operating system
• Well-defined interfaces to system
resources
• Dynamic and reliable memory and
resource management
• Tool chain availability
• Key questions:
– Who maintains what?
– Who invests and for what motivation?
@Feda AlShahwan
Overview
Guiding consortia
Java
Open development
and standards
Linux
Symbian
No ’own’
developement needed
Microsoft
Full access
Single company
to everything Proprietary development effort
OS
31
Chapter 2
Summary
•
•
•
•
•
Mobile Application Development
Mobile User Interface Design
Native and interpreter
Mobile platforms
–
–
–
–
–
–
–
Symbian OS
Java
Palm OS
Brew
Microsoft CE
Embedded Linux
Do-it-yourself
Mobile systems require programming skills that incorporate the
most incompatible parts of the system
– Limited memory and performance
– User extensions
•
Many available platforms all of which could become the dominant
design
– Competition, lack of de-facto standards, divergence
@Feda AlShahwan
References
•
•
•
Series 60 Platform Basics” Provides basic information on the Series 60
platform.
“Introduction to Designing C++ Applications” This manual deals also
with the Hello World Basic application, but provides more in-depth
descriptions and instructions concerning the application, its structure
and implementation
“Designing C++ Applications” Provides detailed instructions on
designing C++ applications for Series 60. It is recommended that you
read the Introduction to Designing C++ Applications before this manual
@Feda AlShahwan
33