Android client improvements/Project Proposal
- Matt Raykowski
- Roman Tsukanov
Last year another GSoC student created Android application for OpenNMS. I discovered some issues with usability and UI, forked that project and made some improvements. Generalized list of changes can be found on my Trello board.
In this project I would like to make more substantial improvements and implement features that will make application more useful and easy to use.
Benefits to the OpenNMS community
OpenNMS users will get a very useful mobile tool for monitoring network on their Android devices. It will have a nice user interface, built according to Android design guidelines. Enhanced functionality of OpenNMS should attract more users.
Notifications about new alarms and list of events
In addition to lists of nodes, outages, and alarms, list of latest events can be added. User will be able to see events without having to open a web app.
To make user's life even more easier, notifications about new alarms can be implemented. User will not have to open application periodically to find out if something requires attention, Android's service can do this job in background, even when device is not being used. If something new comes up, service will create a new notification and vibrate or/and play the sound. If user would like to know more information about received notification, he can click on it to activate the appropriate activity. User will have options that will allow changing interval of background checks, choosing whether it is allowed to use cellular connection or Wi-Fi, or disabling that service completely.
Another important part of the app that requires attention is list refreshing mechanism. Right now it is very unstable. If some kind of error occurs during access to RESTful interface user will not know about it. Network may be unavailable, or information about OpenNMS server entered in settings incorrect. There are no error messages that will notify user about these kinds of issues. He will just see an empty list that says nothing. One way to fix this issue is to add toasts with error messages that will be shown if something goes wrong during list updates. We can also add checker to settings activity that will try to access server before saving information to help user identify connectivity problems easily. Or create dialogs with information about the error and suggestions about possible ways to fix it.
The last major improvement that I'd like to make is to add an ability to acknowledge alarms. Users will be able to do that from activities showing specific alarms. It should make application more useful and interactive. This feature can be implemented using /acks/ interface and Google's Resting library that is already used to get information about nodes, outages, and alarms.
Application will support Android 2.1.x (that is API level 7) and newer. This is a very broad range of devices. More than 99% of all Android devices registered in Play Store (based on April 2, 2013 distribution data) will be compatible with OpenNMS Android client.
We should keep using libraries like ActionBarSherlock to be able to use modern UI elements and features on older devices.
The final deliverables would consist of:
- List of events.
- Background service that will show notifications about new alarms.
- Refreshing mechanism improvements.
- Ability to acknowledge alarms.
I already began working on a prototype. You can find it in my repository on GitHub.
I will have exams between June 20 and July 6. During that time I may take some part of the day to prepare for exams. Also, sometime in the beginning of June (I don't know exact time frame yet) I will go to China to participate in a programming competition (for about a week). Although, these events shouldn't affect my GSoC schedule too much. I will be able to continue development on my laptop and will try to keep in touch with my mentor if I am out of town.
My planned schedule
I can start working on my GSoC project before my exams/trip during community bonding period. After the exams I am planning to devote around 35-45 hours per week for GSoC. I am certainly willing to put more effort if the project is behind schedule.
After May 27, when Google announces the accepted student proposals, the whole available time of GSoC is about 16 weeks. Accordingly, my planned schedule is:
May 27: Accepted students announced.
May 27 - June 17 (3 weeks): New list of events:
- Week 1-2: Finishing implementation of events list.
- Week 3: Testing of implemented features and improving layouts with information about specific items in lists.
June 17: Coding period officially begins.
June 17 - July 29 (6 weeks): Background service and notifications:
- Weeks 4-5: Implementation of background service that will check if user needs to be notified about something new.
- Weeks 6-8: Implementation of notifications.
- Week 9: Testing implemented features.
July 29: Mid-term evaluations.
July 29 - August 19 (3 weeks): Refreshing mechanism improvements.
- Week 10: Implementation of views for empty lists.
- Weeks 11-12: Resolving issues related to unset variables and list updating.
- Week 13: Implementation of error messages.
August 19 - September 16 (4 weeks): Acknowledgment feature:
- Weeks 13-14: Implementation of acknowledgment feature for alarms.
- Weeks 15-16: Final testing of all implemented features and bug fixing.
September 16: Suggested 'pencils down' date.
Tasks that should not bring a lot of unexpected problems have been moved to July and the beginning of August, so they will not be affected by exams and my trip.
I will keep in touch with community, make reports about development, and try to find people who are willing to help me test application and provide feedback.