N
N
niosus2013-11-12 01:31:49
Android
niosus, 2013-11-12 01:31:49

With an architect?

Hi Habr!
I thought for a long time whether this question is suitable here and in the end I came to the conclusion that I would try. So poke me with your nose if something is wrong.
A little background. I'm a master's student and what I'm doing now rarely requires beautiful architectural solutions in the code. However, since it won’t fit into my head on its own, I write something myself, where I try to implement what seems right to me in life.
So the situation is this. At the moment, I have the architecture of a piece of an application that I write in my spare time for android. It would be very, very cool to hear opinions on at least some points:

  • whether this is done;
  • approach problems;
  • how it is done correctly from your point of view;

So, the actual architecture. I will describe in words, if something remains unclear or you need clarity, I can draw or throw in a small code example.
I have:
  • activity, the essence of which I defined for myself as “control everything”.
  • some classic Worker, which is a kind of smart queue of asynchronous events.
  • three fragments (in the ViewPager) that do one single thing - draw the UI and notify via activity callbacks that something has happened.

There are no problems with Worker, everything is clear and logical there. My problems (as it seems to me) in my Gue.
These three fragments inherit from an abstract class that inherits from fragment and implements some common things like onAttach() or a constructor.
Farther. In addition to the methods of the abstract class, these fragments also have their own methods. Thus, when my controlling activity hears that something is happening somewhere, it looks at which fragment is currently active (getting it as an object of an abstract class or even a fragment in general), casts it into a concrete class, and calls the necessary functions in it to change some element of the gui.
And this is where I'm suspicious. First of all, Android Studio doesn't like it because I end up declaring an object of a concrete class. Secondly, I don’t know how to change it, and here I’m already starting to get nervous about it, whether I have some kind of fundamental mistake, by making which now you can’t fix anything without rewriting. Well, plus, I'm a little stuck in this architecture. When you come up with one thing, it's hard to look at it differently.
In general, if you are still reading this and you have a craving to help people like me, then I would be very grateful for your criticism of what I already have and suggestions on how it can be improved/changed.
Or, alternatively, a place on the web where you can read about something similar to what I described. Thanks in advance.

Answer the question

In order to leave comments, you need to log in

2 answer(s)
S
Seter17, 2013-11-12
@niosus

casts it to a concrete class

This seems to me to be a real miss. And I think this is your fundamental mistake. The essence of multiple inheritance from an abstract class (interface) is to get away from specifics and make everything more abstract. I will assume that part of the methods of your concrete classes. which you call after the cast can be combined into an abstract Proceed () method, for example, in which each will have its own hierarchy of calls to its heap of methods.

@
@xave, 2013-11-12
_

What if you do not make different subclasses of your ViewPager with different methods, but create one specific ViewPager class and implement the "Strategy" pattern. Depending on the event, your activity will pass to the resulting ViewPager class an instance of the Strategy class that implements the ConcreteStrategy algorithm for this event.

I have: an
activity, the essence of which I have defined for myself as “control everything”.

And it does not fall under the description of God Object?

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question