I have very general question about managing android library project and I feel it might have pretty simple solution. The library might be used as a base program for other projects, like framework but It could be better described as a group of functionalities that are the same - just to save time.
Lets say we have project where we decide to distinguish base part which is exported as library.
Those library contains activities, network utilities, some preferences and database schema(!).
Is there any pattern how to do this, is it a good idea to do this with database too?
I mean actually I've got the library but almost every method that is dependent from other one has to be overridden what causes to override almost everything.
Maybe the system should be designed with specific cohesion strategy?
Thanks
Related
I have a project in Android Studio and two different app module but both of them are using this same Android library (core code). I want change some resources and logic in application but this code is in core (Android library). How do I approach this? How to customize core code?
I've been asking the same question and after some research, I've found that you have different approach:
Gradle Flavors:
Why Product Flavors?
They address the issue of having separate project code for each version of the app while still having one project code.
Given a scenario where you have a free and a paid app you can limit features in the free and expose all the other features in the paid version of the app.
Given another scenario where you want to implement region-specific functions depending on the country, you can use product flavors for such a use case.
White labeling (these are apps that are developed by a certain company, and they are re-branded and resold by other companies).
Pros
They address the issue of having a separate project code base for each version of the app.
They keep the code tidy and makes it much easier and faster to navigate through the code base as everything related to the specific product flavor would be kept in their corresponding folders.
Cons
(Scaling Up) The more variants, the greater the complexity which thereby makes it harder to maintain the codebase.
-IDEs sometimes takes time to build the project after switching between variants.
Source: https://levelup.gitconnected.com/simple-guide-to-android-product-flavors-674106455038
Multi-Module
Why ?
Faster build times.
Fine-grained dependency control.
Improve reusability across other apps.
Improves the ownership & the quality of the codebase.
Stricter boundaries when compared to packages.
Pros
Scales well as the application grows with new features
Medium to large development teams are able to work on different modules without affecting each other (Merge Conflicts)
Encapsulates unit and ui tests to their specific features
Keeps Resources separated between modules. Which improves readability and organization
Keeps logic contained in their own modules, which can be hidden behind interfaces
Forces the developer to keep their code better organized and structured
Improved build speed, as changes in a module means only that module will need to be rebuilt
Cons
Adds additional boilerplate around the construction of the modules
More development time overall
Requires a maven/gradle file for each module
Navigation between module activities can be difficult to setup correctly
Requires a lot more pre-planning on how best to structure code, and determining where shared code bases are stored.
Limited amount of online resources showing best practices
Source:
https://medium.com/swlh/modularization-by-feature-and-layer-with-android-architecture-components-80bf317d737
https://codelift.dev/android-modular-app-architecture/
Also look at the gradle doc to start with modularizing.
You can build the library's aar and use it in your main projects by simply copying into lib folder in your project directory.
Or you can build it with services like Jitpack and add it to your project by the implementation method in Gradle.
I'm developing some Kotlin libraries and I have the following conceptual issues:
The first library is based on spring's classpath scanner and is intended for use as a spring extension, so it pulls spring-core as a dependency. Is this ok? How would the potential user of my library handle different spring versions?
The second library is based on first and it is intended for use in p2p networks. It synchronizes with other peers and provides a shared state that can be easily retrieved by library user using special pre-defined spring service. Is this ok for a library to have side effect like this? Maybe there are some patterns for implementing/distributing such libraries?
If this is not ok, can you please guide me how to do this right.
Thanks in advance.
This is a bit general question, and having concrete examples would help understand if that's "okay" or "not okay" to do it.
But generally speaking:
It's fine if your library depends on other libraries of specific versions. Most of the libraries do. The question is how heavy and obtrusive this library you depend on is. And unfortunately for you, Spring libraries are known to be both. In case of the end-user of your library, in case of conflicts he'll simply have to choose whether he wants to update his Spring version for your library or not
Having some distributed state is not necessarily a side effect. EhCache is a distributed cache library, for example. The basic pattern is to be as SOLID as possible. When I developed caching for Vert.x WebClient library, I made it rely on interfaces instead of solid implementation, so if someone decides he doesn't want to use your library (Spring component, for example), he could provide an alternative solution.
Again, those are basic guidelines, without seeing your code. If you intend to open source it, feel free to share specific bits to get more concrete insights from StackOverflow community.
I am creating a project for my studies which is based upon a trading system.
This trading system is using some moving averages to decide when to buy or sell a stock.
The language that I will use is java.
My question is whether I should use a 3rd party library (like JFreeChart) or should I try to build the whole application on my own (I have some java swing experience)?
Thank you.
If there is something which already does what you need, you should really use that in the first place.
Creating your own, is usually not advisable since using 3rd party applications will mean that you will be using something which is already tested and has lots of more features.
Using a 3rd party API will save you time, time which you can than invest into other aspects of your project (communities always tend to make life simpler).
A few more points I thought I should mention is that although developing everything yourself is usually a great (if not the best) way of learning things, I think that employers tend to prefer it when people are already familiar with certain 3rd party popular API's.
If the licenses are compatible (for instance JFreeChart is LGPL, so you can use it without opening your source code), and the library does what you need, why would you reinvent the wheel?
Using a library that is already tested and developed by many people can save you a lot of time, and if you need something different or a bug fixed, you can always fix it yourself and commit it so the rest of the community can also benefit.
If I were you I would befriend JFreeChart. It is a de facto standard for Swing plotting/charting (at least in the free world). It has some quirks and needs some hacking to get your result from time to time. But it is well tested, the limitations are well known, there is a community of users with experience that can help you with the problems.
I would rather not reinvent the wheel, unless I needed a very specific wheel...
It depends how much time you have and what you want to achieve, if you create your own charting it would be great experience, but if you are looking towards building your career in finance domain then you would be better off looking at the pricing models.
Also there are many matured solutions to get your charting requirement done, you can just use them so as to save time and definitely you can learn a lot by looking at some great Open Source code.
I'm wondering if there is some recommended reading, best practice or opinion on how to organize larger Java projects.
I made the observations that there are folks who split up everything into projects (i.e. modules) and create many many projects that share a web of dependencies. This has the advantage that compilation is often super fast, but when the project gets large nobody knows anymore what depends on what and why. Not talking about dependent libraries, version conflicts & co.
The alternative is to have just a couple of projects such as frontend, backend, ... . The namespacing does the job.
Any opinion, further reading anyone could recommend?
As soon as you start splitting a big project up into smaller projects, you encounter a lot of dependency tracking that you generally didn't have to consider. You could manage this yourself or you could use software which already handles a lot of the core issues.
I would recommend Apache's Ivy. It integrates well with Apache's Ant, and has a separate configuration file (which gets checked in) to track what is required for each kind of build.
Apache's Maven is another good choice; however, it does a lot more than Apache's Ivy. Sometimes that "a lot more" means you doing less of what you would have done anyway, sometimes that "a lot more" means you are doing (and configuring) things that you didn't do before. Depending on the fit of your practice to Maven's, migrating to Maven might be easy or very hard.
In addition, using Ivy, you can set up your own private repository of "permitted" jar files to pull from, and that will make code auditing much easier. Basically, reconfigure ivy to not pull from the web, but to pull from your local repository only, and then control access to the repository to only allow jar files which were reviewed to have acceptable licensing.
Once you have software in place, you can afford to split projects up into smaller pieces. This will permit you to do the right thing (if your project favors small decomposition) instead of the expedient thing (a few big chunks which might not really buy you much in decomposition maintainability). As far as where to make the cuts, that depends heavily on the specifics of your application.
Many small pieces tend to be easier for a new person to digest one-by-one. They also get people thinking about where functionality is to be added to a project; however, it does cost time and effort to untangle and separate all of the components. The plus side is that it is generally easier to test and validate something smaller, the downside is that it is a longer road to decompose one monolithic collection of responsibilities into many small, well integrated yet functionally disparate units.
Good luck
A very large project will need to have some way of tracking all of the libraries and other dependencies that it uses. The defacto standard for doing this is Maven. It's definitely the best way to start keeping track of what is going into your application.
Then you can decide how to split your application up. Basically, what you're trying to do here is to split up your application up into complete functional pieces. For instance, if you had a website that had a contact form, a photo gallery, a shopping cart, and a forum, you would split the project up into pieces that contained each of those different modules.
Actually, you will want to utilize both projects and namespacing.
Namespacing is an important tool for differentiating what purpose a code has at the code level. Regardless of what project a class comes from, the package should give me some idea of its purpose.
At a higher level, it is easier to manage builds and your development environment by having your code separated into projects. For instance, if you are developing a UI, why do you need to have the database code loaded into you IDE? It is just extra clutter in your workspace. It also makes it simpler to share common functionality between different projects. This will of course lead to needing some form of dependency management, of which either of the mentioned tools such as Maven or Ivy will suffice.
An important note though. Do not use split packages between projects. This causes nightmares if you or anyone who will ever use your code wants to do so in an OSGi environment. So, your namespaces should be unique within a project, although they should share a common root with other related projects.
I'm willing to develop a soccer game for Android.
Because the complexity of the AI, i really think i need to design it using a FSM (Finite State Machine) and not with a monster switch.
Googling around i found some FSM written in Java, but nothing explicitly compatible with Android: I wonder if there is someone here that used a FSM before for that platform.
I was looking for a FSM for Android a few months ago but couldn't find anything suitable, so had to create my own.
I used it in a few projects by now and quite happy. It makes code much cleaner and is easy to use. If anyone's still looking for a state machine for java, check EasyFlow out.
You can contribute to the project as well.
Android has an internal Hierarchical State Machine (HSM), which integrates with the Android message Queue.
It is internal, so you're not able to access it explicitly from the SDK.
However, if you follow the terms of the Apache 2.0 licence you can make your own version.
https://android.googlesource.com/platform/frameworks/base/+/gingerbread-release/core/java/com/android/internal/util/HierarchicalStateMachine.java
Edit:
This class is now called StateMachine.
This state machine (FSM) implementation used in Android and provided by Google seems to be a good option. You can get it here on Github.
You can use the StateMachine class to define states, the initial sate, you can perform tasks when you enter or exit a state, you can send events and delayed events in order to implement timeouts for instance.
I did not find many other alternatives, but this implementation contains all the features I was looking for. This is part of the Android project, so I presume this was good tested. Hope this help.
You can try out my Kotlin library with DSL for creating state machines.
It helps me in Android projects.
https://github.com/nsk90/kstatemachine
Another open source option is Engine by #doridori