TRANSITIONING CUSTOMIZED ACASI WINDOWS .NET SOLUTION ...

EJISDC (2015) 66, 2, 1-11

1

TRANSITIONING CUSTOMIZED ACASI WINDOWS.NET SOLUTION TO ANDROID JAVA ON LOWER-PRICED DEVICES AND TECHNICAL LESSONS LEARNED Stan Mierzwa Population Council New York USA [email protected]

Samir Souidi Population Council New York USA [email protected]

Karen Austrian Population Council Kenya Kenya [email protected]

Paul Hewett Population Council Zambia Zambia [email protected]

Adan Isaac Population Council Kenya Kenya [email protected]

Minyoi Maimbolwa Population Council Zambia Zambia [email protected]

Chung Wu Population Council New York USA [email protected] ABSTRACT Research-based organizations are continuing to find ways to leverage newer technologies in projects, specifically using lower cost hardware solutions if at all possible. There exist many electronic data collection solutions for purchase, as well as free open-source options to assist researchers and investigators, particularly those engaged in international public health. Sometimes, however, these solutions may not meet the specific needs of the research project. In this case, organizations may opt to architect and develop a custom product. Android devices, both smartphone and tablet-based, continue to expand into many markets globally, particularly in the developing world. These devices can be found in most major cities and local technology support for them, as well as an understanding of their operation is growing along-side this expansion in use. Recently Google chose India to introduce the first of a series of affordable smartphones under its Android One initiative, a bid by the company to win over the “next billion” users in emerging economies (Rai, Saritha 2014). Software developers may be required to transfer existing developed applications and programs to operate on the new Android-based devices. In our case we had a working Microsoft .NET program developed in the C# programming language that works well on Windows-based laptops and tablets, but it could not be used on the lower priced Android units. Converting the .NET application or at least the heavier programming logic in the application, to the Java language may be possible and the details of performing this task are discussed in this paper. Keywords: Self-report survey data collection; Electronic Data Collection; ACASI (Audio Computer-Assisted Self-Interviewing); CAPI (Computer-Assisted Personal Interviewing); CASI (Computer-Assisted Self-Interviewing); C#; Android; Java; Tablet devices

The Electronic Journal of Information Systems in Developing Countries www.ejisdc.org

EJISDC (2015) 66, 2, 1-11 1.

INTRODUCTION

After successfully developing a Microsoft Windows-based operational customizable electronic self-report data collection tool that had been used successfully for several years in the developing world it was requested that we move forward and re-write or modify the system for use on the Android operating system. According to eMarketer, mobile phone users will continue their rapid transition to smartphones as 3G and 4G network coverage expands and devices become more economical. (Processor.com, 2014). It is expected that by 2017, smartphones will eventually reach 2.5 billion in use globally. One of the key reasons for this rapid increase in smartphone sales is simply that the cost has continued to decline. According to Gartner, worldwide device shipments for PC (Desktop and Notebooks) are decreasing as compared with tablet computers and mobile smartphones. Demographers and social science researchers at the Population Council inquired whether it would be possible to take the well-defined and mature working PC ACASI/CAPI/CASI solution and create a fully working system to function on Android smartphones or mini-tablet devices. One of the main drivers for this request was that hundreds of devices would be needed for two projects in the developing world, and if it was possible to bring hardware costs down, it should be attempted. In addition it was thought that the older Windows-based version should be made available on the more open-source Android-based hardware devices. In this article we hope to detail how we decided to go about making an existing solution work on Android devices, the challenges we encountered and overcame, [the tasks that went better than we expected,] and the current state of the solution. 2.

METHODOLOGICAL APPROACH

2.1

Port a Working Application to Android

Mobile smartphone devices in many areas of the world where our scientists, demographers and researchers work are more often than not running the Android operating system. Although you will find some Apple iOS, BlackBerry and Windows smartphones, the majority of devices are configured with Android. Recent statistics reveal that Android usage increased by about 10% within the last one year from 17.67% in January 2013 to 27.97% in January 2014, thereby displacing Nokia’s Series 40, which had been the African continent’s leading mobile OS for several years (Techloy.com, 2014). When providing a mobile data collection solution for a project, it is most important to determine the popular platforms in use. There are several reasons for this; one important one is that in case there is a need for local “on the ground” technical support for troubleshooting or implementation, it is far better to find a platform that staff and users may already be familiar with. What this means is that for local implementation, we can rely on staff in the local countries for the assignment and not have to rely on project staff to travel from a headquarters office where, in our case, the Android data collection system was built. A frequent goal when introducing a technical system for international development projects is to transfer knowledge and ensure that the local incountry staff can utilize the solution independently and therefore be able to further engage both with that system and/or any future ones. Another reason that we decided to migrate a system that was already working to the Android platform is that we were able to find mobile mini-tablet computer systems that were lower in price than those made by other manufacturers, such as Apple or Microsoft. When we began, we knew that for at least two distinct projects in two separate countries, namely Zambia and Kenya, there would be a benefit experienced from the new system working on Android tablet devices. It was estimated that approximately 200 mini tablet devices would be needed. It was, The Electronic Journal of Information Systems in Developing Countries www.ejisdc.org

2

EJISDC (2015) 66, 2, 1-11 therefore, important to locate reasonably priced units that exhibited good performance. The units had to have at least 7 inches of screen real estate, an SD card interface, be sturdy enough to pass a simple drop test, and, of course, they had to test well with the software system that we had developed. The information technology team did consider whether it was possible to simply use an opensource solution, or purchase a product that would provide a combination of ACASI and CAPI survey technologies on the Android platform. After researching such existing products, we determined that such a product did not exist. One possible option was to take an already existing open-source application and modify it to provide the ACASI option, but after we had a less than optimum experience in modifying or customizing another open-source solution or for another heavy data-driven website, we decided we would go with our own solution. The benefits of migrating or modifying our own existing solution were that we were familiar with the programming logic already in place, the expected results of the method data were already collected and that the solution had been working well for many years. 2.2

Previous Experience in Building Self-Report Data Collection Systems that Provided Foundation and Experience

The Population Council’s Information Technology group has assisted with the creation of customized ACASI and CAPI/CASI (Computer Assisted Personal/Self Interviewing) solutions for over ten years in a variety of research projects. These solutions involved the development of a full customized ACASI module, in which respondents listen to prerecorded audio questions through headphones connected to a handheld computer and record their responses using a touchscreen (Mierzwa, Souidi, et. al., 2013). Our development experience includes designing data collection interfaces for semi-literate populations and implementing them in resource-poor areas. At the time of this publication, our team has overseen approximately 19 distinct research projects in 10 countries and in 21 different languages (Savel, Mierzwa, et.al., 2014). 2.3

Research Project Details

The initial version of the system that we created is being used in two research projects that are located in Zambia and Kenya. REacH (Randomized Evaluation of HIV/FP Service Models) is a randomized-controlled implementation science research project to methodically compare the incremental costs and resulting health service uptake and utilization of two experimental models of family planning and HIV service linkage and integration and is taking place in Zambia. (6) The Android ACASI solution that we created is also being used in the Adolescent Girls Empowerment Program (AGEP) in Zambia and the Social and Economic Assets for Vulnerable Adolescent Girls (SEAVAG) study in Kenya. AGEP and SEAVAG are programs that will enable Zambian and Kenyan girls and young women ages 10-19 to gain a comprehensive set of social, health and economic assets at age-appropriate intervals. For Zambian and Kenyan girls, social isolation, economic vulnerability, and lack of appropriate health information and services are critical problems that prevent a healthy transition from girlhood into womanhood. The issues that girls are confronted with – high rates of gender based violence, unsafe sex that puts girls at risk for unwanted pregnancy and HIV infection, dropping out of school, lack of economic resources or other income generating options, lack of agency and participation – are linked with one another through their root causes. (7) AGEP is a randomized-controlled trial that is testing three impacts of three different packages of services on key sexual and reproductive health outcomes. It also has a costing component.


3

EJISDC (2015) 66, 2, 1-11 SEAVAG is a quasi-experimental study that is examining the relationship between adolescent girls’ social and economic assets and their experience of sexual exploitation. 2.4

Building the Prototype

After we decided to convert the existing electronic data collection system to the Android platform, the question about whether to build a native app versus a web application arose. A web application is one that is typically accessed via the Internet using a smartphone or tablet web-browser. In the web app scenario, the processing of the web pages is hosted remotely on a server and information is passed from server to the web-browser on the client. A native application, on the other hand, is an executable program that is created to work on the proprietary operating system of the specific smartphone or tablet device. Depending on the device’s operating system, different programming platforms are utilized. The operating system is typically iOS for Apple devices, a version of Linux for Android devices, and Windows Mobile for Windows-based devices. Programming languages may also differ per operating system platform for the devices, but traditionally are Objective C for iOS, Java for Android and C# for Windows mobile units. There are advantages to both of the two approaches to providing applications for the Android platform. For these two projects, we decided that since interruptions in Internet service would be more likely to occur than not, we would need to opt for a native application. Native apps can more effectively use phone hardware such as accelerometers, gyroscopes, GPS, cameras and microphones as well as phone software applications such as contacts and calendar (Kiruspapillai, Craven, et. al., 2013). A native application does not necessarily require that the device be connected to a server to function. Consider the example of the game Angry Birds, where one can continue to play the game on an Android device without being connected to a remote server. Native applications also provide a greater range of options for the user interface that are provided by the Android Library (developer.android.com, 2014). Another option discussed during the initial design of the application was whether the application should be built to utilize the cloud. Such a system that utilizes more of the cloud or hosting would provide the ability to use very low-end smartphones and rely on a hearty backend system. One of the current approaches to the problem of low-end smartphones is executing the application completely on a resource rich server, thereby converting the client into a thin client. The client transfers only the events (e.g. screen taps, button pressed) to the server (Ghorpade, Chavan, et.al., IEEE, 2013). Although this idea was considered we ultimately decided against the cloud model given that consistent Internet connectivity would not be available in the local developing world environment. The original data collection solution was coded in the C# programming language and using the Microsoft Visual Studio integrated development environment (IDE). This combination of programming language and development tool could not be used to create the Java application for the Android platform. The Android operating system is built on a modified Linux kernel. The software stack contains Java applications running on a virtual machine, and system components are written in Java, C, C++, and XML (Butler, Margaret, 2011) After reviewing several different IDE’s we decided it was best to utilize the Eclipse JUNO platform for Java development and Java SE Development Kit 7 – both available freely as open-source. Eclipse was originally developed by IBM in 2001 (www.eclipse.org, 2012). The Eclipse IDE was quite different from Visual Studio, the IDE and development tool that was used to build the initial Windows-based data collection system, and therefore required a lot of “hands-on” interaction for us/our programmers to become comfortable with it. Since much of the logic and program functionality were and are working well in the C# .NET application, we wanted to re-write the exact functionality in the Java version for Android. This seemed like an The Electronic Journal of Information Systems in Developing Countries www.ejisdc.org

4

EJISDC (2015) 66, 2, 1-11 inefficient task to take on at first, but after reviewing and beginning the prototype we recognized that much of the logic and even some of the C# code could be ported to the new Java version. This was helpful in the effort or porting over some of the program code. Java and C# are very similar programming languages; both languages are class-based and objected oriented with runtime compilation (en.wikipedia.org, 2014 & www.oracle.com, 2014). That said, much of the programming code for declaring variables and calling forms had to be completely re-written because this works differently in Java. When it came to certain logic and objects developed, particularly in programming the logic in question template design, we were able to port some of the code from C# to Java with minor edits. When declaring standard controls in .NET, one could add a control and it would be automatically declared in the form and class. The controls are then only available in the class and cannot be used in other classes or forms unless it is declared inside User Controls or Inherit form/control. In Android Java, the design of the controls is done in a different section and needs to be referenced manually inside each Activity in which you wish to use them. One benefit of this approach is that you can use the same design layout in any activity. Another challenge in Java is that when using String declared variables, we found an inconsistency. In C# we were able to use an IF condition to check if a String was empty or equal to a String. In Java we modified this strategy by using the String.equal (String) format method. Team Foundation Server was configured for Eclipse as a source control system. However, it was found to be challenging to debug the application and ultimately we had to disconnect the source control system or we risked not completing the project on time. The originally designed Microsoft Access database could no longer be used in the Android platform and a conversion to SQLite was done. In order to perform the conversion, we used a third party tool called SQLite Data Wizard to handle the task. Java does have a solid SQLite library and we were able to use the same syntax as TSQL used in C#. 2.5

Some of the Challenges that Went Better than Expected

In building the Android solution and packaging it, the question of how to make it available for installation on devices was ultimately raised by the development team. Most Android applications are made available via the Google Play store. However, since the users of the system that we created were located in two countries in Africa where Internet connectivity can be interrupted and the application was only to be available and used by the study team internally, it could not be made available via the Play store. This became an issue when the program needed to be installed on several hundred devices. Downloading the application via a USB connection was attempted, but was slow during the transfer. Ultimately the application was copied to a micro-SD card and manually copied to each Android device, where it was independently installed. This may seem as if it was an atavistic way of doing things, but it worked well and also guaranteed that we would not run into issues because of Internet download speed, interrupted transfers, or no access. Performing software updates on Android devices that were not connected to the Internet was also done by transferring the database and .apk installation files via the micro-SD cards, which worked well. However, when replacing the database created with MySQL, we found that if we deleted the file in the destination folder first, we were able to transfer the file from the micro-SD card successfully. Again, this was a manual process, but worked well and did not require Internet connectivity. The Samsung Galaxy Tab II hardware devices were selected after evaluating several other units, including those made by Google and Lenovo. The units were less expensive than traditional touch-screen laptops and PDA devices that were used in the past. After almost ten


5

EJISDC (2015) 66, 2, 1-11 months of use as of the date of this write-up, the hardware and software are standing up well with almost no hardware failures. We also discovered that we could buy protective cases with keyboards built in at a lower cost than simple cases. 2.6

Challenges that Were Unexpected and What We Would Do Differently

The Android data collection solution was designed to be completely data driven. What this means is that the translated questionnaire text and response options, as well as the survey skip logic, were developed to be database-driven. In order to create the survey, the database fields needed to be populated. The survey questionnaires were lengthy for the initial use of this new data collection system, including over 150 distinct questions. Since the surveys were going through changes from the research investigators after the initial questionnaire design was completed, we ran into some version control issues. To combat this issue we began to keep a log and change control of survey change updates. In addition, a field was added to the database to record the exact version and date of the questionnaire. Since we experienced some database corruption during editing, a change was made in order to keep various versions of the database so that we would be able to back out to a previous version easily. Using dual monitors has its advantages when comparing questionnaire text and logic from the instrument source to the database version. A helpful hint, which may sound obvious but we feel is important, is to read over the survey instruments before entering the contents into the database. It would be easier to simply copy the contents without review, but we have found that despite the fact that members of our technology group are not scientists we do occasionally find errors or issues and this is helpful to the research investigators. During the setup and implementation of the devices, which included hardware and software installation, training, and follow-up after the initial data collection had begun, several challenges surfaced and needed to be addressed. This effort was led by the Information Technology specialist from the Population Council Kenya office, which traveled to Lusaka, Zambia to address the issues. The Samsung Tablet [hardware] was a new device on the market and one in which therefore was unfamiliar to both the research and implementation teams. Initially, both the assigned interviewers and the project development team thought it would be difficult to use or operate, but this concern quickly diminished as use continued. The tablet devices were more prone to scratches and thus in future projects screen protectors should or will be procured. During training several key points were reinforced in order to protect the devices and data security. Since the devices support Bluetooth and Wi-Fi connectivity, the training was adapted to include notifying the interviewers that it was their responsibility not to connect to insecure networks or to share any information or files. For project use, there was no need to connect to any network from the devices since data merging was done manually. During the training, many of the administrators were new to Android devices, and in becoming familiar with the units they began experimenting and changing some settings. While personal use of such devices may warrant changing the settings, for a study where standards need to be maintained, this isn’t optimum. In the future it would be beneficial to figure out how to “lock down” the devices so that settings could not be altered. After initial data collection had begun, a few observations were made that would warrent further adjustment of the implementation:


6

EJISDC (2015) 66, 2, 1-11  

 

Thoroughly charged tablets are required when interviewers are away from a power source for a full day. Therefore the tablets were put through a checklist daily that included charging them every evening to full charge. Investigators also suggested that a simple data aggregator or analyzer be created to give the data managers the ability to review all surveys done daily and compare against the planned daily output. This could be added easily to the devices themselves or perhaps on the centralized data manager computer where all surveys were merged. Since the hardware devices are bigger than PDAs, they are also more attractive and are at greater risk for theft. Because of this, the ability to track and trace lost units to a GPS coordinate was suggested. The rate of data collection increased much faster than anticipated. Although this was considered positive at first, it became apparent that the original design to merge the data with a dedicated data manager computer to centralize all data results in order to batch transfer the result data for analysis was problematic. This was because of the incremental growth of the results database that gets transferred. This was a concern of the research investigators because of the growth of the database of results. Because of this constraint it was noted that future versions of the application should include an improved mechanism for transferring the data.

Because of the request to complete the development quickly and be ready for the Phase 1 of data collection, the application was completed in less than six months. Despite this rapid development, by one developer, no errors were encountered with the data. Putting a strong emphasis on the logic to work as expected was critical as it is envisioned that the Android data collection system/solution will continue to be used, just the same as the .NET C# application which has been in production for almost seven years. An area where an emphasis was not placed was in the area of centralized data management. The existing strategy and application that had been used in the .NET solution were utilized to merge data from the Android tablet units. The data manager system allows all tablet units to merge into a Microsoft Access database on a centralized system. Although this process worked, it had limitations due to the number of records being captured; the process to merge and transfer the data to the researchers was slower than anticipated. Going forward a design to merge the resulting survey data online to an SQL server will be considered. 3.

DISCUSSION

Given that Android-based devices have only been around for a few years and were really only developed after Google purchased Android, Inc. in 2005, it would not be unusual to doubt whether these new products could be scaled up and used for a large data collection project. There is a general concern in the emerging areas of eHealth and mHealth that many projects incorporating technology are for the most part only being introduced into pilot projects; in these efforts the total number of devices is relatively small and can’t generally be scaled up for much larger efforts, such as expanding into different countries. Using lowercost technology devices, such as the Android devices we used in the project we describe in this paper, can be considered as contributing towards these smaller pilot projects. However, given the number of devices used in our project, the number of locations where they were used, and the number of surveys captured thus far, we have to wonder whether the effort should be considered in the context of a pilot or larger scale-up of implementation? Cost is often a big factor when preparing research project budgets as well as whether it is possible and even feasible to introduce information and communication technology. Two common questions that have been raised by donors during research protocol budget preparations are “what is the actual cost to introduce electronic data collection systems?”, and The Electronic Journal of Information Systems in Developing Countries www.ejisdc.org

7

EJISDC (2015) 66, 2, 1-11 is it actually worth the squeeze. These are hard questions to answer cleanly, meaning one would need to compare the cost of conducting surveys manually, perhaps via paper and pencil, with using automated technology. This question is easier to answer if you have historical data from previous studies. However, it can be inferred that the cost of introducing electronic data collection systems will be lower if it is based on a large number of surveys completed. If one is doing a small pilot study in which only several hundred surveys are envisioned to be collected, the cost per-survey will certainly be higher. 3.1

Results so far with the System

The rate at which records were captured using the new Android data collection was faster and the number of records much larger than the system designers originally envisioned. Between April 2013 and December 2013 thousands of electronic surveys were completed, at the rate of growth shown in Figure 1. During this same period, over a million records were created; the number reflects the number of surveys completed/administered and the questionnaire design, in which over 120 questions can possibly be administered to participants.

Figure 1.


8

EJISDC (2015) 66, 2, 1-11

Figure 2. 4.

CONCLUSION

It was possible to collaborate successfully with an IT staff person from our local Kenya office to do the remote installation, configuration, testing and implementation. This can be credited to the fact that Android devices are very prevalent in many parts of the world, particularly in sub-Saharan Africa, and are therefore familiar to staff in that office. In addition, having a technology expert available locally rather than in the United States proved to be invaluable. This provided for more efficient and clearer reporting of problems encountered with the application to the software development team in the United States. This also provided for better outcomes in terms being able to clearly explain and demonstrate how to use the application to any user who might need a little more time to get familiar with using Mobile Application Technology. In addition, some of the issues that would have been initially reported as “problems” were solved or explained without the need to consult the software development team. An example of this was changing settings on the devices. Furthermore, this allowed some problems to be solved locally. An example of this was the ability of our local staff to replace any missing or misplaced audio files that are required for the audio portion of the questionnaire should any devices be accidentally tampered with after final setup.. We also showed that it is possible to install Android applications and updates without going through the Google Play Store; updating software and data offline with an SD card works well. Despite their low cost, small device footprint, and low storage capacity, the rate of survey and record creation over the time period of the data collection reported in this paper demonstrates that it is possible to grow the number of records at a large rate on Android devices. Many Android devices are capable of data collection via open-source or free tools, such as the popular Open Data Kit (ODK) and FormHub. In addition there are data collection tools available for purchase such as Magpi and Ona.IO. Our team did consider the idea of using The Electronic Journal of Information Systems in Developing Countries www.ejisdc.org

9

EJISDC (2015) 66, 2, 1-11 one of the available tools; however, we could not locate one that would support the combination of CAPI and ACASI along with more complicated skip patterns with the ability to create customized detailed screen or question type solutions, so we opted for what we thought would be a solution that could be used on many different projects. Converting or transitioning a Windows .NET application to Java so that it can operate on Android devices is possible, but does require a manual conversion – practically a re-write. There are now available software development tools, such as the Xamarin mobile platform, that may be allow for writing applications in C# and Visual Studio and then be made available to run on iOS for Apple devices as well as Android devices. These classes of tools were not approached as a solution for converting the programming code for the project described in this paper. It should be noted that hybrid applications are beginning to emerge that provide cross platform solutions with abstraction via the same native Application Programming Interface (API) so that developers can write apps only using JavaScript and HTML5. With these hybrid applications one may be able to avoid writing such application programs as described in this paper for a particular operating system or platform. ACKNOWLEDGEMENTS We thank the behavioral researchers Erica Soler-Hampejsek and Eunice Muthengi, at the Population Council, for their efforts on the survey design and implementation expertise. We are grateful for the expert article editing by Irene Friedland and Craig Savel at the Population Council. This work was supported by the United Kingdom Department for International Development (DFID), the NoVo Foundation, and United States Agency for International Development (USAID) and Population Services International (PSI). REFERENCES: Android Becomes Most Widely Used Mobile OS for the First Time in Africa (2014) http://techloy.com/2014/02/04/android-becomes-widely-used-mobile-os-africa/, Feb 4. Butler, M. (2011) Android: Changing the Mobile Landscape, IEEE Pervasive Computing, 10, 1, 4-7. Ghorpade, S., Chavan, N., Gokhale, A. and Sapkal, D. (2013) A Framework For Executing Android Applications On The Cloud, International Conference on Advances in Computing, Communications and Informatics, 230-235. Hewett, P.C., Mensch, B. and Erulkar, A.S. (2004) Consistency in the Report of Sexual Behavior among Adolescent Girls in Kenya: A Comparison of Interviewing Methods, Sexually Transmitted Infections, 80, 2, 43-48. Mierzwa, S., Souidi, S., Friedland, I., Littlefield, S., Katzen, L., Savel, C., Boccio, D. and Ramarao, S. (2014). Approaches that Will Yield Greater Success when Implementing Self-Administered Electronic Data Capture ICT Systems in the Developing World with an Illiterate or Semi-Literate Population Population Council: http://www.popcouncil.org/uploads/pdfs/2013_ACASI-ICT.pdf Population Council (2011) Safe Spaces, Financial Education and Savings for Adolescent Girls in Zambia, award proposal. Population Council (2012), Implementation Science Research to Support Programs under the President’s Emergency Plan for AIDS Relief (PEPFAR): 1.3.6.d., award proposal. The Electronic Journal of Information Systems in Developing Countries www.ejisdc.org

10

EJISDC (2015) 66, 2, 1-11 Rai, S. (2014) Google Introduces Android One Phone for Emerging Markets, New York Times Bits, Sept 15th: http://bits.blogs.nytimes.com/2014/09/15/google-aims-atdeveloping-markets-with-android-one-initiative/?_php=true&_type=blogs&_r=0 Savel, C., Mierzwa, S., Gorbach, P., Meyer, K., and Souidi, S. (2014) Web-based, Mobiledevice Friendly, Self-report Survey System Incorporating Avatars and Gaming Console Techniques, Online Journal of Public Health Informatics; – in review Selvarajah, K., Craven, M.P., Massey, A., Crowe, J., Vedhara, K. and Raine-Fenning, N. (2013) Native Apps versus Web Apps: Which Is Best for Healthcare Applications? Human-Computer Interaction, 189-196. Processor.com (2014), Vol 36 Issue 3 http://developer.android.com/guide/topics/ui/index.html https://www.eclipse.org/org/ Comparison of C Sharp and Java : Wikipedia : http://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java http://www.oracle.com/technetwork/java/intro-141325.html


11