I am working on an android Audio Recording application, our app is currently designed to work on all android phones, the Nexus 7 and the Motorola Xoom tablets.
I was wondering if there are any guidelines or best practices to re-design/modify our app for Nexus 10. More specifically, any pointers on the below points would be really helpful:
UI guidelines to support the new 2560x1600 resolution
Android resource files related modifications (based on similar guidelines)
Any sample or open sources apps that have been modified to work on the nexus 10
Best practices creating and running a nexus 10 emulator since there is no such AVD device by default (screenshot below). Any thoughts on creating one, keeping the high resolution in mind.
As long as you have xhdpi assets, and layouts made for 10" tablets, you shouldn't have to do anything (except add a new xxhdpi launcher icon, as #Mattias mentioned).
To make a Nexus 10 AVD, navigate to Device Definitions:
Then, click New Device. Fill it out something like this:
Now it will be listed in the devices drop-down that you show above.
Regarding your second point, resources:
While the nexus 10 is a xhdpi device, it will use the launcher icon from xxhdpi "one bucket up" if available, so make sure to provide one as it will look much better/clearer/sharper. Reason is that there is room for a bigger icon on this device. Launcher icon size at xxhdpi is 144x144 pixels.
For reference see:
https://plus.google.com/118292708268361843293/posts/ePQya3KsTjW
The best way to emulate the Nexus 10 is to use AndroVM. I am currently running Android on it with the full Nexus 10 2560x1600 resolution and it fits onto my HD screen if I set AndroVM to use 320dpi.
Oh.. and it's VERY fast :-)
I personally use it over emulators and real hardware devices as it's extremely responsive and the deployment of the APK is lightning fast.
I do not contribute to the AndroVM project myself by the way, but it has speeded up my own development cycle considerably. In all development cycles, a developer waiting to see if their code tweaks work using an emulator or a hardware device adds considerable time overhead. I would thoroughly recommend using AndroVM regardless of screen size during normal code development.
Related
I have install flutter and android studio and setup as usual in new laptop running windows 11 pro. But when I start emulator its fonts are not clear, blurred. I tried switching emulated performance from hardware to software, but not works, is any one facing this issue.
My monitor display resolution 1366 * 768 Scale 100%
I used pixel emulator with 1080* 1920 resolution
and Pixel 3a with 1080*2220 resolution
same problem exist with both emulators.
Actually I don't think there would be a solution for that.
Because this problem is related to down scaling emulator window too much.
But you can do one of these:
1- create a new emulator and use a smaller screen size (around 720p). the downside is that you can not create emulator with Google play system images, as they need 1080p phone screen size. you can still use Google Apis images.
2- use a monitor with at least 1080p resolution.
3- use third party emulators like Memu. you can choose any screen resolution in these emulators, and they come with google play. also their performance is much better than Android studio native emulator.
4- use a physical Android phone.
I would first start off with saying sorry If I tagged this in the wrong section. However, I consider this a development question. I'm thinking on getting the Nexus 7 tablet (running Jellybean).
However, Is this tablet any good to develope on? considering the screen size is not HUGE, neither small.
And is there any difference developing on Jellybean?
As I couldn't find any opinions on this anywhere I decided to ask here.
Again, sorry If I'm tagging the wrong things. Feel free to edit!
I think the nexus 7 is a good enough tablet platform for developement. I have tried a few things i made there myself.
You need to consider the screen size and the dpi of the device.
For Nexus 7, it is large screen and tvdpi which is not suitable for mobile apps.
Mostly, mobile device has normal screen with hdpi.
i think one difference at least in older tablets is that theres one less route for the audio (mic)
I made an application under Android emulator provided worked perfectly on all types of dispositives (small, normal, large, xlarge) (-ldpi,-mdpi, -hdpi,-xhdpi). But the last few days I saw that in some phones with the latest versions of android (these phones consist with a lower bar like tablets) did not look properly.
So my question is: what kind of phones have or can upgrade to these versions of android? (small-HDPI, normal-HDPI, normal-xhdpi???)
Thank you!
Theoretically, nothing stops a manufacturer from making an ldpi device capable of running ICS or JB. However, in practice, most devices with ldpi and even mdpi to some extent do not have good enough processors in both CPU and GPU departments to be able to run the newer version of Android.
Till date, the lowest I've seen an ICS device go screenwise is a normal-mdpi display. However, I do not know the details of every device in existence, and there could be lower devices as well.
You should design your app keeping in mind all device configs, at most excluding only ldpi and small displays.
I encountered a weird behaviour when starting to test my app on some 7in Android models and I would like to find out if others are finding the same problem and what people recommend as a fix.
Here are the details:
The application has full tablet support, which is triggered with qualifiers for the layouts. xlarge devices get the tablet mode with multiple fragments being displayed on the screen.
For newer Android versions there are also some values that set variable that change the UI on the flow using the sw600dp qualifier as well as the xlarge one.
The problem:
I am now testing on the Kindle Fire and the RIM BlackBerry Playbook and also want to support the upcoming Google Nexus Tablet (or whatever it will be called) and other 7in form factor devices.
Both the playbook as well as the fire have a 7in screen and a 1024x600 screen resolution.
However the playbook seems to trick Android into thinking it is a xlarge device, while the fire does not do that.
Both the tablet as well as the standard UI work fine, but imho the tablet mode is nicer and is fine to be used on the 7in device. However if I push the layout into the large qualifier to also get that tablet mode on the fire I will also get it e.g. on the Note or other quite a bit smaller devices.
With Android 4x I can use the sw600dp and other qualifiers but what about older versions? I assume a 7in device is supposed to behave like a tablet but what about e.g. the Note..
What are best practices for this scenario? Are my observations with the playbook reporting xlarge correct?
However the playbook seems to trick Android into thinking it is a xlarge device, while the fire does not do that.
Device manufacturers are the ones who choose which buckets a device goes in with respect to size and density. This goes double for manufacturers like RIM and Amazon, who do not want the Play Store and therefore do not have to abide by any particular compatibility requirements the Play Store dictates, so they are welcome to thumb their noses at Google's guidance.
What are best practices for this scenario?
I can't tell you "best".
However, if there are specific devices for which you wish to override some layouts to use a specific size, here's what I would try (assuming the layout you would be using for normal cases is known as R.layout.main):
Step #1: Create res/layout/main_funky.xml as a symlink or hardlink to res/layout-xlarge/main.xml (and likewise for -land, etc.).
Step #2: In your Java code, wherever you refer to R.layout.main (e.g., onCreateView() of a Fragment), decide whether to load R.layout.main or R.layout.main_funky depending upon android.os.Build data to detect these oddball devices by model. Since R.layout.main_funky is one of your normal main layouts, all of your code that depends upon widgets should be unaffected by this choice.
Step #3: In your particular case, add MMPD (magic Maven pixie dust) to steps #1 and #2... :-)
Are my observations with the playbook reporting xlarge correct?
I bought a Playbook, determined that RIM's distribution model is... unpleasant, and did the bare minimum to have a book chapter on it. I haven't tried to see if it is -large, -xlarge, or something else.
That being said, the NOOK Tablet IIRC suffers from this (claiming to be -xlarge rather than -large).
I would expect a Google Nexus tablet, if such a thing comes to fruition, to correctly honor size buckets, plus be running a new enough Android version that -sw600dp and kin will work.
I want to begin development for mobile and android seems like a good choice (with iphone requiring a mac and WP7 not being that popular).
I have a question regarding the testing platform, I'm pretty low on cash and have been wondering if using a mid range phone would hinder my development? I have the ability to buy either a LG Optimus One, a Motorola Milestone or a Nexus One, all representing different segments of the market and each one costing more than the previous.
two concerns I had were screen resolution and CPU power, how much does these two variables matter to development?
Well:
Resolution - there are 3 main groups:
ldpi - Low Density - devices with screens 240 x 320,
mdpi - Medium Density - 320 x 480,
hdpi - High Density - 480 x 800, or 480 x 854.
Of course the bigger screen == the more expensive phone.
2 . CPU power - all currently available CPUs (besides a few low-end phones) will propably serve you well (of course, it depends on what do you really want to do)
I, as a developer, would like to add here a third element - which API level (version of Android) are you targeting? Nowadays, 2.1 - 2.3 rocks, and 3+ if the device is a tablet.
Keep in mind, that if you buy a great phone, you may develop application which will be running quite fast on it, but it will not on other low-end devices. Btw, you can always check if all elements will properly layout on the lower screen using built-in emulator(s). So, in my opinion, there is good to have mid-end phone, just to check sth(s).
PS : Nexus one - AFAIK this phone is a debug version (means you can do a little more than with a standard retail phone :) ).
If you can buy a Nexus One that will serve perfectly. Obviously it doesn't cover every form factor but its BETTER than a midrange phone.
If you come across issues on a specfic device you can always use a cloud debugging service like:
http://www.perfectomobile.com/ (they used to have 2 hours free when you register)
You can emulate the different screen sizes
CPU power depends completely on what you are coding, but most the time you should be ok.
Me Personally I've got:
a Nexus One running 2.3
a HTC G1 running 1.6 (flip out keyboard formfactor)
I also use perfecto for issues with the SonyErricson X10mini (ldpi)
I emulate Honeycomb 3.0 on the PC (altho hoping to buy a XOOM soon).
Putting on my MBA hat: From a product development perspective it's probably a good idea to make sure your product runs on the widest product segment of whatever platform you're developing for. If that happens to be a mid-range product, your development efforts are probably aimed at the largest market segment and potential customers might be more likely to own/purchase this device. Even better if there's a common platform across all segments. You should probably perform some sort of market analysis to prove this out.