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.
Related
I am working on some application that has different type of users namely a mechanic and a customer.
Now I have two solutions
1 To make separate applications for both
Pro:
Modular application,manageable and lesser size .
Con:
Code redundancy like login pages for both apps.
2 To make a single application for both.
Pro:
One application caters so overhead saved.
Con:
Lot of thinking and flexible arch. In place is needed.
I am kinda confused ,if someone can guide me with this.It'll be great.
Some sort of examples and links would be superb.
Diagrams would also do.
I guess the most reasonable option would be to have:
A Library Project with the common parts (anything you want to reuse, basically), and
Two Application Projects for the distinct applications.
That way you can reuse the common parts (no duplication) and still keep the specific parts separate.
See Managing Projects in the Android documentation, this precise scenario is listed as one of the main use cases for library projects:
If you are developing multiple related applications that use some of
the same components, you move the redundant components out of their
respective application projects and create a single, reuseable set of
the same components in a library project.
My scenario
I have to implement a "modular" android app. There is a core module from which I should be able to invoke other modules. Each module provides a different feature to the user. Imagine I am making a city guide, then one module may contain a map with POIs, another one an event calendar and a third one pre-defined city guides. The modules contain views to be loaded in activities of the core module (like dashboards where each module puts its item/picture). They also contain activities which should be invoked (like when a user taps an item on the dashboard). As far as I know, I will need a database and/or preferences only in the core module. The "plug-in modules" use classes (utilities) of the core module, e.g. when connecting to the backend.
My solution on iOS
For iOS, I achieved this with targets in XCode. I have one project and depending on the customer's needs I compile only the relevant modules. It would be even better if the user can install modules whenever he wants, without the need of reinstalling the "core" application.
My problems on Android
In SO, I already found various solutions like library project, switching from Eclipse to Android Studio + something, using package manager and broadcast receiver... But I still don't understand... How is the modularity of an android application to be achieved?
Here are some concrete problems that I see:
Libraries: My modules all use classes of the core module, so they are not independent. I achieve the modularity by using interfaces/inheritance depending on the flexibility that I need.
Broadcast receiver: This seems to be everything else than recommended. See, for example, here or here.
What I need is, at least, to be able to use the same code for delivering app with features A and B to one customer and with B and C to another one. And, until now, I have no idea how to achieve it.
PS: I don't want to use scripting, I am not familiar with that.
I don't see this "modular" app as anything different from one app, with several packages, each containing discrete functionality, that is adapted to some list of settings or external parameter (either provided by the user or you).
My approach would be to have a "main" package. That package would contain the shared functionality you mention above and serve as the hub for your application. I would then create separate sub-packages for the different "add on" functionality. This allows you to still use the code in your main package with a simple import statement. From your description these additional functions should probably be implemented as a Fragment. A Fragment is almost a stand alone application with the exception that it is "hosted" by an Activity. Depending on how these add on functions are used (I cannot tell if they relate to the UI, just background processing etc) you could easily have 3 of 4 different fragments and choose to load only 1 or 3 or 2 of them at runtime.
To control which parts of the code are used I would just set up a simple switching class (it could even be part of the first activity launched, I cant tell from your description above). Here I would check for some setting indicating which parts of the app will be "active." This could be easily defined using SharedPreferences to store a specific configuration, e.g. use A and B, prior to delivering the final project. You would then just initialize the fragments you need and display them either (1) individually in a Fragment layout element or FrameLayout; (2) collectively in some other view structure like a ViewPager.
I follows your links on the BroadcastReceiver and I am still not sure why they are "everything else than recommended." Used correctly a BroadcastReceiver is very useful. I tend to use a LocalBroadcastManager along with a BroadcastReceiver to notify other sections of the app when some AsyncTask, e.g. downloading a lot of data, is complete. These parts of the app can then access a local database or process the information downloaded on their own time. I wouldn't use a BroadcastReceiver to modulate parts of the app if that is what you're looking for. I would instead just use a SharedPreference file to set the configuration at runtime.
If you need modules like facebook sdk or something like that better use library project. If you use Idea or Android Studio there is such thing like Module. If I need some modeles in one app I prefer just put in different packages like com.appname.model, com.appname.ui and so on. Broadcast Receiver isn't about modules. As I know there isn't analog of ios target.
Currently I am working on an application aimed to small local businesses, which serves as a template for other applications (other stores). The base application allows local stores to send notifications to their customers, depending on the business context, notifications can be to report promotions, inform a client that he can pick up his order at the store, notices of new products in the store, etc ... What I do is work on the template for each client and then customize the appearance of the application in the background but the functionality is the same for everyone. My problem is that every time we have more businesses interested in the application and the problem arises when I find bugs or want further improvements, and to update the code in each of the applications can be hell (open each project, add the lines code, recompile, etc ...), and also publish new applications involves a great job because I have to change namespaces whole project, change the authority of the content provider, update references to the namespace associated with the template, etc. ...
Is there any way that I provide update and / or add portions of code in the original template and the changes are automatically reflected in all projects generated from the template?
I have understood Apache Ant can help with the compiling process of large project with many dependencies, but could be useful in the context of my problem?
The solution that I can think of right now is to create a project library and then put everything common to projects, including resources and Activities. The problem is that for example the application Content Provider could not go there because I need to have a single authority in the Manifiest defined for each application.
In advance thank you very much for taking the time to read my message. Any help or advice is welcome. Thank you again.
My question is there any way that I provide update and / or add portions of code in the original template and the changes are automatically reflected in all projects generated from the template?
Make the core code be an Android library project, and use that library project in all the customer apps.
The solution that I can think of right now is to create a project library and then put everything common to projects, including resources and Activities.
Correct.
The problem is that for example the application Content Provider could not go there because I need to have a single authority in the Manifiest defined for each application.
Your ContentProvider implementation can go in the library project. Your customer-specific project will need the <provider> element in the manifest, with a unique authority, pointing to the ContentProvider class from the library.
The project I'm working on requires that N stand-alone applications can be built but also an extra big application with a selection menu that will execute one of those.
The difference between these applications is mainly resources and XML, so they all use a common library which reacts to assets and the information provided in the XML.
The problem is regarding the "mother" application. It has to be able to use the common library using one of the stand-alone resources set. I realized I can access another application resources using:
Resources R2 = getPackageManager().getResourcesForApplication("com.example.appa");
int id = R2.getIdentifier("image", "drawable", "com.example.appa");
Drawable myDrawable = R2.getDrawable(id);
And this actually solves the issue, I can supply a package string to the library so it will know where to look for the resources.
Problem is, in order for this to work, I need to have those stand-alone applications installed on the device, and that's something I cannot do (think of it as a quiz application, the stand-alone apps are only one topic while the "mother" app allows access to all different topics and, as far as I'm aware, Android Market won't allow downloading all apps and installing them just so I can access their resources).
Conceptually speaking, this issue would be solved if I could make those stand-alone applications as libraries and adding them to the mother app. The mother app would then use a package string depending on user choice and then use the library. So far I haven't been able to work this out and I can't find information about this so I'm afraid this can't be done.
Each topic application has, for example, an intro.png with an image regarding the topic of the app (for example a roman or a greek image) and the idea is to access package_string.intro.png so it will automatically access the right one depending on user choice.
After struggling to do this I finally found out resources are indexed which means only one "intro.png" exists in one application, no matter how many libraries you try to link, you can't create a reference to lib1.intro.png or lib2.intro.png. I finally built a resource manager system which works with "lib1_intro" or "lib2_intro" on demand. Not the cleanest of solutions but, meh, it works I guess...
Moving my edit to an answer as I read about accepting answers and this is how it should have been done instead of just editing my first post
If I needed to build an android SDK that other developers can integrate into their android apps, is jarring my SDK the only way to go about it? As far as I have learnt, jarring has the following considerations:
If your app uses a layout, then you have to create it programmatically. Since jar files cant carry any resources.
The jar will needs to be placed in the lib/assets folder and added to the build path (in Eclipse) -- Learnt here: Android - Invoke activity from within jar
The main app will have to create an Intent object and specify the package and class name in the jar to start the activity.
Any one have other ideas of going about any of the above steps?
Thanks
George
Creating a JAR is, in my opinion, a very bad decision. Android has specific features just for the kind of thing you're looking for. If your JAR:
provides some sort of (structured) data to be used in other applications, use a ContentProvider;
does some backround processing and makes that processing's results available to other applications, use a Service;
provides an Activity that gets some input from the user (or shows some information about something), eventually processes it and returns it to the calling Activity, just create that Activity and any application will be able to start your Activity as long as it's installed on the phone.
If you use one of the three solutions above, third party apps will be able to probe for whether your application is installed and, if not, prompt the user to install it. Only if your application does not fall into one of the three bullet points mentioned above should you use a JAR. Otherwise, using a ContentProvider, Service or Activity provides:
More standardized interaction between components
Better maintainability -- if you update your SDK you won't have to call everyone who uses it and tell them to upgrade.
No duplication -- if you were to provide a JAR and multiple applications that use it would be installed on a device, multiple copies of the JAR would be present on that device, thus using more memory than it has to. If you provide one of the three components mentioned above, one copy will satisfy all applications that need to use it.
Again, these components are specifically designed and provided by the Android OS for creating such SDKs. Please, only use a JAR if you really, really have to. Otherwise, provide a standardized ContentProvider, Service or Activity and document the way it's supposed to be used (i.e. how to use/query/integrate it).