I was reading several guides and one book about the Strategy pattern. I noticed that in all the guides there is a referall to a Contextclass that favoring delegation over implementation decide for some specific behaviors.
As I manage in android the class, object Context on daily basis, I would like to know if the SDK engineers tought at the Android Contextas a concrete (complex) implementation of the strategy pattern.
As Wikipedia says, the Strategy design pattern enables selecting an algorithm at runtime (where multiple possible implementations exist). The Context class does not encapsulate any single algorithm. And for the services that it allows to access, there are no multiple possible implementations selected at runtime; there's just a single implementation provided by the OS.
Therefore, no, the Context class has nothing in common with the Strategy pattern.
Design patterns represent the best practices used by experienced object-oriented software developers. It is naive to believe in a platform like Android this is not applied. For example, a design pattern when designing Android Context would be when dealing with different screen sizes. The context has instruction based on a Strategy Design Pattern to deal with so many different screen sizes.
I found this to be the simplest and most useful tutorial for design patterns with example of using context class.
https://www.tutorialspoint.com/design_pattern/index.htm
Basically, Context is reference that holds global information about an "Application environment".
This is an abstract class whose implementation is provided by the Android system.
It allows access to application-specific resources and classes, as well as up-calls for application-level operations such as launching activities, broadcasting and receiving intents, etc.
In short, it's reference about things running inside application (you can assume it as global pointer to application process registry to be used in application environment, *in my opinion).
You can check out more here.
Related
I am currently integrating architecture components into my app according to the official documentation and the sample apps provided by google (sunflower and todo-app). I realized that none of these use interfaces for ViewModels (the sunflower app does not even use interfaces for repositories).
My question is: is it reasonable to just omit the interfaces for ViewModels (including advantages and disadvantages)?
Is it reasonable to just omit the interfaces for ViewModels?
The below is quite general and applicable not just for ViewModels.
Advantages:
less code
Disadvantages:
won't be able to use most of the well-known design patterns;
won't be able to properly unit test classes (no mocking);
won't be able to properly use dependency injection frameworks;
code refactoring when using another concrete implementation.
The answer depends on the complexity of your ViewModel. If you are never going to create more than one implementation of an interface (including mocking), then there is no need to create the interface, so you can reduce the code and the overall maintenance burden.
That said the important things to consider are:
Can you unit test your view model, even without the interface (answer should be yes, otherwise you have some other problems IMO)
Can you still use a dependency injection framework (the answer is yes at least for some DI frameworks like Prism)
Are you only ever going to create one implementation of your ViewModel?
I believe that the mark of a well-designed ViewModel, should have a relatively simple implementation, and be easy to unit-test without having to resort to mocking.
I'm working on an Android project and I would like to know any recommendations about what's a good architecture to build an android application.
I want to use dependency injection using Roboguice and I've been reading about MVVM pattern or MVC pattern (Android MVVM Design Pattern Examples).
Also I know that roboguice have a pretty cool Context-Based Event's raising and handling feature that could be very testable as the code is decoupled.
Any recommendations on a working design pattern? a testable and scalable architecture you have worked with or developed?
The Android platform provides a common set of design patterns, and with the limited hardware resources you get compared to Web-apps it is still often best to stick with using these directly in production code. There are other frameworks that sort of "wrap" the base platform; these are worth looking into if you have a specific purpose (or perhaps for prototyping/experimenting), but for the best level of support you are generally best sticking with the standard components.
This is a great resource when working on UI solutions: http://www.androidpatterns.com/
Specifically for DI: There is a Spring framework for Android, I've had a play with it and it looks quite promising. You've already mentioned Roboguice as another alternative to this. However, to avoid performance and library overhead, I still find the easiest approach is to write a simple reflection-based class that registers and injects dependencies within my own code. Similar to this approach, except I usually move the injection code into a separate singleton and reference it from there.
In my experience most of the third-party offerings are not yet mature enough to rely on right now, and don't really give you much on top of what the base platform provides. They are constantly progressing, however, so be sure to experiment with the big names from time-to-time.
Effective Java (Joshua Bloch) Item 17 says :
"Design and Document or inheritance or else prohibit it"
However, just a cursory glance through the Android APIs reveals that most of the API classes are non-final; which is OK if they are also documented for inheritance (View of Activity, for example). But there are also several non-final classes, but the documentation makes no mention about the inheritability of these classes. Just some arbitrary examples to illustrate my point:
The classes representing the System Services (WifiManager, NotificationManager ...)
Utility classes like UriMatcher.
Some hardware-specific classes like Camera.
Openness and extensibility being the philosophy of Android, is the convention reversed here? Meaning, could one assume that all of the Android API classes are designed to be inherited (whether explicitly documented or otherwise); unless declared final?
Just my €0,02: Clean OO design by the book is one thing, making things work for all possible use cases in practice is another. The principles of clean OO design sometimes are somewhat of academic nature. - And maybe a little bit of black and white.
Think for instance about who uses the Android API provided by google: It's not only app developers but also device manufacturers who need to specialize general APIs for their devices.
So, for me, SW design is neither black nor white in most cases; the shades of grey are important.
And finally: In practice I have seldom (read: never) seen problems caused by "carelessly" omitted final keywords (on classes), while unreflected overuse of final (often caused by thoughts like "my code is sooo [great | ugly], no one will actually ever want to modify it through inheritance") can be quite a pain.
"I know that I know nothing" seems to fit here: It is presumptuous to claim that one knows all the crazy, ingenious, creative, smart,... ideas of others for how one's code may be used in the future beforehand.
The Android developers went to great lengths to ensure that extensibility, while not recommended in many cases, is possible. The motivation behind this appears to be related to testing environments.
For instance, it would be much more difficult to create a faux WifiManager for the purposes of creating unit tests if it were finalized. Without the finalization, it is trivial to subclass the WifiManager (e.g. to mimic "unexpected" wifi disconnection during operation) and return an instance of this subclass from a customized testing Context.
So while you will probably never find a reason to implement a subclass of the these classes in an application that you ship to the end users, the flexibility is there to allow you to extend them if it is necessary for one reason or another.
In the case of utility classes, the answer is simply that the utility of the class is not diminished by allowing the developer to subclass; in many cases, a developer can achieve more understandable code reuse by inheritance than by aggregation and delegation.
How do I make application context available to all classes in application in the app?
My supporting classes need to be able to access it in order to access resourses.
Best answer: pass in a Context to your supporting classes' methods, as the application context may or may not work for your particular cases. You will notice, for example, that many supporting classes in Android take this approach, and it is generally a good idea to follow the patterns set forth by the platform developers.
Possibly tolerable answer: use a static data member to hold a reference to the Application object. Be very very careful that you do not introduce memory leaks in the process.
I'm new to Android. Can someone explain me the concept of Context class/Object. What it is? What it will be used for? Why Context class?
Have you seen the android developer's guide? it will answer your questions:
Interface to global information about an application environment. This is an abstract class whose implementation is provided by the Android system. It allows access to application-specific resources and classes, as well as up-calls for application-level operations such as launching activities, broadcasting and receiving intents, etc.
A Context has a lot of functions, but as a developer, you primarily use it to load and access application resources.
In programming Android applications, you will hardly ever need to use the Context class directly (not possible at all since Context is abstract), but you will need the child classes that derive from it like Activity, Service etc.
You might want to look these up.
You can think of Context, like the end-user-interface that will use that code. When you are in a class you can know based on Context if you have visual screen(Activity), or a running service(Service).
To compare against some other programming example, you can think of Context is equal to Console App, GUI App, or even Applet.
I hope if you read this source code you will have answer for the problems:
http://www.devdaily.com/java/jwarehouse/android/core/java/android/content/Context.java.shtml