Android Clean Architecture - Seperate Usecases, Single Usecase, or not a Usecase at all?

Question

I'm working on refactoring an older project of mine to follow the Clean Architecture paradigm (and loving it so far) and one of my components is causing me a bit of confusion in relation to whether or not it should exist as a UseCase.

Simple Example For instance, the requirement is there is a contact information screen, that will display previous answers, and give the users the ability to submit updates.

Do I have two use cases (1 user submits contact information, 1 view contact information).

Or is it just 1 UseCase (Edit contact information, with 2 functions to return previous and also submit)?

My Actual Example Bold is the use case i'm not sure about below if you want to skip to that.

The screen itself is a grid of 10 images that you user can select between to have that image featured elsewhere in the application. Nine of These images are resources in the project, one is a spot where a user can upload an image of their own, and the user's selection is stored in Shared Preferences.

Use Cases:

1. User Selects an Image

   This is definitely a use case and the business logic behind it makes sense to me why. The user is taking an action in the view layer and i'll be updating my data layer (repository) with their selection. Perfect.

2. User Uploads their own image- This is a use case as well. User uploads their image and do some work to store it, as well as select it as their selection. So two pieces of functionality in one use case, which makes sense. It fits the whole requirement. Perfect

3. Display Options to User ? - This is the one that is throwing me for a loop. So when the user navigates to this screen, I need to start it by displaying the 10 options for the user to select between, as well as highlighting the previously selected image.So is it a separate use case for me to say Display options, or get options? Or instead, since 9 of these images are in resources, is this just part of my view set up? If thats the case, do I create just a Use Case for retrieving user's uploaded Image?

I know i've got a few other instances like this where there is like an initial data set up set.

Most of the time it comes from an API or the database and it is part of a more complete business rule that makes sense as a UseCase. I'm just a little unsure for cases like this, where maybe i'm reading from a file or loading from some existing resources.

Thanks for the advice!

Answer 1

Is it about use case or user interface ?

What you call use case seems to be the detailed specification of a user interface:

• The screen itself is a grid of ...
• User Selects an Image ...
• User Uploads their own image ...

In other words, your focus is more on "how" than on "what". So the first question to ask is what you want to document.

Is it the user interface ?

You could of course use use cases (UC) for this purpose. But they might be a suboptimal overkill: the link between the actions described in the UC and the user interface elements is not clear; In addition, UC are not meant to document an ordered sequence of actions with alternatives.

Spontaneously, I'd rather recommend to use a couple of wireframes to express such things very effectively.

If the user interface is complex, and requires some sequence of actions, you may consider activity diagrams rather than use cases.

Or is it about the system purpose?

Use cases are more effective at describing the purpose of a system, i.e. for what goals the user will interact with the system. The focus should be on the big picture rather than the details.

For example, I understand that the goal of your application users is not to manage and upload pictures nor to fight with grids; the goal is to manage resources (Main use case). Use cases could be decomposed to should what subgoals the user wants to achieve, e.g. what the system shall allow a user to do with resources. Typically it could be things like maintain a catalogue of ressources resources, describe individual resources, allocate resources to projects, etc...

How these use cases will be achieved in the system depends on its design. For instance one could imagine a single screen application that allows to launch all use cases. Alternatively, you could also define a transactional system, in which each use case would have its specific user interface.

Additional reading

I highly recommend you Ivar Jacobson's Use Case 2.0 free ebook. Jacobson invented the use case approach of UML. In this ebook, he clarifies the main intent of use cases, and how they could be used in a modern agile context.