In an Android application, I notice that the package name of a class does not have to match the name that was generated when I created the new project. In other areas, Java is insistent that everything matches. I would like to understand why this is not the case for package names, and what the implications are.
Example: I create a new project named TextToSpeech, using my own reverse domain name. This gives a package name of com.lexogram.texttospeech; the path to the MainActivity.java class file is TextToSpeech/app/src/man/java/com.lexogram.texttospeech/.
I now go to a TextToSpeech tutorial and copy-and-paste the code into my project. This code uses com.example.texttospeech as the package name, both in the MainActivity class and in the AndroidManifest.xml. I run the project, and everything works fine.
Does this mean that each activity can use a different package name, so long as the name is used consistently across all files in the activity?
What it means is that your project can have multiple packages inside of it.
Java documentation explains them nicely:
To make types easier to find and use, to avoid naming conflicts, and
to control access, programmers bundle groups of related types into
packages.
Related
I am creating an object of a public library class that uses an object of some package-private class in its code. That package-private class has some malformed logic. Now I want to change the logic. Any idea how to do that other than downloading the library, changing its code and then importing it as a module?
What I have done so far:
I created a new class with the same name by creating a new custom package with the same name.
I mean I created a package at my root folder com.abc.xyz and created a class X in it. But the problem is that my code is still using the old library version of the class X instead of this new one. I checked this by attaching debugger points in my class X. Interesting things is when I'm navigating through Android Studio IDE's code navigation tools, it is showing that my Y class is using my version of X class and not of the library author.
So the second question is that is this technique even possible in Kotlin, if yes then what I'm doing wrong?
I got the above idea by reading the below lines somewhere:
With Java, the encapsulation can be easily broken, because external
code can define classes in the same packages used by your code and
thus get access to your package-private declarations
I'm new to mobile development and Xamarin. I am trying to make an instance of a class which is found in another project under the same solution (HotDog and HotDogDataService). I get the red underline the using saying The type or namespace name 'RaysHotDogs' could not be found.
Why can't I instantiate these classes in this project? The classes are public.
One of your projects is not being build, judging by the error message provided - in one of your layout files, if you look at the xml you probably have invalid property, It's one one of the relative layouts as far as I can see.
No tutorial presents a concrete example of how an internationalization plug-in fragment is created an used. I need translations to the plugin.xml's and source code files. Trying to wrap my head around where the translations go, and where the i18n facade goes.
1. How does that fragment apply to an multi-plugin enterprise application, and more importantly, how do all those plugins externalize their strings inside appropriate folders in the fragment?
2. What about external JARs? How does the mechanism provide translation support for external resources?
3. With the risk of being a long-shot, would it be possible to provide independent translation of a view or perspective? Not necessarily at runtime, because I know bundles can't be dynamically switched.
There is some help available, this article lists the process. It's based on Eclipse 2.0 (!) but the basic ideas are still correct.
An even better article is this tutorial by Vogella
For each plugin you need to translate, you will create one plugin fragment. The fragment is associated to one host plugin, so you need several fragments. Each fragment can contain several languages though. The languages are separated by the folder structure as described in Step 5 in the first article
I am guessing you are referring to non-eclipse Java jars that you have made yourself, yes? If so, that is a completly different process, best suited for a separate question with the Java tag. Oracle has a guide that may help. But keep in mind that you only need to translate the content that the user is exposed to. So a refactor to keep all user visible strings to the Eclipse plugins might be a good idea.
Are you referring to the name of the view/perspective? If so, yes. You can translate the information you give in your plugin.xml aswell. See Vogellas article, chapter 3
Edit:
At nr.3 I was referring to choosing which View to translate (e.g. via a view menu), then restart the app, then only the said view should translate
Well.. I think of a way that would work in theory, but I'm not sure its the best alternative.
So translatation is based on locale. And given the locale a certain translation is chosen. If no appropriate translation exists, a default will be selected.
So if your View menu were to change the locale of the application to, say "us-en-v1", and you only had one view which had a translation for the locale "us-en-v1", that would mean that particular view would be translated, but the rest of the application would use a default (could be that they default back to the closest translation, dont remember exactly).
Then for each view you would create a new translation and use a unique locale for each.
That should work, but it abuses the way translations are supposed to work, so it could lead to issues.
I've done something similar at one time, one app was used in the same language but different customers had different vocabulary. So we used the i18n to make the application use the right terms by defining our own locales.
We are using http://babel.eclipse.org/babel/ to let people translate existing ressources. The build process adds the required language fragments to the artefact. Each plug-in defines its own Messages.properties / Messages.java file.
I guess, you can't do much about external jars.
For instance:
public final class MyMessages {
// a string member as you reference it later in the code
public static String login_window_user_label;
// static initializer which initalizes the fields in this class
static {
NLS.initializeMessages("mymessages", MyMessages.class);
}
}
And (usually in the same package) you have a properties file, in this case,
mymessages.properties
which includes the string:
login_window_user_label = Enter username to login to {0}
And within the code you do:
String userNameLabel = NLS.bind(MyMessages.login_window_user_label, Environment.getName());
Thats how we make our bundles "translatable". The build generates the language fragments and the babel server instance allows the translation.
This is also a design question. I don't know the best way to design having many activities and how to break them up into packages while still accessing the apps resources.
I have an application which allows a user to login and access a tabbed activity which gives access to many modules. If they click a module they will load the module which will in turn contains a tabbed activity.
Currently i have 3 packages within this app:
com.appname.app (many activities i'd like to split up, login, module list etc)
com.appname.app.XML (xml handlers)
com.appname.app.Utils (static util classes etc)
I'd like to add a new package to contain all my modules so something like
com.appname.app.Modules ( or even a seperate package for EACH module)
But i can then no longer access the main apps resources without referring to them with a full package name such as setContentView(com.appname.app.R.layout.channel_list);
Obviously within any com.appname.app activities i just reference the resources such as layouts via setContentView(R.layout.channel_list);.
I'd have thought that a sub package (sub directory) should have access to a parent's resources without having to use com.appname.app.R.layout.channel_list instead of R.layout.channel_list. Which is why i'm assuming something is wrong with my design
The same issue goes for accessing string, drawable etc resources...
Im sure this is something very basic I'm missing. I've tried manually importing the "parent" package and that didn't work either.
is this how i should be doing things? or should i somehow be creating the resource files within each module package? or there another way i should be handling the design/split up of my app?
Since the Android pre-compiler would compile all references to a R.class file and place in in the main package there's no better way than to explicitly import the resources wherever you want to use them
import com.appname.app.R;
so that no full qualifier is needed.
I've developed several Android apps now and have created a code base of classes that I frequently use in more than one app. This code is all in a subversion (svn) repository with each app in its own repository. Each app then has svn:externals references for the needed packages (e.g., com.company.android.views). This works great except in the case when the R class has to be imported for custom attributes.
A custom view has an import like this:
import com.company.apps.myapp.R
so that it can have code like this:
attributes.getBoolean(R.styleable.WebImageView_autoload, autoload)
That custom attribute is defined in res/values/attrs.xml:
<declare-styleable name="WebImageView">
<attr name="autoload" format="boolean" />
...others
</declare-styleable>
This works perfectly, but the problem comes when I have a second app that uses this same view. Now I update the import to import com.company.apps.anotherapp.R so that it will work with "anotherapp" and that breaks it with "myapp." When working on several apps at once, this becomes an issue.
My temporary solution has been to check in an update to the applicable classes and then lock the svn:externals to that specific revision. Each app ends up being locked to a different revision, which gets messy fast, but that still seems better than copying the various classes into the app's repo directly.
The only other solution I've thought of it using reflection, something like:
Class class = Class.forName(context.getPackageName() + ".R");
Field[] fields = class.getDeclaredFields();
And then loop through the fields, assigning the ones I care about to variables that are used throughout the class. This seems rather heavy-handed though, especially when we could be talking about several classes needing to do this.
How can I solve this issue? Is there a way to dynamically import the com.company.apps.*.R or to somehow generate a different R class that doesn't depend on the specific app? Or is there some other obvious (or not so obvious) solution I've totally missed?
Took me a while, but I found a good answer: Library Projects.
Structurally, a library project is similar to a standard Android application project. For example, it includes a manifest file at the project root, as well as src/, res/ and similar directories. The project can contain the same types of source code and resources as a standard Android project, stored in the same way. For example, source code in the library project can access its own resources through its R class.