• Mobile devices are different
• Hardware
• Capacity
• Connectivity
• Energy consumption considerations
• User context
• Limitations and opportunities
1.6. Within this part of the course...
• Learn the different
• Design patterns,
• UI techniques,
• Operating system services
• that help designing and developing efficient, reponsive, ergonomic, useful applications for the different mobile platforms
1.7. RESTRICTIONS OF MOBILE SOFTWARE DESIGN
1.8. Always keep in mind...1/3
• Users need quick and responsive applications
• On mobile, users can't extend the hardware for the sake of software
• Software ergonomy has greater importance
• Device should be portable Small screen
• Various input and output on the very same platform
• Touchscreen, trackball, ITU-T 12-keypad, qwerty,Can be changed run-time
• Portrait and landscape modes
• Multiple screens
• Scalable UI: Own or built-in graphic elements
1.9. Always keep in mind...2/3
• Put efficient code into the hardware!
• Memory leak?
• Even the gc needs resources
• Temp files on the storage
• Profiling
1.10. Always keep in mind...3/3
• Limited connectivity
• What if there's no connection?
• What if it stops working?
• What if network speed is slow, with huge latency? (e.g. video)
• It has its own cost
• Data transfer, call, SMS, MMS...
• Does the user know about that?
• Data cache, seldom update/upgrade...
1.11. Mobile computing capacity
• Calculating to a given length
• Differences are in order of magnitude between desktop and mobile processors
1.12. Get to know the palette!
1.13. ARCHITECTURE OF ENTERPRISE SYSTEMS
1.14. Participants of mobile market
• Network providers
• Builds up and maintains the mobile network, makes possible to communicate between phones
• E.g. T-Mobile, Telenor, Vodafone
• Service providers
• Provides various services to mobile phones or network's customers
• Voice-transfer: presently provided by the network operator, but increasingly splitting up: VMNO (Virtual Mobile Network Operator)
• E.g. Skype, Google, application developers, etc.
• Mobile phone manufacturers
• E.g. Nokia, Sony-Ericsson, Samsung, HTC, Apple
• Customers
1.15. Mobile phone's functions 1/2
• What are the functions of a present-day modern mobile device?
• Communication (voice, e-mail, sms, etc.)
• Organizer functions (calendar, note)
• Web browsing
• Game
• Music/video playback
• Navigation
• Paying, authenticating
1.16. Mobile phone's functions 2/2
• Some extreme use-cases
• Controlling a robot (IR, Bluetooth, WLAN etc.)
• Observation via network (built-in microphone and camera)
• Mobile client for any network based application (e.g. Gmail mobile, blogs)
1.17. Generic architecture diagram
1.18. Architecture
• Middleware
• Usually a web application
• SOAP, REST
• Its role and weight differs from application to application
• Mobile client
• We are now regarding the thick clients
• Small and mid size
• Patterns differ from the desktop
• A variant of MVC (for example, the M-V-VM)
1.19. MVC: basics
• View: Displaying User Interface, representing data, interaction
• iOS: UIView, WP: UIElement
• Model: Providing and saving data
• Controller has no connection towards the view
• Limited and hard to use
1.20. Model-View-Presenter
• Android, iOS
• View can access the model via the controller
• The controller is aware of the view, it can directly modify its contents if some change occurs
1.21. Model-View-ViewModel
• Silverlight, Windows Phone
• To minimize the Code behind of the View
• ViewModel ( Controller):
• Views connect to it by databinding (the ViewModel is the Data context)
• Filtering and aggregation
1.22. Architecture of mobile applications
• Follow the MVC conventions common on the given platform!
• Put the UI and data representation to the View class, but not the business logic!
• Each part of data transformation should happen in the controller or the model parts
• Transformations that do not affect the business logic (do not alter the state of the application,) can happen in the model
• If a UI event reaches the View, BL tasks should be delegated to the controller.
1.23. COMMUNCATION
1.24. Communication
• Over HTTP/HTTPS
• Transaction based
• TCP stream -based
• Continouos, synchronous connection
• The middleware should steadily supervise it
• On client side, the open socket needs resources
• For special tasks, such as streaming
• The business layer is usually a web service
1.25. Webservice implementation
• The standard HTTP-based interface can be
• SOAP-based
• XML messages
• RPC-like, WSDL descriptors at server side
• REST (Representational State Transfer)
• Standard HTTP queries (POST/PUT/GET/...)
• Resources with general interfaces, or URIs
• RESTful requirements: client-server architecture, stateless, cache-able, layered structure, uniform interface
1.26. The REST body
• CSV
• Simplest
• Hard to extend and understand
• XML
• Structured, easy to understand
• Too verbose
• JSON
• More difficult to understand than XML, because of the lack of labels
• More compact
1.27. How server can reach the client
• Polling
• Scheduled queries delay can be big
• Frequent and unnecessary queries: energy, computing time, bandwidth
• The application should be running
• Push notification messages
• On every important platform, with external support
• Handled by the operating system
• Small sized messages
1.28. DATA STORAGE
1.29. Data storage: where?
• Correlates with the offline capability of the client
• At server side
• Either way, e.g. RDBMS, cloud, ...
• Client side
• For small amount of data: XML or file
• SQL on every platform
1.30. Sychronization with the server
• Keeping the data up-to-date is critical question
• Full synchronization
• Easy, with many unnecessary resending
• Only in case of small dataset or rare synchronization
• Incremental synchronization with version control
• Resending only which has higher version
• More work at server side, minor extra task at client side
• Implementation for example with timestamp
1.31. CONSEQUENCES OF LIMITED NETWORK ACCESS
1.32. The network can be down...
• In a tunnel, out of office, abroad...
• Two main strategies:
• Only online operation:
• Retrieves data from server at every view displaying
• Temporary data storage
• Stops working with network outage.
• Prepared for offline operation:
• The application represents data from a local database,
• Updates the data with the middleware on a time basis or with a predefined trigger
1.33. Offline operation
• Critical if connection is dropped during synchronization
• Transactions on both sides
• Communciation on a background thread
• Without blocking the UI thread
• Disabling the UI (e.g. with a waiting indicator)
• Only when inevitable
• Only when data are downloaded
1.34. Strategies of offline operation
• Partial offline operation:
• Client offers most of the functionalities
• Specific tasks (e.g. data modification) can not be performed
• Unlimited offline operation:
• Every function can be performed
• Modifications stored in a local data store
• Synchronization when network is available
1.35. APPLICATION PUBLISHING
1.36. Testing
• Preparation of testing report
• Predefined testing scenarios
• The functional test should cover all the use cases
• Hit the whole user interface
• Test with extreme input data
• Stress test: both on client and server side
• Incerasing the size of database, or simulating the increase of synhronized data amount
• Emulated clients can be used to test the server side
1.37. Technical documentation
• Application specification
• 3rd partry libraries and their licensing
• Further applied technologies
• Compilation steps of server and client sides
1.38. Further documentation
• Installation docs
• Should happen without user interaction or configuration
• Compilation guide
• User guide
• Is user interface ergonomic and straightforward to be used without the user guide?
1.39. Installation package and metadata
• Validation steps:
• Permissions, capabilities: exactly the needed ones?
• Application name, and icon is OK for all the (available) device types?
• Is metadata and other text that is shown to the user during installation correct?
• Obfuscation
1.40. SUMMARY
1.41. Summary
• Desiging and impementing software for enterprise context
• Different design patterns and circumstances
• Usually a client/server architecture
• Eventually with offline functionality
• And data synchronization
1.42. References
• Frank H. P. Fitzek (editor): Mobile Phone Programming and its Application to Wireless Networking.
Springer-Verlag, 2007. (ISBN: 978-1-4020-5968-1)
• John Hunter, Scott Olson, Ben Horgen and Kenny Goers: Professional Cross-Platform Mobile Development in C#. 2012, Wrox.
• Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994
• Bulent Tavli: Mobile Ad Hoc Networks: Energy-Efficient Real-Time Data Communications. Springer, 2010.
2. 2 Introducing the Android mobile platform Android
application components UI design
2.1. Lecture 2 - Outline
• Android platform introduction
• Application components
• UI Design
2.2. ANDROID PLATFORM INTRODUCTION 2.3. Genesis of Android
• Android is one of the most popular mobile operating systems of present days
• It is a brand (TV spots, ads, etc.)
• Google stands behind
• Android offers the picture of a well functioning OS
• Revolutionized the picture of mobile operating systems
2.4. Open Handset Alliance
• Android is not only Google's development
• More than 50 member companies
• 11 manufacturer (HTC, LG, Motorola, Samsung, Asus, Garmin, Huawei, Sony Ericsson, Ericsson, Toshiba, Acer)
• 13 semiconductor manufacturer (not at least Intel, Marvell, nVidia, Broadcom, SiRF, ARM and Atheros)
• 10 operator (example T-Mobile and Vodafone)
• 12 software company (Google, eBay)
• 7 other corporation
• Members are changing frequently
• Android:
• Product of huge knowledge and lot of work
2.5. Android hardware requirements
• Open Handset Alliance members get the OS free
• But! Google grants permission to Google Maps, YouTube and Google Play only when a device fulfills some hardware requirements:
• At least QVGA resolution display
• 128 MB RAM and 256 MB flash memory,
• Bluetooth
• mini or microSD memory card
• WiFi
• Without these applications, these phones are rather feature phones
2.6. Android and Google integration
• After assigning a Google/GMail user, the OS will keep the contact list, the messages, the conversations, and the calendar synchronized with it
• When the user starts a conversation with a new partner in Gmail, then the new name will be shown in Android contact list
• When the user adds a new contact after a phone call, it will be synchronized with Gmail. This works for calendar and GTalk too.
• Users can share their photos created with the camera of the devices at Picasa
• Using Latitude, users can share their position with friends
• Google+ community network functions
2.7. Android versions
• Developers must follow version changes
• Could be significant differences between versions
• Google pursue backward compatibility, but there are deep gaps (v 3.0)
• Before developing, it's neccesary to choose the minimum supported version well
• Version codename: some candy
2.8. Structure of Android platform
2.9. Platform build-up 1/3
• The structure of the platform is simple and clean
• The red part is the Linux kernel, which contains:
• Drivers of the hardware components
• These parts are created by the device manufacturers, because they know best "what is in the box"
• Memory management, process scheduling, low energy consumption performance management
2.10. Platform build-up 2/3
• The green parts are program libraries/services which run on the Linux kernel, like: libc, SSL, SQLite, etc.
These are implemented in C/C++
• The Dalvik virtual machine in the yellow part is based on these parts
• Not compatible with Sun's virtual machine
• Totally different instruction set
• It runs different binary programs
• After compiling, Java programs are not compiled into .class files, but to a Dalvik Executable format, which extension is .dex. It is usually smaller then .class files size
• Java is only the programmig language!
2.11. Platform build-up 3/3
• Ont the blue parts are only Java source code
• Java source is run by the virtual machine. This is the essence of Android:
• A visible and touchable operating system
• Running programs
• The virtual machine can hide the whole Linux file system, and the users can see only the file system provided by Android Runtime
2.12. Managed code
• Managed code runs on a virtual machine (Dalvik)
• It makes the application run secure
• An application can't ruin the whole system
• Memory management is happening with a garbage collector
• But! Be careful to create "good" source code
2.13. APPLICATION COMPONENTS
2.14. Applications
• Present days, the mobile client applications are more popular than web pages optimized for mobile displays
• General applications can be launched with icons
• Android grants much more:
• Services, running in the background
• Launch an application when an event occurs
• Autostart services in boot time
• Etc.
• An application can be deeply embedded in the OS
• Hold attention to user experience
2.15. Android Runtime 1/2
• After install, every Android application runs in an own secure environment (security sandbox):
• Android is a multi user operating system based on Linux. Every application is actually a different user.
• By default, the system assigns a unique Linux user identifier to every application
• This ID is hidden from the application, only the system knows about it
2.16. Android Runtime 2/2
• After install, every Android application runs in an own secure environment (security sandbox):
• Every process has its own VM instance, thus the applications source running separately from the others
• Every application runs in its own Linux Process
• Android launches the Process, when a component of the application is started. The Process will be closed, when it is not needed any more, or the system needs more free memory for other applications
2.17. Application rights
• It is possible to use the same Linux user ID by two applications, thus they can use each other's files
• From resource saving reasons, these applications running in the same Linux Process, and they sharing on the same virtual machine too
• Every application can request various rights to get access to device's data/hardware: contact list, SMS, camera, Bluetooth, etc
• Every access right must be approved by the user during the installation process
2.18. Application components
• Every component is a unique building block of the application
• Every component grants a unique interface via the system can reach them
• Not every interface available for the user
• Components are helping to describe the application's global, unique behavior
• 4 application components exist. They have different purposes and life-cycle models (which defining the component's creation and destruction)
2.19. Android application structure 1/2
• An Android application builds up from one or more application component(s):
• Activities
• Services
• Content Providers
• Broadcast Receivers
2.20. Android application structure 2/2
• Every component has its own role in the application
• Any component can activate itself
• Even an other application can activate the single components
2.21. Activities
• Independent View with own UI
• Example:
• Reminder application
• 3 Activity: ToDo list, create new ToDo, ToDo details
• Activities are independent, but they making up the whole application together
• Activities can start from another application too, like:
• Camera application can start the "create new ToDo" Activity, and assign the created photo to the reminder
• Inherited from android.app.Activity class
2.22. Services
• The Service component represents a task which running in the background for a longer time
• No user interface
• For example a downloader application running in the background while user plays a game in foreground
• Other components (Activity) can launch it, or bind it for control
• Inherited from android.app.Service class
2.23. Content providers
• Content provider's task is to manage a shared data source
• The data can be stored in the file system, in SQLite database, in the web, or in other persistent datastore, which is accessible for the application.
• Via Content Providers, other applications have access to the data
• For example: CallLog application, which grants a Content Provider to access the content
• Inherited from android.content.ContentProvider class and must override every required API call
2.24. Broadcast receivers
• Broadcast receivers are responding to system level events (broadcasts)
• For example: display shut down, low battery, incoming message, incoming call, etc
• The application can send its own broadcast, for example when it want to indicate that an operation is done
• They don't have own UI, rather showing a message in the status bar, or starting an other component
• Inherited from android.content.BroadcastReceiver class; the event is available as an Intent (see later)
2.25. Manifest file
• Application descriptor, defines the application components
• XML file
• Before starting a component, the system checks the manifest file to verify the component's definition
• It provides other tasks too (example: what are minimum requirements to run the application)
• System verifies it at application installation
2.26. Application resources
• An Android application not only made up from source code, but from resources too, just like: images, sounds, etc
• Also the interfaces defined in XML are resources too: layout, animation, menu, style, color
• With resources the application is much more flexible
• The system automatically generates a unique identifier to every resource. They will be reachable from the source code with this ID
2.27. "Back stack"
• When a new Activity is starting, the previous Activity will be stopped, but system preserves it on the "back stack"
• When the Activity started, it will be put on the back stack, and will get the focus
• Back stack: "last in, first out" array
• On "Back button" press, the back stack's top Activity will remove from the array, and the underneath gets the focus
2.28. Activity lifecycle
• For a reliable and flexible application, it is critical to override appropriate the Activity lifecycle callback methods
• The lifecycle of the Activity defined by the other cooperating Activities
• It is necessary to test the Activity's functions in the different lifecycle states
2.29. Activity states
• There are 3 main states:
• Resumed (running): the Activity is in the foreground and it has the focus
• Paused: the Activity is "alive", but another Activity is in the foreground (transparent, or pop-up like), which is not cover it fully. System can kill it when the memory is extremely low
• Stopped: the Activity is "alive", but another Activity is fully in the foreground, and it covers the Stopped Activity. System can kill it when the memory is low
2.30. Activity lifecycle model
2.31. Activity lifecycle-callback
• When an Activity stops for a start of another, the Activity will be notified via the lifecycle callback methods
• Many callback methods are supported (create, stop, resume, destroy, etc.)
• When a stop event occurs, it is typical to release the "big" objects (Database connection, network connection)
• When the Activity resuming, the resources must be allocated again
• These transitions are typically part of Activity lifcycle
2.32. Multitasking
• Task: a performable function, which can use more Activities, but they don't need to belong to the same application
• On pressing the Home button, the system will go to the Home Screen, and we can launch a new task
• On launching a new task, the system keeps the previous task's Back Stack
• The new task gets a new Back Stack
2.33. UI DESIGN
2.34. Different screen sizes 1/2
• Android can run on different display resolutions and densities
• The OS grants a mechanism to support different displays (from version 1.6)
• It takes over the most of the work from the developer
• Developer/designer must create only the appropriate resources
• For example, there are huge differences between a screen of a tablet and a mobile phone
2.35. Different screen sizes 2/2
• The OS automatically scales and resizes the surface of the application to reach the maximal device compatibility
• But! It is important, that the surface and the resources (images) will be optimized for the supported resolutions and densities
• This method can greatly increase the user experience
• Furthermore the device specific visualization will increase the user satisfaction
• Following this method will result an application in a single .apk file, which can support every device in UI regard
2.36. Most imoprtant definitions 1/2
• Screen size:
• Physical screen diagonal
• For simplicity, Android distinguishes 4 different categories: small, normal, large and extra large
• Screen density ( ): the number of pixels within an area. Typically dots per inch. (dpi)
• Android distinguishes 4 different categories: low, medium, high Ă©s extra high
• Orientation: the orientation from the user's point of view:
• Portrait
• Landscape
• Orientation can change in runtime, for example with the rotation of the device
• It's possible to lock the orientation
2.37. Most important definitions 2/2
• Resolution ( ): Number of the pixels of the display
• At UI desing, never work with resolution, only size and density
• Density-independent pixel( )
• Virtual pixel unit, which is expedient to use at UI design
• One dp is one physical pixel on a 160 dpi screen.
• The OS handles every necessary scaling at runtime according to the defined dp
•
• For example on a 240 dpi screen, 1 dp is 1.5 physical pixel
2.38. General screen sizes
• 4 general sizes:
• small, normal, large and xlarge
• 4 general densities:
• ldpi (low), mdpi (medium), hdpi (high), and xhdpi (extra high)
2.39. Runtime operation
• To optimize the visualization, it is possible to set alternative resources to support different screen resolutions and densities
• Typically, we must define different layouts and distinct resolution images
• The OS choose the appropriate resources runtime
• Generally there is no need to define every resolution and density combination
2.40. Density independency
• An application can be density independent, when the UI components preserving their physical size on the
• An application can be density independent, when the UI components preserving their physical size on the