I work on a lot of closed source projects but often find myself extending the same classes, implementing the same libraries, doing the same things for caching and solving memory issues, and seeing other companies I work with facing the same issues
It makes me wonder if there are engines for android out there created for certain purposes. My cursory google search on this issue was unproductive
but I think this question is constructive because there is a real answer to this instead of discussion. Alternatively, what StackExchange site would this be a better question on?
Google Play Services and Volley are great examples and responses by google to certain problems such as but not limited to GPS/Positioning logic, network calls, bitmap caching, but I was wondering if there was anything more that is also maintained.
It sounds like you have a few different problems that each have their own solutions.
extending the same classes, [...] doing the same things for caching and solving memory issues
Making your own library that contains these custom subclasses and caching implementations would probably suit your needs pretty well.
You may also want to learn how to create your own templates for Android Studio. Templates (such as the "new Master/Detail flow" default template) can be used to automatically generate classes and XML files to avoid spending time writing boilerplate code. Here's a GitHub repo with a number of examples.
implementing the same libraries
This sounds like your core complaint is that you want a way to automatically generate a base project of sort for your projects that might automatically include certain libraries, set up a package structure, etc. This can be accomplished using Maven archetypes.
If you want an example of how to create a Maven archetype, I would check out Velcro.
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.
There is a core ERP mobile application for Android. A customer has requested additional features that will require more screens (and Activities) and extra functionality.
Is there a way I can add sort of an extension to the core mobile application in order to intergrate the extra features or should I code on top of the code of the core application?
I am interested in finding a neat solution focused on extendability since different clients might ask for different additional features. How would you deal with such an issue? Any tips on the structure of such a project would also be welcome.
Would it make a difference if the extra features need to use the same db as the core application?
Thank you in advance for your help.
The answer to your question lies in the Open/Closed principle introduced by Bertrand Meyer. Open/Closed Principle is a very simple Object Oriented Design principle which states that
Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification"
From your question its clear that you have identified the core functionalities in your application. So rather than Modifying this core functionalities and making it more specific, I would recommend, on the basis of the Open/Closed principle, that you should freeze your code features and write your customer specific functionalities over it without corrupting the core.
Now to answer your question on what kind of structure you may follow. I would recommend that you create a library project of your core functionalities and make different client specific projects that would include your core functionalities as a library project.
It won't make a difference if your application is using the same db as your core application provided all your applications uses it, else it should not be in your core application in the first place.
Hope this explanation help you.
Update:
My friend pointed out that I may not have understood the question right. So rather than correcting my old post(...which may be useful for others) I am updating it.
So if I understand it right, you have an ERP project which you may not have coded. The right approach, according to me,still would be that you build over this existing code. Rather than making changes on this project, include it as a library because if the project is downloaded from a reliable source, you will have the benefit of getting the updated version as and when it is available.
This is kind of a design philosophy question. Here are a couple choices that might give you ideas:
You could look into making your core application code/features into a custom library. Then your new core application is just a simple wrapper that includes the custom library. Your additional features for a specific customer could then be a different app that also references the core library but will include additional features. There are lots of tutorials on how to turn your app into a custom library. You would end up with different apps that target different a customers. (A tip that took a while for me to uncover is that if you have a resource name in your custom library you can "override" it by using the same name in the app that includes the library. Another tip is that you need to essentially duplicate the manifest of the library in the app by listing all the activities in the library that would be used by the app.) I haven't tried this but it might be that your additional features are each libraries that are included in different apps.
You could have an key the user inputs that will unlock certain features. You could save this as a shared preference so that they don't need to keep entering the key. This approach has the benefit that you can "reuse" features for other clients without any more implementation other than determining which client gets what feature. The majority of users just wouldn't have a key to unlock anything.
Both these solutions should use the same db since they would be calling the same core classes, etc.
Another possible solution is to create a Library Project. Put your core ERP app code inside the library Project, and then create different project for different customers. Each one of these projects will also use the same library project.
Your core library project could expose an api to dynamically register new features (Such as a menu that can expose new menu items).
I know there are a lot of questions out there about multiple Android versions pertaining to free/paid versions but this might be a little different.
My app currently uses AdMob for advertising and it's published on the Android Market and on the Samsung App Store. Unfortunately, the Samsung store will require everyone to migrate to their own Ad Network in the future, Samsung AdHub. Both AdMob and AdHub have their own libraries, their own SDKs.
I'm looking for a solution to build 2 different versions, one including AdMob the another including AdHub (and all the necessary code). What solutions do I have to easily build 2 versions without much hassle when it's time for a new version release?
Lots of solutions recommend to move the main project into a library project and then build 2 other apps which include the library project (the base project). But I'm not very fond of that solution (I prefer to keep my app in one single project, if possible) and I'm trying to look for alternatives and then make up my mind about which one is better for my needs.
I'd think you should make this possible in your code using the Strategy design pattern. It suites well and can be switched at any trigger your like (even on runtime). If you make a facade for each jar file you will be able to change the dependencies while building, having the same source code.
Other option with this method is just making some configuration in your application that determines which library to use.
Some interesting solutions can be found here:
https://groups.google.com/d/topic/android-developers/8pRugcnzR_E/discussion
The way to go now is to use Android Studio and use different Gradle flavors for each app. Thus, if you fix core functionality, you can quickly do a build for each appstore with it's own ad network.
Library Projects is the way to go. Create a base project where you implement all the common stuff and then create two separate project that use the common one as a "Library". then just implement the rest needed to make the Apps behave differently.
Is "AndroidAnnotations" reliable? I've searched it but couldn't find many articles on it(reviews or tutorials).
I've been considering using this library in my project which already has quite lots of users. Before adopting it, I need a good reputation on it. So my concerns mainly are,
Are there famous products using this library?
Can I say it's stable enough to adopt it for my big project?
Will it be maintained well? (bug fixes, etc)
Thanks in advance.
I am the lead developer of AndroidAnnotations. Let's answer your questions:
Can you rely on AndroidAnnotations?
I think so. AndroidAnnotations is a compile time framework which generates code. The generated code is readable java code, which means that if you need to understand what happens, you can. No magic happening at runtime => you are in control.
We try to maintain a list of external articles / tutorials here.
Are there famous products using this library?
Let's be honest: I don't know. Matthias Kaeppler from Qype talked about AndroidAnnotations at DroidCon London 2011. The frontpage lists the applications that we know for sure are using it. I know there are way more people using it because they ask for enhancements and report bugs, but they usually don't let us know when they publish an app. And of course, the idea of "writing clean and maintainable Android code" is not yet very common in the Android community.
Can I say it's stable enough to adopt it for my big project?
We are using it in our own apps, and we find it perfectly stable. So I would answer yes, but I think you should just try it :-) . Download the 2.2 RC2 (will be released stable soon), follow the instructions and see for yourself. You can do progressive enhancement, and start enhancing only one or two activities. See how it fits you, and let us know if anything goes wrong. And if you do release an app with AndroidAnnotations on the Android market, please let us know, we'll update the front page.
Will AndroidAnnotations be maintained?
Yes, it will. Although it started as a personal project, AndroidAnnotations is now sponsored by a company, eBusiness Information. This company employs people (including me) to work on AndroidAnnotations, with the aim of making it a major Open Source Android framework.
As you can see here and there, we are adding a lot of new features for the 2.2 release. And you won't find a lot of open Defects in the issues, because we concentrate on fixing any bug before adding new features.
I would like to add two versions of my app to the Android Market, one for a few cents, and one free version, with ads. That's a very common practice.
I'm currently building AdMod into my app, and it seems I'll have to change quite a few files, so it seems best to make a separate version of my app for this.
How do you achieve that? A branch? A different repository? Has anyone found a way to keep both apps in the same repository in a reasonable manner?
The title is not misspelled, I do mean "realise", i.e. how people manage the two versions, not how they add them to the Market.
This kind of thing is a complete nightmare - unfortunately the Android build system doesn't really support it in any good way.
We do it by having 99% of the code of our application in a library project. We then create one application project for each different version of the app, each of which use that library.
Where we need different versions of the app to behave differently, we currently achieve that by having different resources that are queried at runtime. We are in the process of moving to using Dependency Injection via RoboGuice, however.
There are elements of this that work reasonably well, and others that don't. It's necessary, for example, to duplicate the AndroidManifest.xml file, which can be error-prone (it's easy, for example, to add a new activity to one manifest and forget to do so in the others). It's a mess, unfortunately, but the least-bad solution we've found.
Personally speaking, I would strongly advise against using branches to achieve this effect. They can work well initially, but will rapidly become a maintenance nightmare.
One side benefit of using a library is that we've found that it makes testing considerably easier. For an example of how to set this up, see:
http://www.paulbutcher.com/2010/09/android-library-project-with-tests-step-by-step/
People usually upload them twice(like two different programs) and just modify the title for adding something like Ad-Free, Donate and things like that. And on the free version just add the Free label and also put on the description that it's Ad-Supported.
Here is an example with the SMS Popup application:
For the Android Market, they are considered different programs, but for us it's the same, but one is Ad-Supported and the other isn't.