For iOS and Android apps that are designed with regional/language localization, I want to know: Are all of the different localized strings, etc. downloaded onto the user's device when purchasing from the app store, or is it already optimized for file size, by only downloading those that match the user's regional/language settings at the time of purchase?
If it's the former (everything is downloaded onto the device and then the localization is implemented at runtime), then that will be a big problem for me. My app relies on a very large database of text, which needs to be in the user device's language. Having all of the different language versions at the same time will take up a ton of space. So, that means either I have to: 1) have a monster app file size, or 2) have to release a different instance of the app in each language, neither of which is ideal (though I can live with the second option if I have to). Or is there some other way?
Even though I'm still a long way from release I need to start thinking about this because it will affect the way I organize things going forward.
You have to set it in your app, so i don't think that app thining process takes care of that.
If you have a large base of texts you should consider creating a service for it and fetch texts from that service when needed, based on your device language or a user preference (language menu) if you have it in the app.
Related
i developed an app that contains a lot of activities and different application within the same app and they are all interconnected by sending different intents within it to function the whole app, however they still do different things and i can elimante one without hurting the other and causing the whole app to crash. so if i want i can divide them to be stand alone apps.
My question is this:
Can i have one app that download the basic activities and if a person want a specific activity they can download it (Eg: you download a game and that game includes a different set of levels that can be downloaded by pressing a button hence downloads that particular set of levels.)?
Forgive me if I misunderstood you, but are you talking about creating one big app that consists of many smaller apps, but rather than being all bundled in the beginning, a user can download each one as a module?
If it's this, it's not impossible, but not possible in the sense that I think you're hoping for.
Your one big app will still need all the necessary code and xml files because these need to exist when compiling. But what you can do, which is similar to what games do is to offer downloadable content that isn't code. Essentially, these are resources such as media files, text, or other data of the like.
Those data can be downloaded separately without affecting your app and it helps reduce the size of your app. However, the actual functionality of each individual app will still need to be within your app, but hidden until it's downloaded.
Typically, it's more common to just bundle it all together such as a Measurements app, or to have them as individual standalone apps such as Google Docs, Sheets, and Slides.
You're basically describing how a browser/website works.
If you really wanted to wrap this up as a mobile app, you could use webviews.
I'm working on an app that needs to support a large number of languages. Instead of bundling all languages in the app resources, I want to be able to download the language when the user selects a new language from the settings menu.
The Facebook mobile app does this very well. If you are logged in, go to settings> languages > switch language > pick a different language.
I think Facebook are downloading these language resources, Because if i put my phone into airplane mode , it doesn't work ( prompted with try again, or use english as default).
Since the app resources can't be edited at runtime, i'm guessing Facebook are using a database to download the language , then load the translations from there?!
p.s i'm actually trying to do this in Xamarin...trying to understand the Facebook Android approach so I can implement it myself.
I don't know specifically about Facebook, but I know this technique is in use by some people -- I've seen presentations on similar setups from other companies. There are a couple of obvious benefits:
Reduce overall app size by not bundling 30 languages worth of strings.
The ability to improve localized strings without forcing the user to download an app update.
Better data about what languages your users are using.
When I've seen in presented (again, this was not Facebook specifically), it worked much as you suggested -- user selects the preferred language, app fetches a string bundle from the server, then starts using it. Once the language is set, the app can even periodically refresh the localized string bundle to get updates.
However, there are some downsides to be aware of, especially if the localized strings change over time. It can make support tricky -- if a string has changed, a button (for example) might be called different things depending on exactly when the user was using the app. It also will really put pressure on your i18n strategy and QA to make sure the UI looks decent with strings that might be changing frequently.
If you download localization files you will not be able to use the default localization support within Android.
If you do go ahead with this strategy (downloading of localization files), you will need to create your own class to manage this or alternatively, search for a library which does this for you.
I created a launcher to use my tablet with multiple profiles, it is configurable, I can choose the number of users of the tablet, each one will have its own space, with a list of application chosen by the administrator account from a list view which contains all the applications already installed. this list once selected it will be saved in internal storage space. and the existing menu bar will be changed by the addition of new user. and each will have a new profile configuration file internally, my problem is to update in real-time applications, now, the update is only possible if I restart the application, what is the mechanism in android I can used for growing update my launcher without restarting.
I think this answers your question:
How to force an entire layout View refresh?
I also want to point out that you could use less komma's and make smaller sentences. That makes it clearer for the reader.
I am wondering which name will be better for my app. I am thinking about experiment, which will change name of application (in 10% downloaded apps). Later I could check statistics which app was used more often.
Is this possible?
No. The app name is specified in your manifest so it will be static. You could change the name in the titlebar of the app though.
Picking a good name is key.
depending on exactly what you want you have a few options. You can call
this.setTitle("New Title Here");
from an Activity and this will change the title that appears at the top of the screen just beneath the notification bar. If you are trying to change the title that appears in the launcher, or on the home screen under the icon I don't think you can do this programmatically. You'd have to create two seperate versions of your application and use the different values for < application android:label> inside your manifest for each of them. Or maybe you could create another values folder like values-hdpi if the values folder works the same as the layout and drawable folders (which I suspect it does, but I've never tested.) then it would pull the value from the Strings.xml file inside the hdpi folder if the device has high density display, so you could get a different name for those devices. Maybe using this method you could use a language modifier like values-esp and somehow force the app to go into 'spanish mode' for a certain subset of users so that it pulls this alternate value.
If I understand your question correctly, you want to know if it's possible to test different names on the Android Market, correct?
The only way to do this with the Google Market is to have two separate copies of your app, but using different package names for each. The name that appears in the Market is set on the Developer Console, and while it can be changed, you will not see two different entries for your app in the market.
This is because the market uses your package name to identify your app, not the app name that you supply.
So, while it's easy to change the display name of the app while it is running by using setTitle as #Tim and #Robby have said, this only changes the app title while it is running - it does not affect the name used in the Android package manager, and it also does not affect the name displayed in the Market.
As I say above, if you are wanting to test which name is more popular and therefore results in more downloads, you will need to have multiple apps on the market with different package names. You will also then have to consider how to handle upgrades, and if one name turns out to be very popular, I don't think there's any facility to "upgrade" the other users to your new package name since they are different packages and therefore there is no upgrade path. This means you'll either have to inconvenience users of the old name by somehow asking them to switch to the new app name, or maintain all named versions of your app for the expected lifetime of it.
If you do get your users to switch to the new app, you will then also have to consider how to migrate their data. This can be done (3G watchdog does it when you upgrade from the lite version to pro), but it's an extra layer of complexity that you can avoid.
I am creating an Android application for a customer which will be pre-installed and distributed together with the handsets. Now the customer asked me to lock down the ROM to prevent the future users from using anything else apart from this one app. I.e. no browsing, no email, nothing which could create any costs etc.
Now after some googling it seems to be relatively straightforward to remove applications from an Android image. But even if I can remove the web browser, email client, the Android Market App etc, how can I make sure that the user will not reinstall those apps via the USB connector? As Android is just Linux I am sure there are ways of denying all users the right to install new applications (or actually denying them pretty much anything apart from using this one app).
If somebody could point me in the right direction it would be much appreciated.
EDIT:
To clarify things a bit, the customer does not want to use the android devices as phones, even though they are phones. With 100€ touch screen phones becoming available, it becomes viable to use those phones for just one specific purpose. In my customers case, the device will be used as something like a POS system: the employee uses the phone to process a certain kind of customer request, and for this the app needs to have a data connection which will accrue costs of course. Now obviously contracts can be set up that will oblige employees to pay any irregular costs themselves, but why make it that complicated?
This is not about taking freedom away from users but rather about using android phones as general purpose touch screen devices with a data connection that employees can use in a business environment without shooting themselves in the foot with unexpected high data connection cost.
There's not really a whole lot you need to do to make a single-purpose device. If you play your cards right, it should be something you can do without having to tinker with the ROM.
The quick-and-easy route would be to deploy your application as a replacement for the stock launcher, just like any of the other home replacements that are available. Setting that as the default would cover most of the opportunities for casual tampering, since it would leave no other way to launch or install anything else. The only other things I can think of off the top of my head that you'd need to do are snag the search button so it doesn't bring up the default Android search box atop your app and the green key so the phone app won't come up.
You would, of course, need a way to get to the original launcher to maintain the device and install new versions of your app. I'd accomplish that using a "Maintenance" menu item somewhere that asks for some form of authentication (e.g., a password), changes the home app back to the original and launches it. When you're done doing what you need to do, set your app as the default launcher and you're back in business.
Edit to address MAINERROR (now Octavian Damiean)'s comment:
Any activity in any application can register itself as a home application by adding an intent filter on the android.intent.category.HOME category. It's literally four lines in the manifest, and you don't have to write any code to support it. Take a look at lines 77-82 in the stock launcher's manifest for an example of how this is done. (Ignore the filters on DEFAULT and MONKEY; they're not necessary.) Once the activity is selected as the default handler for the category, it becomes the first thing launched at boot and what comes up when the Home key is pressed. HTC Sense, aHome, Panda Home, etc. all use this mechanism.
Launching the stock home (or any other application) explicitly is about five lines of code.
Side note: There's a application on the Market called Home Switcher that lets you launch any of the activities filtering on the HOME category or set one as the default.
Unless the handset manufacturer adds a lot of shovelware, the stuff that runs in the background should be inconsequential and won't get in the way.
There was a similar question already somewhere. You can indeed limit the functionality of your device by the amount you want or have to. In order to achieve this you will definitely have to build your own modified ROM.
You will have to touch the ROM because you will have to get rid of several applications running in the background. One you won't need them anyway and two as you don't need them they would only consume resources.
You might want to take a look at http://source.android.com there you will find more information about the sources which will hopefully direct you where you need.
Blrfl's answer is great, but it still has a problem: if the user long presses the HOME button, the recent applications popup will appear an the user will be able to launch another app.