Mobile Softwares
Ekler, Péter Forstner, Bertalan
Kelényi, Imre
Mobile Softwares
írta Ekler, Péter, Forstner, Bertalan, és Kelényi, Imre Publication date 2015
Szerzői jog © 2015 Ekler Péter, Forstner Bertalan, Kelényi Imre
Tartalom
Mobile Softwares ... 1
1. 1 Introducing properties of mobile software development ... 1
1.1. Lecture 1 - Outline ... 1
1.2. MOTIVATION ... 1
1.3. Why are mobile clients important? ... 1
1.4. Limited hardware capabilities ... 1
1.5. Consequences ... 2
1.6. Within this part of the course... ... 2
1.7. RESTRICTIONS OF MOBILE SOFTWARE DESIGN ... 2
1.8. Always keep in mind...1/3 ... 2
1.9. Always keep in mind...2/3 ... 2
1.10. Always keep in mind...3/3 ... 3
1.11. Mobile computing capacity ... 3
1.12. Get to know the palette! ... 3
1.13. ARCHITECTURE OF ENTERPRISE SYSTEMS ... 4
1.14. Participants of mobile market ... 4
1.15. Mobile phone's functions 1/2 ... 4
1.16. Mobile phone's functions 2/2 ... 5
1.17. Generic architecture diagram ... 5
1.18. Architecture ... 6
1.19. MVC: basics ... 6
1.20. Model-View-Presenter ... 6
1.21. Model-View-ViewModel ... 7
1.22. Architecture of mobile applications ... 8
1.23. COMMUNCATION ... 8
1.24. Communication ... 8
1.25. Webservice implementation ... 9
1.26. The REST body ... 9
1.27. How server can reach the client ... 9
1.28. DATA STORAGE ... 10
1.29. Data storage: where? ... 10
1.30. Sychronization with the server ... 10
1.31. CONSEQUENCES OF LIMITED NETWORK ACCESS ... 10
1.32. The network can be down... ... 10
1.33. Offline operation ... 11
1.34. Strategies of offline operation ... 11
1.35. APPLICATION PUBLISHING ... 12
1.36. Testing ... 12
1.37. Technical documentation ... 12
1.38. Further documentation ... 13
1.39. Installation package and metadata ... 13
1.40. SUMMARY ... 13
1.41. Summary ... 13
1.42. References ... 13
2. 2 Introducing the Android mobile platform Android application components UI design ... 13
2.1. Lecture 2 - Outline ... 14
2.2. ANDROID PLATFORM INTRODUCTION ... 14
2.3. Genesis of Android ... 14
2.4. Open Handset Alliance ... 14
2.5. Android hardware requirements ... 14
2.6. Android and Google integration ... 15
2.7. Android versions ... 15
2.8. Structure of Android platform ... 15
2.9. Platform build-up 1/3 ... 16
2.10. Platform build-up 2/3 ... 16
2.11. Platform build-up 3/3 ... 17
2.12. Managed code ... 17
2.13. APPLICATION COMPONENTS ... 17
2.14. Applications ... 17
2.15. Android Runtime 1/2 ... 17
2.16. Android Runtime 2/2 ... 18
2.17. Application rights ... 18
2.18. Application components ... 18
2.19. Android application structure 1/2 ... 18
2.20. Android application structure 2/2 ... 19
2.21. Activities ... 19
2.22. Services ... 19
2.23. Content providers ... 20
2.24. Broadcast receivers ... 20
2.25. Manifest file ... 20
2.26. Application resources ... 20
2.27. "Back stack" ... 20
2.28. Activity lifecycle ... 21
2.29. Activity states ... 21
2.30. Activity lifecycle model ... 21
2.31. Activity lifecycle-callback ... 22
2.32. Multitasking ... 22
2.33. UI DESIGN ... 23
2.34. Different screen sizes 1/2 ... 23
2.35. Different screen sizes 2/2 ... 23
2.36. Most imoprtant definitions 1/2 ... 23
2.37. Most important definitions 2/2 ... 24
2.38. General screen sizes ... 24
2.39. Runtime operation ... 25
2.40. Density independency ... 25
2.41. Most important factors ... 25
2.42. Designing user interfaces ... 25
2.43. User Interface resources ... 25
2.44. Some important layout ... 26
2.45. Pop-up windows ... 27
2.46. Menus ... 28
2.47. Localization ... 28
2.48. Creating styles ... 28
2.49. Using themes ... 29
3. 3 Communication between components, Resources, User Interface ... 29
3.1. Lecture 3 - Outline ... 29
3.2. COMMUNICATION BETWEEN COMPONENTS ... 29
3.3. Communication between components ... 30
3.4. Intent ... 30
3.5. Intent delivery ... 30
3.6. Intent object ... 30
3.7. Usage of intents ... 31
3.8. Explicit intents ... 31
3.9. Returning of an activity ... 31
3.10. Intent Extras ... 32
3.11. Implicit Intents ... 32
3.12. Implicit Intent - Actions ... 32
3.13. Implicit Intent - Example ... 33
3.14. Intent resolution ... 33
3.15. Intent filter ... 33
3.16. Intent resolution ... 34
3.17. Intent flags ... 34
3.18. RESOURCES ... 34
3.19. Resources ... 34
3.20. Resource types ... 34
3.21. Qualifiers ... 35
3.22. Example 1/2 ... 35
3.23. Example 2/2 ... 36
3.24. ADVANCED USER INTERFACE ... 36
3.25. Android Fragment Framework ... 36
3.26. Fragment and Activity ... 36
3.27. Fragment lifecycle ... 37
3.28. Different display sizes ... 38
3.29. UI Fragment ... 39
3.30. UI Fragment ... 39
3.31. Managing Fragments ... 39
3.32. FragmentTransaction ... 39
3.33. Communication ... 40
3.34. FragmentDialog ... 40
3.35. Fragment parameters ... 41
3.36. Fragments in older versions ... 41
3.37. ViewPager ... 41
3.38. FragmentPagerAdapter ... 42
3.39. PageTitleStrip and PageTabStrip ... 43
3.40. ANIMATIONS ... 43
3.41. Property Animation ... 44
3.42. Property Animation elements ... 44
3.43. View animation ... 44
3.44. Drawable animation ... 44
3.45. Summary ... 45
4. 4 Persisting and binding data on Android platform, Broadcast Receiver Component ... 45
4.1. Lecture 4 - Outline ... 45
4.2. PERSISTENT DATA STORAGE ... 45
4.3. Persistent Data Storage ... 45
4.4. Shared Preferences ... 46
4.5. Using Shared Preferences - Write ... 46
4.6. Using Shared Preferences - Read ... 46
4.7. Internal and External Storage ... 47
4.8. Internal Storage example ... 47
4.9. External Storage example ... 47
4.10. SQLite Database ... 48
4.11. SQLite Example 1/3 ... 48
4.12. SQLite Example 2/3 ... 48
4.13. SQLite Example 3/3 ... 49
4.14. Network Connection ... 49
4.15. CONTENT PROVIDER ... 49
4.16. Content Provider ... 49
4.17. Similar Conceptions ... 50
4.18. Example 1/3 ... 50
4.19. Query data ... 51
4.20. Query data ... 51
4.21. Example 2/3 ... 52
4.22. Insert and Modify ... 52
4.23. Example 3/3 ... 53
4.24. Create Custom Provider 1/2 ... 53
4.25. Create Custom Provider 2/1 ... 53
4.26. DATA BINDING ... 54
4.27. Data Binding ... 54
4.28. Example - ArrayAdapter ... 54
4.29. Another example 1/2 ... 54
4.30. Another example 2/2 ... 55
4.31. Example - Google autocomplete ... 56
4.32. BROADCAST RECEIVER ... 56
4.33. Broadcast Receiver ... 56
4.34. Registration ... 57
4.35. Events ... 57
4.36. Example - Monitoring calls ... 57
4.37. Example - Registration of receivers ... 58
4.38. Example - handle incoming calls ... 58
4.39. Example - handle outgoing calls ... 58
4.40. Example - screenshot ... 59
4.41. Summary ... 60
5. 5 Network communication, Location based services, Service component ... 60
5.1. Lecture 5 - Outline ... 60
5.2. NETWORK COMMUNICATION ... 61
5.3. Mobile network information ... 61
5.4. Examples ... 61
5.5. HTTP communication ... 61
5.6. HttpClient and DefaultHttpClient ... 62
5.7. HttpGet ... 62
5.8. Result of HTTP request ... 62
5.9. HttpEntity ... 63
5.10. HTTP GET example ... 63
5.11. Modifying UI from another thread ... 63
5.12. URL encoding ... 64
5.13. HTTP POST ... 64
5.14. HTTP POST example ... 64
5.15. HTTPS ... 65
5.16. Processing responses ... 65
5.17. JSON ... 65
5.18. Processing JSON ... 66
5.19. JSON example ... 66
5.20. XML ... 67
5.21. Processing XML ... 67
5.22. XML example ... 68
5.23. TCP/IP socket ... 68
5.24. LOCATION BASED SERVICES ... 68
5.25. Location based services ... 68
5.26. Current Position ... 68
5.27. Providers ... 69
5.28. Examples ... 69
5.29. ProximityAlert ... 69
5.30. Geocoding ... 70
5.31. Reverse Geocoding ... 70
5.32. MapView ... 70
5.33. MapView screenshot ... 70
5.34. Creating MapView ... 71
5.35. MapView - Layout ... 71
5.36. MapView Overlays ... 72
5.37. Creating Overlay ... 72
5.38. SERVICES ... 72
5.39. Service ... 72
5.40. Service types ... 73
5.41. Service lifecycle ... 73
5.42. Managing Services ... 74
5.43. Creating Service ... 74
5.44. Custom Service methods ... 75
5.45. Terminating services by Android OS ... 75
5.46. Service attributes 1/2 ... 75
5.47. Service attributes 2/2 ... 75
5.48. Service example ... 76
5.49. Summary ... 76
6. 6 Introducing the iOS Mobile Platform, Developer Tools and Programming basics ... 76
6.1. Lecture 6 - Outline ... 77
6.2. Devices running iOS ... 77
6.3. iOS the Operating System ... 77
6.4. Behind success ... 78
6.5. Drawbacks ... 78
6.6. Drawbacks ... 78
6.7. The History of the iPhone ... 79
6.8. iOS versions from user perspective ... 79
6.9. iOS versions from developer perspective ... 79
6.10. Hardware, common properties ... 79
6.11. iPhone 5 interiors ... 80
6.12. UDID: Unique Device Identifier ... 80
6.13. BASIC PROPERTIES ... 80
6.14. Relevant attributes ... 81
6.15. iOS multitasking ... 81
6.16. Notifications ... 81
6.17. Sandbox model ... 82
6.18. Isolated Storage 1/2 ... 82
6.19. Isolated Storage 2/2 ... 83
6.20. Application distribution ... 83
6.21. App Store ... 84
6.22. TOOLS AND DEVELOPMENT CONCEPTS ... 84
6.23. Application development ... 84
6.24. iOS development without Objective-C? ... 85
6.25. Official developer tools ... 85
6.26. Xcode the IDE ... 86
6.27. iOS Simulator ... 87
6.28. iOS applications ... 88
6.29. Framework ... 88
6.30. Framework examples ... 88
6.31. Compiling/testing with iOS device ... 89
6.32. Application development and iOS versions 1/2 ... 89
6.33. Application development and iOS versions 2/2 ... 89
6.34. iPad vs. iPhone ... 90
6.35. Mac OS X vs. iOS development ... 90
6.36. Architecture of the iOS applications ... 90
6.37. Model View Controller ... 90
6.38. The MVC concept ... 91
6.39. iOS application base classes ... 91
6.40. View ... 92
6.41. UIView examples ... 92
6.42. View hierarchy ... 94
6.43. Controller ... 94
6.44. View controller in details ... 95
6.45. View and ViewController in the source ... 95
6.46. Model ... 95
7. 7 The Objective-C ... 96
7.1. Lecture 7 - Outline ... 96
7.2. OBJECTIVE-C BASICS ... 96
7.3. Objective-C ... 96
7.4. Primitive types, strings ... 97
7.5. Objects ... 97
7.6. Method calling = Message sending ... 98
7.7. Message sending: Java vs. Objective-C ... 98
7.8. Message sending ... 98
7.9. The id type ... 99
7.10. Classes - Class object ... 99
7.11. Classes - Instantiation ... 99
7.12. NSObject ... 100
7.13. Defining classes ... 100
7.14. Method definition 1/2 ... 100
7.15. Method definition 2/2 ... 101
7.16. Dynamic binding ... 101
7.17. Classes - Instance variables ... 102
7.18. Classes - Properties ... 102
7.19. Creating properties in 2 steps ... 102
7.20. Property synthesizing ... 103
7.21. Inheritance1/2 ... 103
7.22. Inheritance 2/2 ... 103
7.23. Example - Protocol implementation ... 104
7.24. Memory management ... 104
7.25. CONNECTION BETWEEN SOURCE CODE AND INTERFACE BUILDER 104 7.26. Repeat: Model View Controller ... 104
7.27. Repeat: iOS application base classes ... 105
7.28. Repeat: View and ViewController in the source ... 105
7.29. Connection between IB and source code ... 106
7.30. Defining and connecting IBOutlet ... 106
7.31. Action methods ... 107
7.32. Action methods ... 107
7.33. Summary: action methods and outlets ... 107
8. 8 Developing iOS User Interface ... 108
8.1. Lecture 8 - Outline ... 108
8.2. APPLICATIONS WITH MULTIPLE VIEWS ... 108
8.3. View controller ... 108
8.4. View controller types ... 108
8.5. Tab bar controller ... 109
8.6. Tab bar controller example ... 110
8.7. Navigation controller ... 111
8.8. Navigation controller example ... 111
8.9. Split View Controller ... 112
8.10. Simple view controller ... 113
8.11. STORYBOARDS ... 113
8.12. Storyboard ... 113
8.13. Structure of the Storyboard ... 113
8.14. Tab bar controller in storyboard ... 114
8.15. Navigation controller in storyboard ... 115
8.16. Prepare for a segue ... 116
8.17. Storyboard in the project ... 116
8.18. TABLE VIEW ... 117
8.19. Table view ... 117
8.20. Table view styles ... 118
8.21. Structure of the table view ... 119
8.22. Table view types ... 120
8.23. The data source of the table view ... 121
8.24. The behavior of the data source ... 121
8.25. UITableViewDataSource ... 121
8.26. Defining a table view in storyboard ... 122
8.27. Defining cell ... 122
8.28. Static table view ... 123
8.29. UITableViewController ... 123
9. 9 iOS Services - From gesture recognition to Map Kit ... 124
9.1. Lecture 9 - Outline ... 124
9.2. GESTURE RECOGNITION ... 124
9.3. Gesture recognizers ... 124
9.4. Gesture recognizer classes ... 124
9.5. Example: handling swipe gesture ... 125
9.6. Example:handling pinch gesture ... 126
9.7. BLOCKS ... 126
9.8. Block ... 126
9.9. What can we do with blocks? ... 126
9.10. Defining blocks ... 127
9.11. Examples for using of the blocks ... 127
9.12. Blocks and variables ... 128
9.13. What is good in blocks? ... 128
9.14. GRAND CENTRAL DISPATCH ... 128
9.15. Grand Central Dispatch (GCD) ... 128
9.16. GCD ... 129
9.17. What is GCD good for? ... 129
9.18. GCD APIs 1/2 ... 129
9.19. GCD API-k 2/2 ... 130
9.20. Example: download image in separated thread ... 130
9.21. ANIMATION ... 130
9.22. Animations ... 130
9.23. UIView animations: basics ... 131
9.24. UIView animation ... 131
9.25. Defining animations ... 131
9.26. Example ... 132
9.27. Animating view exchange ... 133
9.28. Animation options ... 134
9.29. MAP KIT ... 134
9.30. Map Kit ... 134
9.31. Initializing the map ... 135
9.32. Annotations ... 136
9.33. Defining annotation ... 137
9.34. Annotation ... 137
9.35. Reverse geocoding ... 137
10. 10 Introduction to the Windows Phone platform ... 138
10.1. Lecture 10 - Outline ... 138
10.2. Introduction to Windows Phone programming ... 138
10.3. History 1/2 ... 138
10.4. History 2/2 ... 139
10.5. Windows Phone 7 ... 140
10.6. Hardware requirements 1/2 ... 141
10.7. Hardware requirements 2/2 ... 142
10.8. Windows Phone 7 devices ... 142
10.9. Drawbacks ... 143
10.10. Advantages ... 144
10.11. Windows Phone 8 - Apollo ... 144
10.12. Microsoft design language ("Metro/Modern UI") ... 144
10.13. Metro ... 144
10.14. Iconographic vs. infographic UI ... 145
10.15. Control elements ... 147
10.16. Examples ... 147
10.17. Metro UI platforms ... 149
10.18. Software development for Windows Phone ... 150
10.19. .NET on one slide... ... 150
10.20. WP software technologies ... 150
10.21. Silverlight ... 151
10.22. WP - Why Silverlight? ... 151
10.23. XNA ... 152
10.24. Structure of Silverlight WP applications ... 152
10.25. MVVM ... 152
10.26. Development tools ... 153
10.27. Visual Studio ... 154
10.28. Expression Blend ... 155
10.29. Windows Phone Emulator ... 155
10.30. App development and publication ... 156
10.31. App Hub Account ... 157
10.32. Windows Phone Marketplace ... 157
10.33. XAP files ... 158
10.34. XAML basics ... 158
10.35. XAML ... 158
10.36. XAML example ... 159
10.37. XAML processing ... 159
10.38. XAML basics ... 159
10.39. Property value assignment ... 160
10.40. XAML vs. C# ... 160
10.41. XAML basics - Content property ... 160
10.42. Code-behind ... 161
10.43. Example: code-behind ... 161
10.44. Connection between code-behind and XAML ... 161
10.45. Up and downsides of XAML ... 162
10.46. HELLO WINDOWS PHONE ... 162
10.47. Project structure ... 162
10.48. HelloWP main page ... 162
11. 11 Developing Windows Phone User Interface ... 163
11.1. Lecture 11 - Outline ... 163
11.2. Silverlight object tree ... 164
11.3. Dependency Property ... 164
11.4. Dependency Property (DP) ... 164
11.5. Defining a Dependency Property 1/2 ... 165
11.6. Defining a Dependency Property 2/2 ... 165
11.7. DP value resolution ... 165
11.8. Value change notification ... 166
11.9. Attached Property ... 166
11.10. User interface development ... 167
11.11. WP application base classes ... 167
11.12. Basic UI classes ... 167
11.13. Control component examples ... 168
11.14. Elements of the user interface ... 169
11.15. Layout handling ... 169
11.16. Layout - StackPanel ... 170
11.17. Layout - Grid 1/3 ... 170
11.18. Layout - Grid 2/3 ... 171
11.19. Layout - Grid 3/3 ... 172
11.20. ContentControl ... 172
11.21. Button ... 173
11.22. ItemsControl ... 173
11.23. ListBox ... 173
11.24. Showing and receiving text ... 174
11.25. ApplicationBar ... 174
11.26. ApplicationBar example ... 175
11.27. Icons, pictures in the project ... 175
11.28. Windows Phone Toolkit ... 175
11.29. Windows Phone Toolkit ... 175
11.30. Toolkit example ... 176
11.31. Resources ... 176
11.32. Resources ... 176
11.33. Resource example ... 177
11.34. System resources ... 177
11.35. Playing audio ... 178
11.36. Playing audio ... 178
12. 12 Build Data-Driven Apps with Windows Phone ... 178
12.1. Lecture 12 - Outline ... 178
12.2. Navigation ... 178
12.3. Reminder: Basic UI classes ... 178
12.4. Pages ... 179
12.5. Navigation ... 179
12.6. NavigationService ... 180
12.7. Passing data to pages ... 180
12.8. Even more navigation ... 181
12.9. Animating page transition ... 181
12.10. Transition example ... 182
12.11. Data Binding ... 182
12.12. Data Binding ... 182
12.13. Setting the data source ... 183
12.14. Data source example with Source property ... 183
12.15. DataContext 1/2 ... 183
12.16. DataContext 2/2 ... 183
12.17. Change notification ... 184
12.18. Change notification example ... 184
12.19. Direction of the data binding ... 184
12.20. ObservableCollection T ... 185
12.21. Data Templates ... 185
12.22. Data Templates ... 185
12.23. ListBox data binding ... 185
12.24. Example: ListBox + data binding ... 186
12.25. Presentation of a List element ... 186
12.26. MVVM ... 186
12.27. MVVM architecture ... 186
12.28. MVVM ... 187
12.29. Advantages of MVVM ... 187
12.30. Relation of View and ViewModel ... 188
12.31. ICommand ... 188
12.32. Command example ... 188
12.33. MVVM Light Toolkit ... 189
13. 13 Advanced Windows Phone Development ... 189
13.1. Lecture 13 - Outline ... 189
13.2. Launcher / Chooser Task ... 189
13.3. Launcher / Chooser Task ... 189
13.4. Using Tasks ... 189
13.5. Launchers ... 190
13.6. Launcher examples ... 190
13.7. Choosers ... 191
13.8. Chooser example ... 191
13.9. Launcher/Chooser on the emulator ... 191
13.10. Live Tiles ... 192
13.11. Live Tiles ... 192
13.12. Structure of a Tile ... 193
13.13. Setting data of Tiles ... 193
13.14. Tiles: ShellTile ... 194
13.15. Refreshing the Application Tile ... 194
13.16. Creating a secondary Tile ... 195
13.17. Methods for refreshing Tiles ... 195
13.18. ShellTileSchedule ... 195
13.19. Panorama and Pivot Control ... 195
13.20. Panorama Control ... 195
13.21. Structure of Panorama Control ... 196
13.22. Panorama Control example ... 197
13.23. Some Panorama Control advice ... 198
13.24. Pivot Control ... 198
13.25. Structure of Pivot Control ... 199
13.26. Pivot Control example ... 199
13.27. Application lifecycle ... 200
13.28. Application lifecycle ... 200
13.29. Application lifecycle ... 200
13.30. Page events ... 201
13.31. Tombstoning ... 201
13.32. Example: usage of State at tombstoning ... 201
13.33. Isolated Storage ... 202
13.34. Data storage on the device ... 202
13.35. File handling basics ... 202
Mobile Softwares
1. 1 Introducing properties of mobile software development
1.1. Lecture 1 - Outline
• Motivation
• Restrictions of mobile software design
• Architecture of enterprise systems
• Communication
• Data storage
• Consequences of limited network access
• Application publishing
• Summary
1.2. MOTIVATION
1.3. Why are mobile clients important?
• Several years ago, it was not important at all!
• Today's enterprise applications
• Build on some kind of server side solution
• The thick client on the mobile side gives special interface to access the code at server side
• Often supporting temporary offline
1.4. Limited hardware capabilities
• Low computing performance
• Limited RAM
• Small permanent storage
• Small sized display with low resolution
• High data transfer price
• Lower network speed with higher latency
• Unreliable network connection
• Limited energy resources
1.5. Consequences
• 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 different densities (from the user’s point of view)
• Keeping density independency is very important. For example, a button can be larger on a smaller density screen
• The problems which are related to density can significantly influence the usability of the application
• Andorid helps to reach density independency with two ways:
• The OS calculates the dp, and scale the user interface from the actual screen density
• The system scales image resources automatically from screen density
2.41. Most important factors
• Use the wrap_content, fill_parent or dp units at UI design
• Do not use predefined pixels!
• Do not use AbsoluteLayout (obsolete)!
• We must create different image resources to handle different display densities anyway
• For text scaling it's worth to use scale-independent pixels (sp). They work like dp
2.42. Designing user interfaces
• Defining the layout and the resources in XML
• Assign the UI resource to the Activity
• Layout components from source code:
•
• Dynamic UI handling
• Supporting animations
2.43. User Interface resources
• Layout
•
• Text based resources:
•
• Image resources:
•
• Animation resources:
•
2.44. Some important layout
•
•
2.45. Pop-up windows
2.46. Menus
• Can be defined in source code
• Can be defined in resources
• Dynamic menus
• Set visibility
• Manipulation from Java code
• Supporting submenus
2.47. Localization
• Multi language supported
• Language independent surfaces and resources
• Resource types supporting localization:
• Images
• Layouts
• Text based resources
• Default folders:
•
•
• [fragile]
2.48. Creating styles
• Style file: res/values/styles.xml
<style name="ExampleStyle">
<item name="android:textSize">22sp</item>
<item name="android:textColor">#0000EE</item>
</style>
• Using a style:
<TextView
android:id="@+id/tvHello"
android:text="@string/hello_world"
style="@style/ExampleStyle" />
[fragile]
2.49. Using themes
• Definition like in styles:
<style name="CustomTheme" parent="android:Theme">
<item name="android:windowTitleSize">50dip</item>
<item name="android:textColor">#000000</item>
<item name=
"android:windowBackground">@color/white_color</item>
</style>
• Themes can inherited from each other
• Can set in the Manifest:
<activity android:label="" android:name=".MainActivity"
android:screenOrientation="portrait"
android:theme="@style/CustomTheme"/>
3. 3 Communication between components, Resources, User Interface
3.1. Lecture 3 - Outline
• Communication between components
• Resources
• Advanced User Interface
• Animations
3.2. COMMUNICATION BETWEEN COMPONENTS
3.3. Communication between components
• Every application runs in its sandbox
• Restrictions about sandbox
• Communication through Android OS
• Communication types
• Intent
• From one component to another
• Broadcast Intent
• From one component to others
• Content Provider
• Provides access to data to components
3.4. Intent
• Passive data structure
• Late runtime bind between components
• Components: Activity, Service, Broadcast Receiver
• Abstract description of an operation to be performed or an occured event
• Operation to be performed: if the intent indicates an operation
• Activity, Service, Broadcast Receiver registration / activation
• Occurred event: if an event indicates the intent
• Broadcast message [fragile]
3.5. Intent delivery
• Three type of target components
• startActivity[ForResult](Intent): start or continue an Activity
• startService(Intent), bindService(Intent): start or bind a Service
• send[Ordered|Sticky]Broadcast(Intent): reach all BroadcastReceiver which is interested
• Android OS locate the proper target and instantiate it if needed
• Intent only reaches one kind of component
3.6. Intent object
• Component name: the name of the component that should handle the intent
• If it is empty Android locate a suitable target
• Action: action to be performed or action that took place and is being reported
• Data: the URI and the MIME type of the data to be acted
• Category: additional criteria to the component handling the intent
• Extras: key-value pairs for additional information that should be delivered
• Flags: instruct the Android system how to launch an activity
3.7. Usage of intents
• Common usage: start a new activity
• Two types
• Explicit intent: explicitly defines the component which should be called by its name
• Implicit intent: do not name a target
• Specify the action which should be performed and optionally an URI which should be used for this action
• E.g. open a file, play a video, choose a contact
3.8. Explicit intents
• Explicit call: pass the name of the target to the constructor
• If there is an instantiates in the memory then it continues otherwise the Android instantiate and starts the target
[fragile]
3.9. Returning of an activity
• Sometimes a result is needed from an activity when it ends
• Solution: startActivityForResult(Intent, requestCode)
• To post a result from the target to the parent activity
• Call the setResult(resultCode) before finish()
• Handling the result with the callback function:
• onActivityResult(requestCode, resultCode, extras) {...}
• requestCode: integer, same as the code passed to the startActivityForResult
• resultCode: integer, numeric code of the result
• extras: Intent which can contain key-value pairs [fragile]
3.10. Intent Extras
• Inserting extra data
• intent.putExtra(name, value);
• Reading the data
• intent.get[Typename]Extra(name[, DefaultValue]);
[fragile]
3.11. Implicit Intents
• Implicit call: describe the action which has to be performed
• Multiple targets
• If no component fits
• ActivityNotFoundException
• If the system cannot decide
• "Complete action using" dialog
• Possibility to make Android OS to remember the choice
3.12. Implicit Intent - Actions
• There are a lot of built-in action
• Importants:
• ACTION_EDIT: edit, e.g. contact, file, picture
• ACTION_WEB_SEARCH: start google search with given text
• ACTION_CALL: dial the given number
• ACTION_PICK: choose from a list, e.g. from contacts, from gallery
• ACTION_VIEW: open with the proper application, e.g. installer, file, pdf, picture
3.13. Implicit Intent - Example
• Dial number
• Choose contact
[fragile]
3.14. Intent resolution
• Resolution based on Action, Data and Category
• Comparing the contents of the Intent object to intent filters
• Possible to register to handle intent with intent filters
• In [fragile]
3.15. Intent filter
• Advertise the capabilities of a component and delimit the intents it can handle
• there are built-in filters, e.g. ACTION_CALL, ACTION_IMAGE_CAPTURE
• Action: action which can be handled by the component
• Default or custom
• <action android:name=,,com.amorg.notes.SHOWNOTE''/>
• Data: which type of data can be handled by the component
• Given by an URI and/or a MIME type
• MIME: <data android:mimeType=''vnd.amorg.notepad.note/*''/>
• URI: scheme://host:port/path
• Category: describe the circumstances of handling an intent
• Important ones: LAUNCHER, HOME, DEFAULT
3.16. Intent resolution
• Android OS locate the component which is the best fit
• Only for implicit intents
• Complex process
• There are three tests to match intent with intent filters
• Action test, Data test, Category test [fragile]
3.17. Intent flags
• Used to modify the default behavior of launching an activity
• Important flags
• FLAG_ACTIVITY_NEW_TASK: new activity starts in a new task
• FLAG_ACTIVITY_SINGLE_TOP: if the target activity is in the Back Stack then it will be continued
• FLAG_ACTIVITY_CLEAR_TOP: if the target activity is in the Back Stack then all above will be cleared
• Set with setFlags() function
• Useful only in very rare cases
3.18. RESOURCES 3.19. Resources
• Separated from application code
• Maintain independently
• Externalizing resources allows to provide alternative resources that support specific device configurations
• Default and alternative resources
• Qualifiers in directory names
• Located in subdirectories of res/ directory [fragile]
3.20. Resource types
• Animation
• Saved in res/anim/ or res/drawable/
• Accessed from the R.anim or R.drawable class
• Color State List
• res/color/ - R.color
• Drawable
• Res/drawable/ - R.drawable
• Layout
• res/layout/ - R.layout
• Menu
• res/menu/ - R.menu
• String
• res/values/ - R.string, R.array, R.plurals
• Style
• res/values/ - R.style
• Other resource types
• res/values/ - R.* (e.g. R.bool, R.integer, R.dimen, etc.) [fragile]
3.21. Qualifiers
• Appear in resource directory names:
• To support specific device configuration
• e.g. different layout for landscape and portrait view
• layout-port contains layout for portrait orientation and layout-land contains layout for landscape
• Multiple qualifiers: drawable-port-hdpi/
• The qualifiers must be in a specific order (check out: developer.android.com)
• Examples
• Language for localization: en, fr, hu, etc.
• Screen size: small, normal, large, xlarge
• Pixel density (dpi): ldpi, mdpi, hdpi, xhdpi, nodpi, tvdpi
• Platform version (API level): v3, v4, v7, etc.
• etc.
3.22. Example 1/2
• Layout
3.23. Example 2/2
• String
• Menu
3.24. ADVANCED USER INTERFACE
[fragile]
3.25. Android Fragment Framework
• Fragment: represents a behavior or a portion of user interface in an Activity
• Advantages
• Modularize the code
• Reuseable: use in multiple activities
• Adjust the user interface to the screen
• Multiple layouts based on the size of the display
3.26. Fragment and Activity
• Fragments are attached to an Activity
• Their lifecycles almost the same
3.27. Fragment lifecycle
3.28. Different display sizes
[fragile]
3.29. UI Fragment
• Create
• Extend Fragment class and override onCreateView() method
3.30. UI Fragment
• Attach
• Dynamic
• Load the proper Fragment in runtime
• Static
• In Layout XML
[fragile]
3.31. Managing Fragments
• Manage fragments withFragmentManager class
• Activity: .getFragmentManager()
• Starting FragmentTransaction
• Find fragments with id or tag
• Managing Fragment-stack [fragile]
3.32. FragmentTransaction
• Modify active fragments throughFragmentTransaction
• Starting with the beginTransaction() method in FragmentManager
• Important methods
• add(), remove(), replace(): add or remove fragments in an Activity
• commit(): execute transaction
• show(), hide(): show or hide fragment instance
• setTransition(), setCustomAnimations()
• addToBackStack(): transaction can be added to back stack [fragile]
3.33. Communication
• Fragments have to be encapsulated indirect communication
• Activity acts like a mediator
If direct communication is needed:
setTargetFragment() getTargetFragment() [fragile]
3.34. FragmentDialog
• Fragment can appear as a dialog
• Dialog with custom layout
• Dialog has the same lifecycle as Fragment
• Fragment Dialog can be added to back stack
• DialogFragment is also a Fragment
• It can be shown as a part of an Activity layout [fragile]
3.35. Fragment parameters
• Fragment can be instantiated with its default constructor
• If additional parameters are needed
• Pass them with Bundle
• setArguments()
• The Bundle stores the data during initiation
• getArguments()
• The Bundle survive the changing of orientation [fragile]
3.36. Fragments in older versions
• Official support library
• Static class library
• Support from Android 1.6
• Support for additional components which come with new Android versions
• Loader framework
• GridLayout
• LruCache
• ViewPager
• etc.
3.37. ViewPager
• Layout manager that allows the user to flip left and right through pages of data with swipe gestures, e.g.
Google Play
[fragile]
3.38. FragmentPagerAdapter
• Usually the pages of ViewPager are Fragments
• FragmentPagerAdapter provides the pages
• Working is similar to BaseAdapter
• Fragment getItem(int position): returns the proper fragment
• int getCount(): returns the number of pages
• String getTitle(int position): returns the title of the given page [fragile]
3.39. PageTitleStrip and PageTabStrip
• Widgets which show the titles of pages in ViewPager
PageTitleStrip non-interactive
PageTabStrip interactive
3.40. ANIMATIONS
3.41. Property Animation
• Allow to animate almost anything
• Components
• Animators: provide the basic structure for creating animations
• Evaluators: tell the property animation system how to calculate values
• Interpolators: tell how specific values in an animation are calculated as a function of time
3.42. Property Animation elements
• Duration: the duration of an animation
• Time interpolation
• Repeat count and behavior
• Animator sets: group animations to play together or sequentially or after specified delays
• Frame refresh delay: how often to refresh frames of the animation
3.43. View animation
• Preform tween animation on View objects
• Base animations
• Rotate, scale, translate, alpha
• Defined by XML or Java code, but XML is preferred
3.44. Drawable animation
• Load a series of Drawable resources one after another
• Traditional animation which plays images like a roll of a film
3.45. Summary
• Communication between components with Intents
• Resources are separated from application code
• Qualifiers to create alternative resources
• Advanced UI with reusable Fragments
• Support library for older Android versions
• Create multiple layouts for different display sizes
• Three type of animations to create complex UI animations
• Drawable, View and Property animation
4. 4 Persisting and binding data on Android platform, Broadcast Receiver Component
4.1. Lecture 4 - Outline
• Persistent Data Storage
• Content Provider
• Data Binding
• Broadcast Receiver
4.2. PERSISTENT DATA STORAGE
4.3. Persistent Data Storage
• There are 4 ways
• Shared Preferences
• Store private primitive data in key-value pairs
• Files
• Store data on device memory or on external storage
• SQLite Database
• Store structured data in private database
• Network
• Store data on the web [fragile]
4.4. Shared Preferences
• Store private primitive data in key-value pairs
• boolean, float, int, long, String, Set<String>
• Data will be persisted across user sessions
• Even if the application is killed
• SharedPreferences class is an interface for accessing and modifying preference data
• Modifications through SharedPreferences.Editor object [fragile]
4.5. Using Shared Preferences - Write
• Call edit() to get a SharedPreferences.Editor
• Add values with put...() methods
• Commit new values with commit() method
[fragile]
4.6. Using Shared Preferences - Read
• Call the proper get...() method in SharedPreferences
