A few remarks risen from your questions during question time. Anyway, when in doubt, remember to always justify your design/impelemntation choices in your submission.
1. Content identifiers: you can use as content identifier any piece of information that seams meaningful for customers to identify the content. The simple solution of using a short string is all right for the assignment, assuming that in reality those strings allow customers to uniquely identify the content. For example they could represent the title of a song for music content. YOU CAN ASSUME SUCH IDENTIFIERS TO BE UNIQUE. Some of you are using content manager addresses instead of titles/strings. This solution needs to be justified in your submission as an address is not an immediate way to identify a content by an human customer, without further passages (i.e. querying the corresponding contract for further information).
2. GetNewContentsList(x), GetLatestByGenre(x), etc. methods: for all those kinds of methods there are two opposite simple implementation approaches. The first one is to store additional information on the catalog smart contract to allow it to keep the relevant lists updated. This incurs in an increase of gas expenses for such contract and most content addition or consume operations. The second solution is to leave all the burden to build the lists at request time to the consumer calling the methods. The two solution are a tradeoff between gas consumption and execution complexity/time. In designing your solution and potentially choose between one of the two approaches do keep in mind the following points:
- constant functions do not consume gas but are a burden for the client executing them.
- the gas paid for a transaction is a cost for the transaction creator. Always keep in mind if the gas payer really is the one that will benefit from the gas spent. E.g. is it correct in your scenario that a content creator will have to pay more gas to ease a functionality used by customers? If not trivial, always justify your choices.
3. Time measurment: in a blockchain scenario there is no concept of global clock or exact time, but yet smart contracts need to be globally deterministic. This is why we advise to use block height as time measurement.