Computação Móvel Guide
Guide
User Manual:
Open the PDF directly: View PDF .
Page Count: 4
Download | |
Open PDF In Browser | View PDF |
Mobile Computing Practical Assignment #1 / Design and Development Android applications and services for a theater ticketing and payment Ticket and Payment System 1. Scenario A big music and event theater (for instance http://www.casadamusica.com) wants to provide to its customers an integrated system for an easy acquisition and validation of tickets and cafeteria vouchers. Each customer is previously registered in the system (where his identity was verified, and a payment means (a credit card) is also recorded). The customer account in the company server maintains a record of the tickets and vouchers acquired by each customer. A customer Android app allows him to consult the next few shows happening in the theater and to buy tickets for them, using the company remote server and an internet connection. When the event happens the customer tickets are validated from the customer smartphone in a validation terminal. Sometimes vouchers with free gifts and discounts are offered to the customer, to be redeemed in the local cafeteria. To accelerate the cafeteria operation, a customer can compose an order in his app and add some vouchers to be redeemed with it. He can then approach a cafeteria terminal and transmit his order. The vouchers will be taken into consideration and the resulting price will be automatically paid. In this way the cafeteria attendants only need to take care of supplying the ordered products. When a customer runs the application for the first time (and only once) he should register with the system, supplying some personal data (name, NIF, user name, password …) and his credit card data (type, number, validity). This information should be kept in the server data base. Then, customers can perform all the operations allowed by the app. Selling service Validation service Validation terminal (validation app) validate tickets result validate vouchers Company Server buy tickects present tickects Cafeteria order terminal make an order consult transactions Customer app Customer CMOV - Miguel Pimenta Monteiro 1 2. System applications This ticket and payment system is composed by 4 applications namely: 1. The remote service (a REST service) located on the company server (it can be divided into several groups of operations: register customers, sell tickets, validate tickets, emit and validate vouchers and consult transactions). 2. The Customer App allowing him to register himself in the system, consult shows and buy tickets, select and validate tickets at the entrance gates, compose an order to the cafeteria and eventually select and use gift vouchers, and consult past transactions. 3. The ticket validation terminal (at the entrance gates) runs an Android application capable of reading tickets from the customer app and validate them with the server presenting a validation result (indicating which tickets were validated and which were not). 4. The cafeteria order terminal runs also an Android application receiving from the customer app the ordered quantities of available products (for simplification let’s assume that the available products are only: coffee, soda drink, popcorn and sandwich) and at most two vouchers used in the price calculation. After validation of the vouchers the terminal should show an order number, products ordered, vouchers accepted and final price to pay. The customer then collects the products in another place at the cafeteria. 3. Operations and interactions The operations and interactions between these software pieces should be, at least, the following: 0. Registration – the first operation the customer app should do is to register the customer in the service. The customer should supply his name and NIF and credit card information (type, number, validity). Also, the app should generate a cryptographic RSA key pair, and transmit the public key to the server (in some format). If the operation succeeds a unique ‘user id’ (a uuid value – 16 bytes) should be generated and returned to the app. This ‘user id’ and generated private key should be stored locally by the app (the values are never shown to the user and the key should be in a protected keystore). The server takes note of all this information in some database. 1. Consult the next performances and buy tickets – the customer can see the next performances to be presented in the theater. Some info about each should be presented, including the performance dates and prices. An option to buy a given number of tickets is also present. A purchase is done transmitting the performance date and number of tickets, together with the registered ‘user id’, all signed by the private key of the user. A local user authentication can also be performed. After showing the intended tickets to buy, its total price, and getting the customer confirmation, they are bought and assumed paid using the customer credit card. Tickets are now emitted (with also unique IDs (another uuid)) and transmitted to the customer app. Both the server and the app store and take note of the tickets. For each bought ticket a cafeteria voucher is also generated (also with a unique ID (uuid)) for a free coffee or popcorn, randomly selected. These vouchers are also transmitted to the app and stored. Also, whenever the total paid value to the company by this customer attains a new multiple of say €100.00, another kind of voucher is created giving a 5% discount in a cafeteria order. Use the REST protocol for this interaction. Tickets should contain the name of the show, the date of performance, its unique ID and a place in the room (don’t care about availability and ensuring unique places). A voucher should have a product code (free coffee or popcorn or the 5% discount voucher) and its unique ID. 2. Present tickets – in this interaction a set of a maximum of 4 tickets can be transmitted to the validation terminal. The user must choose which tickets, from the available in his device, he wants to validate. The validation app should be configured to accept tickets for a single show CMOV - Miguel Pimenta Monteiro 2 (with the same date). The transmitted info must contain the user id, the number of tickets, the tickets’ IDs and the show date. The validation terminal should show in a very visible way if all the tickets were validated or not. All the presented tickets in the customer app pass now to a ‘used’ state, but are not deleted. In this way the customer can see their used tickets but not use them again. Note: If you have two Android real devices supporting NFC, that should be the communication channel between customer app and validation app. If you are using a single real device and an emulator, or two devices without NFC, you should use a QR code to transmit the information (use a byte representation to minimize the message size). If you are using two Android emulators the only available channel is a socket and TCP/IP. (See https://developer.android.com/studio/run/emulator-networking). Choose an appropriate solution for this communication channel. 3. Validate tickets – in this interaction the ticket IDs and the user id are sent to the company server for validation. The server should verify the existence of the ticket, belonging to that user, and that they were not yet used. The server changes the tickets state before sending back the validation result. Use the REST protocol for this interaction. 4. Make a cafeteria order – From a local menu of products each customer can compose a cafeteria order. If he owns vouchers he can add a maximum of 2 adequate vouchers to the order. At the cafeteria terminal the app transmits this information (user id, ordered products and vouchers). After validation with the server, the terminal should clearly show an order number (integer), the products in the order, accepted vouchers and the total price charged in the credit card (taking into account the accepted vouchers) with the customer NIF. All the vouchers presented by the customer (accepted or not) are deleted from the customer local data. All this info is signed with the user private key before sending. 5. Validate vouchers and pay an order – The order containing the vouchers, the ordered products and the user id, with signature, are sent to the server. The server verifies the signature and if the vouchers are valid and if they apply to the ordered products (only one 5% voucher is accepted in each order) and calculates the final price, using the accepted vouchers. Those are also marked in the server as used. Again, if the total value expended by the customer so far attains a new multiple of €100.00 a new 5% discount voucher is emitted (but not transmitted back), and assigned to the customer. The result information (validation and total price including accepted vouchers) is transmitted back to the order application. 6. Consult transactions – At any moment, and using an internet connection, the customer can consult his passed transactions (well, at least a few of them) of buying tickets and placing cafeteria orders. Whenever this operation is performed all unused tickets and vouchers assigned to this user in the server are transmitted back, and totally replace the local info existent. In this way used tickets are deleted from the customer app allowing the customer to recover some voucher transmitted by mistake in a previous order or not yet transmitted. 4. Signatures To verify a signature, the server should use the customer public key which was transmitted at the registration phase. The key pair is generated by the app (once) and the private key is kept stored there. For the signature keys use the “RSA” algorithm and a length of 368 bits, and for the signature algorithm use “SHA1WithRSA”. This produces a signature of 46 bytes which is the shortest, using standard algorithms. 5. Communications All the communications in all the operations, except operation 2. and 4., are done using the internet and the http protocol (in a REST service), over Wi-Fi or over the phone operator network. The communication between the customer app and terminals should use NFC or a QR code and camera. CMOV - Miguel Pimenta Monteiro 3 If you have two physical Android phones supporting NFC use them. If not, use the QR code technique. The QR code technique can also be used between a physical phone and an emulator. QR codes can only represent a small number of bytes, so the information coded should be the minimum possible (use binary values, not strings; in the Android or Java side you can use the ByteBuffer class for easy manipulation of such values). With one real phone and an emulator, the emulator should be the user phone presenting the QR code and the real phone can capture it with the camera. If you don’t have any Android physical phone available, you can use a TCP/IP connection between two different emulators. 6. Design and development You should design and implement the set of applications capable of comply with the described functions and demonstrate its use. The applications should have a comfortable and easy to use interface. You can add any functionalities considered convenient, and fill any gaps not detailed in this specification. You should also write a report, describing the architecture, data schemas, included features, navigation map, and performed scenario tests. The applications use should also be included in the report, presenting the significative screen capture sequences. CMOV - Miguel Pimenta Monteiro 4
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.7 Linearized : No Page Count : 4 Language : pt-PT Tagged PDF : Yes XMP Toolkit : 3.1-701 Producer : Microsoft® Word for Office 365 Title : Computação Móvel Creator : Miguel Monteiro Creator Tool : Microsoft® Word for Office 365 Create Date : 2018:10:08 10:39:00+01:00 Modify Date : 2018:10:08 10:39:00+01:00 Document ID : uuid:DF15B718-BEFA-4210-8EDF-A073C4AFF8BD Instance ID : uuid:DF15B718-BEFA-4210-8EDF-A073C4AFF8BD Author : Miguel MonteiroEXIF Metadata provided by EXIF.tools