Archive | maart 2014

Server side update

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.


Client side update

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.


Client side + refinement

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. 



I thought my presentation went well. The feedback I got was mostly about the presentation itself or about some extra features I could consider. But not much criticism towards my work itself, which is always nice.  In the next presentation I will try to make the figures explaining the decision system more easy to understand and not use 3D objects anymore. Also I think I may have gone a little too fast when explaining because it seemed at the amount of questions I got it wasn’t al clear how it all worked. So I will try do this better in the future. 

Decision system

I finished the decision system. I will explain the working of the system during my presentation on Wednesday. I checked most of the queries, not all of them, the simple update, insert and select queries will be automatically tested once a client is linked with the web service. So there is no need to spend time checking them now. The more difficult queries that support the working of the decision system have been tested however and all work. So the backend is as good as done. I also started with the push notification server. I can send messages now to the devices, I just need to pass the information needed for an emergency case and that part is done as well. Will try to finish this before the presentation and maybe implement what the client needs to do when a message is received. Don’t know if I will finish this in time for the presentation. But I am glad the back end stuff is as good as done and we can start linking the client with the web service.


I have finished making a MySQL database. This for the users to log in, to store their whereabouts and for the pushing of the GPS location and linking an iOS token to a person. Furthermore I have set up a web service that works with JSON, this service the device will access for doing all the things I mentioned above. This web service is done although not all the functionality has been tested, will explain later why. The web service uses stored procedure of the MySQL database so in the web service no queries are defined. These procedures have been written as well although again not all of them where tested.

Why is not everything tested? Because I am still working on the push notification server. I have wrote the client code for connecting to the push serve, but not the server code. Therefore the devices don’t get iOS tokens. These tokens are necessary for pushing the notification and updating their location and so on.

I also wrote a query for the decision system based on the pushed GPS location. The query will return all tokens and their location ordered by distance between them and the victim it will also show the update time. The push notification will have to retrieve these information remove all the users with a distance larger than one kilometer and also those entries whose updates where to old.

So there is still a lot to do. First the push server has be implemented, working on that as I wright this. Then the decision system has to be implemented. The decision based on the victim’s location and the pushed GPS location is easy now based on the query, but then the AED locations have to be integrated, so the users are routed first (if possible) to the nearest AED. Also if there aren’t enough users we will use their whereabouts stored in the database as well. After this is all done, implement it in iOS so the devices know what to do when a push notification comes in, maybe check again if they’re really in the neighborhood and then testing.