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.
Related
In the last period i am having the chance to develop some apps for personal reason, and taking a look to what today the companies are organizing their work in the Android Ecosystem i encountered many and many times this kind of project configuration:
MVP (Model-View-Presenter) as Design Pattern for app architecture;
RxJava for Reactive programming event-based;
Dagger2 for dependency injection;
ButterKnife for fields binding with annotations, used in combo with Dagger2 in order to make your life simplier;
Espresso and Mockito for testing (really nice to use in this kind of environment with this kind of settings)
So, is this becoming a new standard, in your opinion? If so, do you think that is a good idea apply this (relatively) new guidelines and you usually use this kind of project tools/pattern/libraries into your apps or you think there is something better? If you don't like, it, why? What do you think could be a better approach?
(Obviously each project is different, and for each project is always better engineerize the best solution/architecture possible for the kind of users/team/dev involved. I am trying to understand/discuss this kind of model that seems to become widely used in his concept in many, many companies)
Thank you for your time, i hope to create an interesting discussion on the argument in order to all improve our skillset/projects.
Enjoy your day!
We can not say above methods as standard because Android-Sdk does not have any official support from its Libraries and API's. But As far as development environment is considered now a days Developers are using these methods for writing better code base for their apps, better understanding for future development.
As per my knowledge using these libraries is useful only if they have good support from developers as these are open source libraries. For example I am using AndroidMVC right now for MVP pattern. As per my knowledge this is very good library as I am using it since last year but As there is only one developer working on that library, it's very hard to get support for bug fixes(forget about enhancements).
So while selecting any open source library you should always look all the parameters like support, enhancements, bugs etc.
Libraries like Glide, ButterKnife, OkHttp, Couchbase lite, retrofit, Volley etc are some evergreen libraries of Android.
But again OkHttp, Retrofit and Volley are used for similar purpose i.e. for networking. Now developer have to choose according to pros and cons of each library.
As far as question - should we use libraries or not? is considered. I think YES. We should use these kind of libraries which are stable because it saves lot of time and it's not of use rewriting the code if we already have it in form of library.
Throughout Google search some people has told that Android architecture is MVC just like in iOS. But I couldn't feel the separate Model concept in Android. What is the design pattern behind Android design? And what are the main differences in case of programming concept (not IDE, language)?
Well lets see what we have on both sides:
iOS:
UIViewController
UIView
Your stuff (models and other)
Android:
Activity
View
Your stuff (models and other)
If you don't know already, Activity is the equivalent of UIViewController in Android.
Given that we know that you can now draw the line for yourself and see that in fact both platforms do work in the same manner from the MVC point of view but that can't stop you implement you project's architecture as you think it's the best for you.
Of course the low level implementation and logic in some cases are pretty different on both platforms though.
The way I understand it is that Android's architecture is more MVVM than MVC. But I'm also very new to all of this so don't take it for granted. Another opinion on this would be nice!
What are the specific benefits or advantages of using a dependency injection framework for Android, like Dagger, Transfuse or RoboGuice?
For example, what kind of apps would benefit the most from using DI? is there more of a performance advantage, or is it more on the ease of extending an app, or even more about making it testable?
One of the reasons for asking this is to gauge if an app I'm developing would actually benefit from it or not much. Since I intend the app to be serious at some point, testability and ease of extension would be great, even if costly to use (more time to setup, learning curve, etc) for the first versions.
Thanks!
For example, what kind of apps would benefit the most from using DI?
Dependency injection (as a pattern not a library) benefits almost all code.
It promotes designing modular components which expose only the necessary APIs required to perform a specific action. When you are forced to break up pieces of your applications you have to consider how much implementation detail to expose, how the API behaves, and the visibility of classes and methods.
It promotes logical abstractions of components (think: interfaces and their implementations). You certainly don't have to do this, but it ends up occurring organically anyway the more you DI things.
It facilitates testability by creating a single point of type consumption through which a class obtains something it needs. Need to swap out a Foo for a TestFoo? No problem.
Is there more of a performance advantage?
No. The dependency injection libraries exist solely to reduce boilerplate around the pattern and increase the declarative ability to request dependencies.
Is it more on the ease of extending an app?
Absolutely. While I would never recommend using Guice (or RoboGuice) in an Android application, the introductory talk to Guice from Google I/O is a fantastic introduction to why dependency injection is important in this regard.
Even more about making it testable?
Yes and no. This is a happy side-effect of proper abstraction and modularization. Testing is a great thing so the fact that dependency injection offers an ease into it is also great.
I gave a talk about Dagger in the context of Android recently which you can watch* or view the slides. The talk starts out with dependency injection as a pattern and then moves into how Dagger reduces the boilerplate and enables some pretty cool features as well.
I also made a fairly advanced sample application which leverages Dagger for complex injection use-cases that might also be worth checking out.
*The talk is currently not free, but will become so at some point in the next 10 months.
I'm debating using guice in an android project that is quite complex and has a lot of business logic. Guice seems like a good fit, but whenever I start reading deeper into it, it starts to look more complicated than it needs to be.
One thing I don't understand is: if Guice is so great and the best way to write java code, how come there is so little Android code that uses Guice... and why didn't Google use guice internally for Android?
Guice totally makes sense to be used and in fact is used in a whole bunch of applications. The extension RoboGuice adds some niceties for Android that makes it super productive to use.
In fact I can not imagine writing an Android app without it. Too painful.
Check out the links to apps using Roboguice on the website (e.g. Google Docs, OpenTable...). Also other apps like the Square app are known to use Guice directly.
It totally makes sense .. go do it!
Together with Robolectric it will also make your testing efforts easier.
PS: I am a committer on RoboGuice so I am partial ;-)
PPS - June 2013: Recent developments have given rise to other annotation/dependency injection based frameworks that do most of the work at build time and therefore avoid the performance hit of the runtime reflection (that is slow on Android) and are therefore more suitable for performance critical work - check out Dagger and AndroidAnnotations if you are interested in that.
Actually google discourages using Guice or RoboGuice in android applications due to memory overhead.
Source:
http://developer.android.com/training/articles/memory.html#DependencyInjection
5.11.2014 Edit:
There is a dedicated fast dependency injection library for android. I can see more and more people using it:
http://square.github.io/dagger/
13.04.2015 Edit:
Google released its own version of dagger, which does not use reflection in runtime:
http://google.github.io/dagger/
You know there is RoboGuice? It's Guice for Android.
The problem with demonstrating the strengths of a dependency injection framework is that it isn't possible to achieve it with a simple Hello World application. These frameworks show their value only in big systems with a lot of complexity. Also, they have a somehow steep learning curve.
Therefore it is quite normal that you can't find enough tutorials - open source projects that use Guice. This will be most often used in enterprise applications that do not get published.
As why Google doesn't use Guice, Guice doesn't fit everywhere. It adds a perfomance overhead and it doesn't make sense to use it in places, where it isn't needed.
As a beginner for Android development, code samples I am learning from look somewhat disorganized and are hard to test or even to understand. So I followed this post suggested: Using Dependency Injection with Roboguice? and am trying to use Android-binding and Roboguice. But I am now worrying about how good they really are.
Are they good enough for all Android projects including ones with a couple of views?
After building an app with these tools, how is the app's performance in comparison without the tools? Any problem with using these tools?
Is there any other tool that can help me for Agile/TDD?
I've only used Roboguice and this is my opinion of it.
Roboguice is derived from Guice. So it's not really a dependency injection framework built from the grounds up for mobile environment. That being said, it can cause quite some overhead to your app.
On the other hand, I haven't seen any mobile app that reached a complexity that really needs dependency injection. I had an app the used Roboguice, but soon I realized that it's making my app more complex than it needs to be. So I stripped it out. I guess this depends a lot on the scale of your app.