PA 8001 2014 Practical 3

From CERES
Jump to: navigation, search

Objectives

There are two main objectives for this practical:

  • Learn about and use the basic concepts of Android programming
  • Understand the concurrency constructs in Android


Instructions

Submit a single .zip file on blackboard with two folders, each containing the solutions to the below-specified parts.

For the first application, specify beforehand at least four different test-cases and include them as a comment in your main class. Also for each non-trivial function specify pre- and post-condition and some test-cases. Implementing the test-cases using JUnit is not necessary, but will be considered a bonus.


For the second application, start with a list of scenarios (use-cases) that the following application should be able to deal with: the scenarios should specify what kind of interactions the app should support in which order so as to realize users' requirements. Subsequently make an architectural design (preferably, but necessarily, using notations such as UML Class Diagrams an Sequence Diagrams) to show how the application should be decomposed into a number of activities and services. For each activity design the layout beforehand. Then, start programming. After you are doing, update the scenarios and design to reflect what you have actually implemented; use the scenarios as test-cases and make sure that the app does what it is supposed to. The folder containing the second application should be structured into two sub-folders: the first containing a single pdf reporting on the scenarios, design, test-cases and their outcomes, and the other containing the Eclipse project.



Part 1: ADT Basics: Prime Factorization

Install Android SDK (or ADT bundle) from [1].

Make a new Android project similar to the one created during the lecture and further elaborated at [2].

Modify it in such a way that in the main activity the use can enter an integer n and in the second activity the prime factorization of all natural numbers from 1 to n is displayed (one by one in a text-box, with 1 second delay). If the entered text is not an integer, then an error message should be logged on the developer terminal, a toast notification is displayed and the second activity should not be started.

At any moment the user should be able to stop the calculation and return to the main activity.


Observe the behavior when a large natural number is entered. This is caused by the single-thread model in the application. Separate the threads for calculating next numbers and make UI reactive.


Part 2: Message Distribution List

The goal of this application is to implement an Android client for a distribution list manager. The functionalities provided by this client are listed below:

  • Start up: logging in to the server by providing a user ID
  • Creating a distribution list
  • Subscribing to a distribution list
  • Sending a message to a list
  • Fetching the messages sent to a list
  • Deleting the messages in a list
  • Bonus: Saving and Forwarding the messages


Starting up

To achieve this, you will be given message server and user partial implementation. The server listens on port 4444. Your app should first allow the user to enter this IP address and a unique ID; use your HH account login name as the unique ID throughout this practical.

Then the app tries to connect to the server; if unsuccessful it will make three attempts with a 10 second delay in between (while providing sufficient information as toast messages). If successful, the client will receive the following tag from the server


<Accepted connection from  id +/>


where id is the unique identifier (account name) provided by the client. Then, the app will provide the following options:

  • to create a distribution list
  • to subscribe to a list
  • to send a message to a list
  • to fetch the messages sent to your lists
  • to delete the messages in a list
  • Bonus: to saving the messages on the SD card, and
  • Bonus: to forward them using SMS


Creating a distribution list

The app shows a layout in which the user can enter a unique list ID and presses the submit button, the client sends the following structure to the server

<CreateList>
    <ListId "ESPMsg1"/>
    <Owner "HHID" />
</CreatList>

The serve will reply to the client with

<Request to create a list is accepted/>

if no list with the same ListID exists, or otherwise reply with:

<Request to create a list is rejected/>

This is shown by a toast message and the app will return to the main menu.

Subscribing to a list

The owner of a list is automatically subscribed to a list, but any other user can also subscribe to any existing list. This is achieved by choosing the Subscribe option from the main menu and then filling in the name of the list to be subscribed in and pressing the submit button. As the result, the following structure is sent to the server:


<SubscribeList>
    <ListId "ESPMsg1"/>
    <User "HHID2" />
</SubscribeList>


If the subscription has been successful, then the following message is displayed:

<Subscribed to group successfully />


Otherwise an error message with the following structure is sent:

<ErrorMsg>
    Reason
</ErrorMsg>

where reason specifies the reason for failure and it should be displayed as a toast message. The user should be able to edit the subscription data and submit again, or cancel it and return to the main menu.

Sending a message to a list

To send a message to the list, the Send option must be selected from the main menu and then the name of the list must be filled in to which the message is sent, and the message text, and finally the send button is to be pushed. As the result, the following structure is sent to the server:


<SendMsg>
    <ListId "ESPMsg1"/>
    <User "HHID2"/>
    <Msg> 
       Text 
    </Msg>
 </SendMsg>

If the message delivery has been successful, then the following message is displayed:

<Message delivered successfully />


Otherwise an error message with the following structure is sent:

<ErrorMsg>
    Reason
</ErrorMsg>

where reason specifies the reason for failure and it should be displayed as a toast message. The user should be able to edit the message, or cancel it and return to the main menu.


Deleting the content of a list

To delete all the messages in the list, the Delete Messages option must be selected from the main menu and the user must fill in the name of the list subsequently and press the submit button; then a confirmation screen will show up in which the user must press the confirm button (or otherwise cancel) . As the result, the following structure is sent to the server:


<DelMsgs>
    <ListId "ESPMsg1"/>
    <User "HHID2"/>
 </DelMsgs>

If the operation has been successful, then the following message is displayed:

<Deleted all messages successfully />

Otherwise an error message with the following structure is sent:

<ErrorMsg>
    Reason
</ErrorMsg>

where reason specifies the reason for failure and it should be displayed as a toast message. The user should be able to edit the name of the list, or cancel it and return to the main menu. Note that only the owner of a list will be able to delete all messages.


Fetching the content of a list

Members of a list can ask for all the messages sent to the list since its creation (or last deletion by the owner). To do this, the user has to select the Fetch option from the main menu, and then fill in the list name and submit. As the result, the following structure is sent to the server:


<FetchMsgs>
    <ListId "ESPMsg1"/>
    <User "HHID2"/>
 </FetchMsgs>


If the operation has been successful, then the following message is displayed:


<FetchedMsgs>
    <NumMsgs "2"/>
    <Message> 
       <MsgID "1" />
       <SenderID "HHID1" />
       <Content> 
              Text 
       </Content> 
    </Message>  
    <Message> 
       <MsgID "2" />
       <SenderID "HHID2" />
       <Content> 
              Text 
       </Content> 
    </Message>  
 </FetchMsgs>


Otherwise an error message with the following structure is sent:

<ErrorMsg>
    Reason
</ErrorMsg>

where reason specifies the reason for failure and it should be displayed as a toast message. The user should be able to edit the name of the list, or cancel it and return to the main menu. Note that only members are allowed to fetch the message of a list.

Storing Fetched Messages and Sending them as SMS

Each of these two additional task will count as a bonus (.1 point for the final mark). These options are enabled in the main menu only after a Fetch action is done (after which no delete should be performed). In that case, by clicking on each of these options, the user should fill in the file name or the telephone number and then the fetched messages will be saved or sent as an SMS. In both cases, the result of the operation (success or failure) should be shown as a toast message.

Back to Embedded Systems Programming