Create the "User information" class

[inbalzukerman]

For more information see: #24 #19

Create the class that handles the user information. It's required functionalities:

• use a parser from the "Utils" Package to "read" the user information saved on a file
• getters and setters of the user information itself (age, contacts for emergency, etc. )

Notice - this class should be implemented in the "System" package

[SharonKL]

@inbalzukerman are we going to put this in the prototype of Milestone Alpaca? This requires development of another GUI, logic to handle registration requests and development of a new database type.

I think in the upcoming prototype presentation this isn't required, and we can push it to the second presentation (in roughly 2.5 weeks?), while now focusing more on the communication with sensors and apps, and data management.

Any one agrees/disagrees? @EliaTraore @ylevv @roy-shchory @RonGatenio

[ylevv]

I agree, it is more reasonable to move it to the next milestone.

[EliaTraore]

I agree. Even if it gets implmented now, I'm pretty sure the current version of apps doesn't have the code and gui to handle it at the moment.

Can't we already open bunny-milestone and put it there?

[inbalzukerman]

@SharonKL - I agree, clearly it's not too relevant to out current milestone, and it is not part of it's defined goals.

@EliaTraore - I think it is better to leave it in the general "Sprint 2" milestone since there aren't any goals for the lovely about-to-come bunny(?)-milestone. It sounds reasonable that it would belong there, but anyhow we'll know better after defining the goals for the next milestone formally ☺️

[EliaTraore]

Off topic but, why the question mark next to bunny? its obviously the best choice for the next sprint :heart_eyes: I mean look at it -

[EliaTraore]

I think its within our reach in the current milestone, plus 1/4 of #75 depends on it (hence the "blocker" label). Don't mind implementing it if you're not down for it right now.

[inbalzukerman]

@EliaTraore It's ok, I can implement it. Let's just agree on what functionalities are required from UserInformation (?)

[inbalzukerman]

@SharonKL , @EliaTraore - What do you think? what functionalities are required from UserInformation ?

[SharonKL]

• name
• phone number
• address
• emergency contact(s)

[EliaTraore]

• ApplicationHandler specifically needs a Alert(String appId, String msg, EmergencyLevel elvl) method, to notify such events.
• In general I think it should keep default profile, defining the contacts in different elvls, and allow adding custom profiles per application.
• and of course personal info name, phone, address, maybe medical record as well

[SharonKL]

• didn't know we have different emergency levels
• no need to exaggerate, lets leave the medical record out for now

[EliaTraore]

• Well you don't wanna call the hospital every time the elder falls asleep in his couch :stuck_out_tongue_winking_eye:
• I agree that its not critical, but whats the complication beside keeping a file in your filesystem?

[inbalzukerman]

My current point of view:

• I'll implement a class representing a "contact", including name, id, phone number and elvl to be informed at.
• UserInformation will include all the "basic" information of the user (name, age, phone number etc.) and a map of contacts. Moreover this class will implement methods such as:
  • getContactsOfElevel( String id, emergencyLevel elvl)- which wil return all contacts which should be informed at emergency elvl or "lower"
  • userInfoToXml()- which will allow saving the information if needed
  • xmlToUserInfo( File xmlfile)
    • usual yet necessary getters and setters

@EliaTraore @SharonKL - a penny for your thoughts?

[SharonKL]

• • Why does this method receive an id? and I suggest renaming it to simply getContacts(eLevel) and maybe overloading this function with a no-parameters alternative to receive all contacts, getContacts()
  • rename to toXML()
  • why not have a constructor take a File as an argument instead? Or maybe use a factory

[EliaTraore]

• Why does a contact need an elvl attribute? keeping contacts in lists by their elvls seems better since it will make alert(String appId, String msg, EmergencyLevel elvl) easier to implement (otherwise you will have to go through all the contacts to find those with the appropriate elvl). And regardless, a contact might have couple of elvls in which he wants to be informed.
• • Missing the aforementioned alert method
  • @SharonKL I'm not sure yogi would like us using XML instead of Xml since (as he told us in the Id vs. ID case), the java convention is to go with CamelCase even for acronyms. Moreover, we did go with Id in the end and not ID, so that's kind of the project convention right now
  • No crucial right now, but I think that the profiles offer needed functionality. An SOS app might have different set of people that need to be contacted then a stove app for example.

And another thing I just thought of - we should consider adding email-related elvls, and add an email field to the definition of contact as well. It will be easier to implement sending alerts via email (so we might be able to show it in the presentation of bunny) and maybe some people prefer email alerts.

[SharonKL]

• agree
• • לא הבנתי
  • for some reason I thought we used ID. Agree, I prefer Xml. Oh and by the way, Java has no official convention for acronyms (afaik). Yosi will be able to correct me probably
  • possible, we can also have a default profile, and allow the user to create special ones for some apps (but I think this shouldn't be of any concern to us in milestone Bunny)

[EliaTraore]

-

- (omg hebrew is so edgyy) The apps depend on `alert(String appId, String msg, EmergencyLevel elvl)` to notify about abnormalities. We could either put that in a separate class (#comunicationHandler #calledIt) or have it as part of the `UserInformation` class.

I thought that since keeping the info by itself is a small task, this class could go ahead and implement the functionality of contacting the contacts as well. If you guys think its should be in a separate class+issue then I'll go ahead and start the github-paperwork on it.

• He's like the boogyman, say his name 3 time and he will appear out of thin air to share some trivia with ya
• Thats exactly what I meant by profiles :smile: imo its not too complicated but it isn't a priority either... Just something to consider when implementing (even if its not implemented now, a flexible implementation could make adding it later less complicated)

[inbalzukerman]

@EliaTraore - I agree with you about not saving the emergency level in the Contact class and I will add an email field asap- really good idea 👍 😄

I don't really understand what do you mean by "profile" though 😞

[EliaTraore]

a profile is just a - Map<EmergencyLevel, List<Contact>> (assuming thats the structure holding the info) the default profile will have a list for every elvl, each of which is initialized (since we have to have a default) and then the user can say "i wanna have a special behaviour for SOS app" so you create a new map assosiated with the id of the application, and when an app alert on some behaviour you first check its map (if it exists, and the elvl have an initialized list there), and if not you go for the default profile.

[EliaTraore]

Now that I'm writing it, I see that there's a small issue of knowing the appId by the sides involved, so for now I guess the basic implementation could ignore the appId param of alert and just use the default profile, since its really not that critical at the moment.

[inbalzukerman]

Thanks for the explanation 😊 👍

[inbalzukerman]

@EliaTraore and @RonGatenio - By now I'm (really) almost done with my part of this class (only some safety checks to add on one method) Feel free to work on alert, I left it empty 👍

[inbalzukerman]

@EliaTraore , @RonGatenio - I've noticeג there is another issue regarding the alert method and it's implementation. Therefore, I've completed this issue since alert's implementation is a crucial part of #108 . Therefore, I'm closing this issue 😄 🎉