I have a wearOS application combined with a mobile app in Android Studio. I communicate between those two with listeners who listen on certain paths and behave diffently dependent on the messages they recieve.
I had to define the meaning of the messages in each module and thereby violated the DRY-principle.
Is there a way to store a constant so that both modules can access it in their code and/or manifest?
I would suggest creating a new module for the shared code and add it as a dependency for your mobile and wear modules.
Yes, it's a little bit of overhead for just a few constants. But it helps keep things organized.
Related
Some time ago i created a wear module on existing project.
Both modules have identical Application ID and packages.
Is there any possibility to solve this problem without creating new Android Library to contain classes which i want to be shared? (I have too many files and it will take too much time to fix project)
Afraid not (there is no "possibility... without creating new Android Library"). The handheld and wearable apps are distinct APKs, running on separate devices, and cannot share code at runtime. You need to move your common code into a library that will be compiled into into both.
Is it advantageously to have multiple modules in an Android Studio Project over having only a single large app-module?
I know about Android Modules in general and the advantages of SOLID so my focus is especially considering build performance. As gradle can do incremental builds, and if only one module changes, those other modules don't need to be processed?
Is this noticeable or is there even a considerable amount of overhead?
It is of great advantage to have multiple modules rather than to create a single large app-module. Following are the key points:
If you find the compile time is taking longer then you can disable the module from gradle you are not working upon temporarily and compile it faster.
A module helps us to divide project into discrete units of functionality also. You can create one data module which contains all pure java beans and can be used by multiple app if you are in same domain. Eg. Finance domain can have two applications one for viewing policies for customer and other can be for an insurance agent for viewing the same data. But the data module can be shared across all apps and even the data module can be borrowed from server or API team. Data module can be tested individually without any android dependencies and any one knows about java can write test cases.
Each module can be independently build, tested, and debugged.
Additional modules are often useful when creating code libraries within your own project or when you want to create different sets of code and resources for different device types, such as phones and wearables, but keep all the files scoped within the same project and share some code.
Also Android app module and Library module are different.
You can keep two different versions of module based on the API releases as from ASOP.
You can have a look for more on android developer resource
How modularization can speed up your Android app’s built time
App modularization and module lazy loading at Instagram and beyond
Modularizing Android Applications by Mauin
Survey on how Android developers were modularising their apps
There was an article on Medium yesterday, which exactly adresses my question:
https://medium.com/#nikita.kozlov/how-modularisation-affects-build-time-of-an-android-application-43a984ce9968#.at4n9imbe
tl;dr:
First and most important, the hypothesis was correct, modularising project can significantly speed up build process, but not for all configurations.
Second, if splitting is done in a wrong way, then build time will be drastically increased, because Gradle build both, release and debug version of library modules.
Third, working in test-driven way is much easier for a project with multiple modules, because building a small library module is way faster then the whole project.
Forth, doing many things in parallel slows down the build. So having more powerful hardware is a good idea.
Below you can find results of all experiments described in this article
Update
Addressed at Google I/O '17: https://youtu.be/Hx_rwS1NTiI?t=23m17s
I'm making an app which needs to be able to connect to multiple watch faces (not at the same time). I have multiple modules in my project. I can't add
wearApp project(':wearApp1')
wearApp project(':wearApp2')
in the same gradle dependencies section.
Is there a way to do this?
You can only have a single Wear module per application, because a requirement for auto-installation is that it have the same package name as its "wrapper" handheld APK. But, you can build that module out with as many watch faces (and whatever else) as you'd like.
A watch face is simply a Service, and you're free to include as many <service /> elements in your manifest as you want. Each will appear as a separate entry in Wear's watch face picker. They can share code or resources if that's helpful to your app's architecture, and in fact doing so is easier when they're all in the same module.
Likewise, that same module can include an Activity, or any other Android components you need. It's a full-fledged app, and can be as complex as required.
But you'll definitely need to merge the code into a single wearable module. If you already have these watch faces as separate modules, the easiest route might be to make them into libraries, and just create a single wearable APK that includes them.
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 single android app with a custom logo, some custom json service endpoints, occasional custom text, and possibly a custom color scheme.
For my client this particular app will need to be rebranded and distributed as an entirely different app about 5-10 times over. So I'm looking for way to reuse the most amount of code - the activities and services will be identical except for the custom things I mentioned.
First off, how can I share projects in the sense that one project will hold all code (including activities), and the others just modify a few values. I can't think of a smart way to share both service code and activity code with the occasional value thrown in via properties.
Do android layout/string resource files have the ability to pull from properties? Can activities be bundled inside a jar and shared with other projects?
You can use Android library project to share the common code. Start by reading this article
You do not have to have different java namespaces, they can be common for all projects. All you need is to replace resources and modify manifest to contain different namespace for each application. There is no problem with several applications having the same name of classes inside. Unless you want to rebrand it all the way user could not find it is actually the same code, of course.