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.
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.
I've been working on a writing a game for Android. Until now I've been using Java instead of the NDK, but I've decided to port my code to C++ (for performance, memory management and industry standards reasons).
Porting my application shouldn't be a problem (I've written my fair share of C++ applications), but I've been using RoboGuice as a dependency injection framework because otherwise my object graph would become too complex rather quickly.
I've been looking around, but I haven't found any resources about using a dependency injection framework in combination with the Android NDK.
Can someone tell me if there any such franeworks available. If so, which one would you recommend?
If you have a C++11 compiler for Android you could use several frameworks (I wrote Infectorpp) but there are others available. You should note that DI is quite limited in C++ due to the lack of reflection so you should make some compromises as not everything you did in RoboGuice would still be possible.
By doing a quick search seems that C++11 is possible on Android. I don't have an Android device and still not needed to emulate it, but if you have any feedback it will be wellcome (private message here or support ticket on google code is enough), the library is headers only so no special build stuff is required for it, apart enabling c++11 on your compiler wich is just one extra option by command line. If that will works good on Android then it will be definitely good also for PC. (Do not misunderstand please, I'm using it heavily, but seems very few people is interested in DI in C++ and so I get very little feedback)
There was also a nice framework cpp-resolver: a little awkard to use because you explicitly register factory functions for injecting ALL parameters, but very scalable, especially for server applications.. (decouple object lifetime management and works with plain old C++).
The most complete framework is probably wallaroo
If you search something really easy to use Infectorpp is a good choice
If you need control over lifetime (mostly servers): Cpp-resolver is perfect
If you need exotic features and configuration files: wallaroo
As side note, run-time configuration is possible also with frameworks that do not explicitly support it:
You just need a Factory that istantiate a different type based on a configuration file you could read through a class that you add as dependency to factories (Probably you don't need to know that since you were already using DI frameworks, but still good to know for occasional readers)
I want to develop an android application that supports dynamic loading and unloading of bundles. Therefore, I am considering using an OSGI implementation framework.
What would be my best OSGI implementation choice?
By best, I am talking about Documentation (Availability of resources), Compatibility with Android API, and support for embedding OSGI in Android Application.
While searching, I found two implementations that seem to be good:
1- Apache Felix
2- Knopflerfish
Any suggestions? Thanks.
Both work on Android. Like Balazs pointed out in a comment, there are quite a few subtle differences between Dalvik and the JVM and some of those do bite you when doing OSGi style dynamic loading of code. From memory, you also have to worry about not being able to load the same class twice (even if they are privately packaged in different bundles). However, since you're probably designing the application from scratch, you can probably work around such issues.
You will also find some information here: OSGi container for Android
One tricky aspect though is that Android is also a bit of a moving target. The first version of Android did not have the classloader methods exposed that we needed to get Felix running, so we had to do a bit of reverse engineering. It is hard to predict what future versions of Android will bring though. Things might break. Are you going to choose your own version of Android and deploy it to the devices you target, or does the code need to run on existing devices?
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.
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.