Hi all, Nick here. I will be talking about our newest feature in our app: the regular background checking of IVLE announcements.
Previously, the user had to manually press the refresh button in the announcements page to retrieve any new announcements from the modules. This might cause the user to miss some important announcements because it is not intuitive to manually keep on checking the announcements. So we decided to ask the app to do the checking for the user instead!
The user can set the time interval between each checking. Timings range from 1 hour to 24 hours. In our current app, we have an option for a 15 seconds interval, but this is intended for debugging and testing purposes only. Nobody should be so crazy to always want 15-second updates from IVLE. On the other hand, if the user does not want regular updates from IVLE, the feature can be turned off in the settings page.
The regular checking is implemented using the AlarmManager class given in the Android API. We normally think of alarms as the ring-ring machine that wakes us up in the morning. Well, the Android AlarmManager is similar. It can set a specific time, interval and repetitions for certain activities to happen on the phone. We make use of this convenient functionality for our app.
As mentioned previously, the user can set the refresh interval in the app's settings page. Once set, the app will then call the AlarmManager and make it set it's own "alarm" for the refresh Service. A Service in Android is just a background process with no UI elements. We use this Service to call the IVLE API that gives us unread announcements. The phone's "alarm" works by simply activating the refresh Service when the time is reached (it does not actually ring the real alarm in your clock). The Service then parses the data received and then informs the user if there are any new and unread announcements.
How does the app inform the user then? It simply shows a notification at the notification bar. This is done easily with the class called NotificationCompat. The actual class is supposed to be simply Notification, but the Compat is appended because this is a special class that allows your notification to show on older versions of Android (Compatibility). The Notification class is updated specifically for the newest versions of Android only. We thus use the notification builder supplied with the NotificationCompat class and this allows us to easily show the notification on the phone.
We encountered problem while doing this feature. We sometimes were unable to cancel the checking of the notifications because the cancel function provided by the AlarmManager is not very intuitive. We managed to fix it but the result is pretty messy spaghetti code. Also, we still have no idea why the original way we did it does not work. This shall be a notable issue should any of us do a similar feature in other apps in the future. Hopefully we can further understand the problem next time.
Alright that's all, hope it has been an interesting read. If you would like more technical details, feel free to browse our source code in our Github. The link is in the sidebar. Alternatively, you may comment below or contact us directly :)
Thanks for reading!
Orbital Programme 2014
Monday, 28 July 2014
Saturday, 5 July 2014
Home Page and Settings
Hello! JiaWei here again. This week, we focus on home page and settings.
Coming up with the homepage was rather challenging. We had a debate on how will it look like before we code it out. It has to fulfill our goal of "Viewing everything in one place" and look attractive to the users. After much debate, we decided to put Homework and Quizzes in - as they have due dates, as shown above in the right picture.
We drew inspiration from the Chrome app, momentum and Windows phone lock screen. And herein lies the challenge, how do you make the words blend in with the background? Not only do the words have to be visible to the users, they should not distract the users from the background as well. We want to establish the feeling of space, yet, show the important stuff.
After many trail and error, we finally got the right picture to go with our fonts. It wasn't easy as some backgrounds had drastic contrast between the top and bottom half. This makes it difficult to read the fonts in transparent white. Some were too dark, causing the black layout to become rather opaque.
Never knew something that looked so easy was actually so complicated.
So after we finished the homepage, we continued to Settings.
Settings also allow users to set their target CAP and current CAP. This will cause automatic update on "My CAP" text field in cap calculator and take away the fuss of typing in their CAP.
Users can also enter in their specialisation from Settings page, allowing it to be displayed in the profile page. This hasn't been accomplished yet as though. We wanted "Second Major Specialisation" to be greyed out if the user does not have a "Second Major Specialisation", similar to the effect of "Number of items" to display when "Show Homework" isn't checked. However, while the latter was achieved by the "dependency" option, this cannot be used on "Second Major Specialisation".
Homepage
  |
| NusBuddy Homepage |
Coming up with the homepage was rather challenging. We had a debate on how will it look like before we code it out. It has to fulfill our goal of "Viewing everything in one place" and look attractive to the users. After much debate, we decided to put Homework and Quizzes in - as they have due dates, as shown above in the right picture.
We drew inspiration from the Chrome app, momentum and Windows phone lock screen. And herein lies the challenge, how do you make the words blend in with the background? Not only do the words have to be visible to the users, they should not distract the users from the background as well. We want to establish the feeling of space, yet, show the important stuff.
After many trail and error, we finally got the right picture to go with our fonts. It wasn't easy as some backgrounds had drastic contrast between the top and bottom half. This makes it difficult to read the fonts in transparent white. Some were too dark, causing the black layout to become rather opaque.
Never knew something that looked so easy was actually so complicated.
 |
| How we separated the picture to find a picture that fits |
 |
| Giving a sense of space |
We used white transparent fonts on transparent black background. You can do this by adjusting the front 2 hexadecimal in your rgb colour. The first 2 number represents the transparency of the colour. "0" for fully transparent and "f" for full opaque.
So after we finished the homepage, we continued to Settings.
Settings
As of now, our settings page will give users the option to "show homework" on their homepage, or not to. We also allow users to fill in their target CAP and current CAP. We have yet to finish First Major Specialisation and Second Major Specialisation.
"Test Days" setting allows users to set the number of days the task will appear in the homepage before the task dues. For instance, setting it to 1 day will cause all the task due on the next day to appear.
"Number of items" is dependent on "Show Homework". Unless "Show Homework" is checked, the user cannot adjust the number of items to show. As the photos are difficult to upload and arrange, I shall bombard you with collage that I have made that are pretty to follow and less taxing for myself.
"Test Days" setting allows users to set the number of days the task will appear in the homepage before the task dues. For instance, setting it to 1 day will cause all the task due on the next day to appear.
"Number of items" is dependent on "Show Homework". Unless "Show Homework" is checked, the user cannot adjust the number of items to show. As the photos are difficult to upload and arrange, I shall bombard you with collage that I have made that are pretty to follow and less taxing for myself.
"Number of items" is dependent on "Show Homework". Unless "Show Homework" is checked, the user cannot adjust the number of items to show.
Users can also fill in their target CAP from settings such that it appears in both the Profile page and CAP Calculator. The later helps since it reduces the fuss of typing in your current CAP whenever you calculate your CAP.
We will finish up on this problem and move on the Announcement page. In there, we have to create the refresh and make a setting for it - the time intervals to refresh announcement.
I also apologise for the "ugly" post, with the pictures out of alignment and all.
I also apologise for the "ugly" post, with the pictures out of alignment and all.
Till next time :)
Jia Wei
Sunday, 15 June 2014
Dealing with HTTP connections
Hi, Nick again. Thought I'd write about this (extremely overdue) topic of HTTP connections in Android apps using Java. However, as this is a blog post and not a textbook, I cannot deal with too many technical details. Click the hyperlinks in the text to bring up the relevant information pages if you wish to read more about these topics.
HTTP CONNECTIONS
To start off, we first look at HTTP. HTTP stands for Hyper-Text Transfer Protocol. It is the "language" of the web; your browser requests data from web hosts via this mode of communication. The web host then sends back the relevant data, which could be HTML files (webpages), images, videos, anything.
When a client (your browser) talks to a server (the web host), we say that a session has been established. The client sends a HTTP request, and the server replies with a two-part response: a status line and the message body. The status line tells the client whether the request has been understood and replied to correctly. A status code of "200" means everything is OK, perfect. And as well all know, the status code "404" means the item requested was not found. There are many other status codes on Wikipedia here, but the one that we NEED to know is simply "200". This is the one that will come with a sensible message body, whose contents are our main concern.
So what's inside the message body? It depends mainly on the type of HTTP request that was sent by the client. There are two main kinds: GET and POST. A GET request is simply asking the server to return a resource, while a POST request means the client is sending, or "posting", data to the server for some purpose, and the response should describe the outcome of the sending. A good example of a POST request is a login. The client sends the username and password to the server, and the server, after checking, will return a message describing the success or failure of the login. An example of a GET request is asking IVLE for a list of modules; in this case, the message body would contain the list of modules.
However, each server has it's own way of structuring its response content. The list of modules returned by the IVLE server above are usually in JSON format. JSON stands for JavaScript Object Notation, and it's a handy way of dealing with data. JSON has two main data structures: Object and Array. An object is a unordered set of key-value pair mappings, where the keys are strings and the values are either objects, arrays, or primitives (int, boolean, etc). An array is an ordered set of values, and these values can be objects, arrays, or primitives as well. The values are accessed by calling the relevant position in the array. A JSON structure can be written as a string, where the { } curly braces represent objects and [ ] square brackets represent arrays.
ANDROID IMPLEMENTATION
Now that we know how HTTP connections work, we can take a look at how to implement them in an Android app.
I am sure we have all experienced a webpage loading very slowly before, or our internet-based game "lagging". This is usually caused by the server not responding to our computer's HTTP request immediately, but the browser or game needs the data to carry on. In this case, the only thing to do is wait for the response. Waiting is not optimal, as the response may really take ages to reach the client. Also, on single-threaded programs, the waiting time would make the computer appear to have "hung" because the program cannot continue without the response data. Let's make a simple example: you dial your friend on your phone, and while waiting for your friend to pick up the call, you stop doing everything else. No walking, no blinking, no breathing even. It's pretty difficult to live like that.
Fortunately, we can multitask, and so can Android apps (multi-threading). They have the capability of running multiple threads in parallel, which means one program can do a few things at once. Every app has one main thread, which the User Interface (UI) runs on. If we perform a task on the main thread that takes up a lot of time, the UI will freeze for that amount of time. Even if we try to show a loading bar, the bar will freeze at a point while the task runs on the main thread. However, if we run our time-intensive task in the background on a separate thread, then the loading bar can show normally and the UI will not freeze. The background task will then notify the UI thread once it is complete, and then the UI can update itself accordingly.
Android provides us with a nice, easy-to-use Java class called AsyncTask, which allows us to run a background (asynchronized) task and then return the result of the task to the main thread upon completion. We therefore put our HTTP requests in this AsyncTask, so that the program can wait for the server to respond and yet not have to suspend all other activities. Click the hyperlink to view the AsyncTask API if you want more implementation details.
To carry out the HTTP connection in Android, we need to first create a URL object. URL stands for Uniform Resource Locators, which is the string of letters and symbols you see in the address bar. The object is created by defining the URL in the constructor. A HttpURLConnection object is then created from the URL object's openConnection() method. The status code (remember "200" and "404"?) and the response content can then be requested from the server by running getResponseCode() and getInputStream() respectively. The Input Stream received must be read by a stream reader to get the entire response content. Since we have been running on the background thread, we just need to send the response content back to the main thread for the UI to be updated accordingly.
IVLE AND NUSBUDDY SPECIFICS
Let's now focus specifically on the IVLE LAPI's URLs and responses.
The IVLE LAPI (Learning Application Programming Interface) is a collection of URLs to which HTTP requests can be sent, and relevant responses received. We use HTTP connections establish sessions with the IVLE servers such that we can send, request and receive data regarding the following:
When a user calls the URL for his profile page, and the data of the profile would be sent back to him. The URL for the Student Profile looks like this:
The response content is, by default, structured in the JSON format (as mentioned above). This means we can read the response content as a string. This string is then parsed as an actual JSON object using the Java class called JSONObject. We can now easily extract the data from the response using get() methods on the JSONObject object.
The actual JSON response string looks like this:
In our app, we work with JSON quite a bit because it's the default response structure of the LAPI. It is also very convenient to use as a simple data storage object because of the key-value mappings. One drawback is that if the JSON structure in the server's response changes, our methods for extracting the data would break.
SUMMARY
We have covered HTTP requests (GET & POST), the JSON structure, multi-threading in Android with relevant classes, HTTP connection objects and how to deal with responses, and finally an example of how we apply these methods in our NUSBuddy app.
HTTP CONNECTIONS
To start off, we first look at HTTP. HTTP stands for Hyper-Text Transfer Protocol. It is the "language" of the web; your browser requests data from web hosts via this mode of communication. The web host then sends back the relevant data, which could be HTML files (webpages), images, videos, anything.
When a client (your browser) talks to a server (the web host), we say that a session has been established. The client sends a HTTP request, and the server replies with a two-part response: a status line and the message body. The status line tells the client whether the request has been understood and replied to correctly. A status code of "200" means everything is OK, perfect. And as well all know, the status code "404" means the item requested was not found. There are many other status codes on Wikipedia here, but the one that we NEED to know is simply "200". This is the one that will come with a sensible message body, whose contents are our main concern.
So what's inside the message body? It depends mainly on the type of HTTP request that was sent by the client. There are two main kinds: GET and POST. A GET request is simply asking the server to return a resource, while a POST request means the client is sending, or "posting", data to the server for some purpose, and the response should describe the outcome of the sending. A good example of a POST request is a login. The client sends the username and password to the server, and the server, after checking, will return a message describing the success or failure of the login. An example of a GET request is asking IVLE for a list of modules; in this case, the message body would contain the list of modules.
However, each server has it's own way of structuring its response content. The list of modules returned by the IVLE server above are usually in JSON format. JSON stands for JavaScript Object Notation, and it's a handy way of dealing with data. JSON has two main data structures: Object and Array. An object is a unordered set of key-value pair mappings, where the keys are strings and the values are either objects, arrays, or primitives (int, boolean, etc). An array is an ordered set of values, and these values can be objects, arrays, or primitives as well. The values are accessed by calling the relevant position in the array. A JSON structure can be written as a string, where the { } curly braces represent objects and [ ] square brackets represent arrays.
ANDROID IMPLEMENTATION
Now that we know how HTTP connections work, we can take a look at how to implement them in an Android app.
I am sure we have all experienced a webpage loading very slowly before, or our internet-based game "lagging". This is usually caused by the server not responding to our computer's HTTP request immediately, but the browser or game needs the data to carry on. In this case, the only thing to do is wait for the response. Waiting is not optimal, as the response may really take ages to reach the client. Also, on single-threaded programs, the waiting time would make the computer appear to have "hung" because the program cannot continue without the response data. Let's make a simple example: you dial your friend on your phone, and while waiting for your friend to pick up the call, you stop doing everything else. No walking, no blinking, no breathing even. It's pretty difficult to live like that.
Fortunately, we can multitask, and so can Android apps (multi-threading). They have the capability of running multiple threads in parallel, which means one program can do a few things at once. Every app has one main thread, which the User Interface (UI) runs on. If we perform a task on the main thread that takes up a lot of time, the UI will freeze for that amount of time. Even if we try to show a loading bar, the bar will freeze at a point while the task runs on the main thread. However, if we run our time-intensive task in the background on a separate thread, then the loading bar can show normally and the UI will not freeze. The background task will then notify the UI thread once it is complete, and then the UI can update itself accordingly.
Android provides us with a nice, easy-to-use Java class called AsyncTask, which allows us to run a background (asynchronized) task and then return the result of the task to the main thread upon completion. We therefore put our HTTP requests in this AsyncTask, so that the program can wait for the server to respond and yet not have to suspend all other activities. Click the hyperlink to view the AsyncTask API if you want more implementation details.
To carry out the HTTP connection in Android, we need to first create a URL object. URL stands for Uniform Resource Locators, which is the string of letters and symbols you see in the address bar. The object is created by defining the URL in the constructor. A HttpURLConnection object is then created from the URL object's openConnection() method. The status code (remember "200" and "404"?) and the response content can then be requested from the server by running getResponseCode() and getInputStream() respectively. The Input Stream received must be read by a stream reader to get the entire response content. Since we have been running on the background thread, we just need to send the response content back to the main thread for the UI to be updated accordingly.
IVLE AND NUSBUDDY SPECIFICS
Let's now focus specifically on the IVLE LAPI's URLs and responses.
The IVLE LAPI (Learning Application Programming Interface) is a collection of URLs to which HTTP requests can be sent, and relevant responses received. We use HTTP connections establish sessions with the IVLE servers such that we can send, request and receive data regarding the following:
- Login
- Modules
- Announcements
- Gradebooks
- Final Exam Timetables
- Student Profile
When a user calls the URL for his profile page, and the data of the profile would be sent back to him. The URL for the Student Profile looks like this:
https://ivle.nus.edu.sg/api/Lapi.svc/Profile_View?APIKey={String}&AuthToken={String}The APIKey is a unique key to identify the caller, while the AuthToken is an authentication token for the current logged-in user's session.
The response content is, by default, structured in the JSON format (as mentioned above). This means we can read the response content as a string. This string is then parsed as an actual JSON object using the Java class called JSONObject. We can now easily extract the data from the response using get() methods on the JSONObject object.
The actual JSON response string looks like this:
{"Results":[{"UserID":"a0108358","Name":"NICHOLAS LUM AIK YONG","Email":"a0108358@nus.edu.sg","Gender":"Male","Faculty":"School of Computing","FirstMajor":"Computer Science (Hons)","SecondMajor":"","MatriculationYear":"2013"}],"Comments":"Valid login!","LastUpdate":"\/Date(1400344894329+0800)\/","LastUpdate_js":"2014-05-18T00:41:34.3293461+08:00"}It's kinda messy in string form because of the nested objects and arrays, but with an online JSON parser, the structure can be made pretty clear:
With this data, we can then build the profile page of the user that requested it.
In our app, we work with JSON quite a bit because it's the default response structure of the LAPI. It is also very convenient to use as a simple data storage object because of the key-value mappings. One drawback is that if the JSON structure in the server's response changes, our methods for extracting the data would break.
SUMMARY
We have covered HTTP requests (GET & POST), the JSON structure, multi-threading in Android with relevant classes, HTTP connection objects and how to deal with responses, and finally an example of how we apply these methods in our NUSBuddy app.
Update 15 June: A Different GUI
Hi, it's Nick. Haven't blogged in a while because we've been too engrossed in coding, haha.
We decided to implement the Tests and Quizzes page, which is similar to the Homework Planner page. This section of the app was originally not planned for in our Trello Board, because the implementation is very similar to the homework planner and we thought it would not be worth doing as we wouldn't learn anything new. However, we felt that the minimum viable product would be more complete if we added this in. Anyway it's good that we did it, because we had the opportunity to rethink our GUI design.
So why did we even think of redesigning in the first place?
Our first idea was to make something similar to the original design in our mock-up, which allows all events to be manipulated on the page itself without further navigation. Then we decided to do away with the "box" design so that we can utilize more screen real estate. This also made the layout look neater (in our opinion). We then tried to put the date and time on the same line as the event title, but it didn't look very nice because of the arrow at the side. Thus we opted for the two-line format, similar to the View All page of the Homework Planner. The click-to-expand feature stayed, but we made changes. The location header is a simple "@ " while the description header is gone. Also, the buttons have been pushed to the corners.
There are still a few kinks to iron out from this design. The date and time display line could be improved by finding a better place to put the time field. I think that it's a little out of place right now. However, if the time is placed on a new line, each event box would take up extra height. We might simply just encode the date and time as one string, similar to the homework page.
Also the delete and edit buttons could use a redesign themselves. The default button style does not suit the context very well. The placement of the buttons could be improved too, as I find that there is a lot of empty space wasted in the middle, but if the buttons are close together it doesn't look good either. Maybe's it's really down to the button style.
Lastly, to prevent clogging up of the page, we might only show at most two (or just one?) events, with a "see more" expander to show the rest if needed. While this is excellent at saving screen space, it reduces the "bird's eye view" advantage, which is our main selling point. Also, this is very similar to the View All feature in the current Homework Planner page.
So what do you think? Is this design better, or would you rather the one from the Homework Planner? I personally like this one better, and if we both continue to like it then we will refactor our homework planner page (and likely the other pages also) to look like this.
Anyway I'll be off Serving The Nation until the 21st, and Jiawei is involved in FSC too, so we're gonna be inactive for the most part of next week. Hopefully we don't fall too far behind!
We decided to implement the Tests and Quizzes page, which is similar to the Homework Planner page. This section of the app was originally not planned for in our Trello Board, because the implementation is very similar to the homework planner and we thought it would not be worth doing as we wouldn't learn anything new. However, we felt that the minimum viable product would be more complete if we added this in. Anyway it's good that we did it, because we had the opportunity to rethink our GUI design.
L-R: Test and Quizzes and the expanded Event view
So why did we even think of redesigning in the first place?
Our first idea was to make something similar to the original design in our mock-up, which allows all events to be manipulated on the page itself without further navigation. Then we decided to do away with the "box" design so that we can utilize more screen real estate. This also made the layout look neater (in our opinion). We then tried to put the date and time on the same line as the event title, but it didn't look very nice because of the arrow at the side. Thus we opted for the two-line format, similar to the View All page of the Homework Planner. The click-to-expand feature stayed, but we made changes. The location header is a simple "@ " while the description header is gone. Also, the buttons have been pushed to the corners.
There are still a few kinks to iron out from this design. The date and time display line could be improved by finding a better place to put the time field. I think that it's a little out of place right now. However, if the time is placed on a new line, each event box would take up extra height. We might simply just encode the date and time as one string, similar to the homework page.
Also the delete and edit buttons could use a redesign themselves. The default button style does not suit the context very well. The placement of the buttons could be improved too, as I find that there is a lot of empty space wasted in the middle, but if the buttons are close together it doesn't look good either. Maybe's it's really down to the button style.
Lastly, to prevent clogging up of the page, we might only show at most two (or just one?) events, with a "see more" expander to show the rest if needed. While this is excellent at saving screen space, it reduces the "bird's eye view" advantage, which is our main selling point. Also, this is very similar to the View All feature in the current Homework Planner page.
Comparison of the Tests vs Homework pages. Click to enlarge.
L-R: Tests and Quizzes page, Homework Page, Viewing All Homework of a module.
So what do you think? Is this design better, or would you rather the one from the Homework Planner? I personally like this one better, and if we both continue to like it then we will refactor our homework planner page (and likely the other pages also) to look like this.
Anyway I'll be off Serving The Nation until the 21st, and Jiawei is involved in FSC too, so we're gonna be inactive for the most part of next week. Hopefully we don't fall too far behind!
Friday, 6 June 2014
Update on 6th June
Hello it's Jia Wei this time round. This post will be more technical so please bear with it.
Nick and I are now implementing the "View" homework page, which allows one to view all their homework in a particular module.
This is how it looks:
Upon tapping a homework, the tab expands.
Upon pressing edit button:
Some of the problems we faced was the delete button problem. To remove a homework, we must remove it from the database, the view homework page and the homework page. To ensure a user experience, we tried to remove deleted homework as fast as possible. We did this by overriding onBackPressed() (this method is called whenever the android back button is pressed) but this method appears to have some loopholes.
The showing and hiding of information when the user tap their homework was manageable but tedious. Aside from changing the hidden information visibility, we also had to get the homework data from database and set them into separate containers. We also had to implement a random id generator to help randomise the id of these homework since each homework is unique.
As of now, we are trying to have the fields in Add Homework page filled up with information whenever the press the edit button. There is also the need to reformat how the date in the date field will appear. Oh, and set a limit to the year since once it hits 2038 for the calendar goes back to the 1900's after year 2036.
Some minor bugs discovered while blogging:
- Due date (both date and time) of homework are set to calendar mode. This means we can set a due date that has already passed. We'll need to set limits to this.
And... after some googling, turns out that Calendar provided by Android is buggy.
Okay, time to get Nick to help me out again...
Nick and I are now implementing the "View" homework page, which allows one to view all their homework in a particular module.
This is how it looks:
Upon pressing edit button:
Some of the problems we faced was the delete button problem. To remove a homework, we must remove it from the database, the view homework page and the homework page. To ensure a user experience, we tried to remove deleted homework as fast as possible. We did this by overriding onBackPressed() (this method is called whenever the android back button is pressed) but this method appears to have some loopholes.
The showing and hiding of information when the user tap their homework was manageable but tedious. Aside from changing the hidden information visibility, we also had to get the homework data from database and set them into separate containers. We also had to implement a random id generator to help randomise the id of these homework since each homework is unique.
As of now, we are trying to have the fields in Add Homework page filled up with information whenever the press the edit button. There is also the need to reformat how the date in the date field will appear. Oh, and set a limit to the year since once it hits 2038 for the calendar goes back to the 1900's after year 2036.
Some minor bugs discovered while blogging:
- Due date (both date and time) of homework are set to calendar mode. This means we can set a due date that has already passed. We'll need to set limits to this.
And... after some googling, turns out that Calendar provided by Android is buggy.
Okay, time to get Nick to help me out again...
Thursday, 5 June 2014
Update 5th June: Doing Homework!
Hi all, it's Nick.
We have just started the first sprint iteration, which runs until the end of June. Our main focus this sprint is to complete the Homework Planner and the CAP Calculator. We are still in the midst of creating the Homework Planner, so I'll just show some of its sub-features that we managed to implement so far.
But first, our new splash screen!
This screen will show when the app starts or when the user is logging in. It may not look very impressive but it seems like a sleeker interface as compared to progress dialogues popping up everywhere. This is simply the login screen, but with the text fields hidden and a small progress ball shown.
Alright, now on to the Homework Planner.
The boxes shown here are containers for homework items, segregated by module. The module codes are gotten from the IVLE API, and then used to dynamically generate the view. The page is empty now because we have no homework items yet.
So how does one add a homework?
Tapping on any of the module containers will bring up a popup menu with two options, Add and View All. The popup menu is bound to the module container which was tapped, so if the user decides to add a homework, the homework item will be put under the chosen module, as we shall see.
Tapping the Add option brings the user to the Add Homework page.
The user will then fill up the relevant fields. The only two required fields are the Event Title and the Date. Here are a couple of examples for filling up the details.
Ticking the Recurring Event checkbox will cause additional radio buttons to show, offering more details of the event recurrence. We still need to beautify the page a little more, but for now it's functional. After filling in all the information, we press Add Event to save the homework item to the database backend. The Add Homework page is then closed, and the Homework Planner page is brought to the front again.
The image above shows a populated Homework Planner page. The homework items are stored in a database backend, local to the phone. On creation or refresh of this page, the database is polled. As a module container is being created (dynamically), the logic also performs a database query for all the homework items that are bound to that module. These homework items are then displayed under the appropriate module code.
For our next step, we will implement the View All page. This page will showcase all the homework items under a selected module, and will offer deletion and editing of the homework items.
Some details of our backend database implementation:
Alright that's all for now, hope to have Jiawei writing the next post :)
Thanks for reading!
Nick
We have just started the first sprint iteration, which runs until the end of June. Our main focus this sprint is to complete the Homework Planner and the CAP Calculator. We are still in the midst of creating the Homework Planner, so I'll just show some of its sub-features that we managed to implement so far.
But first, our new splash screen!
Alright, now on to the Homework Planner.
So how does one add a homework?
Tapping the Add option brings the user to the Add Homework page.
For our next step, we will implement the View All page. This page will showcase all the homework items under a selected module, and will offer deletion and editing of the homework items.
Some details of our backend database implementation:
- We are using the Android API version of SQLite.
- The database currently only has one table, "homework". We are still looking to see if we can utilize it better.
- We chose to use a local database because its response time is much faster than cloud storage.
- Also, it should be possible to retrieve the actual .db file and upload it to a cloud storage if the user wants to backup his data.
Alright that's all for now, hope to have Jiawei writing the next post :)
Thanks for reading!
Nick
Friday, 30 May 2014
Update 29 May: Build-up to First Milestone
Today's pairwork session was largely spent working on the project's Readme and time log. It was quite interesting as we discovered new ways to manage our project and tasks more efficiently. I'll talk about the tools that we are currently using to help us.
Firstly, there's this cute website called Trello. It is basically a to-do list manager at its core. In Trello, you first create a Board. This board, which is a container for the entire project, holds Lists. Lists are general aspects of the project that should be focused on. For example, we have a list called "Features For This Sprint" that holds tasks. These tasks are wrapped in Cards, which the lists contain. The cards are the most detailed components; they can hold the task descriptions, additional checklists and activity history. Furthermore, the entire board can be made public for viewing, and shared among team members who are given editing privileges. It was pretty intuitive to use and we hope that it would serve us well throughout this project.
Our Trello Board can be found at this link.
This was overlooked by us, somewhat, but Google Docs Spreadsheet is a pretty good tool for keeping a time log. We were inspired to use this when we saw the sample readme. It is pretty efficient now, especially since we can sort by date, but I don't know whether it will become hard to use when there are more and more entries. It's getting a little hard to read even now. Our time log sheet can be found here.
Of course, there's this blog. We intend to update this blog regularly with our thoughts and reflections about the things we have learnt along the way. This will allow us to track our learning process and also for posterity's sake. Additionally, the blog has customizable sidebars that can hold to-do lists and other information. However now with the Trello and Spreadsheet, those sidebars may not come in handy as much. Another reason for setting up the blog is so that we may experiment with any HTML/CSS/JS that we learnt in mission controls, but so far we have not been focusing on that.
We use git as our version control tool, and Github as the online repository service so that we can share code among ourselves. Encountered problems with binary files differing during a merge, but that is because we did not set up the gitignore file properly.
Lastly, team communication is mostly text messaging and regular meetups in school. These methods have served us well thus far, so I highly recommend them to all other teams.
Thanks for reading!
Nick
Firstly, there's this cute website called Trello. It is basically a to-do list manager at its core. In Trello, you first create a Board. This board, which is a container for the entire project, holds Lists. Lists are general aspects of the project that should be focused on. For example, we have a list called "Features For This Sprint" that holds tasks. These tasks are wrapped in Cards, which the lists contain. The cards are the most detailed components; they can hold the task descriptions, additional checklists and activity history. Furthermore, the entire board can be made public for viewing, and shared among team members who are given editing privileges. It was pretty intuitive to use and we hope that it would serve us well throughout this project.
Our Trello Board can be found at this link.
This was overlooked by us, somewhat, but Google Docs Spreadsheet is a pretty good tool for keeping a time log. We were inspired to use this when we saw the sample readme. It is pretty efficient now, especially since we can sort by date, but I don't know whether it will become hard to use when there are more and more entries. It's getting a little hard to read even now. Our time log sheet can be found here.
Of course, there's this blog. We intend to update this blog regularly with our thoughts and reflections about the things we have learnt along the way. This will allow us to track our learning process and also for posterity's sake. Additionally, the blog has customizable sidebars that can hold to-do lists and other information. However now with the Trello and Spreadsheet, those sidebars may not come in handy as much. Another reason for setting up the blog is so that we may experiment with any HTML/CSS/JS that we learnt in mission controls, but so far we have not been focusing on that.
We use git as our version control tool, and Github as the online repository service so that we can share code among ourselves. Encountered problems with binary files differing during a merge, but that is because we did not set up the gitignore file properly.
Lastly, team communication is mostly text messaging and regular meetups in school. These methods have served us well thus far, so I highly recommend them to all other teams.
Thanks for reading!
Nick
Monday, 26 May 2014
Introducing Our App
Nick here. I'll be introducing our project in a bit more detail.
Our app, called NUS Buddy, is a personal assistant-style productivity application designed to bring the most important information in IVLE to the NUS student user. Announcements, grade books, and final exam details are just a couple of taps away. The app will also have to-do-list functions for keeping track of homework, assignments, and quizzes. Additionally, there is an in-built CAP calculator, where students can simulate their CAP score by simply entering their module's projected grades. As an extension, the app may offer social aspects like sharing of timetables and target for the semester with a list of friends.
The technologies we will utilize include Android development and debugging tools, Java & XML coding in the Eclipse IDE, the IVLE LAPI to retrieve JSON data, possibly some SQLite database functionality, and Facebook social tools if we implement the social extensions. We may also utilize some HTML/CSS/JS to decorate this blog a little, but this is not the main focus.
I will now introduce various aspects of the application with accompanying images. I will describe each page's significance and purpose, and may delve into the implementation technologies. Some challenges and possible improvements of each page will also be considered.
Follow the jump to view the finer details.
Follow the jump to view the finer details.
Friday, 23 May 2014
JIAWEI's update :D May 23rd
Jiawei here!
In the first 3 days of starting this project, I was really blur. I followed every instruction on the android development tutorial on the android website and still didn't manage to make MyFirstApp work. Nick says it's due to the version - kitkat, jellybean.. yeah those. The website shows that it's okay to have Froyo as the lowest version but that's not the case. After changing the lowest version to JellyBean (By Nick, any version of JellyBean should do) and redoing the tutorial, it worked!
The second problem I faced was getting used to Eclipse. I'm a new Eclipse user so the boxes and the squiggly lines are new to me. What turns me off most was the technical jargons they use for errors. Given my limited knowledge in programming, I couldn't quite get these jargons and I have to Google them. Sometimes these explanation give raise to more technical jargons and I have to Google for them too. This means I spend 1 hour Googling on an API method I read when I spent 5 seconds writing this API method. Still, I have to say I learn a lot faster with Eclipse highlighting these errors for me.
Currently, I'm tasked with a simple, small portion of our project. We meet up during the weekdays to do pair programming - actually, this means Nick doing 80% of the work and me just nodding, talking, and doing the Googling. I try to "catch up" with him by watching Android Development Tutorials Youtube videos. It's working out better now. I'm able to code out something decent without bombarding him with questions. Nick also spends less time repeating things to me. Now, we're more "what to put in" instead of "how to put it in".
Time logging: I took about 1 day just to complete the first tutorial, not including download and setup time. We then did pair programming for 3 days, about 7 to 8 hours for the first 2 days and 5 hours on the third day.
In the following days, we aim to complete our app - have the functions pin down first before we start on GUI. In the meantime, we'll still go for Orbital milestones or mission control to learn more stuff. Hopefully we have time to try out some of the things they taught, like HTML5 and CSS to make this blog look nicer.
Cheers!
JIAWEI
In the first 3 days of starting this project, I was really blur. I followed every instruction on the android development tutorial on the android website and still didn't manage to make MyFirstApp work. Nick says it's due to the version - kitkat, jellybean.. yeah those. The website shows that it's okay to have Froyo as the lowest version but that's not the case. After changing the lowest version to JellyBean (By Nick, any version of JellyBean should do) and redoing the tutorial, it worked!
The second problem I faced was getting used to Eclipse. I'm a new Eclipse user so the boxes and the squiggly lines are new to me. What turns me off most was the technical jargons they use for errors. Given my limited knowledge in programming, I couldn't quite get these jargons and I have to Google them. Sometimes these explanation give raise to more technical jargons and I have to Google for them too. This means I spend 1 hour Googling on an API method I read when I spent 5 seconds writing this API method. Still, I have to say I learn a lot faster with Eclipse highlighting these errors for me.
Currently, I'm tasked with a simple, small portion of our project. We meet up during the weekdays to do pair programming - actually, this means Nick doing 80% of the work and me just nodding, talking, and doing the Googling. I try to "catch up" with him by watching Android Development Tutorials Youtube videos. It's working out better now. I'm able to code out something decent without bombarding him with questions. Nick also spends less time repeating things to me. Now, we're more "what to put in" instead of "how to put it in".
Time logging: I took about 1 day just to complete the first tutorial, not including download and setup time. We then did pair programming for 3 days, about 7 to 8 hours for the first 2 days and 5 hours on the third day.
In the following days, we aim to complete our app - have the functions pin down first before we start on GUI. In the meantime, we'll still go for Orbital milestones or mission control to learn more stuff. Hopefully we have time to try out some of the things they taught, like HTML5 and CSS to make this blog look nicer.
Cheers!
JIAWEI
Getting Started with Android
Nick here. So here's a post to start the flow. I'll be talking about how to begin creating apps for Android.
To start developing on Android, the first thing you need to do is to visit the Getting Started page on the Android Developers' website. There, you can find tutorials on the very basics, to some slightly more advanced material. There is also a link to download the Android SDK, which very nicely comes with the Eclipse IDE. Their version of Eclipse has all the needed plugins already pre-installed, and what more, it is portable! This means you can basically start writing code on Eclipse from the get-go with very minimal setup. However, to fully utilise the Android functionality, you need to download some additional Android files. This is handled quite well by the Android SDK Manager found under the Window tab on the taskbar.
The SDK offers two ways that you can run your own Android apps. You can either plug in your Android phone to your machine, or you could run an Android emulator on your machine itself. I personally prefer to use my phone as the running platform. The emulator runs pretty slow on my PC, and it doesn't have the same feel as a touchscreen interface. To use your phone as the running platform, however, you need to unlock the developer mode. Under Settings -> More -> About Device, find the item that states the Build Number, and tap it rapidly for about ten seconds straight. Eventually, a toast notification will pop up, telling you that you have unlocked the Developer Mode. Now under Settings -> More, a new item called Developer Options will appear. Navigate into it and mark the box that corresponds to USB Debugging. This allows Eclipse to work hand-in-hand with your phone while running your application. Any errors encountered will be passed back to Eclipse and shown on the error log output.
Word of warning: do not mess around with other settings in the developer options menu unless you know what you are doing. This menu was locked for a reason!
I am not experienced enough to give a good "getting started" tutorial right now, so I won't waste our time in trying to do so. Android's own tutorial for building your first app is pretty decent in getting most people started. However it might still take some independent learning, exploring, and experimenting to be fully comfortable with the concepts covered. When I started learning, I had no time limit to meet, hence I was able to learn at my own pace. Google and StackOverflow were extremely helpful when I encountered difficulties. If you have the luxury of time, I really do recommend independent learning. For me, nothing beats the satisfaction of solving problems and finding solutions by myself.
Alright, so that's the end of the post. As I said, this post is on how to begin developing for Android. I doubt it would actually help anyone, lol, but it was quite a fun experience writing this anyway.
Time logging: I probably took about 8 hours just to complete the first tutorial, including download and setup time.
Thanks for reading!
Nicholas
To start developing on Android, the first thing you need to do is to visit the Getting Started page on the Android Developers' website. There, you can find tutorials on the very basics, to some slightly more advanced material. There is also a link to download the Android SDK, which very nicely comes with the Eclipse IDE. Their version of Eclipse has all the needed plugins already pre-installed, and what more, it is portable! This means you can basically start writing code on Eclipse from the get-go with very minimal setup. However, to fully utilise the Android functionality, you need to download some additional Android files. This is handled quite well by the Android SDK Manager found under the Window tab on the taskbar.
The SDK offers two ways that you can run your own Android apps. You can either plug in your Android phone to your machine, or you could run an Android emulator on your machine itself. I personally prefer to use my phone as the running platform. The emulator runs pretty slow on my PC, and it doesn't have the same feel as a touchscreen interface. To use your phone as the running platform, however, you need to unlock the developer mode. Under Settings -> More -> About Device, find the item that states the Build Number, and tap it rapidly for about ten seconds straight. Eventually, a toast notification will pop up, telling you that you have unlocked the Developer Mode. Now under Settings -> More, a new item called Developer Options will appear. Navigate into it and mark the box that corresponds to USB Debugging. This allows Eclipse to work hand-in-hand with your phone while running your application. Any errors encountered will be passed back to Eclipse and shown on the error log output.
Word of warning: do not mess around with other settings in the developer options menu unless you know what you are doing. This menu was locked for a reason!
I am not experienced enough to give a good "getting started" tutorial right now, so I won't waste our time in trying to do so. Android's own tutorial for building your first app is pretty decent in getting most people started. However it might still take some independent learning, exploring, and experimenting to be fully comfortable with the concepts covered. When I started learning, I had no time limit to meet, hence I was able to learn at my own pace. Google and StackOverflow were extremely helpful when I encountered difficulties. If you have the luxury of time, I really do recommend independent learning. For me, nothing beats the satisfaction of solving problems and finding solutions by myself.
Alright, so that's the end of the post. As I said, this post is on how to begin developing for Android. I doubt it would actually help anyone, lol, but it was quite a fun experience writing this anyway.
Time logging: I probably took about 8 hours just to complete the first tutorial, including download and setup time.
Thanks for reading!
Nicholas
First Post!
Hello everyone! :D
Our team No Trubbel will be maintaining this blog throughout the course of our Orbital programme. This blog will serve as both a place for us to reflect on what we have learnt, and also as a time log to meet the Orbital programme requirements.
So let's start off by introducing our project!
Our project is the development of an Android mobile application called NUS Buddy. This app aims to be a personal assistant for the NUS student using it. We will get important data from IVLE and display them neatly and conveniently so the user does not have to keep visiting the IVLE website just to stay up to date. The app will also offer functionalities like an in-built CAP Calculator and Simulator, together with to-do list managers that help the user keep track of their homework, tests, and exams. Basically, NUS students using this app will have a much easier time managing their academics in school. :)
And now, we'll introduce ourselves!
Hi! I'm Nicholas, a CS student who just finished year 1. I am interested in all things computers, which makes choosing a focus area a pretty hard choice. Currently, I am working as a Lego Mindstorms robotics trainer for the primary school level. My hobbies include producing electronic music and EATING. I probably should add "exercise" into that list one day. Anyway, I hope to learn as much as I can from the Orbital programme. Specifically, I would like to gain experience in designing and implementing mobile applications. I feel that such exposure will always be valuable regardless of whether I pursue software engineering in the future.
Hi! I'm Jiawei. A female CS student who just finished year 1 in NUS as well. I'm into reading and gaming (actually I just want to know the storyline, I'm not really into playing haha). I am considering taking Software Engineering as my focus area but I'm still open for choices. During this Summer break, I aim to learn how to design and develop Android Apps, as well as create and design websites.
So to sum up, we hope that this Orbital experience will be as fulfilling for us as it was for our seniors. Future posts will include regular updates on what we have learnt while trying to build the application. We are confident that there will be a lot to write about!
Thanks for reading!
No Trubbel
Our team No Trubbel will be maintaining this blog throughout the course of our Orbital programme. This blog will serve as both a place for us to reflect on what we have learnt, and also as a time log to meet the Orbital programme requirements.
So let's start off by introducing our project!
Our project is the development of an Android mobile application called NUS Buddy. This app aims to be a personal assistant for the NUS student using it. We will get important data from IVLE and display them neatly and conveniently so the user does not have to keep visiting the IVLE website just to stay up to date. The app will also offer functionalities like an in-built CAP Calculator and Simulator, together with to-do list managers that help the user keep track of their homework, tests, and exams. Basically, NUS students using this app will have a much easier time managing their academics in school. :)
And now, we'll introduce ourselves!
Hi! I'm Nicholas, a CS student who just finished year 1. I am interested in all things computers, which makes choosing a focus area a pretty hard choice. Currently, I am working as a Lego Mindstorms robotics trainer for the primary school level. My hobbies include producing electronic music and EATING. I probably should add "exercise" into that list one day. Anyway, I hope to learn as much as I can from the Orbital programme. Specifically, I would like to gain experience in designing and implementing mobile applications. I feel that such exposure will always be valuable regardless of whether I pursue software engineering in the future.
Hi! I'm Jiawei. A female CS student who just finished year 1 in NUS as well. I'm into reading and gaming (actually I just want to know the storyline, I'm not really into playing haha). I am considering taking Software Engineering as my focus area but I'm still open for choices. During this Summer break, I aim to learn how to design and develop Android Apps, as well as create and design websites.
So to sum up, we hope that this Orbital experience will be as fulfilling for us as it was for our seniors. Future posts will include regular updates on what we have learnt while trying to build the application. We are confident that there will be a lot to write about!
Thanks for reading!
No Trubbel
Subscribe to:
Comments (Atom)