LokTalk Android Application

Designed and developed an android application that would help its users to get connected to a local area network without having active internet and without signing up. Followed Extreme Programming Development Lifecycle as part of the Software Engineering Course

Ovewview

The idea of the LocTalk was to design and develop an android application that would help its users to get connected to a local area network without having active internet and without signing up. The users will be able to have a talk among themselves, query, send and receive promotions, advertisements etc. The application will be of great utility in Wi-Fi enabled zones like shopping malls, classrooms, canteens, airports etc. If someone has this app installed in his mobile and a working Wi-Fi around him, then he can connect to others around him available on the local network. Asking for help from strangers, posting your queries and even advertising your products in the form of text can be done using this app. The app can be very useful in the following scenarios:-

• When you go to a shopping mall, you don’t need to roam around in various shops looking for best offers, all you need is LocTalk which will enable you receive the best ads on your mobile.
• You go to a library, someone already has the book which you want, you can request that person for the book by maintaining your anonymity.
• You want to promote your event, or sell your product, all you need to do is to post the ad in the app and your ad will reach to each and every person who is connected to the network having this app.

Sections

The design was mainly distributed into 3 parts: Tabs, Profile, and Personal chat. The distribution was done in this fashion as each of the parts is independent of the other. This allows us to classify functions and interlink them in the modules.

One of the main features of our application was different categories of tabs. Messages pertaining to a particular subject or topic would fall under its particular tab. This would allow user to quickly view messages of the topic he/she is interested in. But the perceived drawback this feature has, is that the various tabs cannot be diverse enough to cater to the slight difference many messages would have, nor would the tabs be comprehensive enough to cluster messages pertaining to ambiguous subjects correctly. The sole reason for this is human expression and language. Since often people try to convey a lot of things together creating these kind of inconsistencies. Hence this was a tradeoff between ease of message viewing and correct classification.

The next important motivation for this application was showing advertisements and offers. But since this is a group based application, there would be inevitable cases of spamming in the advertisement section. This would hide the important and genuine features in the junk of excessive messages. Hence we were compelled to introduce two types of users. The premium and the regular user. Only the premium user would be able to post advertisements in the advertisement tab. Since a person would have to buy the application to become a premium user, such users would not be very high and hence spamming in the premium advertisement tab can be controlled. The issue which arises next is that the USP of our app is communication over a local network but without internet connectivity. This voids the possible use of central servers to store user details. Hence there would be no way in which a user can every time verify whether he/she is a premium user through the server. Secondly, a central server design would have security issues and privacy concerns. Hence we decided to launch two applications. One would be the premium one and other the free one. The free application would not have an option to post premium advertisements. Hence, the application duplication was a design tradeoff to security and privacy issues.

The feature of private chat was inevitable. The naive approach would have allowed any user to initiate personal chat with any user (peer) connected in the same network. This design would have had a seamless user interaction, but could have resulted in a person spamming the inbox of other connected users with unwanted messages. Hence to counter this possibility, we have inserted a chat request barrier. A person can only chat personally if his/her peer is willing to communicate by accepting his request.