So far in this project there have been numerous problems and issues which have had to be researched and tackled which have ultimately led to quite a lot of hacking and the use of version specific code. Having thought I had passed the worst I started to look at implementing the RESTful API for backwards computability but have now hit yet another problem but this time with androids support for basic http authentication. As will be discussed later I’m implementing a truly RESTful API for once following closely to Roy Fieldings dissertation and avoiding creating a REST-RPC hybrid. For this reason I’m making use of as much functionality of the HTTP specification as possible and for security reasons will be creating the API with basic http authentication over an encrypted https connection.
The issue that has now arisen is that during the development of the android platform once again they have changed the libraries it uses and so Android 1.5 uses Apaches HTTP Client 4.0 Beta2 and so approaches HTTP authentication slightly differently. This will therefore mean that I will once again have to wrap classes and add another layer of complication to the project to just ensure that it remains compatible and that all the platforms can communicate in some manner.
Having now looked at the feasibility of this project on the Android development platform it has become clear that there will be many difficulties in developing this project but that with various amounts of hacking it will still be possible to achieve the desired functionality. At present the application will alter its operations dependant on the underlying Android platform thereby making use of various methods dependant on the current version.
For example Bluetooth is key to this project and as already demonstrated un interrupted communication can only be completed with versions 1.5 and 1.6 using JNI to hack into the underlying BlueZ library. Trying to use the same technique on higher versions is likely to crash the application and so at this level the application will revert to using the existing cellular network for data transfer and the official bluetooth API to detect devices. This is far from an idea situation but will effectively ensure that the core functionality continues to be supported. The problem that arrises from this is that an application must be developed that uses libraries that both the higher and lower levels can and can’t see. This is highly problematic both in terms of compiling the application as it is linked to non existent libraries and also during run time as inconsistencies on the availability of Bluetooth hardware and its state will only cause further errors. These runtime exceptions are hard to catch and so I have been experimenting on effectively catching these and preventing the application from crashing on the various Android platforms.
I have effectively found a method to overcome this making use of both Java reflection to determine if a function exists on the current platform and wrapper classes that can throw runtime errors preventing the main thread from crashing during execution. To prove this I’m porting a simply bluetooth application that scans for bluetooth users on both platforms making use of BlueZ and the official API to achieve this. Although this application appears to be compiling and running without error at present it is hard to determine the full functionality due to the lack of an Android phone to test the Bluetooth ability. Although this is true it is possible to test the emulators response to both techniques and the ability to determine if the higher libraries are available. Once this application has been verified as working I will wrap the current official API and the BlueZ functionality into several classes that can be safely called without crashing the main executing thread.
It is import for the application to be able to track the general movement of the user to ensure that later versions can create a detailed profile of the users activities and determine information such as the location of work and various meeting points. This could help generate a value for the say the users work life balance by categorising the time spent at each of the locations. To achieve this it is important to be able to support reverse geocoding so that the latitude and longitude of the user can be entered to determine what area or geographical features are near their current location.
This has been acheived though the use of the geonames database which provides a freely available database for the creation of web services. Through the use of this I have created a geocode.robhemsley.co.uk web service that allows users to pass various parameters such as the co-ordinates of a location and be returned details regarding the users current location. This is very similar to that available through the Google Maps API but more importantly as hosted locally has no bounds on the number of requests that can be made to the service. This means that if the service is still to be hosted within the cloud although this will clearly be a bottleneck I will have control over the access available.
As previously stated to help reduce the battery consumption of the mobile phone the background scanning service will be adjusted depending on the movement and location of the device. One of the basic measures will be the population density of the area which can be used to calculate the average walking speed of the population. This will then allow us to adjust the frequency of Bluetooth scans if there is likely to be a large number of people within the vicinity and determine the speed that they will be passing the device.
To be able to determine the population of the area the user is located within the web service first gathers the nearest 10 locations to the passed co-ordinates and then uses the DBpedia services to undertake a SPRQL query to find details relating to the specified place. The problem with this is that you must provide an entry resource for this query which created from the geonames location. This may differ though so for example the geonames database may return the place ‘City and County of Cardiff’ for the area of Cardiff. If this is to then be used with DBpedia there is clearly no entry under this name and is therefore stored under the shortened title of Cardiff. The web service will therefore try and strip the actual location and store this under which can then be used to attempt to get the population. If this is then unsuccessful the search is widened to the next nearest region and the search for the population with Dbpedia will be undertaken again. Only after all 10 closest locations have failed does the population revert to 0.
The XML shown below is gathered for a location whose geo co-ordiantes are within the Cathays area of Cardiff, Wales. To run this query the following URI is used: http://geocode.robhemsley.co.uk/?function=reversegeo&lat=51.490549&long=-3.180424&format=XML&fclass=A The arguments are self explanatory apart from fclass which relates to the feature class of request such as Area(A), Location (L), Place (P) further details can be found here with examples of each. The service currently only outputs XML but will shortly be converted to provide JSON as well.
<Locations xmlns:xsi=’http://www.w3.org/2001/XMLSchema-instance’ xsi:noNamespaceSchemaLocation=’http://geocode.robhemsley.co.uk/geocode.xsd’>
<Name>third-order administrative division</Name>
<Description>a subdivision of a second-order administrative division</Description>
Following on from the previous post on Android Bluetooth and the problems with connections and the requirement of prior pairing I have been able to do some testing on a G1 phone running Android 1.6. This phone lacks support for Bluetooth in the first place and so had to make use of other projects such as Bluetooth backport to be able to make use of the underlying functionality. These applications had limited success with some being unable to complete their intended functionality. As this was with the use of other libraries I wanted to try talking directly with the underly BlueZ libraries to see what was going wrong.
To achieve this I made use of the Android Native Development Kit that allows you to compile C/C++ code that can then be called from within your Java application therefore acting very similar to Java Native Interfaces. After converting some hello world type applications I was able to call upon the header files for the libraries associated with Bluetooth therefore gaining access to the Bluez library.
BlueZ is a mature linux library that is used in a variety of OS to provide Bluetooth functionality. Although having much functionality it lacks any form of documentation with the development community taking the stance that to use it you should read the source code. With this said I had previously bought the book ‘Bluetooth essentials for programmers‘ which has proved very useful in a variety of projects and luckily for this also contained a chapter outlining some basic functionality using the BlueZ libraries.
By hacking together the hello world application with this example code I was able to compile and successfully run the application and make a connection between a computer and the android phone sending some serial data. This therefore confirms that it will be possible to complete this project on the android platform without having to have root access to the device.
As the project will be running throughout the daily activity of the user it is important to ensure that the application can run in the background of the device without any visual interface. This has been one of the main reasons for looking at the Android OS due to its ability to create background services as required. This will therefore allow for the creation of life blogging type services which will gather the details of the Bluetooth devices around the user and their current location. Both these two features will require access to low level hardware which must be powered up to be able to take each reading. This will be a major concern within the application as these will create a substantial drain on the battery power of the device on top of running a thread continually throughout the phones operation. This issue has been highlighted by other manufactures who have only recently started allowing multi-tasking on their devices and only for very specific services such as music and geo location based applications.
Some effort should therefore be taken to reduce the amount of polling the application makes while running on the users device. Ideally some form of push service would be used to only start the application when some message is required but this would obviously still require some further backhaul technology which would be using power and so be similarly costly. This solution would also fail to solve the requirement of Bluetooth scanning which requires up to 13 seconds to complete an entire device enquiry on both trains to locate all possible devices. As we hope to detect devices passing the user ideally we want to undertake this scan as frequently as possible but would also clearly drain the battery within a few hours. To overcome this the hope is to use the zones identified with the users profile to determine the interval that scans should be made. If a user is clearly sleeping they are not going to be moving and so it is feasible to turn off the GPS service and only undertake a scan every hour. Of course when the current time becomes within the hour of the user normally waking the service can re adjust to every half hour etc until movement is seen when the GPS scan frequency can return to normal.
This approach can also be applied to Bluetooth scanning by determining the population density of the users current location. If your working within an office it is unlikely that you are to be detecting many new devices over time and so device inquiries can be reduced. Continual device inquiries are only required when the user is located in an area of high throughput and so by checking for movement via the GPS and determining the walking speed of the user or checking the type of environment such as urban/rural this can help make a decision on the frequency of scan required. As mentioned in the book ‘A Geography of Time’ people change their temp of life to reflect that of the environment and so by taking a users GPS coordinates this could be checked to find the nearest settlement which could in turn be checked against DBpedia for the population density. This would then allow us to determine roughly the average walking speed that should be expected for the area and so adjust the scan interval to reflect this. Certain environments will also have an effect on the required scan interval such as being in a cinema or a bar. Projects such as Tripod have shown the possibility of taking GPS data and attempting to find the landmark or region of interest for captioning of images. Similar techniques can therefore be used to try and determine the purpose of the users location and from this combine it with other users recorded GPS and scan details to show if there will be frequent changes over the next specified period of time and lead to appropriate adjustments.
The major concern with all of this is that a wider contextual information is required to make these assumptions effectively and as stated in the main research paper this should be undertaken within out the use of the internet. To try and bridge this I hope to locally record data relating to Bluetooth scans and GPS data and then once a day upload this for analyse. After this stage is complete the device will then receive an updated profile and an interests file stating location points, landmark types, categorisation of activities at this place etc which can then be used locally without further network access. As more users then start to use the system and more data is created over time the battery life and efficiency of the device will increase as it synchronises with your daily schedule of life.
I have recently just finished the book ‘A Geography of Time‘ by Robert Levine a Social Psychologist. In this book he outlines how our perception of time varies around the work and documents the various factors that effect our interpretation and understanding of the progression of time. The book has proved useful in showing various metrics have been used in clarifying the personality of people in terms of their tempo in life and how daily activities can be divided into various time zones.
The idea of zoning peoples days into various categories such as work, leisure, sleep etc will be useful within this project as it will allow us to greater shape the users profile giving the ability to determine the users work life balance and build up an idea of the purpose of the users location. This will be achieved though the creation of a service similar to that of life blogging where the the location and devices around the user will be recorded throughout the day. This will then be uploaded to the server at a predefined time interval such as once a day where the data can be appropriately analysed to categorise key locations and time zones throughout someones normal life. This can then be amended to the users profile allowing the application to make decisions on the users current location and purpose without having to continually check with the server using the internet.
To achieve this the backend server will clearly have to do heavy data analyses and data mining to find patterns in the users daily life. This has raised some questions about using cloud services as currently there is no support for sql databases and so much effort will have to be made to achieve the same goals. One of the major difficulties if cloud services are to be used is that there will be no prevision for geo spatial data objects making it hard to easily query the data set and determine basic relationships. This will be later discussed shortly before implementation.
Having looked closer at the Bluetooth API 2 that the Android supports it has become clear that for their own security reasons they have decided not to support the creation of unencrypted and non authenticated connections. This means that unlike J2ME development where as long as the developer has control of both the client and server that connections can be made without pairing with Android this is simply not possible.
Their approach has been to abstract the pairing from the developer automatically blocking your applications thread and starting the pairing process for you without any further programatic control. This issues has been raised on thread such as this where it has been clarified that it is not possible with the current API to create a connection without first pairing the devices. Feedback from Google has been that they will look into this but will not take this step lightly as they want to weigh up the users privacy with convenience for the developer. Within this project this is clearly a major obstacle and is likely to require the movement of the project onto another development environment.
Before this decision is made I will continue to look into the possibility of bypassing this by plugging into the original underlying BlueZ libraries. I have no experience of JNI or the BlueZ libraries with Android and so this may yet prove impossible but due to my lack of C/C++ experience this route should be explored first.
Having looked at the Android Bluetooth API I have discovered that unlike J2ME application development all devices must be paired before any communication can take place. Therefore regardless if the device is running a custom server application on a device it still has to undertake the pairing procedure first. This would mean that whenever two users pass that they would have to pair devices which would completely defeat the purpose of the project. To even compare the suitability of the users messages the two parties would have to meet and swap automatically generated pairing pins. If you were to share a message with a stranger then this would clearly create difficulties as you would have to firstly identify the user and then ask for the pin…
I have been trying to find any form of hack to overcome this but at present have been unsuccessful. The only hope is to be able to implement a third party library that supports the full Bluetooth specification. In terms of the maturity of Bluetooth on Android it has only recently been provided with the original versions simply not supporting any form of Bluetooth connectivity. For this reason the current implementation lacks much functionality and only supports a small number of protocols making it rather inflexible.
The plan is to investigate potential JNI use to be able to get access to the underlying Bluetooth stack implementation in its native language.
Within the application users can receive messages from many different people be they close friends or complete strangers and so the labelling of an utterance is important in providing the user with the appropriate level of detail. For example when receiving a message from a complete stranger being presented with their full name is ineffective in portraying the relationship or type of interaction that has taken place. As messages are distributed based on the physical interaction the user undertakes it is important to be able to categorise how two users interact and their relationships.
Overtime a profile is created for the user which shows their general schedule and pattern of movement and as such allows the identification of say home and work locations which in turn can be found and used to categorise the other devices around the user at these locations. From this groupings can be made so that disseminated messages can then be categorised accordingly and the senders relation to the user in turn identified.
For example if the application was used within the Computer Science department in Cardiff University as a student the system should over time be able to determine over time the following levels of interaction.
Cardiff University Computer Science Student
Cardiff University Computer Science
Within society social networking tools such as Facebook and Twitter have become common place with users continually uploading further information about their lives and their social interactions to these systems. By doing so there is becoming an ever increasing collection of information that has no defined life span and so is set to archive the activities of the user long after their interest in these systems has ended. In society people remember events differently with variations taking place as peoples recollection of an event alter over the progression of time. In this environment where the facts are maintained forever this is lost and instead a permanent record is kept. This raises many privacy concerns as after an event occurs in the digital world it is not possible to forget and move on instead the event is catalogued forever and can be recalled precisely by all.
Anne Galloway on her blog back in 2003 talks of this concern and the longevity of information that she saw in the many emerging ubiquitous devices. Although this pervasive networked world of devices has not developed social networking has taking its place hoarding information as she saw. In this post she mentions the various reasons why memory changes and the types of memory loss being actively undertaken by people. Within this post she uses the term ‘Forgetting Machines’ which has fascinated me for quite some time with the thought that it would be desirable to add noise or inconsistency to collected data over time. In this way it would then be possible to better reflect human nature placing a life span on information or forcing the portrayal of events to change by some degree. The problem with this approach is clearly altering information and ensuring it correctly reflects the original events without miss representing the information. The difficulty in this and frankly the undesirable effects have meant this has not been pursued further as I was unable to define an approach which would ensure that false information was not created.
This topic though has recently resurfaced with an article on data fading by which the granularity of information shown adjusts overtime. This allows for information such as age to become less precise over time changing to banded groups such as 20-25 over the life time of the data. I feel this approach goes some way to addressing the problem and provides an implementation that produces the desired level of noise within the data without leading to misrepresentation. This simple approach works well and I feel should be implemented within any social networking structure to ensure that user generated content does not remain indefinitely in full detail but becomes more summarised over time.
Within this project I hope to apply the concept of data fading/forgetting machines within both the construction of the user profiles and the messages they disseminate. For example the location of the user will be recorded and so over time the potential area that the user was recorded within should widen giving greater anonymity as time progresses.