Over the past years, my own library with many helper methods has grown a lot and I kind of lost the vision how to properly sort it.
I tried with simple folder structure like UI/TextView, UI/EditText and so on. My logic was to have the general name for root, then type name for folder, then classes inside. But in time, it so grew that I now cannot find many methods and I discovered that I have multiple duplicated methods.
Can anyone direct me to a good and quality Android helper project where I can see how they sorted their library?
Or is there any public open source project where Android developers contribute with their own helper methods aiming to creating the ultimate helper library? If such thing exist, I would rather fill the gaps with my own methods and use the whole project in my applications, then continue upgrading my own library.
Try this library it's very interesting .
It's the android-bootstrap library , while it's still in the beginning and needs improvements but the necessity of such libraries may make it a very important project , that you contribution to may be very helpful for you and for the community , the design of the library code is easy which makes it easy to understand and you can easily add futures as you want .
Related
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 have a project that I have been working on which is a standard android application that does not include any other external libraries at this time. I am now looking at making a game at the end of the app(its a quiz so after the questions I want to make a mini game).
So what I am trying to find out is can I just import the libraries that it uses and connect them to my project rather than creating a LibGDX project and importing that?
What it comes down to is your personal preference. In answer to your question, yes you could just add in the jar files and such into your current project, however you are going to have to edit your manifest and some add in some other stuff besides jars using this Setup. In my personal opinion it would be easier to create a libgdx project using the tutorial found here, but in the end as I said before it all depends on what exactly you want to do.
Before deciding, ask yourself.
Do I want to have everything in one project, or can it be in more than one?
What would be better in the long run for managing my app.
Do I want ease now or later?
Cheers!
I have multiple Android applications, and I've created a common Android library project, and a common Java library project (The Android library project compiles the java one). These libraries are filled with common components that I use for all my Android apps.
I'm using gradle as my build system.
I'm using git for versioning.
What would be the best way to link everything together? Keep in mind things are still being added / changed in the library, and I need a way to propagate changes to all the Android apps. Copy / Paste wouldn't be a great option. I've tried a few things, and they aren't working out very well, so I'd love some input.
EDIT: It's probably also worth mentioning that multiple people are working on these projects. It's not just me.
The current version of Android Studio has a limitation that all of its modules must be under the project's root directory in the filesystem, and this limitation hampers a lot of people in your situation, because frequently they want those common libraries to live someplace else. It seems like this is the case for you as well.
We're in the process of lifting this limitation in Android Studio, and soon you'll be able to have modules outside the project root. I think this might be the best solution for you -- you can pull your common libraries from wherever makes sense in source control, put them wherever makes sense in your filesystem, and link them up into whatever projects need them. However, this isn't available yet, but will show up in v0.5.0, which will hopefully go out this week. I haven't personally tested it in our dev builds and can't vouch for how well it works, but at any rate it should be coming along soon.
Some developers have worked around the limitations by adding script to their settings.gradle files to set different module root directories. They say it works, but I find it a little scary because the IDE just isn't expecting things to work that way, and I don't know for sure if there are problems with it.
If you read other answers to this question on Stack Overflow, they're written before this feature was implemented and will have different advice. If you don't want to wait for 0.5.0 or there are problems in it that prevent you from using it, you can follow that general advice, which is to have your common code compile to libraries that you publish to a Maven repository (which can be local to your machine or common to the developers in your group), and pick up those libraries with Maven-style dependency statements in the projects that need them. This has the disadvantage that you'll need to open up separate projects to edit the code in those libraries, along with a more complex build process, but it will work.
Is there a handy-dandy equivalent to org.apache.commons.beanutils.PropertyUtils on Android?
I can't seem to use bean utils in my android app due to some dependencies on PropertyDescriptor,and IndexedPropertyDescriptor. So I'm wondering if there are any alternatives?
Basically all I want to do is use a method name as a string "someMethod" and feed that into setMethod(anObject, "someMethod", value), much like PropertyUtils does; but without having to resort to the nasties of reflection...
Or are my hands tied and I need to use Reflection?
There is bridge library which works on Android: android-java-air-bridge.jar. Just include into project path and use all apache beanutils features in your Android project as you could use in ordinary java application. Moreover, there are lot of other classes which moved to this Android supporting library. Look at the list.
There is a possibilty to use libraries or write own code depending on the PropertyUtils. But it sure isn't dandy. You can get the general idea about what has to be done in this thread.
There are apparently some projects who have successfully solved the issue, so you can study thier solution. Take a look at Drawingpad-base and libgdx. You can find PropertyUtils in the package com.madrobot.beans in the first project and com.badlogic.gdx.beans in the second.
We have several apps that will be very similar in layout and code. The only difference is we will be switching out graphical elements, and making changes to a single constants file and strings file. Of course, theres several problems with this -- the first being namespace. Having an app with the same namespace will overwrite any other apps.
What are some suggestions to doing this?
Currently our namesapce is:
com.company.appname
I figured I could do:
com.company.appname.appversion
I've seen post about ant scripts that helps with this, but I'm wondering if theres more fluid solutions now.
I would suggest looking into Android Library Projects to help with this.
I use this approach for a Lite vs. Free edtions of one of my apps. I have a Library project that contains all of the source and most of the resources for the apps and then 2 projects that use the 1st as a library project, one for Lite and one for Full edition.
The two dependent projects each have their own resources and manifest, allowing the namespace to be different and for me to swap in different strings, drawables, etc. depending on the edition.
I tried the Ant approach but it seemed to be much more of a hassle than the Library project approach. Hope that helps.