Ram15144

3D-point-cloud-Visualization

3D point cloud visualization to understand the dense and sparse regions in the data.

Applied-AI

Projects in CS 514 : Applied Artificial Intelligence course in UIC

Automated-Tranportation-Survey

The Automated Transportation Survey (ATS) is a smartphone-based prompted recall travel survey that aims to support data collection initiatives for transport-modelling purposes. - Tracks the movement of the user all-day using GPS and stores the information in a database. Google Maps API is used and the routes taken by the user during his travel are monitored with GPS. - The information regarding the total stop time at a specific place and what the user did at that place is collected in the form of a survey. - The information is processed and provided to urban planners for better city layout. - Developed using Android Studio.

Broadcast-receiver-with-fragments-and-permissions

This project contains two Android apps which work together (API level 25). Here is a short summary of the apps: 1. MyApplication (A1) consists of a single activity containing two fragments. The first fragment consists of a list naming at least 6 Chicago landmarks (e.g., the Museum of Science and Industry, Wrigley Field, the Lincoln Park Zoo, etc.) Interactive app users can select one of the landmarks. When this happens, the selected item stays highlighted and the second fragment displays the web page of the highlighted item. This app also defines an options menu with at least two items: (1) exiting A1 and (2) launching the next application, Landmark Gallery (A2). A1 launches A2 by sending a system broadcast. In addition, application A1 maintains an action bar. The action bar shows the name of the application and the overflow area. 2. Application A2 is a picture repository; pictures are displayed in an Android Gallery. The gallery shows images from each of the landmarks discussed in application A1. A1 first starts the gallery in A2 by sending a global broadcast; A2 contains a broadcast receiver with appropriate filters to catch A1’s broadcast. When it receives a broadcast, A2 launches the gallery even though A2 was not running before A1 sent the broadcast. In addition, A2 defines a new, dangerous-level permission. The broadcast receiver contained in A2 requires that the broadcast sender (e.g., application A1) own this permission in order to respond to a broadcast. Use a meaningful and unique permission name of your choosing for the new permission. Also, make sure that A1 has the permission before sending the broadcast. A1 has the following design: When the device is in portrait mode the two fragments are displayed on different screens. First, the device will show only the first fragment. When the user selects an item, the the first fragment disappears and the second fragment is shown. Pressing the “back” soft button on the device, will return the device to the original configuration (first fragment only), thereby allowing the user to select a different point of interest. When the device is in landscape mode, application A1 initially shows only the first fragment across the entire width of the screen. As soon as a user selects an item, the first fragment is “shrunk” to about 1/3 of the screen’s width. This fragment will appear in the left-hand side of the screen, with the second fragment taking up the remaining 2/3 of the display on the right. Again, pressing the “back” button will return the application to its initial configuration, showing the first fragment across the entire display. The action bar is displayed at all times regardless of whether the device is in portrait or landscape mode. Finally, the state of application A1 is retained across device rotations, e.g., when the device is switched from landscape to portrait mode and vice versa. This means that the selected list item (in the first fragment) and the page displayed in the second fragment will be kept during configuration changes.

chicago-energy-visualization

Chicago-Ward-Cancer-Rate-Visualization

Visualization (map and bar graph) of the cancer incidence and the ward income for each ward.

Federal-Cash-Android-Studio

Get data from http://treasury.io/; parse and display it in the app according to the user input.

Guess_Game_Android_Studio

A strategy game called Guess Four in which each of two players sets up a secret sequence of four decimal digits. The two players take turns guessing the sequence of digits of their opponent. A player responds to an opponents guess by specifying the number of digits that were successfully guessed in the correct position and the number of digits that were successfully guessed but in the wrong positions. Thus, if a players chosen number is 2017 and the opponent guesses 1089, the opponent would be told that one digit was guessed correctly in the correct position (i.e., the 0), and another digit was guessed in the wrong position, (i.e., the 1). The implementation involves two background threads that play against each other while also updating the user interface with their moves. The first thread to correctly guess the opposing thread’s number wins the game. The UI thread is responsible for creating and starting the two worker threads and for maintaining and updating the display. Each worker thread will take turns taking the following actions: 1. Waiting for a short time (1-2 seconds) in order for a human viewer to take note of the previous move on the display. 2. Figuring out the next guess of this thread. 3. Communicating this guess to the opponent thread. 4. Waiting for a response from the opponent thread. 5. Communicating both the guess and the response from the opposite thread to the UI thread. While carrying out the above steps each worker thread is able to respond to guesses from the opponent thread. Whenever a guess from the opponent thread is received, a worker thread responds by communicating the number of correctly positioned and incorrectly positioned digits contained in the guess to the opponent thread. Furthermore, the game must proceeds in lockstep between the two threads. A thread is not allowed to make two consecutive guesses without handling an intervening guess from the opponent thread. The UI thread is specifically responsible for the following functionality: 1. Showing the two initial numbers chosen by the worker threads. 2. Receiving notifications of guesses and their outcomes by the worker threads. 3. Displaying the guesses and responses of each worker thread in an appropriate format as each worker thread communicates this information to the UI thead. 4. Displaying a button to start the game. Pressing this button while a game is in progress will void the current game and start a new game from scratch. 5. Checking on the status of the game, by determining whether one thread has won or the game needs to continue. 6. Halting the game after each thread has made 20 guesses without identifying the opponent’s number. 7. Signaling the two worker threads that the game is over; the two threads stops their execution as a result of this action. Displaying the outcome of the game in the UI. Implementation: 1. Handlers are used to implement the communication between the three threads involved. Each thread has a handler, a job queue and a looper. 2. Both runnables and messages are included in the job queue of the worker threads. 3. The two worker threads uses different strategies for winning the game. 4. The game is played at such a speed that a human user can clearly see and understand the move of each thread. 5. The app’s display has two layouts or fragments, one for each worker thread, lying side-by-side and occupying the entire screen width. Each side displays the secret number of the corresponding thread at the top and a scrollable list of the thread’s guesses and the opponent thread’s responses in the remainder of the vertical space. 7. The two worker threads will use a random number generator to create their secret number. These numbers are communicated to the UI thread, which will immediately display both numbers.

Huhu

Android app that helps people digitize medicinal prescriptions, get health hazard alerts in your area and analyse the previous health presented as a graph. * Built on Node js server, using azure cloud, Microsoft SQL database and Android Studio.

IBM-Watson

This bot chats with you to identify the food you have eaten. It provides feedback about how healthy the food was and it detects the mood of the user based on the messages typed.

Ram15144/Guess_Game_Android_Studio

A strategy game called Guess Four in which each of two players sets up a secret sequence of four decimal digits. The two players take turns guessing the sequence of digits of their opponent. A player responds to an opponents guess by specifying the number of digits that were successfully guessed in the correct position and the number of digits that were successfully guessed but in the wrong positions. Thus, if a players chosen number is 2017 and the opponent guesses 1089, the opponent would be told that one digit was guessed correctly in the correct position (i.e., the 0), and another digit was guessed in the wrong position, (i.e., the 1). The implementation involves two background threads that play against each other while also updating the user interface with their moves. The first thread to correctly guess the opposing thread’s number wins the game. The UI thread is responsible for creating and starting the two worker threads and for maintaining and updating the display. Each worker thread will take turns taking the following actions: 1. Waiting for a short time (1-2 seconds) in order for a human viewer to take note of the previous move on the display. 2. Figuring out the next guess of this thread. 3. Communicating this guess to the opponent thread. 4. Waiting for a response from the opponent thread. 5. Communicating both the guess and the response from the opposite thread to the UI thread. While carrying out the above steps each worker thread is able to respond to guesses from the opponent thread. Whenever a guess from the opponent thread is received, a worker thread responds by communicating the number of correctly positioned and incorrectly positioned digits contained in the guess to the opponent thread. Furthermore, the game must proceeds in lockstep between the two threads. A thread is not allowed to make two consecutive guesses without handling an intervening guess from the opponent thread. The UI thread is specifically responsible for the following functionality: 1. Showing the two initial numbers chosen by the worker threads. 2. Receiving notifications of guesses and their outcomes by the worker threads. 3. Displaying the guesses and responses of each worker thread in an appropriate format as each worker thread communicates this information to the UI thead. 4. Displaying a button to start the game. Pressing this button while a game is in progress will void the current game and start a new game from scratch. 5. Checking on the status of the game, by determining whether one thread has won or the game needs to continue. 6. Halting the game after each thread has made 20 guesses without identifying the opponent’s number. 7. Signaling the two worker threads that the game is over; the two threads stops their execution as a result of this action. Displaying the outcome of the game in the UI. Implementation: 1. Handlers are used to implement the communication between the three threads involved. Each thread has a handler, a job queue and a looper. 2. Both runnables and messages are included in the job queue of the worker threads. 3. The two worker threads uses different strategies for winning the game. 4. The game is played at such a speed that a human user can clearly see and understand the move of each thread. 5. The app’s display has two layouts or fragments, one for each worker thread, lying side-by-side and occupying the entire screen width. Each side displays the secret number of the corresponding thread at the top and a scrollable list of the thread’s guesses and the opponent thread’s responses in the remainder of the vertical space. 7. The two worker threads will use a random number generator to create their secret number. These numbers are communicated to the UI thread, which will immediately display both numbers.

Ram15144/3D-point-cloud-Visualization

3D point cloud visualization to understand the dense and sparse regions in the data.

Ram15144/Applied-AI

Projects in CS 514 : Applied Artificial Intelligence course in UIC

Ram15144/Automated-Tranportation-Survey

The Automated Transportation Survey (ATS) is a smartphone-based prompted recall travel survey that aims to support data collection initiatives for transport-modelling purposes. - Tracks the movement of the user all-day using GPS and stores the information in a database. Google Maps API is used and the routes taken by the user during his travel are monitored with GPS. - The information regarding the total stop time at a specific place and what the user did at that place is collected in the form of a survey. - The information is processed and provided to urban planners for better city layout. - Developed using Android Studio.

Ram15144/Broadcast-receiver-with-fragments-and-permissions

This project contains two Android apps which work together (API level 25). Here is a short summary of the apps: 1. MyApplication (A1) consists of a single activity containing two fragments. The first fragment consists of a list naming at least 6 Chicago landmarks (e.g., the Museum of Science and Industry, Wrigley Field, the Lincoln Park Zoo, etc.) Interactive app users can select one of the landmarks. When this happens, the selected item stays highlighted and the second fragment displays the web page of the highlighted item. This app also defines an options menu with at least two items: (1) exiting A1 and (2) launching the next application, Landmark Gallery (A2). A1 launches A2 by sending a system broadcast. In addition, application A1 maintains an action bar. The action bar shows the name of the application and the overflow area. 2. Application A2 is a picture repository; pictures are displayed in an Android Gallery. The gallery shows images from each of the landmarks discussed in application A1. A1 first starts the gallery in A2 by sending a global broadcast; A2 contains a broadcast receiver with appropriate filters to catch A1’s broadcast. When it receives a broadcast, A2 launches the gallery even though A2 was not running before A1 sent the broadcast. In addition, A2 defines a new, dangerous-level permission. The broadcast receiver contained in A2 requires that the broadcast sender (e.g., application A1) own this permission in order to respond to a broadcast. Use a meaningful and unique permission name of your choosing for the new permission. Also, make sure that A1 has the permission before sending the broadcast. A1 has the following design: When the device is in portrait mode the two fragments are displayed on different screens. First, the device will show only the first fragment. When the user selects an item, the the first fragment disappears and the second fragment is shown. Pressing the “back” soft button on the device, will return the device to the original configuration (first fragment only), thereby allowing the user to select a different point of interest. When the device is in landscape mode, application A1 initially shows only the first fragment across the entire width of the screen. As soon as a user selects an item, the first fragment is “shrunk” to about 1/3 of the screen’s width. This fragment will appear in the left-hand side of the screen, with the second fragment taking up the remaining 2/3 of the display on the right. Again, pressing the “back” button will return the application to its initial configuration, showing the first fragment across the entire display. The action bar is displayed at all times regardless of whether the device is in portrait or landscape mode. Finally, the state of application A1 is retained across device rotations, e.g., when the device is switched from landscape to portrait mode and vice versa. This means that the selected list item (in the first fragment) and the page displayed in the second fragment will be kept during configuration changes.

Ram15144/chicago-energy-visualization

Ram15144/Chicago-Ward-Cancer-Rate-Visualization

Visualization (map and bar graph) of the cancer incidence and the ward income for each ward.

Ram15144/Federal-Cash-Android-Studio

Get data from http://treasury.io/; parse and display it in the app according to the user input.

Ram15144/Huhu

Android app that helps people digitize medicinal prescriptions, get health hazard alerts in your area and analyse the previous health presented as a graph. * Built on Node js server, using azure cloud, Microsoft SQL database and Android Studio.

Ram15144/IBM-Watson

This bot chats with you to identify the food you have eaten. It provides feedback about how healthy the food was and it detects the mood of the user based on the messages typed.

Ram15144/Insert-new-Contact-using-Android-App

Project functional specification: The app starts off with a main activity containing a welcome message and a button. Upon pressing the button, your app displays a second activity containing a one-line editor field, a button, and a read-only text view. The second activity allows the interactive user to enter the first and last names of a person in the editor field. When the button in his activity is pressed, your app switches to a different app for adding a new contact with the specified first and last name. This app could be the built-in Contacts app in the device, or a different app with similar functionality that the device’s user installed on the device. Now the device’s user has a chance to enter the new contact’s information. The contacts app must return automatically to your app when a user saves a new contact. Alternatively, the user may choose to return to your app without saving a new contact by pressing the “back” button. Either way, when your app resumes it will display a message in the read-only text field indicating whether the user had successfully saved the new contact or not.

Ram15144/Picture-gallery-using-gridview

Android app that implements the following functionality. The main activity in the app displays a grid. Each grid cell contains a thumbnail picture of a car (from outside the car) above the name of the car’s manufacturer. For instance, a grid cell contains a thumbnail showing a Honda Civic, above the name “Honda”. The thumbnails are separated by thin spaces (no more than 5 dp) uniformly on all four sides when the grid is displayed on the android device. Also, the thumbnails are sized such that there will be 3 columns in portrait mode. Each grid cell supports two kinds of functionality, depending on whether an app viewer performs a short vs. a long click on a cell. A short click brings up a new activity that shows the entire picture of the selected car on the entire device display. This picture must be a higher resolution and bigger than the thumbnail displayed earlier. The user can return to the grid view by selecting the “back” soft button on the phone. However, if a user clicks on the displayed picture instead, you must open a browser activity showing the web site of the car’s manufacturer. For instance, if your app shows a picture of a Honda Civic, the app brings up the Honda web page from the official Honda web site. A long click on a grid cell brings up a “context menu” showing the following three options for the car under consideration: (1) View the entire picture (similar to a short click); (2) Shows the official web page of the car manufacturer in a new activity; and (3) brings up a list containing the names and addresses of three car dealers for the selected manufacturer in greater Chicago area. The gridview is designed in such a way that it will display optimally in portrait mode, and reasonably well also in landscape mode.

Ram15144/PrescriptionManager

Ram15144/Ram15144.github.io

Ram15144/US-county-shootings

Shows the deaths due to shooting in each US county and some analysis of the data in each county.