Further lectures during the semester
|Unless stated otherwise, all further lectures will be only 2 hours long (12:30-14:30) and will be held at Taub 4|
|To help us prepare for your submission, we need you to submit a short (one paragraph) of your project.|
Write this description in the README of your project.
Submit it by midnight the day before your submission.
To submit the README:
1) go to https://github.com/Technion236503 and select the repository of your group
2) click on README.md
3) click the small pencil icon on the right to edit the content
4) when you're done, press "commit changes" at the bottom of the page
Additional notes for backlog submission
|1) The Product Backlog should contain user stories and not development tasks.|
2) User stories are short descriptions of user/customer visible functionality. Development tasks (that you should not define at this stage), are derived from the user stories and are meant for developers.
3) User stories should be described in a language that the user understands. Do not use words such as "Fragment" or "Intent".
4) Ideally, user stories should not describe the structure of the user interface but only the desired functionality.
5) User stories should be short and concise.
6) You should create a Project in GitHub called "ProductBacklog". Within the Project, you should create the stories as notes. Creating them as issues is less recommended but possible. The stories should be sorted by importance.
Team names in GitHub
|We assigned each team a number for identification and used that to create your user groups and repositories.|
Please decide on a name for your app and let us know so we can change the group and repository names to match the app name.
|First project submission|
It's time to start planning the projects.
Each team already has an approved idea so you should all know what you'll be working on for most of the semester.
In the first submission you will need to submit the project backlog.
Oren explained in class how create a project backlog in GitHub.
We've already opened repositories for all teams and sent invites to the email with have on record
Use the new repository to create a project for the backlog (as explained in class).
The backlog should contain all features of your app, sorted by importance to the app (such that the first feature should be implemented first).
Think about which features are most useful to the target audience of your app, which are most needed, which will make using the app most comfortable and convenient, and which make it stand out as a mobile app compared to similar websites or other platforms.
We expect to see a full backlog for the entire project.
Use the following form to choose a time slot for your team:
Attendance to your team's submission is mandatory.
As part of your current submission we will decide together which features need to be delivered on each submission and which are nice-to-have (meaning you will most likely not have time to implement them).
|Backlog submission (+ 1st round of team meetings): 3/5|
Mid-semester submission: 5/6
2nd round of team meetings: 6/6
Poster deadline (for demo day): 20/6
Demo day: 4/7
Final Submission: 6/7
pictures for new list items in hw3
|the new list items added via the fab are allowed to have the same picture|
|We noticed there were a few errors in the numbers mentioned in some of the feedback.|
We've uploaded a corrected version.
HW1 grades published
|We published the grades for hw1.|
We also uploaded individual feedbacks which you should be able to access via the grades system.
Many submissions were poorly written and don't seem to be properly tested.
Use this feedback to improve your submissions for hw3 (we generally try to avoid testing the same things in hw2).
Also make sure you follow the guidelines and use emulators to test your apk on several versions and configurations.
A note about extensions
|As a general rule, we do not accept late submissions.|
If you need an extension you may contact Omer.
Note that we will not approve any extension requests in the last 24 hours before the submission deadline so plan ahead.
First lecture tomorrow
|12:30-16:30 @ Taub 5|
See you there
Registration is closed
|The course is full.|
We have sent emails to all teams that were accepted to the course.
If you didn't get an email from us, we're sorry but that means we decided not to accept your project this semester.
Compared to previous semester we have less available slots this time, meaning we could accept less projects.
We apologize for any delayed responses.
Due to the low number of available slots we opted to take our time to properly evaluate each idea.
We note that if we reject your idea it does not mean it was a bad idea.
It only means that we decided to go in another direction.
We had several good ideas that we had to reject.
Good luck to all of you
External project suggestion
|An external company has approached us with an idea for a project for the course.|
If you don't have any ideas of your own, you can ask to do this project by specifying it in the registration form.
Project Title: RightHear - Do it yourself
With "RightHear - Do it yourself" (DIY) application any small business can easily become accessible for blind and visually impaired people which are using the RightHear users application.
The DIY package contains a bluetooth sensor and an Android RightHear configuration app. Once a blind visitor enters the sensor's transmitting area inside the store, the RightHear users application will start to give audio accessibility guidance.
In this project you will be tasked with developing the Android RightHear configuration app.
The app should allow business owners to set up and configure RightHear sensors in their stores without requiring assistance from a professional.
This will include:
Adjusting the sensor transmitting area.
Entering the accessibility content.
Logging the sensor installation location (for maintenance).
You will be required to define the features required for the app, come up with appropriate UI and UX and implement the app.
A representative from RightHear will guide throughout the project.
We will provide you with a Bluetooth sensors kit (using the iBeacon technology).
To help you get started we can also provide a skeleton Android project integrated with the sensors SDK (and code examples of communicating with the sensors via a simple API).
|Applying to the course is possible via this form: |
Registration is open to groups of 3 students (no more, no less) in at least their 3rd year.
All students must have prerequisites(OOP or yearly project, see relevant post).
At part of your registration application you need to include an app idea.
The course staff will review all applications once every ~2 weeks.
If you have any questions, email Omer.
We will formally enroll all accepted students at the beginning of the semester.
|Homework - 12 points |
First project submission (backlog) - 10 points
Second project submission (partial app) - 25 points
Final project submission (full app) - 55 points
Sum - 102 points
|There is a Facebook group.|
You can use it to talk and ask each other questions.
The course staff doesn't use the group and doesn't follow it.
If you want our opinion/comment/reply/answer/etc, send us an email. Don't tag us on Facebook.
IDEs, emulators and other stuff
|A few notes regarding the tools you'll need to install. |
The standard IDE (and the one mentioned in hw0) is Android Studio.
Android Studio is relatively "heavy" and consumes a lot of memory and cpu.
If you can, it's better to use Android Studio.
Otherwise, look for the Eclipse version and use that instead.
Google's avd (Android Virtual Device) is usually very slow and hard to work with.
Instead we recommend using Genymotion (mentioned in hw0).
Google play services:
If you use Genymotion, their provided images don't include the Google play services (used for interacting with Google provided services, such as sign in with Google).
If you need these services, you can find an apk version of them on the internet and install that on the Genymotion device.
No need to install them right now. If, in the future, you see that you need them, you can always add them.
|Attendance to most lectures is highly recommended but not mandatory.|
There are a few dates when attendance is mandatory.
See 'Important Dates' post to know when those lectures are.
Useful knowledge we do not teach
|Developing mobile apps usually includes dealing with networking and databases. |
We do NOT teach these subjects in the course.
These subject are not prerequisites for the course and you may register even if you don't have any experience with networking/databases but you'll be expected to learn them on your own.
|The purpose of the prerequisites is to guarantee that all students in the course have the knowledge necessary for the course. |
In our case this knowledge is programming in JAVA.
Other subjects, such as networking, databases, etc., are very useful in the course, but depending on your project might not be necessary and are therefore not a prerequisite.
If you can show that you took a course that demanded JAVA at some capacity (such as OOP or the yearly project), you can apply to the course.
Why only courses are acceptable and not other java experiences?
We need to know that you know the material at a reasonable level and we get that from your grade in the relevant courses.
Other java experiences don't give us that evaluation of your knowledge and are left to the TAs' judgement.