Ultimately I wish to produce a compressive Contact Manager with some specific features.
I thought it would be good to experiment by extending Contact.
So using git I checked out froyo-release and tried to build it.
That didn't work so well as it contains things like
import
com.android.internal.telephony.CallerInfo;
and friends.
I'm considering the following two approaches:
Suppress the internal stuff under
the assumption that I really don't
need it.
Start with a toy Contact Manager
and implement (reinvent) everything.
My guess is that I am going about this incorrectly.
"I want that third alternative" --kirk.
Just for completeness, the new special behavior is to provide
an action list for a contact based on the types of that entities data.
A lot of the applications that ship with the platform unfortunately make use of non-public api's, which means they require a lot of hacking to build as sdk apps.
You can build them as part of a full platform build, or you can modify them to connect to the private api's via reflection or by including stubs for the private api functions that will get automatically stripped out later (as their names conflict with the real ones) - but if you want the result of your work to be something you can portably and reliably distribute other than as part of a rom upgrade, you probably need to rework things to use only public APIs.
Related
I would like to determine which third-party SDKs (like Mixpanel, Google Analytics, Facebook SDKs) are being used in an app, if any. Is there a way to find this out?
Assume for the purposes of this question that I am not the developer of the app, and therefore I don't have access to the source code.
You can use a service like Appbrain to find that out. It's free for the first few lookups.
It's not possible to reliably enumerate the libraries used by an application, for a few reasons.
The main reason is obfuscation: If a user turns on Proguard or R8, they will rename the library's classes, potentially in such a way as to make them unrecognizable.
Another reason is that there's simply not a comprehensive list of every Android library in existence, or a mapping of class names to libraries.
However, if you did want to try to do this, you'd want to retrieve the application's class files and then hunt through them for the start of package names from libraries you care about (as obfuscators are less likely to rename the entirety package names, though they still might). For example, if you wanted to see if an application uses okhttp3, you'd look to see if there are is an okhttp/okhttp3 folder (for the package okhttp.okhttp3).
You could maybe even automate this by finding a list of popular Maven/Gradle packages, downloading them, extracting the class names, and using that as your dataset.
I would like to determine which third-party SDKs (like Mixpanel, Google Analytics, Facebook SDKs) are being used in an app, if any. Is there a way to find this out?
Assume for the purposes of this question that I am not the developer of the app, and therefore I don't have access to the source code.
You can use a service like Appbrain to find that out. It's free for the first few lookups.
It's not possible to reliably enumerate the libraries used by an application, for a few reasons.
The main reason is obfuscation: If a user turns on Proguard or R8, they will rename the library's classes, potentially in such a way as to make them unrecognizable.
Another reason is that there's simply not a comprehensive list of every Android library in existence, or a mapping of class names to libraries.
However, if you did want to try to do this, you'd want to retrieve the application's class files and then hunt through them for the start of package names from libraries you care about (as obfuscators are less likely to rename the entirety package names, though they still might). For example, if you wanted to see if an application uses okhttp3, you'd look to see if there are is an okhttp/okhttp3 folder (for the package okhttp.okhttp3).
You could maybe even automate this by finding a list of popular Maven/Gradle packages, downloading them, extracting the class names, and using that as your dataset.
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 am working on a set of novelty applications that share their fundamental behavior (picking random words from a database and combining them). Because they all work BASICALLY the same, I tried to treat the base of the code as a template of some sort, with mixed results.
As I am working on an update, I wanted to make the project a little more MVC friendly and started looking into using a ContentProvider instead of a straight SQLiteOpenHelper. I am leaning this way because Google's documentation is INCREDIBLY adamant about using them. My issue is in the realm of naming collision.
TL;DR Skip here for the question.
If two 3rd party Android applications (made by the same developer) both want to use the same ContentProvider, but not rely on another application being installed, can they both include a copy of the ContentProvider (with the same authority and everything) and be allowed to be installed at the same time (using the highest version of the ContentProvider available)?
I am not sure if this is possible with the way content providers are set up, which seems monolithic. I can't imagine Google didn't see this as a potential problem or desired feature. Yes, some complexities could arise, but we have overcome dll hell and other similarly named problems... it can't be all that difficult to do right.
I am leaning this way because Google's documentation is INCREDIBLY adamant about using them.
Not all Googlers agree with that position, let alone other schmucks like me. I only use a ContentProvider for sharing data between processes.
If two 3rd party Android applications (made by the same developer) both want to use the same ContentProvider, but not rely on another application being installed, can they both include a copy of the ContentProvider (with the same authority and everything) and be allowed to be installed at the same time (using the highest version of the ContentProvider available)?
AFAIK, the first ContentProvider registered would win, not the highest version. In fact, I'm not sure the second app will install if it attempts to redefine an existing ContentProvider.
Moreover, if the user uninstalls the current ContentProvider, the other app is screwed, since its data now goes "poof".
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).