This post is a little out of the ordinary since it is not my idea, I’m simply posting so progress can be seen for the project.
At the beginning of this semester, I was approached by Bilal Bajwa and some other OSU students about an app idea that would stand to benefit the muslim student community at Ohio State.
The Problem: Those who practice Islam are required to pray five times per day as outlined in this CNN Article. This is not an issue within itself, however it can be when someone finds themselves in an unfamiliar place. Though, even in a frequented public space, it can be hard to organize, and often muslims find themselves praying alone in the presence of others not familiar with the practice.
The Solution: Bilal has proposed a mobile application that helps students organize into groups for the 5 prayers. They envision a system where a students with the app installed will receive a notification before the call to prayer. After logging in and checking in, the student will be presented with a map and list showing the locations of other students and groups that have already started to form in the area. The student will be able to “RSVP” to any of the groups presented, or will have the option to create their own. In this way, we hope to help Muslim students organize for prayer in a much more community-like setting.
This post is going to be a little non-traditional in that some work has already been done towards the final product. I will provide some detail into what has been accomplished already, and where we would like to take the application as we move forward.
What Has Already Been Done:
A couple of friends and myself took this up to the “Kent Hack Enough” Hackathon last month in order to test out the possibilities of the system. We discovered quite a few things about our capabilities. We designed the back end in NodeJS using MySQL for data storage, and the front end was very obviously Android (we are saving iPhone for later). A few issues became very apparent very quickly.
- Network calls in Android are an incredible pain. This isn’t the first time I’ve had to do this, however, I’ve never had to make so many different network calls in one application. All calls must be performed on a separate thread, and thus open the door to several potential race conditions, lots and lots of spaghetti code, and high indent levels.
- Authentication is going to be a real challenge. Due to the planned openness of the system, security will be of the highest concern. Storing user locations in a database comes with its inherent security risks and one of the tasks that was put on the backburner due to time constraints was this.
- Although the maps API in Android is much easier to deal with than I previously thought, half of the time was just spent getting the map to display. There are a bunch of issues that come up with the use of the compatibility library when displaying map fragments, and most of our time was spent trying to fix the same stack trace over and over again.
- The Dalvik runtime doesn’t do nearly as much garbage collection as I thought. Due to the large amount of data exchange and storage being performed, we were plagued by memory leaks that couldn’t be traced to a source. We will have to be much more diligent about this the next time around.
- Finally, I was not responsible for the back end implementation on this iteration. At the time of the Hackathon, I had never used NodeJS to design anything remotely similar to a WebAPI. There is a lot of code in there that I still do not understand, and MySQL is something I am very unfamiliar with. The back end is going to be implemented in a very different fashion this time around.
With all of the troubles, several good things did come out of the proof-of-concept.
- We got the map to work without any issues. As I said, the API is very simple in general, so most of the map manipulations were one line of code each.
- The back end did end up working. Although this part of the project will be overhauled in the next iteration, there is a lot that can be learned from the way it was done.
- Although not functioning in the final implementation, many of the map manipulations were working very well in the end. This won’t be terribly much of an obstacle this time around.
How It Will Be Done:
From all of the lessons learned at the hackathon, I have a much better idea of how I will be implementing We Pray this time around.
In general, there is not much that can be done about the Android network calls issues (unless I want to make my own library for it). I will simply have to exercise a lot more discipline with the extra time that I’m given.
In general, it won’t be terribly hard to just do the back end in NodeJS once again. Now that I have a little more experience with it, I can have the advantage of designing it around the needs of the mobile client as opposed to the other way around.
The data in this case is going to be highly relational. As much as it makes me cringe, the DB would best be done with some type of standard SQL implementation. All we really need is a user table, and a group table, and that’s honestly it. Some type of Cron-Job will need to be set up to clear out locations after certain events or time intervals.
The nature of the daily prayer is that they change every day based on the times of sunrise and sunset. I foresee the need of potentially two services here. The first service will be used to determine the prayer times for the day, so that they can be routed to the mobile devices as a notification. The second service I will need is a way to determine prayer times based on location. It is very possible that both of these exist in the same api, but this will definitely require some searching.
The final issue will be iPhone. I have never done iPhone, so I will either need to phone a friend for this, or swallow my pride and learn it. There really isn’t much else to be said about this.
This project’s source will not be made public until it is fully functional and operational. As per usual, I will be hosting the git repo on BitBucket, however this one will be private. I will also be diligent about posting updates since I will be the only one with access to the source.
Cheers,
Dan