A little decision system revision has been done. Before, we send the people to the victim that were nearest to the victim based on their radius. We only calculated their route distance to check that the real route distance was smaller than 1000 meters. So if we would send 15 people these people would be the first 15 out of 60 people sorted on their radius distance between them and the victim and with a real route distance smaller than 1000 meter. Also to check the route distance for sending a volunteer to an AED and then to a victim was done by two API calls, one for calculating the route for a volunteer to an AED and one for from an AED to the victim.
Now I have done it a little different, I calculate the real route distance for all 60 people first and sort those first. And then send the first 15 to the victim with a route distance smaller than a 1000m and for the remaining I select the next 15 people in the sorted list who have a route distance smaller than 1000 meter with an AED in the route, the AED is seletected that has the least impact on the route distance for that volunteer. I have calculated that it takes 4 seconds for 60 Google Maps API calls. We need at least 15 Google Maps calls in the former decision system which would take around 1 second, so for the extra 3 seconds we could possible save minutes in real routing time! I haven’t done this for the AEDs tough, I could have calculated all routes to AEDs, and from AEDs to the victim for all remaining volunteers but this would be more costly. For example if the first 15 volunteers were picked and we have 5 AEDs in the vicinity of victim, we would have to make 225 API Calls resulting in additional 15 seconds! And that’s not really necessary because we already send 15 people that are closest to the victim, so they can help the victim while the other volunteers with an AED are on route. Now to be fair in our system if we are lucky we would still have to make 75 API calls resulting in 5 seconds. But the total calculating time is still half of the other calculation. Now as it was done before this would be incorrect because an AED route took 2 API calls instead of one. So this difference would be even bigger. However I did a small optimization, because the AEDs are the same for each volunteer, the same route from an AED to the victim is taken, the only thing that is different is the route to an AED. So if we would have 15 volunteers and 5 AEDs in the old version we would do actually 150 API calls! I have optimized this by calculating for those 5 AEDs the real route distance to the victim. This means we only do 80 API calls instead of the 150 API calls, saving us roughly 5 seconds in calculation time!
Another change is how the messages are pushed to the devices. First I made two lists of notifications, one list of all the volunteers that will receive a notification sending them directly to the victim the other list will contain the volunteers that are send first to an AED. Because of the queue system for the push server, I will now add them to the queue for processing as soon as the volunteer is picked out for notification.
In conclusion, we have added a 3 second calculation for the ordered list on real route distance, but by optimizing saved more than that!
More difficulties came to the surface when trying to deploy on the servers. The proxy server isn’t making it easy. To reduce the difficulties I have been asked to update the java push server library to a later model because newer versions allow for providing proxy settings. Unfortunately the newer version isn’t backwards compatible meaning the old code doesn’t work with the new library. You really have to make a lot of adjustments to the code. But now the system should run better. It now has a queue with multiple reads pushing the notifications in the queue to the devices, which adds a level of performance and that is nice! Also the code is now less complicated and you don’t have to specify the Apple host or port. Too bad these nice things came at the cost of changing code in the web service. However this doesn’t solve our problem, the notification is send but it doesn’t reach the device. Gonzalo Parra will look into this why this is happening it is not a program error but something to do with the server as it is working on my machine. This has delayed the evaluations however, I hope I can start them soon!
Made some small changes to the database and server. This because while reading my previous text I saw that I wanted to track which volunteers had actually received an read the notification, but I hadn’t put functionality in the web service and database providing this. So that has now been done. Now you can see which devices are notified, which volunteers read it and when and which of these volunteers actually arrive at the victim. Can be a handy tool when analyzing the evaluations.
Furthermore I have been writing, but haven’t found much inspiration. There is still a lot to do. I think I have around 30 pages of plain text now (35 with images and a couple of pages that are half full). I hope I will find more inspiration soon and that I can start with the evaluations.
Again I had to deal with some difficulties, hereby my progress isn’t as great as I had hoped. First deploying the war file of my web service on the department’s servers, was not that easy. Apparently there are some subtle differences between a Glassfish web service and a Tomcat web service. The code was exactly the same but the project looked a little different. It took me a little while to figure this out though. Also if the new war is deployed, it will be fingers crossed the PushServer does what it supposed to do. Because on Windows machines it runs without Errors, however it doesn’t really send anything, on Mac the same code does send the push notifications. So let’s hope on Linux servers it works as well!
The application is almost finished. The routing map does refresh the route every 10 seconds. So choosing a different route doesn’t pose a problem, the poly line on which you travel will also be removed and refreshed every 10 seconds. I wanted to just refresh the route when you deviate from the path and just update the polyline every couple of seconds. But I haven’t found a way to do this. To check if you deviated from the path and that to draw the polyline between your current position and the destination and not for the entire route. Maybe I’ll check up on this later on, but for now this will have to do. It isn’t optimal but it works, it just recalculates the route more than it really has to.
The application does something weird when receiving notifications, when you press the notification you can catch the notification in didFinishLaunchingWithOptions. However when you open the application not by clicking the notification but the app icon the launchOptions are nil. So it’s like you haven’t received a notification at all! You could catch this, by checking if you have badge, and asking the web service if a notification was send to you. Now before I program this extra functionality, which will produce new backend functionality, stored procedure, new functions for the web service, I want to test it on a real iPhone. It’s not very hard to implement this, but I will not do this unless it proves to be necessary.
Tomorrow I will start testing the application myself: the notification part and the navigation part. I also will start writing now. I am glad the programming part is almost over, and I can start writing. What I don’t look forward to is the debugging part. So fingers crossed that everything works from the first go!
As mentioned in my previous post I will now update the location of the user every 10 seconds when he is in an emergency situation. Otherwise every 5 minutes his GPS location will be pushed. And the device will notify the server when he is in an emergency situation and is near the victim (50 meters). Furthermore I saw there was a small bug in the web site I made yesterday for tracking users in an emergency case, I fixed that. The web service, as requested by Gonzalo Parra now works with a .properties file for accessing the MySQL database. He also asked that I look in to an error with .sql script I sent him for the database which I did. I also looked into how to produce a war file, I tried making this, and next Thursday I will go through this with Gonzalo Parra and hopefully deploy this .war file.
I have to add a custom back button in the application and also redraw the screen. But that will have to wait until Friday. I’m also going to examine how I’m going to build the thesis text.
I decided to add a little functionality in to the server side, making the testing and evaluating later on a bit easier. Now the web service can provide the gps pushes of all the volunteers notified for a specific emergency case. So you can track their progress. I will also do a small client side update tomorrow, when an emergency case is going on you won’t update your gps location every 5 minutes but every 10 seconds. So we can more accurately track the moments of our volunteers when they are rushing to a victim. Furthermore, added a website to the web service, where you can enter in the emergency case you want to track and you will see the victim displayed on the map and the volunteers that were notified. The site will refresh every 5 seconds the volunteers location, this making it easy to show their progress.
Tomorrow I will implement this change about the gps pushing in the client side. And try to finish some other stuff like notifying you have arrived at the scene or redrawing of the route to the victim while moving.
The client can now login, his token will be registered at the server. This is necessary to push notifications to the device. Every four minutes the GPS location of the device will be pushed to the server when the app is running, the app doesn’t have to run in the foreground it may also run in the background for this to work. I wanted to send the time when the emergency case was created with the notification, but I ran into a problem. The notification size became too large. So I had to implement a work around. When the device receives a notification it gets the emergency case id, with this id it can pull the additional information from the web service regarding the emergency case. The time of the emergency case is necessary because when you check the notification and so much time has passed that your help would be too late, an alert should be shown. It is implemented now as follows: Your route is shown first before checking if you would be too late. The checking is done based on the system timestamp minus the creation time of the emergency case, then I calculate the minutes necessary for you to travel over the calculated route (average speed 10 km/h), and when I add these two up you should still arrive within 10 minutes. If not, you get an alert message and you are redirected to the home page. But I faced a problem, I wanted to send the java.sql.timestamp with the json object. When receiving it looked something like: “Mar 6, 2014 9:00:47 AM”, when I tried to transform this string to an NSDate using a formatter using: “MMM d, yyyy, h:mm:ss a”, it crashed constantly, I tried some other format strings but none seemed to work. I debugged it, it crashed at the MMM, maybe some language settings or something, it didn’t recognize Mar as March. After losing lots of time searching the web for solutions and debugging it, I decided to do the following. In the web service remove the java.sql.timestamp and do the conversion there to a European format: “dd/MM/yyyy HH:mm:ss”. That worked like a sharm, too bad I had lost so much time on this simple thing.
Yet to be done is, deciding you are at the victim’s location and pushing it to the server. Also redrawing of the map. I will probably update the map every 10 meters or so, and recalculate the route, so if you go of track a correct route is still shown. Also when you have passed the AED, this destination should be removed from the route and you should only be navigated to the victim. Furthermore some debugging will be required and some alert views have to be added when you don’t have your GPS location tracking on or you don’t have internet access. Still a few things to do, I hope they do go smoother than these few things I did now.
I have been working on the client side and doing a little bit of refinement in the web service. The push server can now handle notifications with different types of parameters and the number of parameters can also vary. For now we only have two types of notifications, one where you are send directly to the victim and to other you are send first to an AED. Here you see you have different number of parameters the push server will handle the two in the same way. Also if you make a new notification type, you don’t have to alter the push server. The client can now login and register it’s device token for notifications also it will push it’s GPS location in a time interval of 4 minutes even if you minimize the application.