I have used retrofit-robospice module in my previous project, it uses retrofit 1.6 .
with the new version of retrofit (retrofit 2), I want to rewrite that module with retrofit 2 . I have heard from some programmers that there is no need to use robospice anymore and you can just use retrofit 2 itself .
the reasons that I use robospice :
Listeners
Configuration Change Managment
async requests
caching
no memory leaks
so my question is do you recommend using retrofit-robospice module ?
if yes in which scenarios ?
and does it worth rewriting that module for retrofit 2 ?
IMHO. What you asking here is a subjective opinion of different people. Everyone will just say to use or not to use a retrofit-module. So i'll just be like others. In my experience robospice-retrofit makes an excellent job, and i definitely recommend to use it and i'm using it myself. But again it's just another opinion of another person.
If you're already asking this question then it must be that the scenarios of using Robospice you've got figured out yourself until now. Why would you ask if that's not true. There's an excellent infographics which illustrates the usage better than any words.
And the last one about does it worth to rewrite the module or not. The answer is: "Yes, it is worth the effort". The library itself is an open source project with the code base located on GitHub. Not to mention that by 'rewriting' the module one would save the others from asking that same question again in the future. So instead of asking somebody else to do the work and give it on the silver plate everyone may just do the work by himself and share his work with others. And after that one would be able to tell us was it worth to rewrite the retrofit Robospice module or not.
Related
Am working on a huge android project that has more than 50 APIs request
and using the MVVM pattern, My question is:
can I add all the requests in the same app repository or I must create a repository for each service?
As others suggested in the comments you should first define the modules of your app and then create the corresponding Repositories. This way you can easily maintain and test your application.
I strongly suggest you to have a look on this https://github.com/nickbutcher/plaid and mostly this video https://youtu.be/Sy6ZdgqrQp0
A good solution to this problem is, You must not implement all your API calling code to the same repository as it will become a massive single repository class. It will also be violating design principles i.e. rule of 30 as you are saying you have at least 50 APIs to work with.
Also, it is not a good practice to modify a class, again and again, see Open Close Principle.
You can make multiple API calling classes under the same package name.
I know that both Exposed and Anko can operate SQLite easily, could you tell me which one is more better when I develope an Android App?
Use the framework you are most comfortable with. I tried Exposed once and it was ok for what I've used it. jooq might also be a valid alternative instead.
Reading the documentation of both, Room and Anko, I would stick to either one of those.
Regarding which of those, I just found an issue asking the very same question (even though just as a second or third question):
https://github.com/Kotlin/anko/issues/484
Some other resources I found regarding Room and Anko:
Stress-free SQLite with Anko: the comment regarding Anko vs Room is also insightful:
Anko SQLite provides a nice API to manage your data persistence layer but you still have do the heavy lifting by yourself. While Room is more like a framework. Generates databases from annotated classes for you, provides observable queries and has a really nice testing support. Also works well with Android Architecture Components.
Ah... and don't get me wrong. Exposed is ok too, I am still using it ;-) But if you are familiar with both, you may also have your preferred choice already. If you don't know any, you can try both and choose the one where you grasp the documentation more quickly or you feel more comfortable sooner.
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.
Disclaimer. I'm asking this on someone else's behalf and given that I know as much about Android development as penguins about flight, it may be clumsy. In such case, let me know and I'll remove it or try to reformulate.
I've created a web service that's reachable at the URL on the following form.
http://server/Blopp.svc/Store/value1/value2
The back-end part I've got covered but I'm worried about the front-end development. I've got a colleague that's making the app and he's got the rudimentary GUI done. However, in order not to do a lot of convoluted coding, he's heard that there's a certain library for making such URL calls.
What's the name of it? Is there certain other aspects to take into consideration or is there an (almost) standard one that everybody uses?
Please not that the app's functionality is at the moment limited to providing the web service with data. All the logic and presentation is done on the website and not inside the app.
I've never built up an Android app, so I'm asking for understanding if this is a dumb formulation. I just want to help my co-worker and he seemed to struggle with the details.
Is there perhaps a smoother way to make the call to a web service if I substitute the patter of the URL to use query strings? Any other approach that makes it easier for an Android developer? I'm not familiar with the area but I want to make things easy for my team-mate.
There are quite a few different HTTP libraries available and it would really depend on your specific requirements which one you used (if any - you can roll your own HTTP requests using HttpURLConnection) Two of the more popular ones are:
Volley
http://developer.android.com/training/volley/index.html
Written by one of the guys on the Google Play team and part of the AOSP. Very flexible and easy to use however I would hesitate to recommend it as it relies on the now deprecated Apache Http classes in its public API.
Retrofit
http://square.github.io/retrofit/
From Square. Version 2 is currently in late stages of beta. It allows you to define your API as an interface. It has dependancies on their OkHttp library as well. Very fast and also has RxJava support baked in.
I'm looking for an alternative HTTP client library than what is already included in the SDK. I haven't been able to find any. Does anyone know of any? It doesn't have to be open source.
Many of the issues with Android's built in HttpClient are related issues that have been resolved in HttpClient 4.1. Dirk Boye has created a script to convert the HttpClient 4.1 sources into an Android friendly package. You can find some prepackaged jar files and his script here: https://code.google.com/p/httpclientandroidlib/
You have different options to manage networking in Android:
OkHttp (needs Okio) + Volley + Gson: is a common REST solution for JSON based APIs. You can use each of these tools separately, so for example if you don't need JSON serialization/deserialization you can just use OkHttp + Volley (where OkHttp is the Http client and Volley is a REST library/helper that offers an easy way to load images as well). If you just want an alternative Http client you can use OkHttp(+Okio) which is the best one or among them right now. OkHttp needs Okio(that you can use as well separately) and is a library that complements java.io and java.nio to make it much easier to access, store, and process your data. You can find more information about this solution here..
OkHttp (needs Okio) + Retrofit + Moshi + Picasso. This option is pretty much equivalent to the previous one. Retrofit is comparable to Volley, Moshi to Gson and Picasso is on image loading department. All of this stuff was mainly developed by the same guys and all tied together works like a charm. More on that here.
ION is a very good library that tries to deal with a lot of stuff mention in the options 1 and 2 (Http client, REST helper, uses Gson as well and load images). Better check this out.
Android Async Http: I haven't tried and don't have any information about it, but looks like might be worth taking a look.
I'd say the option 1 is being replace by the option 2. The option 3 has a lot of fans and is developed basically by one (awesome) guy, but offers a LOT of things that you might be not using. That's the reason the Square guys (guys behind option 2) have split everything in 5 different libraries. I can't say much about the option 4. I might be checking it out soon.
Notable mention is Glide, that is (maybe) the best image loading library today developed by the (Google acquired) Bumptech guys.
A guy working on Okio/OkHttp was working in Google on the SDK http client, worked on Gson and is working on Moshi. That's the reason I am more inclined for the option 2 nowadays, people use to do better stuff than previously, or at least not worse.
OkHttp by Square is a good alternative.
Volley made by Google is also great in design.