Archive | april 2014

Decision system optimization

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

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!

Client side update + change web service

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.