Create NCCommunication+Hovercard

[thisIsTheFoxe]

Add class models for return type
Add getHovercard(for userId:)

Related

• Profile page ios#1715
• Avatar hovercard talk-ios#654

Note

I wasn't able to really test it with NC beta 2 installed (at first, was able to test eventually). Feel free to test it yourself and let me know if you have these or other problems.

1. I got "appId": "", for the talk action. Probably some version incompatibility. It worked when using the spreed master branch.
2. The authentication token did not work! Could also be a server issue..

[marinofaggiana]

Hi @thisIsTheFoxe will be better move the Hovercard class in NCCommunicationModel, so all the class (record -> after stored in DB) are available in a single file with the NC prefix, result: @objc public class NCHovercard: NSObject and I would like to keep the @objc compatibility if possible until we decide to remove the OBJC compatibility, and remove the JSON logical and insert it inside the func getHovercard, what's do you think ?

[thisIsTheFoxe]

Ok, for now, but especially in line with refactoring we should definitely consider splitting up NCCommunicationModel into much, much smaller files and improve at organisation at a directory level.
I do get the @objc dependencies, but the faster we can move on to Codable the better - imo.

remove the JSON logical and insert it inside the func getHovercard, what's do you think ?

Well, in line with the MVC patter, I like to keep the controllers light and the models heavy. That way the business logic is
not 'leaking out' to places where it isn't relevant. Rather, it's contained in the model and the controller can focus on what to do with it.

[marinofaggiana]

Ok, for now, but especially in line with refactoring we should definitely consider splitting up NCCommunicationModel into much, much smaller files and improve at organisation at a directory level. I do get the @objc dependencies, but the faster we can move on to Codable the better - imo.

What's you mean for directory level

remove the JSON logical and insert it inside the func getHovercard, what's do you think ?

Well, in line with the MVC patter, I like to keep the controllers light and the models heavy. That way the business logic is not 'leaking out' to places where it isn't relevant. Rather, it's contained in the model and the controller can focus on what to do with it.

it depends ... here the world is divided into 2 parts :D, to me it doesn't make much difference then at the basic code level, in the end it's just code reading philosophy but I like that everyone expresses themselves as they wish it is enough to be coherent and easy to read ... in fact, later on I would no longer want to deal with this and concentrate on anything else.

[thisIsTheFoxe]

I just mean that we should organise code in more files and group those in directories. Big files are just super messy. There's shouldn't be any reason to have a file >1000 lines of code. Especially in Swift, 400 is already considered big - imo.