How do I verify Android internationalization visually? - android

We're facing a upcoming internationalization project for our Android app, expanding significantly on the three currently supported languages. All the languages that we're initially supporting will use existing layouts and are left-to-right, and we are already familiar with language specific setups (separate resource files etc.) as required, so fortunately nothing too exotic is in store for now.
I would like to be able to visually verify that our layouts work and that everything looks OK. Are there any good tools or best practices available for this need? Trying to find resources, I've only been able to identify tools for managing the actual string resources themselves or different platforms for sourcing translations, but nothing that would render them in their actual context for verification.
The only immediate thing that I can think of is to essentially run our test scripts with something like this screenshot lib, and then rinse and repeat for every language we should support. Is there a better, less work intensive and time-consuming (a single testrun times languages supported will probably take at least a few hours on a single device) approach?

Related

multiplatform or android platform alone and desktop alone for Kotlin

i am trying to make a project that is designed for a business and a customer where the business will be on the desktop side and the customer will be on the android side.
i was wondering since both the platforms will have unique UI(tabs/services/actions... etc.) that serves their needs:
should i use Kotlin multiplatform and use as much shared code as possible or build a standalone app that works separately on each platform and then share information by servers?
are there even other ways to accomplish my goal?
so far here are the most important pros and cons of multiplatform:
+reduce time consumed
+ability to share code which reduce bugs and possible errors.
still in alpha version (experimental) which means not enough libraries in support .
to be honest the only thing that is stopping me from choosing multiplatform is the "experimental " warning sign and if i chose to make desktop app alone might as well make android/IOS app altogether( since the sharing code ability between android and IOS is very much reliable) and in that way i would have gained an extra platform for my phone app in return for the added time of development
i really need an answer from any experienced Kotlin developer and thank you in advance :)
What the KMP thought for is sharing business logic between platforms.
If you have different business logic(business/customer sides) not sure how much you’ll be able to share, but the least you can do is data objects: you can share same objects between business/client/server to make sure your json parsing is stable and doesn’t require changes in many places.
You’ll be able to share a lot of stuff if you choose to share android business logic with iOS, but note that there’re some pitfalls you need to learn, so I’d say you’ll spend 2x time for two platforms in first 1-3 month (same time as if you would do for two separate apps), and then your’ll be able to make two apps with average speed of 1.5x time.
Don’t forget that all UI part will take same time as for a separate app, so it won’t be “free”
Still if your project is big enough, it should pay off.
What’s about KMP being experimental: as for me it’s already stable enough and I’m using it in my current project for sharing code between ios/android/server.
It’s in active development phase so most of problems you face will be fixed fast, or you’ll get a workaround on the youtrack
For the JVM part you almost loose nothing: you had to use Native frameworks but if you need to using jvm dependencies in the shared module, you had to provide alternative code for an each other platform(ios, etc) using expect/actual
It has some limitations for iOS platform. The main one, I think, is that you had to work with a specific memory model: you can’t modify objects from different threads, but if you choose your architecture wisely it won’t be a big problem.
I think your decision should depend on how much logic code you need to share between different platforms, and if there's a lot - KMP is a good solution.

Lisp on Android

I'm interested in getting started with Android development and would like to use a Lisp-style language. However, I want something that won't limit me if I choose to write a complex app, so it also needs to have reasonable performance, executable size and startup times. This limits my choices to languages that compile to JVM bytecode that have Android support.
Clojure (Neko)
This would be my first choice because of Clojure's expressiveness, but I have heard that it has problems with slow startup times and poor performance on Android. However, the threads that I came across are quite old so I'd be interested to know if things have improved since then.
Scheme (Kawa)
I came across this option here. Scheme is a nice language, so this option is appealing but it looks like the Android specific libraries it provides may be somewhat minimal. Of course, one could always call the Java libraries from Scheme.
I'd be interested to hear about any experiences with using the above languages (or other lisps for that matter) on Android. Thanks!

Moving an existing app to Android 3.x

I have a published app for Android 1.x and 2.x, and now I want to make it support 3.x.
But Android 3.0 has massive API change, especially on UI, thus if I want to make one app compatible to 2.x and 3.x, the code will be ugly and package file will be huge.
On the other hand, if I make another app for 3.x, then I need to maintain two copies of their common codes. That's really annoying.
What should I choose, or does anyone have a more smart solution? Thanks!
If you package them together you could still maintain everything separately - For example: put a prefix in front of every layout and class for 3.x, such as honeyMain.class, and honeymain.xml
Or you could do it a way that makes more sense for you.
Or keep them partially together.
It WILL make your app larger, but then when 15 people with 3.x download it and 60 people with 2.x download it, you get 75 downloads, instead of 15 for one app and 60 for the other. The 75 cumulative will look better on the apps over all ranking on the market.
On the other hand, if the 3.x is really ugly or FCs, then negative ratings will impact both 2.x and 3.x, but that is easily controlled for by testing, testing, testing.
Also, I personally hate managing code for two different apps. It's overly repetitive.
So, my recommendation is to package them together.
Make use of resource qualifiers, e.g. -xlarge, -v11, etc.
Use reflection where necessary or other techniques to avoid pulling in stuff not supported by API level.
Use the compatability library, that way you can fragmentize your code regardless, avoiding duplication, and with little effort handle different screen sizes.
See providing resources
See multple screens
See compat lib
Right click on your project and select "properties",select "android" from window,and which type of version you want check it and apply

Is there a possibility to use cross-platform-solutions additionally or integrate their api

In the recent weeks I have been busy with the issue of cross-platform development. That starts with the problem that I had the feeding to write a wrapper for the communication-API of MoSync (I don´t knew this SDK and others for cpd before). It should be used in our Java environment for instance to easy create a bluetooth-connection to different phones and so on.
For me the other question is now, how I can use such SDKs like MoSync, Titanium and others in a existing project? In my opinion it is not possible. Either you develop nativ or with a cpd-framework.
I would also be interested in when do you recommend this frameworks (I know already that there are some other threads about this). I personally would say that there isn´t a great future for this SDKs because of technical drawbacks and dependencies. In addition, the market for cross-platform solutions (hybrid, interpreted, cross-compiler) is at least as fragmented as the market for mobile operating systems themselves
What are your experiences?
Martin
Cross-platform implementations of any type, on mobile or anywhere, are primarily to reduce the time to market. That statement may look like oversimplified, but it more or less holds true. So, the ideal situation to use it would be to have an application/game that maybe, uses the common denominator of features across the smartphones, which could include touch, a decent UI, the network, maybe the accelerometer in some cases LBS. So, you land on multiple phones in quicker time and reduced development cost.
If you are looking to utilize a lot of hardware specific features, then we land into what's commonly known as the unknown territories. Then you have to do what people always do, gather more information about the landscape of phones to target and see if the "chosen framework" has the power to dish out the features on those platforms. In this case, you cant possibly deploy one off-the-shelf.

How do you release two versions of an app on the Market?

I would like to add two versions of my app to the Android Market, one for a few cents, and one free version, with ads. That's a very common practice.
I'm currently building AdMod into my app, and it seems I'll have to change quite a few files, so it seems best to make a separate version of my app for this.
How do you achieve that? A branch? A different repository? Has anyone found a way to keep both apps in the same repository in a reasonable manner?
The title is not misspelled, I do mean "realise", i.e. how people manage the two versions, not how they add them to the Market.
This kind of thing is a complete nightmare - unfortunately the Android build system doesn't really support it in any good way.
We do it by having 99% of the code of our application in a library project. We then create one application project for each different version of the app, each of which use that library.
Where we need different versions of the app to behave differently, we currently achieve that by having different resources that are queried at runtime. We are in the process of moving to using Dependency Injection via RoboGuice, however.
There are elements of this that work reasonably well, and others that don't. It's necessary, for example, to duplicate the AndroidManifest.xml file, which can be error-prone (it's easy, for example, to add a new activity to one manifest and forget to do so in the others). It's a mess, unfortunately, but the least-bad solution we've found.
Personally speaking, I would strongly advise against using branches to achieve this effect. They can work well initially, but will rapidly become a maintenance nightmare.
One side benefit of using a library is that we've found that it makes testing considerably easier. For an example of how to set this up, see:
http://www.paulbutcher.com/2010/09/android-library-project-with-tests-step-by-step/
People usually upload them twice(like two different programs) and just modify the title for adding something like Ad-Free, Donate and things like that. And on the free version just add the Free label and also put on the description that it's Ad-Supported.
Here is an example with the SMS Popup application:
For the Android Market, they are considered different programs, but for us it's the same, but one is Ad-Supported and the other isn't.

Categories

Resources