SlideShare a Scribd company logo
1.1. Concept
                    1.2. App Goals                             Introduction and
                                                                     Goals
                    1.3. General Goals

                    2.1. Communication Android-Server
                                                               General Diagrams
                    2.2. Entity-Relationship
Table of Contents




                    3.1.   Tasks done: Scaling
                    3.2.   Tasks done: Optimization
                    3.3.   Tasks done: Cache                        Tasks
                    3.4.   Tasks done: Non-Interactive Zoom
                    3.4.   Remaining tasks: Interactive Zoom

                    4.1. Technologies used: REST Imp.
                                                               Technologies used
                    4.2. Technologies used: ORM Imp.

                    5. Questions
                                                                                   1
1   Introduction and Goals




                             2
» Android App for graphical display of statistical data.
   » Diagrams should have zoom and scroll capabilities.
   » Different months, different series and different qualities
     can be selected.
   » Each user can enrich the application adding comments
     to the diagrams.




Concept                                                           3
» In any Mobile App, some factors to take into account,
   » Computational process is limited Heavier tasks must
     take place on the server.
   » Memory is limited Avoid heavy objects, or keep
     them in cache and instantiate them only when is strictly
     necessary.
   » Don’t waste bandwidth Avoid unnecessary, heavy or
     repetitive requests to the server.
   » Save battery Don’t make an intense use of the
     computational     processor    and   of   the   internet
     connection.




App Goals                                                       4
» Scale the charts to the Mobile screen resolution.
  » Optimize the transmission and the display of the
   charts.
  » Create an optimal mechanism to interact with the
   server in the zoom-in process.
  » Create a cache mechanism for retrieve previous
   graphs
  » Have different users with different access levels
   (chars, categories).




General Goals                                           5
General Diagrams




                   6
Web Server: Handle the request; transform it in a SQL
query; process it and creates the JSON representation for
the response.
Database: Basic DB behavior, response to the SQL queries.
Client: Performs an HTTP Request; converts the JSON
response to Java Object and display the results and/or
performs some data processing.

                HTTP/JSON
                 REST



                            Web Server
  Mobile App




                                                   Database
                                          TCP/IP




Communication Android-Server                                  7
Entity-Relationship Diagram   8
Tasks




        9
» Scaling (average algorithm) Fix Output = Screen resolution




Tasks done: Scaling                                         10
» Optimization (deleting,   or   nulling   the   duplications)
 Variable output




Tasks done: Optimization                                    11
» Why cache?
    Persistence ==     Requests ==   Battery consumption
» Two level cache implemented: Disk & Memory Cache.
   » MemoryCache  Offers fast access at the cost of taking
     up valuable application memory.
   » DiskCache  Persist valuable data retrieved from the
     Server. Fetching and writing process is slower than in
     MemoryCache.
» Both Caches are HashMap, and the key will be the HASH
 of the URL Request.
» Both caches implements the algorithm LRU.



 Tasks done: Cache                                            12
1. Create HASH of the URL Request.
2. Try to obtain the key from the
     Memory Cache. If works, go to 5.
3. Try to obtain the key from the
     DiskCache. If works, go to 5.
4. Retrieve the Chart from the
     Server.
5.   Save the chart in MemoryCache (Object) and DiskCache (JSON)




 Tasks done: Cache                                                 13
» Choosing between the following procedures,
   » Requests on demand Request to the server every
     time we zoom (slow and intense use of Internet).
   » Request when higher resolution needed Request
     more than you need (higher resolution), but not in each
     zoom.
   » Requests in advance Request in background other
     resolutions, that can be loaded directly when the user
     requires them (requires cache implementation).
» For the zoom, last procedure has been chosen




Tasks done: Zoom                                               14
» Request in advance for non-interactive Zoom
                        » Non-interactive Zoom Zoom
                          using the contextual menu on
                          Android. Used for moving among
                          Years/Months/Weeks/Days.




Tasks done: Non-interactive zoom                           15
» Request in advance for non-interactive Zoom
   » Interactive Zoom Two fingers and scroll zoom.
   » Whenever the zoom match the menu selection
     (Year/Month/Week/Day) the view is automatically
     changed to the match, and the corresponding action is
     performed (previous slide)




Remaining Task: Interactive zoom                             16
4   Technologies used




                        17
» Server Side
   » Use of Apache Tomcat as a Java Servlet Container
   » Use of Jersey Framework for implementing REST.
   » Use of Hibernate Framework for implementing ORM.
   » Use of MySQL as a Relational Database Management
     System.




Communication Android-Server                            18
REST: The predominant Web Service Model  Software
system designed to support machine-to-machine
interaction over a network.
Clients requests to servers; servers process requests and
return responses in a well known format.
» Transport layer is HTTP/MIME.
» The URI defines the resource.
» The operations are defined by the HTTP methods (GET, POST,
 PUT, DELETE)
» The response is presented in JSON format (indicated thought
 Media-Type).




REST Implementation                                             19
Advantages

» Simplifying the communication among independent and foreign systems.

» Organize an application into simple resources .

» No problem with firewalls and proxies (port 80, usually open)

» JSON is a lightweight text-based open standard and the Android parser offers
  good performance.

» Possibility of HTTP cache and proxy server to handle high load.

Examples

» GET http://example.com/charts Obtain List of Charts.

» GET http://example.com/charts/1?month=1 Obtain Chart info for January

» PUT http://example.com/charts/1 Modify Chart with id=1



REST Implementation                                                      20
ORM: Mapping technique for converting DB structure
Object structure
Advantages
» Simplify the development of a service.
» Overcomes vendor specific SQL differences - the ORM
 knows how to write vendor specific SQL so you don't have
 to.
Disadvantages
» Developers loose understanding of what the code is
 actually doing  the developer is more in control using
 SQL.
» ORM has a tendency to be slow, if is not used carefully.


ORM Implementation                                           21
Hibernate
@Entity @Table(name = "categories")
public class Category{
private int id;
private String name;
private String description;
private Set<Chart> charts;

@Id @GeneratedValue @Column(name = "category_id")
public int getId() { return id; }
public void setId(int id) { this.id = id; }
public String getName() { return name; }
public void setName(String name) { this.name = name; }
public String getDescription() { return description; }
public void setDescription(String description) { this.description =
description; }
@OneToMany(mappedBy="category", fetch=FetchType.EAGER)
@LazyCollection(LazyCollectionOption.FALSE)
public Set<Chart> getCharts() { return charts;}
public void setCharts(Set<Chart> charts) { this.charts = charts; }
}




ORM Implementation                                                    22
?   Questions?




                 23

More Related Content

PPTX
First spring
PDF
Project Presentation - First Spring
PDF
REST API
PPTX
Graphical display of statistical data on Android
PDF
Preparing your web services for Android and your Android app for web services...
PPTX
A great api is hard to find
PDF
Cross-Platform Data Access for Android and iPhone
PPTX
webinos - Architecture and Strategy
First spring
Project Presentation - First Spring
REST API
Graphical display of statistical data on Android
Preparing your web services for Android and your Android app for web services...
A great api is hard to find
Cross-Platform Data Access for Android and iPhone
webinos - Architecture and Strategy

Similar to TU-Charts Project - First Spring (20)

PDF
Architectural considerations when building an API
PDF
Vaadin - Rich Web Applications in Server-side Java without Plug-ins or JavaSc...
PDF
API Reliability Guide
PDF
Mobile Development Meets Semantic Technology
PDF
Intro to NoSQL and MongoDB
PDF
Designing your API Server for mobile apps
PPTX
Application architecture for cloud
PPTX
HBaseCon 2012 | Gap Inc Direct: Serving Apparel Catalog from HBase for Live W...
KEY
Real-world Dojo Mobile
PDF
Architecture of a Modern Web App - SpringOne India
PDF
Mobile apps & Server Apis, the weak link? par Emanuele Pecorari
PPTX
Skeuomorphs, Databases, and Mobile Performance
PDF
Ideas for addictive series 40 web apps
PPTX
Skeuomorphs, Databases, and Mobile Performance
PPTX
Building Cloud Native Applications
PDF
Developing modular, polyglot applications with Spring (SpringOne India 2012)
PDF
LinkedIn Data Infrastructure Slides (Version 2)
PPTX
Social Photos - My presentation at Microsoft Tech Day
PPTX
Common MongoDB Use Cases Webinar
PDF
Common MongoDB Use Cases
Architectural considerations when building an API
Vaadin - Rich Web Applications in Server-side Java without Plug-ins or JavaSc...
API Reliability Guide
Mobile Development Meets Semantic Technology
Intro to NoSQL and MongoDB
Designing your API Server for mobile apps
Application architecture for cloud
HBaseCon 2012 | Gap Inc Direct: Serving Apparel Catalog from HBase for Live W...
Real-world Dojo Mobile
Architecture of a Modern Web App - SpringOne India
Mobile apps & Server Apis, the weak link? par Emanuele Pecorari
Skeuomorphs, Databases, and Mobile Performance
Ideas for addictive series 40 web apps
Skeuomorphs, Databases, and Mobile Performance
Building Cloud Native Applications
Developing modular, polyglot applications with Spring (SpringOne India 2012)
LinkedIn Data Infrastructure Slides (Version 2)
Social Photos - My presentation at Microsoft Tech Day
Common MongoDB Use Cases Webinar
Common MongoDB Use Cases
Ad

Recently uploaded (20)

PPTX
SOPHOS-XG Firewall Administrator PPT.pptx
PDF
Hybrid model detection and classification of lung cancer
PDF
Univ-Connecticut-ChatGPT-Presentaion.pdf
PDF
From MVP to Full-Scale Product A Startup’s Software Journey.pdf
PDF
Assigned Numbers - 2025 - Bluetooth® Document
PDF
Enhancing emotion recognition model for a student engagement use case through...
PDF
Agricultural_Statistics_at_a_Glance_2022_0.pdf
PDF
7 ChatGPT Prompts to Help You Define Your Ideal Customer Profile.pdf
PDF
Video forgery: An extensive analysis of inter-and intra-frame manipulation al...
PPTX
OMC Textile Division Presentation 2021.pptx
PDF
Encapsulation_ Review paper, used for researhc scholars
PDF
A comparative study of natural language inference in Swahili using monolingua...
PDF
Web App vs Mobile App What Should You Build First.pdf
PDF
WOOl fibre morphology and structure.pdf for textiles
PDF
A comparative analysis of optical character recognition models for extracting...
PPTX
Digital-Transformation-Roadmap-for-Companies.pptx
PPTX
1. Introduction to Computer Programming.pptx
PDF
Approach and Philosophy of On baking technology
PDF
Accuracy of neural networks in brain wave diagnosis of schizophrenia
PDF
project resource management chapter-09.pdf
SOPHOS-XG Firewall Administrator PPT.pptx
Hybrid model detection and classification of lung cancer
Univ-Connecticut-ChatGPT-Presentaion.pdf
From MVP to Full-Scale Product A Startup’s Software Journey.pdf
Assigned Numbers - 2025 - Bluetooth® Document
Enhancing emotion recognition model for a student engagement use case through...
Agricultural_Statistics_at_a_Glance_2022_0.pdf
7 ChatGPT Prompts to Help You Define Your Ideal Customer Profile.pdf
Video forgery: An extensive analysis of inter-and intra-frame manipulation al...
OMC Textile Division Presentation 2021.pptx
Encapsulation_ Review paper, used for researhc scholars
A comparative study of natural language inference in Swahili using monolingua...
Web App vs Mobile App What Should You Build First.pdf
WOOl fibre morphology and structure.pdf for textiles
A comparative analysis of optical character recognition models for extracting...
Digital-Transformation-Roadmap-for-Companies.pptx
1. Introduction to Computer Programming.pptx
Approach and Philosophy of On baking technology
Accuracy of neural networks in brain wave diagnosis of schizophrenia
project resource management chapter-09.pdf
Ad

TU-Charts Project - First Spring

  • 1. 1.1. Concept 1.2. App Goals Introduction and Goals 1.3. General Goals 2.1. Communication Android-Server General Diagrams 2.2. Entity-Relationship Table of Contents 3.1. Tasks done: Scaling 3.2. Tasks done: Optimization 3.3. Tasks done: Cache Tasks 3.4. Tasks done: Non-Interactive Zoom 3.4. Remaining tasks: Interactive Zoom 4.1. Technologies used: REST Imp. Technologies used 4.2. Technologies used: ORM Imp. 5. Questions 1
  • 2. 1 Introduction and Goals 2
  • 3. » Android App for graphical display of statistical data. » Diagrams should have zoom and scroll capabilities. » Different months, different series and different qualities can be selected. » Each user can enrich the application adding comments to the diagrams. Concept 3
  • 4. » In any Mobile App, some factors to take into account, » Computational process is limited Heavier tasks must take place on the server. » Memory is limited Avoid heavy objects, or keep them in cache and instantiate them only when is strictly necessary. » Don’t waste bandwidth Avoid unnecessary, heavy or repetitive requests to the server. » Save battery Don’t make an intense use of the computational processor and of the internet connection. App Goals 4
  • 5. » Scale the charts to the Mobile screen resolution. » Optimize the transmission and the display of the charts. » Create an optimal mechanism to interact with the server in the zoom-in process. » Create a cache mechanism for retrieve previous graphs » Have different users with different access levels (chars, categories). General Goals 5
  • 7. Web Server: Handle the request; transform it in a SQL query; process it and creates the JSON representation for the response. Database: Basic DB behavior, response to the SQL queries. Client: Performs an HTTP Request; converts the JSON response to Java Object and display the results and/or performs some data processing. HTTP/JSON REST Web Server Mobile App Database TCP/IP Communication Android-Server 7
  • 9. Tasks 9
  • 10. » Scaling (average algorithm) Fix Output = Screen resolution Tasks done: Scaling 10
  • 11. » Optimization (deleting, or nulling the duplications) Variable output Tasks done: Optimization 11
  • 12. » Why cache? Persistence == Requests == Battery consumption » Two level cache implemented: Disk & Memory Cache. » MemoryCache  Offers fast access at the cost of taking up valuable application memory. » DiskCache  Persist valuable data retrieved from the Server. Fetching and writing process is slower than in MemoryCache. » Both Caches are HashMap, and the key will be the HASH of the URL Request. » Both caches implements the algorithm LRU. Tasks done: Cache 12
  • 13. 1. Create HASH of the URL Request. 2. Try to obtain the key from the Memory Cache. If works, go to 5. 3. Try to obtain the key from the DiskCache. If works, go to 5. 4. Retrieve the Chart from the Server. 5. Save the chart in MemoryCache (Object) and DiskCache (JSON) Tasks done: Cache 13
  • 14. » Choosing between the following procedures, » Requests on demand Request to the server every time we zoom (slow and intense use of Internet). » Request when higher resolution needed Request more than you need (higher resolution), but not in each zoom. » Requests in advance Request in background other resolutions, that can be loaded directly when the user requires them (requires cache implementation). » For the zoom, last procedure has been chosen Tasks done: Zoom 14
  • 15. » Request in advance for non-interactive Zoom » Non-interactive Zoom Zoom using the contextual menu on Android. Used for moving among Years/Months/Weeks/Days. Tasks done: Non-interactive zoom 15
  • 16. » Request in advance for non-interactive Zoom » Interactive Zoom Two fingers and scroll zoom. » Whenever the zoom match the menu selection (Year/Month/Week/Day) the view is automatically changed to the match, and the corresponding action is performed (previous slide) Remaining Task: Interactive zoom 16
  • 17. 4 Technologies used 17
  • 18. » Server Side » Use of Apache Tomcat as a Java Servlet Container » Use of Jersey Framework for implementing REST. » Use of Hibernate Framework for implementing ORM. » Use of MySQL as a Relational Database Management System. Communication Android-Server 18
  • 19. REST: The predominant Web Service Model  Software system designed to support machine-to-machine interaction over a network. Clients requests to servers; servers process requests and return responses in a well known format. » Transport layer is HTTP/MIME. » The URI defines the resource. » The operations are defined by the HTTP methods (GET, POST, PUT, DELETE) » The response is presented in JSON format (indicated thought Media-Type). REST Implementation 19
  • 20. Advantages » Simplifying the communication among independent and foreign systems. » Organize an application into simple resources . » No problem with firewalls and proxies (port 80, usually open) » JSON is a lightweight text-based open standard and the Android parser offers good performance. » Possibility of HTTP cache and proxy server to handle high load. Examples » GET http://example.com/charts Obtain List of Charts. » GET http://example.com/charts/1?month=1 Obtain Chart info for January » PUT http://example.com/charts/1 Modify Chart with id=1 REST Implementation 20
  • 21. ORM: Mapping technique for converting DB structure Object structure Advantages » Simplify the development of a service. » Overcomes vendor specific SQL differences - the ORM knows how to write vendor specific SQL so you don't have to. Disadvantages » Developers loose understanding of what the code is actually doing  the developer is more in control using SQL. » ORM has a tendency to be slow, if is not used carefully. ORM Implementation 21
  • 22. Hibernate @Entity @Table(name = "categories") public class Category{ private int id; private String name; private String description; private Set<Chart> charts; @Id @GeneratedValue @Column(name = "category_id") public int getId() { return id; } public void setId(int id) { this.id = id; } public String getName() { return name; } public void setName(String name) { this.name = name; } public String getDescription() { return description; } public void setDescription(String description) { this.description = description; } @OneToMany(mappedBy="category", fetch=FetchType.EAGER) @LazyCollection(LazyCollectionOption.FALSE) public Set<Chart> getCharts() { return charts;} public void setCharts(Set<Chart> charts) { this.charts = charts; } } ORM Implementation 22
  • 23. ? Questions? 23

Editor's Notes

  • #5: http://tomayko.com/writings/rest-to-my-wifeA resource is a concept that refers to this thing that you want it refers to a noun.A operation  it refers to a verb.So we can GET, POST, PUT and DELETE charts, categories, comments….Parameters AdjectivesThe other, are just different representations of the concept.
  • #13: Least Recently Used (LRU): discards the least recently used items first.
  • #14: Least Recently Used (LRU): discards the least recently used items first.