Dr. Zheng proposed that we focus on the authentication aspect of our app so that we have some basic functionality. There are two priorities for this:
- initial login functionality (user profile initialization)
- ensure that PIN entry works
--Eugene
Sunday, September 25, 2016
Update 09/25/16
In this week's meeting we shared the information we discovered regarding the localization part of our application. We found that iOS does not allow for the collection of low-level data, i.e., wireless access point information. We have yet to do research to determine a method of gathering this information on iOS. Dr. Kuo said she would inquire about collecting WAP information on iOS. Implementing this feature would increase our sample size in the user study that will be performed later.
Dr. Zheng proposed that we focus on the authentication aspect of our app so that we have some basic functionality. There are two priorities for this:
--Eugene
Dr. Zheng proposed that we focus on the authentication aspect of our app so that we have some basic functionality. There are two priorities for this:
--Eugene
Sunday, September 18, 2016
Update 09/18/16
Hugo and I have started experimenting with a variety of Qt's modules to understand how app features will be implemented later in development. We have also discussed methods of obtaining location information, as well as methods of facial recognition.
At the moment we are considering using OpenCV (Open Source Computer Vision Library) as the back end for facial recognition. OpenCV has a plethora of algorithms that will aid in the detection and recognition of faces. Since OpenCV's primary interface is in C++, it will integrate nicely with the C++ components of our app. The library has sufficient documentation and it is open-source, which is always a positive attribute!
Nico has been planning and designing the server-side part of our application. He has researched prospective classroom integration platforms for us to utilize. Mainly focusing on Moodle, we have decided that it will probably not be a practical method of hosting the server, due to issues discussed in Nico's post. In the coming weeks we will begin exploring other options for our server-side needs.
--Eugene
At the moment we are considering using OpenCV (Open Source Computer Vision Library) as the back end for facial recognition. OpenCV has a plethora of algorithms that will aid in the detection and recognition of faces. Since OpenCV's primary interface is in C++, it will integrate nicely with the C++ components of our app. The library has sufficient documentation and it is open-source, which is always a positive attribute!
Nico has been planning and designing the server-side part of our application. He has researched prospective classroom integration platforms for us to utilize. Mainly focusing on Moodle, we have decided that it will probably not be a practical method of hosting the server, due to issues discussed in Nico's post. In the coming weeks we will begin exploring other options for our server-side needs.
--Eugene
Wednesday, September 14, 2016
Server-side development progress
For the past three weeks I've been working on the design of the server-side component of our application, and consulting with Hugo and Eugene on how the client app is going to tie into this. This post focuses on the prospect of integrating our software with existing classroom management software to see how our software would utilize their APIs if we choose to support them, with a specific focus on Moodle. Since Moodle is a modular, plugin-based system, if we choose to integrate our application with theirs we would need to write a plugin composed of PHP, JS, HTML, and CSS.
Moodle seems to have substantial support for everything we need at first glance. The Enrollment and Access APIs provides functions that allow us to pull a list of the students' classes, check if our software is used in these classes, pull lists of the students in each class, and restrict the use of our software to those enrolled in the class through role-based authentication. Being role-based, this also allows the teacher to act as an administrator so that they can a student after attendance polling has closed if a student has forgotten their phone. The Attendance Module provides and modifies a database for storing students' attendance record, with pre-set options to account for being present on time, tardy, absent without an excuse, and absent with an excuse. Students may upload files, which we would use for the secret-sharing based authorization component of our application. Moodle also handles software updates and logging for us.
What's more, since Moodle is open-source, it is installed and managed by each school that uses it. This was an important design consideration-- if each school runs their own copy of our software, as opposed to us running one copy of the server that services every school, we would not need to concern ourselves with operating at a large scale, or with handling potential downtime. Since our plugin would also be open-source, it could be configured by each school to suit their needs. Because Moodle supplies so much support for us, I began to consider developing the entire server-side component of our software as a Moodle plugin, rather than just potentially providing support for it.
However, there were some serious drawbacks to this approach. First, Moodle's documentation is incomplete, and questions are generally handled by the community. While this is a common approach, this made it difficult to find information critical to continuing with this approach-- like whether an additional JSP could be run from inside our plugin to run our facial recognition algorithm, location-checking, random secret generation, and the other components of authentication our application requires. This would mean that Eugene and Hugo's mobile component would need to interface with this JSP, which would then make calls to Moodle, which I felt defeated the purpose of integrating fully with Moodle. Moodle provides a mobile application that users are free to fork and use for their own purposes, but because this is compiled with Phonegap and Hugo and Eugene have decided to work with Qt, this would be inconvenient. Since they are also implementing methods of authentication we felt were outside of the capabilities of Moodle's native interface, like capturing photos or completing lock patterns, I decided against integrating our server-side component fully.
This has been a very roundabout way of saying that I'm not going to do something, but not for naught! We learned a lot in the process of examining Moodle as a host for our server. Moodle provides enough support for integrating core components of our application that I could write a simple helper plugin to integrate our software with Moodle relatively easily. Since this is possible with Moodle, it is likely possible with alternative classroom managers like Canvas as well. Furthermore, the importance of each school running their own copy of our server-side software for scalability and modifiability reasons helped me to realize that developing a desktop application server for professors to run as they take attendance is the most flexible method of implementing our server-side design-- more on this in my next post!
--Nico
Moodle seems to have substantial support for everything we need at first glance. The Enrollment and Access APIs provides functions that allow us to pull a list of the students' classes, check if our software is used in these classes, pull lists of the students in each class, and restrict the use of our software to those enrolled in the class through role-based authentication. Being role-based, this also allows the teacher to act as an administrator so that they can a student after attendance polling has closed if a student has forgotten their phone. The Attendance Module provides and modifies a database for storing students' attendance record, with pre-set options to account for being present on time, tardy, absent without an excuse, and absent with an excuse. Students may upload files, which we would use for the secret-sharing based authorization component of our application. Moodle also handles software updates and logging for us.
What's more, since Moodle is open-source, it is installed and managed by each school that uses it. This was an important design consideration-- if each school runs their own copy of our software, as opposed to us running one copy of the server that services every school, we would not need to concern ourselves with operating at a large scale, or with handling potential downtime. Since our plugin would also be open-source, it could be configured by each school to suit their needs. Because Moodle supplies so much support for us, I began to consider developing the entire server-side component of our software as a Moodle plugin, rather than just potentially providing support for it.
However, there were some serious drawbacks to this approach. First, Moodle's documentation is incomplete, and questions are generally handled by the community. While this is a common approach, this made it difficult to find information critical to continuing with this approach-- like whether an additional JSP could be run from inside our plugin to run our facial recognition algorithm, location-checking, random secret generation, and the other components of authentication our application requires. This would mean that Eugene and Hugo's mobile component would need to interface with this JSP, which would then make calls to Moodle, which I felt defeated the purpose of integrating fully with Moodle. Moodle provides a mobile application that users are free to fork and use for their own purposes, but because this is compiled with Phonegap and Hugo and Eugene have decided to work with Qt, this would be inconvenient. Since they are also implementing methods of authentication we felt were outside of the capabilities of Moodle's native interface, like capturing photos or completing lock patterns, I decided against integrating our server-side component fully.
This has been a very roundabout way of saying that I'm not going to do something, but not for naught! We learned a lot in the process of examining Moodle as a host for our server. Moodle provides enough support for integrating core components of our application that I could write a simple helper plugin to integrate our software with Moodle relatively easily. Since this is possible with Moodle, it is likely possible with alternative classroom managers like Canvas as well. Furthermore, the importance of each school running their own copy of our server-side software for scalability and modifiability reasons helped me to realize that developing a desktop application server for professors to run as they take attendance is the most flexible method of implementing our server-side design-- more on this in my next post!
--Nico
Friday, September 9, 2016
Update - 09/09/16
In our meeting yesterday, we presented a draft of how the app UI will function and how the different screens will interact with one another:
We were also able to show Dr. Zheng and Dr. Kuo the intial UI we designed in Qt Creator:
Dr. Kuo suggested that we create a drop-down server list so that the student does not need to re-enter the server information every time.
We discussed different methods of fraud prevention like wifi-based localization and facial recognition, which will be implemented after there is a base app.
We decided that having the instructor input student details would be the easiest procedure to initially populate information. Another possible method of information population is interfacing with the Moodle/Canvas API and pulling student information from there.
There was also an idea for an additional feature where the app would send notifications to truant students, informing them of how often they miss class.
Dr. Zheng tasked us with creating a small localization-test app so we can determine the accuracy of the Qt Location module. We will also need to collect access point information for each classroom.
--Eugene
Dr. Kuo suggested that we create a drop-down server list so that the student does not need to re-enter the server information every time.
We discussed different methods of fraud prevention like wifi-based localization and facial recognition, which will be implemented after there is a base app.
We decided that having the instructor input student details would be the easiest procedure to initially populate information. Another possible method of information population is interfacing with the Moodle/Canvas API and pulling student information from there.
There was also an idea for an additional feature where the app would send notifications to truant students, informing them of how often they miss class.
Dr. Zheng tasked us with creating a small localization-test app so we can determine the accuracy of the Qt Location module. We will also need to collect access point information for each classroom.
--Eugene
Thursday, September 8, 2016
Initial Thoughts
I've researched several cross-platform app development frameworks. We want a platform that's free to use, powerful, and runs on iOS, Android, and Windows Phones. Candidates include PhoneGap, Xamarin, CodenameOne, and Qt. It would be difficult to maintain one code-base per OS, but this is also an option.
Qt seems like the best framework for our purposes. With it we can write efficient and multi-platform C++ code. Not only that, but it comes with a JSON/JavaScript-like domain-specific-language called QML for describing graphics layouts and most application logic. QML doesn't support networking so we will have to write the TCP or HTTP code using C++, but QML works well with C++ components.
Qt gives us the benefits of developing with PhoneGap, an easy-to-use language with WYSIWYG editor, and the benefits of writing the app using a compiled language as we would use CodenameOne and Xamarin.
I learned all of this from its very readable documentation --- another feature!
Qt employs asynchronous functions and a related concept called "signals" for handling many inputs, like clicks or network requests. When used right, these improve the application's efficiency; but we'll have to learn about this new control style.
--Hugo
Qt seems like the best framework for our purposes. With it we can write efficient and multi-platform C++ code. Not only that, but it comes with a JSON/JavaScript-like domain-specific-language called QML for describing graphics layouts and most application logic. QML doesn't support networking so we will have to write the TCP or HTTP code using C++, but QML works well with C++ components.
Qt gives us the benefits of developing with PhoneGap, an easy-to-use language with WYSIWYG editor, and the benefits of writing the app using a compiled language as we would use CodenameOne and Xamarin.
I learned all of this from its very readable documentation --- another feature!
Qt employs asynchronous functions and a related concept called "signals" for handling many inputs, like clicks or network requests. When used right, these improve the application's efficiency; but we'll have to learn about this new control style.
--Hugo
Subscribe to:
Posts (Atom)