GOAL
Hi, I plan to include in all my aps a "credits" button that will display my logo, URL, etc.
PREFERRED SOLUTION
In order to be more effective I would like to have it as an independent app, so that if I later modify it, all the apps calling it would get updated to the same credits display, instead of modifying each of them.
ALTERNATIVES
*(a)* Of course the easy solution is to copy it within each of my apps and update manually each of them. I think this is not so effective when the number grows.
(b) Having a kind of external resource like a mobile adapted webpage which would always be called. I would only need to change it. But I open then the workfield out of android.
My first idea is to have to define it as an independent activity and get it called from each of the apps.
I have two related questions:
1. How do I ensure this "credits" activity gets installed with an application (is there a kind of dependency which can be defined?)
2. Is this a reasonable way of doing it within Android context?
Thanks.
PREFERRED SOLUTION In order to be more effective I would like to have it as an independent app, so that if I later modify it, all the apps calling it would get updated to the same credits display, instead of modifying each of them.
No user will download this, so do not bother writing it.
How do I ensure this "credits" activity gets installed with an application (is there a kind of dependency which can be defined?)
There is no way to accomplish this.
Is this a reasonable way of doing it within Android context?
No. As #bigstones suggests, use an Android library project.
Related
I am planning to create a mobile app (android). It has several pages/frames for different cases. Now the number of frames/pages that I would like the app to have would grow over time, so new frames/pages would keep on adding.
Now, I have two options the way I see it. One being keep on adding new version of the app with new pages/frames once every few months. Other being I decide upfront all the possible templates for those frames. Once the templates are fixed, the response (from REST API containing data to display) would also contain the information of which template to use. I could embed the logic on how to interpret the template type available in response in the app code, so the app knows how to display a template of type "table" and what constitutes the table headers, etc.
The caveat for former approach (upgrade) is that once in while, app needs to be upgraded, something which not all users would like to do. A way around it is to enforce an upgrade, which renders app unusable. The problem with the latter approach (template) is that a lot more code needs to be written to make it work right.
I would like to know what approach is mostly used, and whether there are popular apps out there which use the latter (template) approach.
I definitely recommend using the first approach (that is, you submit updates when you actually provide new versions of the app...).
Here are a few reasons which seem to be enough to choose the regular option:
If you use the templates, you are "forcing" updates to the user. One day he has a UI, and the next he has another one (new element in the menu, or new display of a known activity/fragment). And that's worse, because he didn't receive a notification that there was a new version of the app. So he might actually get confused.
You are relying on a web connection to perform this check. So you don't even get the guarantee that this will work (depending on the permissions and business of your app, this argument may be invalid for your particular case. I wanted to answer to the general question though).
You will add a ton of complexity to your application's code (meaning no offense, I doubt you can think up-front about ALL the designs/renderings you will need in the coming months/years). And a higher complexity = more bugs, statistically.
Do you realize that the second approach you are talking about is more or less the principle of a website? Maybe what you are looking for is a simple app which has a webview to your mobile website?
I just got done writing an Android Activity that allows other Activities to call it for some result (it's not intended to be a stand-alone Activity). I'm now working on the equivalent iOS application and can't find any resources for how I would enable similar functionality on iOS.
The situation: The tool I'm producing is intended to be used by other applications, rather than as a standalone application. The thing is, the GUI that needs to be presented to the user is rather involved so I'd like to be able to provide the developer with a "all-in-one" package that they can simply launch and get results from. Doing this in Android was very straight forward. I simply wrote an Activity and instructed the developer to launch this Activity for result. I've looked around and can't find a similar functionality to allow an iOS developer to do the same. What would be the best way to go about doing this?
I think part of the problem I'm having in finding resources is that I'm not entirely sure what what I'm making is called. A library? extension? plug-in? I would think a library doesn't have a GUI and it seems extensions and plug-ins are made for an extensible application (that is, one in which the user can install the extension/plug-in).
Your API could be à single call that would pop up a modal view. A target and selector can be specified to receive an answer. Supplying it to other developers means packing it into a "framework". I'm not sure if you can include resources.
There isn't really any equivalent. The closest you can come is having the second application call UIApplication's openURL with a custom scheme that is listened to by your app, and then when your app is done it would do the same with a custom scheme that is listened to by the calling app.
In practice, the iOS app would usually include the entire activity-equivalent as some sort of library, which at the high level would take the form of a UIViewController subclass that is presented modally and then calls a delegate method or completion selector of some sort on completion.
iPhone development is a different design than Android development, so you may need to rethink what it is you are trying to do.
Most likely you will want to look at just including the code in each program, initially, just so you can get it testable, but that may not be the best solution.
But, without knowing more details about what you are trying to do it is hard to give some suggestions as to better solutions.
For example, you may find LocalNotifications as one solution (http://useyourloaf.com/blog/2010/7/31/adding-local-notifications-with-ios-4.html), but again, it depends on what your needs are.
I found that using local notifications to call a REST service, then to process it and decide if I need to inform the user was helpful, as a replacement for how I used Intents in the Android application.
I have an idea to let users translate my application to their own languages.
I imagine this in this way:
If application is not translated to user's system language, English version of UI is displayed and user is asked for help in translation (it's obvious)
Next, user is asked for translate some phrases from English to his mother tongue. And asked to check some others translations. (it's a bit of work, but nothing sophisticated)
Hard part of my idea is:
User presses "update translation" and text resources for this application are update to latest editions.
Of course it's possible to make frequent updates, but this approach has some disadvantages:
1. I have to make all of those updates frequently, and not all of users will be happy with it.
2 Even if updates will be done weekly, time from make effort to get results will be too long form most of users, and probably, response will be not as good as it can be.
Have you any idea how to load translations "on-line"?
Android currently doesn't support this. To accomplish what you want, you'd need to insert your own resource handling code to return strings everywhere they are used in your UI. This means you couldn't let the framework load strings itself (for example no use of android:text="#string/something" in your layouts), and calling your own function to retrieve a string that wraps Resources.getString()/getText().
And you'll also need to deal with the fact that resource IDs are not stable and can change with every build of your app.
So you are looking at something quite non-trivial.
I have done some internationalizations using:
launchpad with android2po
getLocalization
I will first check if they have some kind of api. If there is no API, I would check the gettext's java implementation and handle translations with it.
You could cache any of the current user's translations in a file on the SD/storage, and show it to that specific user. Then, when it gets its weekly update, remove the cached file and start again?
it's been some time now, since I started reading about android.
I've already made a few basic applications, but I still miss something: How is actually sharing application component being done?
This is what the Android Dev Guide says:
A central feature of Android is that one application can make use of elements of other applications (provided those applications permit it). For example, if your application needs to display a scrolling list of images and another application has developed a suitable scroller and made it available to others, you can call upon that scroller to do the work, rather than develop your own. Your application doesn't incorporate the code of the other application or link to it. Rather, it simply starts up that piece of the other application when the need arises.
I think I came across some question like this, but I think I'm still confused.
Is the only way of getting such a 'private application' information to contact the developers of that application?
Is information about the data that the application operates with private, too?
If it is described in the AndroidManifest.xml file is it available for the other applications, or it is available only to Android?
When I started satisfying my interest in Android - one of the things that grabbed me was the impression of immense interoperability...
:)
Have I been wrong or I still haven't found the way?
Thanks!
How is actually sharing application component being done?
That depends entirely on what you consider an "application component" to be, and what you consider "sharing" to be.
This is what the Android Dev Guide says
That is a fairly bad piece of the documentation. Here is how I would write it:
A central feature of Android is that one application can make use of components (e.g., activities, services) of other applications (provided those applications permit it). For example, if your application needs to display a list of contacts and another application has developed an activity that does just that and made it available to others, you can call upon that activity to do the work, rather than develop your own. Your application doesn't incorporate the code of the other application. Rather, it simply starts up that piece of the other application when the need arises.
Is the only way of getting such a 'private application' information to contact the developers of that application?
Either developers are intending for you to integrate with them, or they are not. If they are, they should be documenting how to do that (e.g., Intent formats to be used with startActivity() to trigger their code). If they do not document such integration points, you can certainly ask the developers to add some. However, randomly shooting Intents at them in hopes of getting a response, even if it temporarily works, is little better than script kiddie tactics -- those developers are not obligated to ensure you code works when they upgrade their app.
Is information about the data that the application operates with private, too?
I do not know what "information about the data that the application operates with" means. Data managed by an application is private by default. Again, application developers can offer integration points for data (e.g., content provider, remote service API) -- some do, some do not.
one of the things that grabbed me was the impression of immense interoperability
Android offers greater interoperability potential than some other mobile platforms. However, using that potential requires consent among the interoper-ees. You cannot unilaterally decide to hack into another app's database, or invoke private activities, just because you feel like it.
Should more Android developers offer more integration points? In the abstract, sure. However, bear in mind that this adds support costs (e.g., answering integration questions) and limits coding flexibility (e.g., need to maintain a stable API for those doing the integrating). Developers cannot be blamed if they do not wish to incur all that.
today is not my day i am stuck with this problem
how can i access other application preference screen from my application by specifying in the preference screen layout using intent or something
what is the better or correct way to do so??????
thanks in advance
regards,
kariyachan
As far as I am aware you are not able to access other applications from your own. That would have huge security implications. Why do you need access to another application anyway?
Applications are separated for a reason. If I download two separate apps that do two separate things, I don't want one of them messing with the other in any way (settings, cache, saved files, database, etc).