Embedded Systems

Embedded systems contain two main elements: ... The embedded

system hardware will also contain other elements including memory,
input output (I/O) interfaces as well as the user interface, and the
display. Embedded system software: The embedded system software is
written to perform a particular function.
Embedded systems basics
• An embedded system is any computer system contained within a
product that is not described as a computer.
• Using this embedded system definition it is possible to understand
the various basic characteristics one. Typically they are:
Cont….
• Embedded systems are designed for a specific task. Although they use
computer techniques, they cannot be used as a general purpose
computer using a variety of different programmes for different task.
In this way their function can be focused onto what they need to do,
and they can accordingly be made cheaper and more efficiently.
• The software for embedded systems is normally referred to as
firmware. Rather than being stored on a disc, where many
programmes can be stored, the single programme for an embedded
system is normally stored on chip and it is referred to as firmware.
Embedded systems contain two main
elements:
• Embedded system hardware: As with any electronic system, an
embedded system requires a hardware platform on which to run. The
hardware will be based around a microprocessor or microcontroller.
The embedded system hardware will also contain other elements
including memory, input output (I/O) interfaces as well as the user
interface, and the display.
• Embedded system software: The embedded system software is
written to perform a particular function. It is typically written in a
high level format and then compiled down to provide code that can
be lodged within a non-volatile memory within the hardware.
Software Constraints
1. Screen size, sensors and interactions

2. Storage and cache sizes

3. Latencies

4. Network issues
Software Constraints
5. Data use requirements

6. Fonts, language and tone of voice

7. Corner cases for product usage

 Architecting mobile applications
• When building an application, architects need to have a plan in place
before they start. Application architecture is the underlying structure
that developers work with to build an application. This foundation
describes the tools and techniques that need to be used to ensure
that the app is well designed and functioning at the highest level.
Conti…
Presentation Layer
The main focus of this layer is how to present the app to the end user.
When designing it, app developers must determine the correct client
type for the intended infrastructure. Client deployment
restrictions should also be kept in mind.
• Another prerequisite for designing this layer is choosing the correct
data format and using powerful data validation techniques to protect
your apps from invalid data entry.
Business layer
Caching, logging, authentication, exception management and security
are all matters of concern. According to our developers, you need to
split tasks into different categories to reduce the complexity of this
layer.
• For complex rules, app policies, data transformations and validation,
you must identify the set of demands separately for each of the
categories.
Data Access Layer
• This layer complies with the app requirements to facilitate secure
data transactions. You must design this dimension so that it can be
rescaled over time as business needs change.
Technology
Choosing Architecture
• When considering the architecture for mobile applications, there are
several questions that need to be asked and answered before a
suitable path forward is selected.
Understand Device Hardware
• Whether an android mobile application architecture, a hybrid mobile
application architecture or an iOS one is the path forward depends on
the devices that will be used most frequently.
• Based on the device OS, screen resolution, space, and memory,
different choices can be made. This is a crucial first step as
understanding the hardware that powers a device will drive decisions
about the minimum specifications the application needs to comply
with.
Is Data or WiFi Always Available?
• To understand which option is best for your mobile application, you
need to understand how and where it will be used. If your application
will always maintain a connection to the server, a thin client approach
might be more suitable.
• If, however, you cannot guarantee this connection, or you need a
more complex UI, then pursue a rich client path. Rich client solutions
are generally more complicated to maintain and install, but they
might also be the only suitable option.
Consider User Interface (UI)
• A UI is how users interact with applications. A confusing UI will only
cause conflict and will impact how your users perceive the app and its
usefulness. While design matters, it should not be at the expense of
the user experience itself. Creating a picture perfect design matters
little if your users are unable to understand how to use the interface
and application.
Choose The Correct Navigation Method
How menus are presented and the app itself functions has a big impact
on an application’s usefulness and popularity. There are a variety of
different navigation methods that an app developer can pursue when
building an application. These include:
• Scroll view
• Single view
• Stacked navigation bar
• Modular controller
• Tab controller
• Gesture or Search driven navigation.
User interfaces for mobile applications
• Your app's user interface is everything that the user can see and
interact with. Android provides a variety of pre-built UI components
such as structured layout objects and UI controls that allow you to
build the graphical user interface for your app. Android also provides
other UI modules for special interfaces such as dialogs, notifications,
and menus.
Touch Gestures and events
• Android provides a variety of APIs to help you create and detect
gestures.
• Although your app should not depend on touch gestures for basic
behaviors (since the gestures may not be available to all users in all
contexts), adding touch-based interaction to your app can greatly
increase its usefulness and appeal.
• To provide users with a consistent, intuitive experience, your app
should follow the accepted Android conventions for touch gestures.
Detect common gestures
A "touch gesture" occurs when a user places one or more fingers on
the touch screen, and your application interprets that pattern of
touches as a particular gesture. There are correspondingly two phases
to gesture detection:
1. Gather data about touch events.
2. Interpret the data to see if it meets the criteria for any of the
gestures your app supports.
Conti…
• Layouts
• Notifications Overview
• Add the App bar
• Control the system UI visibility
• Designing effective navigation
• Implimenting effectictive navigation
• Slide between fragments using ViewPager
• Supporting Swipe-to-Refresh
• Toasts overview
• Pop up messgaes overview
Gather data
• When a user places one or more fingers on the screen, this triggers
the callback onTouchEvent() on the View that received the touch
events. For each sequence of touch events (position, pressure, size,
addition of another finger, etc.) that is ultimately identified as a
gesture, onTouchEvent() is fired several times.
• The gesture starts when the user first touches the screen, continues
as the system tracks the position of the user's finger(s), and ends by
capturing the final event of the user's fingers leaving the screen.
Throughout this interaction, the MotionEvent is delivered to
onTouchEvent() provides the details of every interaction. Your app
can use the data provided by the MotionEvent to determine if a
gesture cares about what happened
Capture touch events for an Activity or View
• The following snippet uses getActionMasked() to extract the action
the user performed from the event parameter. This gives you the raw
data you need to determine if a gesture you care about occurred:
Cont…

public class MainActivity extends Activity {

...
// This example shows an Activity, but you would use the same approach if
// you were subclassing a View.
@Override
public boolean onTouchEvent(MotionEvent event){

int action = MotionEventCompat.getActionMasked(event);

switch(action) {
case (MotionEvent.ACTION_DOWN) :
Log.d(DEBUG_TAG,"Action was DOWN");
return true;
case (MotionEvent.ACTION_MOVE) :
Log.d(DEBUG_TAG,"Action was MOVE");
return true;
case (MotionEvent.ACTION_UP) :
Log.d(DEBUG_TAG,"Action was UP");
return true;
case (MotionEvent.ACTION_CANCEL) :
Log.d(DEBUG_TAG,"Action was CANCEL");
return true;
case (MotionEvent.ACTION_OUTSIDE) :
Log.d(DEBUG_TAG,"Movement occurred outside bounds " +
"of current screen element");
return true;
default :
return super.onTouchEvent(event);
}
}